[GIT PULL] mtd: spi-nor: Changes for 4.11

[Heiner Kallweit]

Am 08.02.2017 um 20:40 schrieb Michal Suchanek:
> On 8 February 2017 at 20:09, Brian Norris <computersforpeace at gmail.com> wrote:
>> + Mark, as the disagreement touches his area
>>
>> Hi,
>>
>> On Wed, Feb 08, 2017 at 11:36:10AM +0100, Cyrille Pitchen wrote:
>>> Le 08/02/2017 à 06:52, Heiner Kallweit a écrit :
>>>> Am 08.02.2017 um 02:09 schrieb Marek Vasut:
>>>>> On 02/07/2017 04:31 PM, Cyrille Pitchen wrote:
>>> [...]
>>>>>> Heiner Kallweit (1):
>>>>>>       mtd: m25p80: consider max message size in m25p80_read
> [...]
>> One example that shows both sides of this coin:
>>
>> 5185a81c02d4 "spi: rockchip: limit transfers to (64K - 1) bytes"
>>
>> The hardware has a hard limit on transfers, at least, which can only be
>> 64K. For some reason there's an off-by-one error (probably a driver
>> bug?), so I cheated and made it one smaller.
>>
>> [...]
>>
>> (snip the rest about trying to split spi_messages within the SPI driver;
>> I agree that would be awful.)
>>
>> But one question: *why* exactly is the transfer or message limit so
>> fixed? If a SPI controller allows manual control over the CS line, then
>> why would anybody care if a sequence of data gets split up into multiple
>> HW sequences (e.g., for a long spi_transfer, why can't we split it into
>> 2 sub-transfers, while keeping the CS asserted?).
>>
>> For the above rockchip SPI controller, AIUI we could actually support
>> the "transfer limit" by doing this. And in fact, it could probably be
>> done within the SPI core code, instead either the SPI driver or the MTD
>> driver.
> 
> Yes, this is something repeatedly open-coded in SPI drivers, unfortunately.
> 
> In this case limiting the transfer size to 64k rather than doing
> another clone of the manual CS handling actually looks reasonable.
> It's not like anything but mtd_debug normally triggers that limit.
> 
>>
>> Now, in this case, *transfer* vs. *message* seems to have a difference,
>> in whether or not you have guarantees about the CS line. The CS must
>> stay asserted (barring the 'cs_change' flag) between transfers, but not
>> between messages.
>>
>> So the one thing I can see that might support Marek's disagreement here:
>> does the FSL ESPI hardware support controlling the CS line? It seems
>> like currently, the driver just uses a few fixed settings for its CSMODE
>> register fields, whereas it might be able to support ->transfer_one()
>> (and flexible CS assertion, and splitting large transactions into
>> smaller chunks) if you handled that differently...
> 
> It was argued that while this is the case with most SPI controllers it
> is not the case with FSL ESPI. I do not recall anybody producing any
> datasheet/manual supporting this, though. It's not like this is a
> confidential piece of hardware, right?
> 

The datasheet (here called Reference Manual) is available on the NXP
(ex Freescale) website, you just have to register.

http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/p-series/qoriq-p1010-and-p1014-low-power-communications-processors-with-trust-architecture:P1010?tab=Documentation_Tab

> Thanks
> 
> Michal
>