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

[Mark Brown]

On Thu, Sep 12, 2013 at 03:03:16PM +0100, David Woodhouse wrote:

> Not so in this case. The controller driver appears "know", in advance,
> what commands are going to be sent. It preloads its buffers (the LUT)
> with what it *expects* us to send, and when we make a request it'll just
> trigger a send from the appropriate buffer. And it will crap itself if
> we actually try to send anything *different*.

> Or so I understand it.

Yes, that was pretty much my understanding of what was going on here -
clearly the way the driver is currently figuring out what the commands
are isn't good enough.

> So to go back to your question: the commands that it "knows" we are
> going to send are indeed specific to (one particular type of) SPI NOR
> flash. But there's nothing on the MTD side which justifies that
> assumption. Even if you use a different type of SPI NOR flash which uses
> different opcodes for its commands, this broken scheme will fall over.

Right, the specific opcodes do need to variable at least and should be
being provided by the driver for the flash - but is the generic format
of the commands and requirement to send them abstractable?  Given that
it's apparently been baked into hardware and based on having a quick
scan through drivers/mtd/devices I'd guess so but...

> Unless, as I say, I've completely misunderstood what's going on here.
> Huang?

...like you say some clarity would be good.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130912/9fedf9a8/attachment.sig>