Messages in this thread | | | From | Michal Suchanek <> | Date | Thu, 23 Jun 2016 23:58:51 +0200 | Subject | Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands |
| |
On 23 June 2016 at 22:46, Marek Vasut <marex@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@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.
Thanks
Michal
| |