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

[Heiner Kallweit]

Am 06.06.2016 um 21:40 schrieb Michal Suchanek:
> On 6 June 2016 at 20:53, Heiner Kallweit <hkallweit1 at gmail.com> wrote:
>> Am 06.06.2016 um 19:40 schrieb Mark Brown:
>>> On Sat, Jun 04, 2016 at 12:22:37AM +0200, Heiner Kallweit wrote:
>>>
>>> Please fix your mail client to word wrap within paragraphs at
>>> something substantially less than 80 columns.  Doing this makes your
>>> messages much easier to read and reply to.
>>>
>>>> Am 06.05.2016 um 14:14 schrieb Mark Brown:
>>>
>>>>> Yes, it's called the maximum transfer size because it is the
>>>>> maximum size of a transfer, not because it's the maximum size of
>>>>> a message.
>>>
>>>> I'd like to come back to this discussion. You said best would be
>>>> to fix the chip driver. To do this and calculate an appropriate
>>>> value for max_transfer_size the chip driver would have to know that
>>>> the spi_device is a spi-nor device.
>>>
>>> That doesn't make any sense, the controller hardware doesn't
>>> magically change based on what is connected to it.
>>>
>> The issue with fsl-espi is that the controller deactivates CS after
>> each physical transfer. And a lot of HW designs use the hardware CS,
>> therefore the advise to use a GPIO instead doesn't really help.
>>
>> If deactivating and reactivating CS between two transfers doesn't
>> affect the functionality of a spi device then we can go with the
>> full max transfer size.
>>
>> In case of SPI NOR CS needs to stay active between command and data
>> read. Therefore the two transfers in the m25p80 read SPI message need
>> to be combined to one physical transfer by the controller driver.
>> Result is that the max read size is effectively reduced by the length
>> of the m25p80 read command.
> 
> Which is what the dummy bytes are used for AFAIK.
> They are received while you are sending the command and white the
> flash is getting ready to send data and after the transfer are deducted
> from the received data in m25p80.
> 
Thanks for the feedback.
The dummy bytes are inserted *after* the read command.
Therefore in the low speed modes usually no dummy bytes are needed.

> If this does not work for fsl-espi for some reason it should be corrected.
> I am working with a controller that can transfer 63 bytes at once and
> I am quite positive it does not do any magic transfer coalescing.
> Still it can read a 4Mbyte flash chip.
> 
> However, spi-sun4 implements transfer_one and fsl-espi implements
> transfer_one_message so the different interface may work out differently.
> 
> Indeed, the spi.c transfer_one_message calls set_cs and then calls
> transfer_one repeatedly which is exactly what fsl-espi cannot do due to
> automagic CS handling. So the fsl-espi limit is probably on message size.
> 
> Maybe adding another quirk the m25p80 driver can query to know to deduct
> the command size from the maximum data size would resolve both cases.
> 
> Thanks
> 
> Michal
>