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

[Michal Suchanek <hramrach@xxxxxxxxx>]

On 6 June 2016 at 20:53, Heiner Kallweit <hkallweit1@xxxxxxxxx> 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.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html