于 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
