Messages in this thread | | | Date | Thu, 17 Mar 2022 15:53:32 +0530 | Subject | Re: [PATCH v2 0/6] spi-mem: Allow specifying the byte order in DTR mode | From | Vignesh Raghavendra <> |
| |
On 17/03/22 3:44 pm, David Laight wrote: > From: Michael Walle >> Sent: 17 March 2022 09:40 >> >> Am 2022-03-16 14:55, schrieb David Laight: >>> Thought... >> >> Thank you for your proposal. >> >>> Can you read the device in STR mode until you get a suitable >>> non-palindromic value, then read it in DTR mode and dynamically >>> determine the byte order? >>> >>> Clearly this won't work if the device is erased to all 0xff. >>> But a check could be done on/after the first write. >>> >>> I suspect write times are actually dominated by the time spent >>> waiting for the write to complete? >>> (Never mind the earlier block erase time.) >>> So always writing in STR mode probably makes little difference? >>> Writes really ought to be uncommon as well. >>> >>> Speeding up reads is a different matter - and probably useful. >>> >>> Of course, if you've got hardware reading the spi memory in DTR >>> mode for config data you might need to byteswap it (compared >>> to the STR writes) - but that is probably a 2nd order problem. >>> >>> I've got some bespoke logic on an PCIe fpga for accessing spi memory. >>> Uses address bits for the control signals and converts a 32bit >>> read/write into 8 nibble transfers to the chip. >>> (uses byte enables - don't an odd number of clocks.) >>> mmapp()ed to userspace for updating the 6MB fpga image. >> >> Our problem is not how to detect that we have to swap it, but >> rather what we do when we have to do it. >> >> If we have a controller which can swap the bytes for us on the >> fly, we are lucky and can enable swapping if we need it. We are >> also lucky when we don't have to swap the flash contents, obviously. >> >> But what do we do when we need to swap it and the controller >> doesn't support it. We could do it in software which will slow >> things down. So depending on the use case this might or might not >> work. We can degrade it to a speed which doesn't have this issue; >> which might be 1-1-1 in the worst case. We could also do just >> nothing special; but this will lead to inconsistencies between >> reading in 1-1-1 and 8d-8d-8d. > > I really doubt you'll notice the effects of a software byteswap > compared to the actual time taken to do an spi read. > > What's the maximum clock rate for spi memory? > Something like 50MHz ?
We have Octal SPI flashes running at upwards of 200MHz clock (400MB/s) so SW byteswap will add significant overhead.
> If the spi controller isn't doing dma then the cpu pio reads > to get the data are very likely to be even slower than that. > (Especially if they are PCIe reads.) >
Modern OSPI/QSPI flash controllers provide MMIO interface to read from flash where DMA can pull data as if though you are reading from On chip RAM
Regards Vignesh
| |