From: David Woodhouse <dwmw2@infradead.org> Date: 2013-09-12 09:50:31
On Thu, 2013-09-12 at 17:28 +0800, Huang Shijie wrote:
? 2013?09?11? 22:05, David Woodhouse ??:
quoted
What*actually* happens, on the wire(s), when the flash driver asks the
SPI controller to perform a transaction?
The LUT registers tell the controller how many wires are needed for a
transaction.
For example, the read status only use a single line, while the quad read
uses 4 lines.
Is this not something that could theoretically be provided by the caller
when it *makes* the transaction?
Conceptually speaking, could it not be an additional argument to
spi_write_then_read() ?
After all, it's the *device* driver (m25p80.c etc.) which will know what
the transaction actually *is*, and how many lines the device will want
to use for each transaction?
--
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/426d49e6/attachment.bin>
From: David Woodhouse <dwmw2@infradead.org> Date: 2013-09-12 15:22:02
On Thu, 2013-09-12 at 22:58 -0400, Huang Shijie wrote:
But for the quadspi driver, it does not need this information.
When the drivers knows that it is a Quad-read transaction, it will uses
the relative LUT sequence which uses the 4 lines.
But the controller driver shouldn't *have* that incestuous knowledge of
the command set of the chip that happens to be connected to it.
That's what we're *complaining* about.
It *should* "need this information", and should just do what it's *told*
to do by the slave device driver.
--
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/a88c7648/attachment.bin>
From: David Woodhouse <dwmw2@infradead.org> Date: 2013-09-12 16:26:12
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>
From: Mark Brown <broonie@kernel.org> Date: 2013-09-12 20:56:44
On Fri, Sep 13, 2013 at 12:12:14AM -0400, Huang Shijie wrote:
On Thu, Sep 12, 2013 at 04:22:02PM +0100, David Woodhouse wrote:
quoted
But the controller driver shouldn't *have* that incestuous knowledge of
the command set of the chip that happens to be connected to it.
I think the controller is designed for the NOR flash, yes, a little
strange.
I think this is part of the problem - you're trying to represent
something that isn't really a SPI controller as a SPI controller (or at
least trying to implement functionality beyond that which a SPI
controller has).
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:
[2] we may can not create all the LUT instruction sequence at the
runtime. For example, the buffer program(OPCODE_PP):
[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:
What this is saying to me is that you should not be impementing this as
a SPI controller, trying to do that is breaking the abstracton that SPI
is offering. Like people have said SPI is just about byte streams.
I think what you should be doing is refactoring the MTD code which
interfaces to SPI flashes to split out the code so that there's an
abstraction which can express what this controller (and presumably
other controllers) can do and then implement this functionaltiy at
that level.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130912/a0a6b3bb/attachment.sig>
On Thu, Sep 12, 2013 at 10:50:31AM +0100, David Woodhouse wrote:
On Thu, 2013-09-12 at 17:28 +0800, Huang Shijie wrote:
quoted
? 2013?09?11? 22:05, David Woodhouse ??:
quoted
What*actually* happens, on the wire(s), when the flash driver asks the
SPI controller to perform a transaction?
The LUT registers tell the controller how many wires are needed for a
transaction.
For example, the read status only use a single line, while the quad read
uses 4 lines.
Is this not something that could theoretically be provided by the caller
when it *makes* the transaction?
Conceptually speaking, could it not be an additional argument to
spi_write_then_read() ?
After all, it's the *device* driver (m25p80.c etc.) which will know what
the transaction actually *is*, and how many lines the device will want
to use for each transaction?
yes. we can set the lines information in the spi_write_then_read().
But for the quadspi driver, it does not need this information.
When the drivers knows that it is a Quad-read transaction, it will uses
the relative LUT sequence which uses the 4 lines.
thanks
Huang Shijie
On Fri, 2013-09-13 at 00:12 -0400, Huang Shijie wrote:
quoted
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.
quoted
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.
quoted
[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.
quoted
[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
On Thu, Sep 12, 2013 at 04:22:02PM +0100, David Woodhouse wrote:
On Thu, 2013-09-12 at 22:58 -0400, Huang Shijie wrote:
quoted
But for the quadspi driver, it does not need this information.
When the drivers knows that it is a Quad-read transaction, it will uses
the relative LUT sequence which uses the 4 lines.
But the controller driver shouldn't *have* that incestuous knowledge of
the command set of the chip that happens to be connected to it.
I think the controller is designed for the NOR flash, yes, a little
strange.
That's what we're *complaining* about.
It *should* "need this information", and should just do what it's *told*
to do by the slave device driver.
I can add the lines info in the m25p80_read() for the quad-read, but the lines
information is redundant to this Quadspi driver.
I will send you the datasheet tomorrow.
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.
[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.
[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{}
I may still miss something. But If we want to create a LUT
instruction sequence at the runtime, we should _PARSE_ out the SPI
NOR command firstly. If we parse out the SPI nor commands, there
is no difference between the pre-populete-LUT and
create-LUT-at-runtime.
thanks
Huang Shijie