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

[b32955@freescale.com (Huang Shijie)]

? 2013?09?13? 00:26, 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?
>
I was at home then. but now i am at office.
>> 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?
>
If we can not parse out the SPI NOR commands, we can not quickly find the
LUT which already programmed last time.
>>    [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?
>
Yes, I really need to send an OPCODE_RDSR in the middle of sending page
data (Page Program) to the chip.

The NOR chip can accept the data input from 1-byte to 256bytes.
So it can handle this.

>>    [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?
Please see the datasheet of the NOR:
www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf


Please see the page 100, the Quad I/O Read, the figure 10.37 shows
the dummy.

The dummy is just a delay in a command sequence.
The dummy maybe only several clock cycles, less then 8 bit.

> I thought SPI was just 'send some bytes, fetch some bytes'. Why is the
> controller doing anything other than that?
>
As the time goes on, the SPI devices or SPI controllers have become more 
and more complicated.


If the Quadspi controller can not know the SPI NOR commands explicitly, 
it can not fill the
LUT correctly, and at last it can not work.




thanks
Huang Shijie