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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux