[PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands

[Marek Vasut]

On 06/23/2016 11:58 PM, Michal Suchanek wrote:
> On 23 June 2016 at 22:46, Marek Vasut <marex at denx.de> wrote:
>> On 06/23/2016 10:35 PM, Michal Suchanek wrote:
>>> Hello,
>>
>> Hi,
>>
>>> this patch is kind of awesome.
>>>
>>> I have a few practical concerns however.
>>>
>>> On 20 June 2016 at 18:50, Cyrille Pitchen <cyrille.pitchen at atmel.com> wrote:
>>>> Before this patch, m25p80_read() supported few SPI protocols:
>>>> - regular SPI 1-1-1
>>>> - SPI Dual Output 1-1-2
>>>> - SPI Quad Output 1-1-4
>>>> On the other hand, all other m25p80_*() hooks only supported SPI 1-1-1.
>>>
>>> Under typical use my estimate is that huge majority of data is
>>> transferred in _read() seconded by _write().
>>>
>>> As I understand it the n-n-n means how many bits you transfer in
>>> parallel when sending command-address-data.
>>>
>>> In _read() the command and data overhead is negligible when you can
>>> read kilobytes at once. So difference between 1-1-4 and 4-4-4 is not
>>> meaningful performance-wise. Are there flash chips that support one
>>> but not the other?
>>
>> That's quite unlikely.
>>
>>> For _write() the benefits are even harder to assess.
>>
>> The page program usually works on 256B pages, so the math is rather easy.
>>
>>> You can
>>> presumably write at n-n-4 or n-n-2 if your controller and flash
>>> supports it transferring the page faster. And then spend possibly
>>> large amount of time waiting for the flash to get ready again. If the
>>> programming time is fixed transferring the page faster may or may not
>>> have benefits. It may at least free the bus for other devices to use.
>>>
>>> The _reg_ stuff is probably negligible altogether,
>>>
>>> Lastly the faster transfers of address bytes seem to be achieved with
>>> increasingly longer command codes given how much the maximum command
>>> length increased. So even in a page write where the address is a few %
>>> of the transfer the benefit of these extra modes is dubious.
>>>
>>> Overall I wonder how much it is worthwhile to complicate the code to
>>> get all these modes in every single function.
>>
>> In my opinion, 1-1-x makes sense as it is supported by most flashes,
>> while n-m-x where n,m>1 does not make sense as it often requires some
>> stateful change to non-volatile register with little gain.
>>
> 
> There is actually one thing that x-x-x modes make easier. If I were to
> implement dual mode switch on my SPI master controller it would be
> probably set for whole message and would not change mid-transfer.

Your IP would not sell as customers would like to use it with SPI
flashes which can only do 1-1-x modes. These flashes are on the market,
today, and thus used and thus you have to support them if you want to
make profit.

In fact, the SPI flash starts in 1-1-1 mode anyway, thus you need to
support that mode. To support other modes, you need to implement simple
switch in the hardware which either shifts out a bit a time, two bits on
two lines at a time or whatever else ; selecting which one it is must be
done synchronous to input clock and on a byte boundary, which is trivial
to implement in hardware.

> Still you can probably simulate x-x-x with 1-1-x by scattering the
> 1-1-x command bits across more bytes.

That's not how you usually implement it. It's quite often a shift register.

> Thanks
> 
> Michal
> 


-- 
Best regards,
Marek Vasut