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, 2013-09-12 at 14:43 +0100, Mark Brown wrote:
> 
> > I only know what's in the patch that you have also received, but it
> > seems to be a table of commands. To send a given command to the flash,
> > you write the actual command to the some slot in the LUT, then 'trigger'
> > it by writing its index to another register.
> 
> OK, so the LUT itself isn't a generic mtd thing, though the commands
> it's apparently sending are?

Kind of.

Imagine you have a controller with a set of SRAM buffers for transmit
data.

One might normally imagine that when you get a request to make a
transaction, you'd load the data-to-be-sent into one of the buffers,
then trigger a "send from buffer <X>".

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.

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.

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

-- 
dwmw2

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux