On Thu, 2013-09-12 at 10:56 +0000, Gupta, Pekon wrote: > > 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. Right. The issue here is that the LUT is currently *pre-populated*, with an incestuously-"known" set of commands that the slave is expected to support. For each "known" command, at controller init time we pick an index in the LUT, then pre-configure that index to send the command in question. Then when we're asked to actually *do* a transaction, we hope that it's one of the "known" ones, look up the right index to use, and just trigger the transaction. We shouldn't have that horrid incestuous preconfiguration. When we get an actual request for a transfer, we should find an unused slot in the LUT, *write* the appropriate values for the transaction we're being asked to make, then trigger it. Obviously the immediate optimisation is to be able to *reuse* LUT configuration so you're not writing to the LUT over and over again for the *same* transactions, but let's not overcomplicate things to start with. I certainly don't see why we should have the controller knowing in advance what the commands will be. (Although hey - if you want to *guess* and prepopulate the LUT with the most likely options at init time, that would be fine. As long as you can cope with then being asked to send something unexpected, and rewrite the LUT as needed.) -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
