Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
On Thu, Dec 17, 2015 at 04:29:01PM -0800, Brian Norris wrote:
> On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> OK, so I think your patch is broken:
>
> > > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > > SPI NOR")
>
> How did you test this? Specifically, this can't possibly have worked
> with a regular drivers/spi/ controllers, since:
>
> (a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
> (b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
> 1/1/4 (i.e., "Extended mode")
>
> I'm tempted to essentially revert that, as it looks essentially
> untested. It would be nice to have a cleaner baseline before trying to
> extend it with Cyrille's work.
>
> Cyrille, what do you think? Is my analysis at all correct here? (Sorry
> if this is addressed elsewhere; there's a lot of text in this
> conversation, but I'm getting hung up very early.) And if so, does it
> hurt to just drop Micron "Quad mode" (4/4/4)?
It looks like you address some of this in patch 2, where you (as I do)
claim that Micron support is broken. It seems to me that it could be
better to kill it than to try to fix it. But maybe that's just the
frustrated maintainer in me speaking.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Hi Bean,
On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> >
> > I'll admit I'm a little fuzzy on the differences between dual and quad
> > modes on
> > various flash manufacturers. Can you help clear it up for me?
>
> For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows
> I/O
> Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
> are all used to transfer address/command/data. For this maybe not the same
> between
> different flash manufactures. For example, for Spansion Qspi NOR, its all
> instructions are
> transferred from host to memory as a single bit serial sequence on the DQ0
> signal, even under
> Quad mode. Dual mode the same as Qaud mode scenario.
>
> for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
> but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
> between different flash manufacturers. Of course, at this moment, SPI NOR
> should work under extended I/O mode.
OK, so to make these statements *much* shorter:
* Micron "Quad Mode" means putting the flash in a 4/4/4 mode
* Spansion (and all others?) are using 1/1/4 modes
Correct?
> > I think some of the comments on patch 2 help too, but I'll just comment here
> > for now.
> > It looks like the current driver has problems regarding the non 1-x-y modes
> > (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> > command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> > this an oversight in patches like Bean's patch?
>
> For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
> Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
> mode,
> Command and address still following extended I/O mode.
The naming is confusing enough here... so in your words, "extended"
means 1/1/{1,2,4} (i.e., command, and maybe address, use 1 line, but
data goes on 4)? And "quad" means 4/4/4?
> For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
> of course, SPI controller should support this. for Micron Qspi NOR, under
> quad mode,
> all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No
> matter what
> kind of command.
OK, so I think your patch is broken:
> > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > SPI NOR")
How did you test this? Specifically, this can't possibly have worked
with a regular drivers/spi/ controllers, since:
(a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
(b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
1/1/4 (i.e., "Extended mode")
I'm tempted to essentially revert that, as it looks essentially
untested. It would be nice to have a cleaner baseline before trying to
extend it with Cyrille's work.
Cyrille, what do you think? Is my analysis at all correct here? (Sorry
if this is addressed elsewhere; there's a lot of text in this
conversation, but I'm getting hung up very early.) And if so, does it
hurt to just drop Micron "Quad mode" (4/4/4)?
(AIUI, this won't exactly be a panacea, since you mention bootloaders
that start us off in quad mode, so we can't use single I/O 0x9f READ
ID.)
> > Why would we even need to enable quad modes like that, if we're not going
> > to send the 4-4-4 opcodes?
> I think, in order to high speed SPI NOR, after enable quad mode,
> SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
> (0x03)
> Can implement as them.
OK. That's odd, but I guess it doesn't matter much. It just makes it a
little less obvious what's going on.
> > My next question (if my understanding is roughly correct) is, do we need the
> > 4-4-4 modes, and what risks come with them? I understand we can shorten
> > the command and address phases, but does that alone yield much
> > performance benefit? And I think the risk is that a given system might not
> > be
> > prepared for the flash to be in a 4-4-4 mode, if the boot code tries to use
> > 1-x-y
> > commands.
>
> As far as my current experience and knowledge, this still need to be enabled,
> especially for
> fast boot, and some IOT devices to store info into SPI NOR.
Do you have any data to about the speed? And you haven't addressed the
risks. There are definitely risks. Cyrille looks like he's trying to
address the risks (e.g., use volatile modes whenever possible), but it
doesn't seem that you are.
> For this patches, my current concern is that host side how to get different
> I/O protocol changes,
> and distinguish between different flash manufacturers I/O mode.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
On Thu, Dec 17, 2015 at 04:29:01PM -0800, Brian Norris wrote:
> On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> OK, so I think your patch is broken:
>
> > > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > > SPI NOR")
>
> How did you test this? Specifically, this can't possibly have worked
> with a regular drivers/spi/ controllers, since:
>
> (a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
> (b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
> 1/1/4 (i.e., "Extended mode")
>
> I'm tempted to essentially revert that, as it looks essentially
> untested. It would be nice to have a cleaner baseline before trying to
> extend it with Cyrille's work.
>
> Cyrille, what do you think? Is my analysis at all correct here? (Sorry
> if this is addressed elsewhere; there's a lot of text in this
> conversation, but I'm getting hung up very early.) And if so, does it
> hurt to just drop Micron "Quad mode" (4/4/4)?
It looks like you address some of this in patch 2, where you (as I do)
claim that Micron support is broken. It seems to me that it could be
better to kill it than to try to fix it. But maybe that's just the
frustrated maintainer in me speaking.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Hi Bean,
On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> >
> > I'll admit I'm a little fuzzy on the differences between dual and quad
> > modes on
> > various flash manufacturers. Can you help clear it up for me?
>
> For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows
> I/O
> Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
> are all used to transfer address/command/data. For this maybe not the same
> between
> different flash manufactures. For example, for Spansion Qspi NOR, its all
> instructions are
> transferred from host to memory as a single bit serial sequence on the DQ0
> signal, even under
> Quad mode. Dual mode the same as Qaud mode scenario.
>
> for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
> but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
> between different flash manufacturers. Of course, at this moment, SPI NOR
> should work under extended I/O mode.
OK, so to make these statements *much* shorter:
* Micron "Quad Mode" means putting the flash in a 4/4/4 mode
* Spansion (and all others?) are using 1/1/4 modes
Correct?
> > I think some of the comments on patch 2 help too, but I'll just comment here
> > for now.
> > It looks like the current driver has problems regarding the non 1-x-y modes
> > (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> > command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> > this an oversight in patches like Bean's patch?
>
> For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
> Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
> mode,
> Command and address still following extended I/O mode.
The naming is confusing enough here... so in your words, "extended"
means 1/1/{1,2,4} (i.e., command, and maybe address, use 1 line, but
data goes on 4)? And "quad" means 4/4/4?
> For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
> of course, SPI controller should support this. for Micron Qspi NOR, under
> quad mode,
> all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No
> matter what
> kind of command.
OK, so I think your patch is broken:
> > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > SPI NOR")
How did you test this? Specifically, this can't possibly have worked
with a regular drivers/spi/ controllers, since:
(a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
(b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
1/1/4 (i.e., "Extended mode")
I'm tempted to essentially revert that, as it looks essentially
untested. It would be nice to have a cleaner baseline before trying to
extend it with Cyrille's work.
Cyrille, what do you think? Is my analysis at all correct here? (Sorry
if this is addressed elsewhere; there's a lot of text in this
conversation, but I'm getting hung up very early.) And if so, does it
hurt to just drop Micron "Quad mode" (4/4/4)?
(AIUI, this won't exactly be a panacea, since you mention bootloaders
that start us off in quad mode, so we can't use single I/O 0x9f READ
ID.)
> > Why would we even need to enable quad modes like that, if we're not going
> > to send the 4-4-4 opcodes?
> I think, in order to high speed SPI NOR, after enable quad mode,
> SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
> (0x03)
> Can implement as them.
OK. That's odd, but I guess it doesn't matter much. It just makes it a
little less obvious what's going on.
> > My next question (if my understanding is roughly correct) is, do we need the
> > 4-4-4 modes, and what risks come with them? I understand we can shorten
> > the command and address phases, but does that alone yield much
> > performance benefit? And I think the risk is that a given system might not
> > be
> > prepared for the flash to be in a 4-4-4 mode, if the boot code tries to use
> > 1-x-y
> > commands.
>
> As far as my current experience and knowledge, this still need to be enabled,
> especially for
> fast boot, and some IOT devices to store info into SPI NOR.
Do you have any data to about the speed? And you haven't addressed the
risks. There are definitely risks. Cyrille looks like he's trying to
address the risks (e.g., use volatile modes whenever possible), but it
doesn't seem that you are.
> For this patches, my current concern is that host side how to get different
> I/O protocol changes,
> and distinguish between different flash manufacturers I/O mode.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Le 08/12/2015 11:25, Cyrille Pitchen a écrit :
> Hi Brian,
>
> Le 07/12/2015 20:34, Brian Norris a écrit :
[...]
>> Also, I see a lot of good comments in patch 2 about Spansion vs.
>> Macronix vs. Micron memories. I wonder if previous developers have
>> completely tested their patches, or if they're just reading the
>> datasheets... so, what kind have testing have you done? Do you have
>> samples of all these flash to test?
>>
>
> I want to be totally honest on this point: I did NOT test with Macronix
> memories yet simply because I have no such memory from this manufacturer.
> I guess Atmel planed to purchase some samples because we also need to test
> their support in the sama5d2 romcode when booting from QSPI.
> So for the Macronix case, the patches are only based on my current
> understanding of Macronix datasheets (MX66L1G45G, 3V, 1Gb, v1.0.pdf).
>
> On the other hand I did many tests with both Micron and Spansion memories
> with sama5d2 SoCs, either with Linux or with the sama5d2 romcode ("normal"
> Fast Read x-y-4 but also eXecution In Place using the Continuous Read mode:
> the XIP mode is not relevant for the Linux spi-nor framework but it should
> take care of the "dummy cycles" it sends to avoid entering into the
> Continuous Read mode by mistake).
> I used at least these memories under Linux:
> - Micron n25q128a13: sama5d2 xplained ultra + linux-next 20151207 /
> at91 linux 4.1
> - Micron n25q256: sama5d2 prototype (FPGA) + at91 linux 3.18
> - Spansion s25fl512: sama5d2 prototype (FPGA) + at91 linux 3.18
>
I forgot few points. First, I did all Quad SPI tests using the Atmel QSPI
controller and driver.
I did no Dual SPI protocol test yet, only Quad SPI.
I'm able to test neither Quad nor Dual SPI protocols with the Atmel QSPI
protocol + m25p80 driver: this driver is not really suited for handling
the Atmel QSPI controller in its Serial Memory Mode.
However I did some non regression tests with the m25p80 driver used on the
regular Atmel SPI controller and driver (drivers/spi/spi-atmel.c) to
access a at25df312a memory (SPI 1-1-1 protocol).
Nonetheless the m25p80 driver was taken into account when I wrote the series.
Indeed Micron, Macronix and Spansion's datasheets provide tables giving the
number of dummy cycles to use depending on both the SPI bus clock
frequency and the Fast Read command. Hence in spi-nor.c, patch 2 sets
nor->read_dummy to the relevant number of dummy cycles (not bits).
Taking Spansion memories as an example, for their factory default Latency
Code value of 0, they expect:
- 8 dummy cycles for Fast Read 1-1-1 (0x0b / 0x0c)
- 8 dummy cycles for Fast Read 1-1-2 (0x3b / 0x3c)
- 8 dummy cycles for Fast Read 1-1-4 (0x6b / 0x6c)
Fast Read 1-2-2 and 1-4-4 are not used with Spansion memories since the
number of dummy cycles to be used with one of these op codes is not suited
for the m25p80 driver.
For Micron and Macronix, except when their Quad SPI mode is enabled, the
Fast Read 1-1-4 or Fast Read 1-1-2 commands are preferred to the
Fast Read 1-4-4 or Fast Read 1-2-2 commands. The number of dummy cycles is
set to 0 for Read command (0x03) and 8 for other Fast Read commands since
this setting update can be done safely writing into volatile bits inside
configuration registers. A multiple of 8 dummy cycles is suited for the
m25p80_read() implementation.
Then looking at the m25p80 driver, the original (unchanged) cycles/bytes
conversion from the m25p80_read() hook only works with SPI 1-1-x protocols:
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
As a matter of fact, 8 dummy cycles stand for:
- 8 bits (1 byte ) for SPI 1-1-z protocols
- 16 bits (2 bytes) for SPI x-2-z protocols
- 32 bits (4 bytes) for SPI x-4-z protocols
So I should also fix the above conversion in patch 3 to cover more SPI
protocols.
Best Regards,
Cyrille
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Hi Brian,
Le 07/12/2015 20:34, Brian Norris a écrit :
> + Bean Huo
>
> Hi Cyrille,
>
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
>> Hi all,
>>
>> this series of patches adds support to the Atmel QSPI controller available
>> on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with a
>> Micron n25q128a13 QSPI memory and a at25df321a SPI memory.
>>
>> In order to use the Micron memory in its Quad SPI mode, the spi-nor
>> framework needed to be patched to fix the support of Quad/Dual SPI
>> protocols with some memory manufacturers such as Spansion, Micron and
>> Macronix. There are many comments in the source code to explain the
>> implementation choices based on the datasheets from memory manufacturers.
>>
>>
>> This series was based and tested on linux-next-20151207
>>
>> 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
>>
>> SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
>>argument to spi_nor_scan() called from atmel_qspi_probe().
>>
>> SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
>>mode of the Micron memory. When probed from Linux, the memory
>>uses its Extended SPI mode and replies to the regular Read ID
>>(0x9f) command.
>>
>> SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
>>before loading the at91bootstrap. When probed from Linux, the
>>memory uses its Quad SPI mode and no longer replies to the
>>regular Read ID (0x9f) command but instead to the Read ID
>>Multiple I/O (0xaf) command. The memory expects ALL commands
>>to use the SPI 4-4-4 protocol.
>
> I'll admit I'm a little fuzzy on the differences between dual and quad
> modes on various flash manufacturers. Can you help clear it up for me?
> I think some of the comments on patch 2 help too, but I'll just comment
> here for now.
>
> It looks like the current driver has problems regarding the non 1-x-y
> modes (e.g., 4-4-4), right? But I see that spi-nor.c never tries to
> send a 4_4_4 command; it only sets read_opcode to
> SPINOR_OP_READ_1_1_{1,2,4}. So is this an oversight in patches like
> Bean's patch?
>
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
>
> Why would we even need to enable quad modes like that, if we're not
> going to send the 4-4-4 opcodes?
First let me clarify one point. This series focuses on Spansion, Macronix
and Micron because when I wrote its patches few months ago, the spi-nor.c
driver supported QSPI protocols only for these three only manufacturers.
Today I notice that now some Winbond memories also use the
SPI_NOR_QUAD_READ flag. Though I try to deal with all manufacturers on a
equal foot, I currently have no knowledge on Windond memories so my
explanations only apply to Spansion, Macronix and Micron memories.
About the SPI 4-4-4 protocol, it is only supported by Micron and Macronix
memories but not by Spansion. Both Micron and Macronix memories provide us
with a special mode, let's call it the Quad SPI mode. As Bean Huo explained
for Micron, once this mode is enabled, the memory expects all commands to
use the SPI 4-4-4 protocol. Hence even if the spi-nor.c driver uses the Fast
Read Quad Output 1-1-4 (0x6b/0x6c) or the Fast Read Quad I/O 1-4-4 (0xeb/0xec)
op codes, the command is interpreted as a Fast Read Quad Command 4-4-4 so must
use the SPI 4-4-4 protocol. As far as I know, there is no currently existing
op code dedicated to the Fast Read Quad Command 4-4-4.
So the op codes may be confusing but when the Quad SPI mode is enabled we
actually use Fast Read 4-4-4 commands.
>
> My next question (if my understanding is roughly correct) is, do we need
> the 4-4-4 modes, and what risks come with them? I understand we can
> shorten the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a given system might
> not be prepared for the flash to be in a 4-4-4 mode, if the boot code
> tries to use 1-x-y commands.
>
I did not run comparative tests between Fast Read 1-1-4, Fast Read 1-4-4
and Fast Read 4-4-4 yet. Honestly I don't expect much difference. However
performances were not the main purpose when I wrote these patches.
Actually the Quad SPI mode of Macronix and Micron comes with a side effect.
Once enable, not only the memory now expects all commands to use the
SPI 4-4-4 protocol but it no longer replies to the regular Read JEDEC ID
command (0x9f). Instead it replies to a new command, the Read JEDEC ID
Multiple I/O (0xaf).
Now let's imagine that the Quad SPI mode is either permanently enabled at
reset using non-volatile configuration registers or enabled by a early
bootloader. When the spi-nor driver tries to probe the memory, the 0x9f
command fails: the driver should adapt, that's why it tries other protocols
such as SPI 4-4-4 (Micron and Macronix) and SPI 2-2-2 (Micron only when in
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Hi Brian,
Le 07/12/2015 20:34, Brian Norris a écrit :
> + Bean Huo
>
> Hi Cyrille,
>
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
>> Hi all,
>>
>> this series of patches adds support to the Atmel QSPI controller available
>> on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with a
>> Micron n25q128a13 QSPI memory and a at25df321a SPI memory.
>>
>> In order to use the Micron memory in its Quad SPI mode, the spi-nor
>> framework needed to be patched to fix the support of Quad/Dual SPI
>> protocols with some memory manufacturers such as Spansion, Micron and
>> Macronix. There are many comments in the source code to explain the
>> implementation choices based on the datasheets from memory manufacturers.
>>
>>
>> This series was based and tested on linux-next-20151207
>>
>> 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
>>
>> SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
>>argument to spi_nor_scan() called from atmel_qspi_probe().
>>
>> SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
>>mode of the Micron memory. When probed from Linux, the memory
>>uses its Extended SPI mode and replies to the regular Read ID
>>(0x9f) command.
>>
>> SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
>>before loading the at91bootstrap. When probed from Linux, the
>>memory uses its Quad SPI mode and no longer replies to the
>>regular Read ID (0x9f) command but instead to the Read ID
>>Multiple I/O (0xaf) command. The memory expects ALL commands
>>to use the SPI 4-4-4 protocol.
>
> I'll admit I'm a little fuzzy on the differences between dual and quad
> modes on various flash manufacturers. Can you help clear it up for me?
> I think some of the comments on patch 2 help too, but I'll just comment
> here for now.
>
> It looks like the current driver has problems regarding the non 1-x-y
> modes (e.g., 4-4-4), right? But I see that spi-nor.c never tries to
> send a 4_4_4 command; it only sets read_opcode to
> SPINOR_OP_READ_1_1_{1,2,4}. So is this an oversight in patches like
> Bean's patch?
>
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
>
> Why would we even need to enable quad modes like that, if we're not
> going to send the 4-4-4 opcodes?
First let me clarify one point. This series focuses on Spansion, Macronix
and Micron because when I wrote its patches few months ago, the spi-nor.c
driver supported QSPI protocols only for these three only manufacturers.
Today I notice that now some Winbond memories also use the
SPI_NOR_QUAD_READ flag. Though I try to deal with all manufacturers on a
equal foot, I currently have no knowledge on Windond memories so my
explanations only apply to Spansion, Macronix and Micron memories.
About the SPI 4-4-4 protocol, it is only supported by Micron and Macronix
memories but not by Spansion. Both Micron and Macronix memories provide us
with a special mode, let's call it the Quad SPI mode. As Bean Huo explained
for Micron, once this mode is enabled, the memory expects all commands to
use the SPI 4-4-4 protocol. Hence even if the spi-nor.c driver uses the Fast
Read Quad Output 1-1-4 (0x6b/0x6c) or the Fast Read Quad I/O 1-4-4 (0xeb/0xec)
op codes, the command is interpreted as a Fast Read Quad Command 4-4-4 so must
use the SPI 4-4-4 protocol. As far as I know, there is no currently existing
op code dedicated to the Fast Read Quad Command 4-4-4.
So the op codes may be confusing but when the Quad SPI mode is enabled we
actually use Fast Read 4-4-4 commands.
>
> My next question (if my understanding is roughly correct) is, do we need
> the 4-4-4 modes, and what risks come with them? I understand we can
> shorten the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a given system might
> not be prepared for the flash to be in a 4-4-4 mode, if the boot code
> tries to use 1-x-y commands.
>
I did not run comparative tests between Fast Read 1-1-4, Fast Read 1-4-4
and Fast Read 4-4-4 yet. Honestly I don't expect much difference. However
performances were not the main purpose when I wrote these patches.
Actually the Quad SPI mode of Macronix and Micron comes with a side effect.
Once enable, not only the memory now expects all commands to use the
SPI 4-4-4 protocol but it no longer replies to the regular Read JEDEC ID
command (0x9f). Instead it replies to a new command, the Read JEDEC ID
Multiple I/O (0xaf).
Now let's imagine that the Quad SPI mode is either permanently enabled at
reset using non-volatile configuration registers or enabled by a early
bootloader. When the spi-nor driver tries to probe the memory, the 0x9f
command fails: the driver should adapt, that's why it tries other protocols
such as SPI 4-4-4 (Micron and Macronix) and SPI 2-2-2 (Micron only when in
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Le 08/12/2015 11:25, Cyrille Pitchen a écrit :
> Hi Brian,
>
> Le 07/12/2015 20:34, Brian Norris a écrit :
[...]
>> Also, I see a lot of good comments in patch 2 about Spansion vs.
>> Macronix vs. Micron memories. I wonder if previous developers have
>> completely tested their patches, or if they're just reading the
>> datasheets... so, what kind have testing have you done? Do you have
>> samples of all these flash to test?
>>
>
> I want to be totally honest on this point: I did NOT test with Macronix
> memories yet simply because I have no such memory from this manufacturer.
> I guess Atmel planed to purchase some samples because we also need to test
> their support in the sama5d2 romcode when booting from QSPI.
> So for the Macronix case, the patches are only based on my current
> understanding of Macronix datasheets (MX66L1G45G, 3V, 1Gb, v1.0.pdf).
>
> On the other hand I did many tests with both Micron and Spansion memories
> with sama5d2 SoCs, either with Linux or with the sama5d2 romcode ("normal"
> Fast Read x-y-4 but also eXecution In Place using the Continuous Read mode:
> the XIP mode is not relevant for the Linux spi-nor framework but it should
> take care of the "dummy cycles" it sends to avoid entering into the
> Continuous Read mode by mistake).
> I used at least these memories under Linux:
> - Micron n25q128a13: sama5d2 xplained ultra + linux-next 20151207 /
> at91 linux 4.1
> - Micron n25q256: sama5d2 prototype (FPGA) + at91 linux 3.18
> - Spansion s25fl512: sama5d2 prototype (FPGA) + at91 linux 3.18
>
I forgot few points. First, I did all Quad SPI tests using the Atmel QSPI
controller and driver.
I did no Dual SPI protocol test yet, only Quad SPI.
I'm able to test neither Quad nor Dual SPI protocols with the Atmel QSPI
protocol + m25p80 driver: this driver is not really suited for handling
the Atmel QSPI controller in its Serial Memory Mode.
However I did some non regression tests with the m25p80 driver used on the
regular Atmel SPI controller and driver (drivers/spi/spi-atmel.c) to
access a at25df312a memory (SPI 1-1-1 protocol).
Nonetheless the m25p80 driver was taken into account when I wrote the series.
Indeed Micron, Macronix and Spansion's datasheets provide tables giving the
number of dummy cycles to use depending on both the SPI bus clock
frequency and the Fast Read command. Hence in spi-nor.c, patch 2 sets
nor->read_dummy to the relevant number of dummy cycles (not bits).
Taking Spansion memories as an example, for their factory default Latency
Code value of 0, they expect:
- 8 dummy cycles for Fast Read 1-1-1 (0x0b / 0x0c)
- 8 dummy cycles for Fast Read 1-1-2 (0x3b / 0x3c)
- 8 dummy cycles for Fast Read 1-1-4 (0x6b / 0x6c)
Fast Read 1-2-2 and 1-4-4 are not used with Spansion memories since the
number of dummy cycles to be used with one of these op codes is not suited
for the m25p80 driver.
For Micron and Macronix, except when their Quad SPI mode is enabled, the
Fast Read 1-1-4 or Fast Read 1-1-2 commands are preferred to the
Fast Read 1-4-4 or Fast Read 1-2-2 commands. The number of dummy cycles is
set to 0 for Read command (0x03) and 8 for other Fast Read commands since
this setting update can be done safely writing into volatile bits inside
configuration registers. A multiple of 8 dummy cycles is suited for the
m25p80_read() implementation.
Then looking at the m25p80 driver, the original (unchanged) cycles/bytes
conversion from the m25p80_read() hook only works with SPI 1-1-x protocols:
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
As a matter of fact, 8 dummy cycles stand for:
- 8 bits (1 byte ) for SPI 1-1-z protocols
- 16 bits (2 bytes) for SPI x-2-z protocols
- 32 bits (4 bytes) for SPI x-4-z protocols
So I should also fix the above conversion in patch 3 to cover more SPI
protocols.
Best Regards,
Cyrille
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> > I'll admit I'm a little fuzzy on the differences between dual and quad modes > on > various flash manufacturers. Can you help clear it up for me? For SPI NOR, currently, don't have an official standard to define an uniform Quad I/O mode protocol. So we can see that there are some difference between Flash Vendor.
RE: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Tuesday, December 08, 2015 3:35 AM
> To: Cyrille Pitchen
> Cc: linux-...@lists.infradead.org; nicolas.fe...@atmel.com; ma...@denx.de;
> vigne...@ti.com; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Bean Huo 霍斌斌
> (beanhuo)
> Subject: Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI
> controller
>
> + Bean Huo
>
> Hi Cyrille,
>
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
> > Hi all,
> >
> > this series of patches adds support to the Atmel QSPI controller
> > available on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra
> > board with a Micron n25q128a13 QSPI memory and a at25df321a SPI
> memory.
> >
> > In order to use the Micron memory in its Quad SPI mode, the spi-nor
> > framework needed to be patched to fix the support of Quad/Dual SPI
> > protocols with some memory manufacturers such as Spansion, Micron and
> > Macronix. There are many comments in the source code to explain the
> > implementation choices based on the datasheets from memory
> manufacturers.
> >
> >
> > This series was based and tested on linux-next-20151207
> >
> > 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
> >
> > SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by
> SPI_NOR_FAST as
> >argument to spi_nor_scan() called from atmel_qspi_probe().
> >
> > SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
> >mode of the Micron memory. When probed from Linux, the
> memory
> >uses its Extended SPI mode and replies to the regular Read ID
> >(0x9f) command.
> >
> > SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
> >before loading the at91bootstrap. When probed from Linux,
> the
> >memory uses its Quad SPI mode and no longer replies to the
> >regular Read ID (0x9f) command but instead to the Read ID
> >Multiple I/O (0xaf) command. The memory expects ALL
> commands
> >to use the SPI 4-4-4 protocol.
>
> I'll admit I'm a little fuzzy on the differences between dual and quad modes
> on
> various flash manufacturers. Can you help clear it up for me?
For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows I/O
Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
are all used to transfer address/command/data. For this maybe not the same
between
different flash manufactures. For example, for Spansion Qspi NOR, its all
instructions are
transferred from host to memory as a single bit serial sequence on the DQ0
signal, even under
Quad mode. Dual mode the same as Qaud mode scenario.
for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
between different flash manufacturers. Of course, at this moment, SPI NOR
should work under extended I/O mode.
> I think some of the comments on patch 2 help too, but I'll just comment here
> for now.
> It looks like the current driver has problems regarding the non 1-x-y modes
> (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> this an oversight in patches like Bean's patch?
For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
mode,
Command and address still following extended I/O mode.
For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
of course, SPI controller should support this. for Micron Qspi NOR, under quad
mode,
all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No matter
what
kind of command.
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
>
> Why would we even need to enable quad modes like that, if we're not going
> to send the 4-4-4 opcodes?
I think, in order to high speed SPI NOR, after enable quad mode,
SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
(0x03)
Can implement as them.
> My next question (if my understanding is roughly correct) is, do we need the
> 4-4-4 modes, and what risks come with them? I understand we can shorten
> the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a give
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
+ Bean Huo
Hi Cyrille,
On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
> Hi all,
>
> this series of patches adds support to the Atmel QSPI controller available
> on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with a
> Micron n25q128a13 QSPI memory and a at25df321a SPI memory.
>
> In order to use the Micron memory in its Quad SPI mode, the spi-nor
> framework needed to be patched to fix the support of Quad/Dual SPI
> protocols with some memory manufacturers such as Spansion, Micron and
> Macronix. There are many comments in the source code to explain the
> implementation choices based on the datasheets from memory manufacturers.
>
>
> This series was based and tested on linux-next-20151207
>
> 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
>
> SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
>argument to spi_nor_scan() called from atmel_qspi_probe().
>
> SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
>mode of the Micron memory. When probed from Linux, the memory
>uses its Extended SPI mode and replies to the regular Read ID
>(0x9f) command.
>
> SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
>before loading the at91bootstrap. When probed from Linux, the
>memory uses its Quad SPI mode and no longer replies to the
>regular Read ID (0x9f) command but instead to the Read ID
>Multiple I/O (0xaf) command. The memory expects ALL commands
>to use the SPI 4-4-4 protocol.
I'll admit I'm a little fuzzy on the differences between dual and quad
modes on various flash manufacturers. Can you help clear it up for me?
I think some of the comments on patch 2 help too, but I'll just comment
here for now.
It looks like the current driver has problems regarding the non 1-x-y
modes (e.g., 4-4-4), right? But I see that spi-nor.c never tries to
send a 4_4_4 command; it only sets read_opcode to
SPINOR_OP_READ_1_1_{1,2,4}. So is this an oversight in patches like
Bean's patch?
commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
SPI NOR")
Why would we even need to enable quad modes like that, if we're not
going to send the 4-4-4 opcodes?
My next question (if my understanding is roughly correct) is, do we need
the 4-4-4 modes, and what risks come with them? I understand we can
shorten the command and address phases, but does that alone yield much
performance benefit? And I think the risk is that a given system might
not be prepared for the flash to be in a 4-4-4 mode, if the boot code
tries to use 1-x-y commands.
Also, I see a lot of good comments in patch 2 about Spansion vs.
Macronix vs. Micron memories. I wonder if previous developers have
completely tested their patches, or if they're just reading the
datasheets... so, what kind have testing have you done? Do you have
samples of all these flash to test?
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Tuesday, December 08, 2015 3:35 AM
> To: Cyrille Pitchen
> Cc: linux-...@lists.infradead.org; nicolas.fe...@atmel.com; ma...@denx.de;
> vigne...@ti.com; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Bean Huo 霍斌斌
> (beanhuo)
> Subject: Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI
> controller
>
> + Bean Huo
>
> Hi Cyrille,
>
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
> > Hi all,
> >
> > this series of patches adds support to the Atmel QSPI controller
> > available on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra
> > board with a Micron n25q128a13 QSPI memory and a at25df321a SPI
> memory.
> >
> > In order to use the Micron memory in its Quad SPI mode, the spi-nor
> > framework needed to be patched to fix the support of Quad/Dual SPI
> > protocols with some memory manufacturers such as Spansion, Micron and
> > Macronix. There are many comments in the source code to explain the
> > implementation choices based on the datasheets from memory
> manufacturers.
> >
> >
> > This series was based and tested on linux-next-20151207
> >
> > 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
> >
> > SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by
> SPI_NOR_FAST as
> >argument to spi_nor_scan() called from atmel_qspi_probe().
> >
> > SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
> >mode of the Micron memory. When probed from Linux, the
> memory
> >uses its Extended SPI mode and replies to the regular Read ID
> >(0x9f) command.
> >
> > SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
> >before loading the at91bootstrap. When probed from Linux,
> the
> >memory uses its Quad SPI mode and no longer replies to the
> >regular Read ID (0x9f) command but instead to the Read ID
> >Multiple I/O (0xaf) command. The memory expects ALL
> commands
> >to use the SPI 4-4-4 protocol.
>
> I'll admit I'm a little fuzzy on the differences between dual and quad modes
> on
> various flash manufacturers. Can you help clear it up for me?
For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows I/O
Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
are all used to transfer address/command/data. For this maybe not the same
between
different flash manufactures. For example, for Spansion Qspi NOR, its all
instructions are
transferred from host to memory as a single bit serial sequence on the DQ0
signal, even under
Quad mode. Dual mode the same as Qaud mode scenario.
for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
between different flash manufacturers. Of course, at this moment, SPI NOR
should work under extended I/O mode.
> I think some of the comments on patch 2 help too, but I'll just comment here
> for now.
> It looks like the current driver has problems regarding the non 1-x-y modes
> (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> this an oversight in patches like Bean's patch?
For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
mode,
Command and address still following extended I/O mode.
For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
of course, SPI controller should support this. for Micron Qspi NOR, under quad
mode,
all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No matter
what
kind of command.
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
>
> Why would we even need to enable quad modes like that, if we're not going
> to send the 4-4-4 opcodes?
I think, in order to high speed SPI NOR, after enable quad mode,
SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
(0x03)
Can implement as them.
> My next question (if my understanding is roughly correct) is, do we need the
> 4-4-4 modes, and what risks come with them? I understand we can shorten
> the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a give
RE: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
> > I'll admit I'm a little fuzzy on the differences between dual and quad modes > on > various flash manufacturers. Can you help clear it up for me? For SPI NOR, currently, don't have an official standard to define an uniform Quad I/O mode protocol. So we can see that there are some difference between Flash Vendor.
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
+ Bean Huo
Hi Cyrille,
On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
> Hi all,
>
> this series of patches adds support to the Atmel QSPI controller available
> on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with a
> Micron n25q128a13 QSPI memory and a at25df321a SPI memory.
>
> In order to use the Micron memory in its Quad SPI mode, the spi-nor
> framework needed to be patched to fix the support of Quad/Dual SPI
> protocols with some memory manufacturers such as Spansion, Micron and
> Macronix. There are many comments in the source code to explain the
> implementation choices based on the datasheets from memory manufacturers.
>
>
> This series was based and tested on linux-next-20151207
>
> 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
>
> SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
>argument to spi_nor_scan() called from atmel_qspi_probe().
>
> SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
>mode of the Micron memory. When probed from Linux, the memory
>uses its Extended SPI mode and replies to the regular Read ID
>(0x9f) command.
>
> SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
>before loading the at91bootstrap. When probed from Linux, the
>memory uses its Quad SPI mode and no longer replies to the
>regular Read ID (0x9f) command but instead to the Read ID
>Multiple I/O (0xaf) command. The memory expects ALL commands
>to use the SPI 4-4-4 protocol.
I'll admit I'm a little fuzzy on the differences between dual and quad
modes on various flash manufacturers. Can you help clear it up for me?
I think some of the comments on patch 2 help too, but I'll just comment
here for now.
It looks like the current driver has problems regarding the non 1-x-y
modes (e.g., 4-4-4), right? But I see that spi-nor.c never tries to
send a 4_4_4 command; it only sets read_opcode to
SPINOR_OP_READ_1_1_{1,2,4}. So is this an oversight in patches like
Bean's patch?
commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
SPI NOR")
Why would we even need to enable quad modes like that, if we're not
going to send the 4-4-4 opcodes?
My next question (if my understanding is roughly correct) is, do we need
the 4-4-4 modes, and what risks come with them? I understand we can
shorten the command and address phases, but does that alone yield much
performance benefit? And I think the risk is that a given system might
not be prepared for the flash to be in a 4-4-4 mode, if the boot code
tries to use 1-x-y commands.
Also, I see a lot of good comments in patch 2 about Spansion vs.
Macronix vs. Micron memories. I wonder if previous developers have
completely tested their patches, or if they're just reading the
datasheets... so, what kind have testing have you done? Do you have
samples of all these flash to test?
Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
