On 24 June 2016 at 00:50, Marek Vasut <[email protected]> wrote: > On 06/24/2016 12:43 AM, Michal Suchanek wrote: >> On 24 June 2016 at 00:14, Marek Vasut <[email protected]> wrote: >>> On 06/23/2016 11:58 PM, Michal Suchanek wrote: >>>> On 23 June 2016 at 22:46, Marek Vasut <[email protected]> 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 <[email protected]> >>>>>> 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 ? >
Yes, the sunxi spi controller can do dual read according to manual but not sure if anyone has tired that, At least the A31 variant can. Thanks Michal
