Messages in this thread | | | Date | Fri, 24 Jun 2016 00:14:15 +0200 | From | Marek Vasut <> | Subject | Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands |
| |
On 06/23/2016 11:58 PM, Michal Suchanek wrote: > 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.
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
| |