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

[Marek Vasut]

On 06/24/2016 12:43 AM, Michal Suchanek wrote:
> On 24 June 2016 at 00:14, Marek Vasut <marex at denx.de> wrote:
>> 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.
>>
> 
>>
>>> 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.
>>
> 
> Checking the manual there is a bit in a register that switches the
> master controller to dual mode receive (only). So the master
> controller can do 1-1-2 read (only). I don't use that feature because
> afaict there is no code in m25p80 which does the switch and as pointed
> out the reg_read commands are done in 1-1-1.

I don't think I understand. Are you talking about some specific
controller now ?

> If there was similar bit for write you could do 2-2-2 write but any
> other option would be quite challenging.
> 
> Thanks
> 
> Michal
> 


-- 
Best regards,
Marek Vasut