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:
smime.p7s
Description: S/MIME cryptographic signature
