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

[David Woodhouse]

On Fri, 2013-09-13 at 00:12 -0400, Huang Shijie wrote:
> I will send you the datasheet tomorrow.

Thanks. Although according to the date header on your email, it is
*already* tomorrow. Any chance of fixing your clock, please?

> Mark and you want to create the LUT instruction sequence at the runtime,
> But there is some disadvantage if we do so:
>   [1] low efficiency: 
>       If you want to change the LUT regitster, you should unlock the LUT
>       register, and change the LUT regitsters, and lock the LUT
>       regitsters again.

Although there aren't *that* many operations we perform, so you'd quite
quickly find yourself using things which are *already* programmed into
the LUT instead of having to re-program them again, surely?

>   [2] we may can not create all the LUT instruction sequence at the
>       runtime. For example, the buffer program(OPCODE_PP):
>       the m25p80_write() may write 256bytes at a time, but the Quadspi
>       controller only has a 64-byte TX-FIFO, so the controller should
>       write a 64bytes firstly, then sends to the NOR with a read-status
>       command. Do you want to create a read-status LUT instruction 
>       sequence at run time? This is not good solution, we should
>       pre-populate the read-status LUT information.

I'm not entirely sure I understand this. What *exactly* happens "on the
wire" in this case? Do you really send an OPCODE_RDSR (0x05) byte on the
wire somehow, when you're supposed to be in the middle of sending the
page data to the chip? How does the chip handle that?

>   [3] We may can not create the LUT instruction sequence at the runtime,
>       since we can not get enough information from the spi_transfer{}.
>       A whole LUT instruction sequence may needs the following info:
>        1.) spi command.
>        2.) lines info: single line, dual lines, quad lines.
>        3.) Address width: 3 bytes address or 4 bytes address.
>        4.) instruction type: Read or write or other. 
>        5.) length info: how many bytes for this transaction .
>        6.) dummy info: how many dummy is needed for this transaction.
> 
>       We can not get the dummy info from the spi_transfer{} 

Again, what does that actually *mean*, on the wire?

I thought SPI was just 'send some bytes, fetch some bytes'. Why is the
controller doing anything other than that?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130912/1198ff3f/attachment.bin>