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

[David Woodhouse <dwmw2@infradead.org>]

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

On Wed, 2013-09-11 at 18:54 +0800, Huang Shijie wrote:
> 于 2013年09月11日 18:41, Mark Brown 写道:
> > So why does the SPI driver have references to the opcodes in it?
> I admit that the Freescale's quadspi controller is very special
> (it is designed too coupled with the SPI Nor FLASH),
> it is driven by the LUT registers.
> 
> I just quote the comment from the patch 1:

That didn't really answer the question, for me. I'm still not entirely
clear what's going on.

What *actually* happens, on the wire(s), when the flash driver asks the
SPI controller to perform a transaction?

Why can't the flash driver *provide* the required information?

So far I seem to have got it into my head that we have a SPI controller
which is connected to more than one device, and we can't send commands
to one without sending to the other... and that means that we have to
send a *NOP* to the "unwanted" device. Is that right?

The LUT registers just seem to be a controller-specific implementation
detail which doesn't really explain the fundamental issue.

It does sound like the general case should ideally be solved by the
driver for the *device* telling the SPI controller what to send as a
'NOP' command, if it really has to send something on this channel when
we didn't ask it to.


But since we don't actually *probe* SPI devices (do we?) and we rely on
them being enumerated in the device-tree or manually 'added' by other
methods, perhaps putting the NOP command into the device tree is the
better approach. At least it solves the issue of what to use as the NOP
command when the m25p80 driver is probing the first of the two chips,
before it's *tried* to identify the second.

Or have I completely missed the point here, somewhere?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]