Messages in this thread | | | Date | Fri, 24 Jun 2016 00:50:28 +0200 | From | Marek Vasut <> | Subject | Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands |
| |
On 06/24/2016 12:43 AM, Michal Suchanek wrote: > On 24 June 2016 at 00:14, Marek Vasut <marex@denx.de> wrote: >> 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. >> > >> >>> 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
| |