Re: [PATCH v3 0/8] Add the Quadspi driver for vf610-twr

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]