[PATCH 2/2] mtd: m25p80: consider max_transfer_size when reading

[Heiner Kallweit]

Am 07.06.2016 um 10:10 schrieb Michal Suchanek:
> On 7 June 2016 at 08:03, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>> Am 07.06.2016 um 01:07 schrieb Mark Brown:
>>> On Mon, Jun 06, 2016 at 08:53:10PM +0200, Heiner Kallweit wrote:
>>>> Am 06.06.2016 um 19:40 schrieb Mark Brown:
> 
>>>> Well, we could reduce the max_transfer_size exposed by the driver by
>>>> the max length of a m25p80 read command in general.
>>>
>>> No!  Apart from anything else this would be a complete and total
>>> abstraction failure.  This is a driver for a SPI controller, not a
>>> driver for a flash controller, which means that it should not have flash
>>> specific hacks in it.
>>>
>>>> Then we might be too strict for other SPI devices, but this may
>>>> be acceptable as the current fsl-espi driver is usable with SPI NOR
>>>> devices only anyway.
>>>
>>> What makes you say this?  I'm guessing that the driver is just broken
>>> but it would be good to understand the specifics.
>>>
>> See fsl_espi_rw_trans():
>> In case of transfers > SPCOM_TRANLEN_MAX it loops and reads in
>> SPCOM_TRANLEN_MAX chunks whilst replacing bytes 2-4 of the
>> message buffer with the new start address to read from.
> 
> That's obviously bogus. Just reject anything too large and let the
> upper layer deal with it.
> 
So far the upper layer wasn't able to deal with it. Now, with the recent
change set initiated by you, we can clean up the driver a little.
This was also the motivation to involve myself in getting this upper
layer functionality into the mtd code.

> Given m25p80 and fbtft would handle this can you use DMA to gather
> buffers from multiple transfers (ie command and data) or does the
> buffer have to be copied together for the transfer?
> 
The fsl-espi controller doesn't support DMA.
The driver copies all transfers to a local buffer.

There's just one nice feature of this controller: It supports a
flash-read-optimized transfer mode, where you can configure:
- first write x bytes
- then read y bytes in either single or dual mode
In tests with a modified driver the dual mode worked quite well.
But that's something for a future extension.

> Thanks
> 
> Michal
>