On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote: > 1.Write to flash config register via config port to switch to QUAD MODE > (or any mode that flash supports). > 2. Populate QSPI_SPI_SETUP_REGx with flash read command, number of > address bytes to use and dummy bytes required. These things being constant for a given flash? > 3. Switch to memory mapped port by writing to QSPI_SPI_SWITCH_REG. > 4. Now, its possible to perform read from 0x5C000000 to 0x5FFFFFFF using > memcpy. The qspi controller hardware will communicate over SPI bus and > get the data. This data is directly sent to RAM via SoC's interconnect. Presumably if it's done via memcpy() it won't go direct to RAM but rather be bounced through the CPU which is a bit interesting for performance (it might help, but it does mean that there's a core stalled waiting for the flash which might not be the best use of resources if there's other things it can be getting on with). With DMA it'd be a direct to memory transfer though. > Advantages of memory mapped port are: improved read performance, > MEM_TO_MEM DMA support can be added (ti-qspi hardware as such does not > provide DMA events). DMA would definitely help here. > I just need to know whether the user that requested the transfer is > m25p80 driver. If yes, ti-qspi driver can take advantage of memory > mapped interface, else just use config port to access SPI bus directly. You don't *really* care if it's that specific user so much as that it's that particular pattern. > Writing separate driver based on spi-nor framework to interface with > m25p80 is not an option because, I would lose the ability to interface > with non-flash devices. You could, however, expose an explicit flash mapping interface for this functionality. That does seem like it's going to be an awful lot easier and help with keeping things like DMA support out of the driver and in the core (which would be useful if there's other controllers with the same functionality, I seem to recall that there are). > The spi_message that is received in transfer_one_message() is too > generic to imply the slave device that is on the other side of the wire. > IMO, the read command does not imply that the slave is m25p80 flash > (besides the read opcodes vary across vendors of m25p80 and across modes). Again, it doesn't matter if it's actually a read command only that it's got a compatible format on the bus.
Attachment:
signature.asc
Description: Digital signature
