[U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash

Vignesh Raghavendra vigneshr at ti.com
Fri Oct 18 09:48:43 UTC 2019

On 18/10/19 7:52 AM, Simon Glass wrote:
> Hi,
> On Thu, 17 Oct 2019 at 08:28, Simon Glass <sjg at chromium.org> wrote:
>> Hi Vignesh,
>> On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra <vigneshr at ti.com> wrote:
>>> Hi Simon,
>>> On 12/10/19 10:03 AM, Bin Meng wrote:
>>>> Hi Simon,
>>>> On Sat, Oct 12, 2019 at 11:08 AM Simon Glass <sjg at chromium.org> wrote:
>>>>> Hi Bin,
>>>>> On Wed, 9 Oct 2019 at 07:55, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass <sjg at chromium.org> wrote:
>>>>>>> On x86 platforms the SPI flash can be mapped into memory so that the
>>>>>>> contents can be read with normal memory accesses.
>>>>>>> Add a new SPI flash method to find the location of the SPI flash in
>>>>>>> memory. This differs from the existing device-tree "memory-map" mechanism
>>>>>>> in that the location can be discovered at run-time.
>>> Whats is the usecase? Why can't spi_flash_read() be used instead?
>>> Flash + Controller driver can underneath take care of using memory
>>> mapped mode to read data from flash right while making sure that access
>>> is within valid window?
>> I can see spi_flash_read_dm() but it does not support returning a
>> pointer to the data, only reading it.

No, I was merely suggesting to use spi_flash_read_dm() (which underneath
can be implemented by spi_mem_ops) to get data from flash instead of
using get_mmap() to get MMIO pointer and then reading the data using
that potiner.

>> Also I cannot find any documentation about any of this. I've been
>> looking in the doc/ directory.
>> I found the spi_mem.h file but it doesn't mention the meaning of the
>> in and out buffer pointers so I don't know how to use them.
>> Is there an API missing or just comments/documentation?

spi-mem.h has struct and APIs documented as kerneldoc:

Note that clients should still use spi_flash_*() APIs to interact with
flash. spi_mem_ops are not an alternative to spi_flash_*() APIs which
are used by other drivers to read/write data from/to flash. This
continues to be the same.

> Apart from this I have found that the ich_spi driver does not work for
> APL since it apparently only supports 'hardware sequencing'. I did try
> getting software sequencing to work, but no dice.
> In addition, I found that enabling SPI flash, etc. added about 6KB of code!
> So I think it might be best to have two SPI drivers for x86 - one for
> software sequencing and one for hardware?
> Regards,
> Simon


More information about the U-Boot mailing list