> > > Indeed - what I was wondering was if those opcodes could be requested > > > from the flash driver rather than coded in there. The driver needs to > > > write the commands to the device but it's not clear to me if it really > > > needs to know the specific commands. > > yes. The driver uses the commands to find the _right_ LUT index, and > > uses the LUT index to > > trigger the controller. > > > > For example, LUT0-LUT3 is used for the READ_STATUS, the driver will > > match the > > 0 index for the NOR's read status operation (0x05), and then the driver > > write 0 to the QSPI_IPCR > > register to trigger the operation. > > But why? > > Your SPI controller's device driver gets a spi_transfer struct which > (indirectly) comes from the m25p80 *chip* driver. That should contain > appropriate values for tx_nbits and rx_nbits to indicate the mode which > its to be used for this particular command. > > All you need to do then is pick a suitable slot in the LUT table, *fill* > the LUTn-LUN(n+3) registers with appropriate values, then write (n/4) to > the QSPI_IPCR register. Or something like that? (Can you provide a URL > for the datasheet for this controller?) > > And if this is a command/nbits combination which has recently been used, > of course you can skip the 'write the LUT registers' step and just use > the same index you used last time. Add some LRU scheme to handle > *which* > index you use... handwave... > Agree.. A minor update is required in m25p80_read() for different types of reads. For taking examples mentioned earlier: @@m25p80_read() > > the read status only use a single line t[0].tx_buf = flash->command; /* read_opcode */ t[0].len = m25p_cmdsz(flash) + (flash->fast_read ? 1 : 0); + t[0].tx_nbits = SPI_NBITS_SINGLE; /* use single wire for this transfer */ > > , while the quad read uses 4 lines. t[0].tx_buf = flash->command; /* read_opcode */ t[0].len = m25p_cmdsz(flash) + (flash->fast_read ? 1 : 0); + t[0].tx_nbits = SPI_NBITS_QUAD; /* use single wire for this transfer */ 'tx_nbits' and 'rx_nbits' are new fields added in struct *spi_transfer for this purpose only. Please refer below patch http://lists.infradead.org/pipermail/linux-mtd/2013-August/047995.html So, this way master-driver (here mtd/../m25p80.c) can pass the info to slave-driver (here spi/../qspi-controller.c), on how to send flash specific commands and opcodes, by embedding that info in spi_transfer. And when the spi_transfer reaches spi/.../qspi-controller.c driver, then you can populate your LUT with info present in spi_transfer. And initiate the actual transfer on SPI bus. Am I missing something here ? (David please correct me if I'm wrong in above explanation) with regards, pekon ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
