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

[Heiner Kallweit <hkallweit1@xxxxxxxxx>]

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.

Well, we could reduce the max_transfer_size exposed by the driver by
the max length of a m25p80 read command in general.
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.
--
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