16 bit NAND fix, request for testers
Subsystems (2)
PATCH v2 1/1 16 bit NAND fix, request for testers
just a small patch to access GPMC NAND registers with 16 bits when the NAND is in 16 bit mode. I tested this on a 2.6.37 kernel, and noticed it was still unpatched in the latest kernel. I don't have the hardware setup or defconfigs to test this patch out, and even if I did I don't have the logic analyzer setup to completely reproduce it on other hardware with the latest kernel. It would be nice to get a tested-by on this patch.
(CC'd mtd list this time)
Thanks.
Christopher Harvey (1):
mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
drivers/mtd/nand/omap2.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)
Signature · 1 line
1.7.8.6
PATCH v2 1/1 mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra 0x0 command for the high byte. This commit uses writew if we're using 16bit NAND.
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
--- drivers/mtd/nand/omap2.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)
drivers/mtd/nand/omap2.c +9 -5
@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) {struct omap_nand_info *info =container_of (mtd, struct omap_nand_info, mtd); +void __iomem *reg;if (cmd !=NAND_CMD_NONE ) {if (ctrl &NAND_CLE ) -writeb (cmd, info->reg.gpmc_nand_command); - + reg = info->reg.gpmc_nand_command;else if (ctrl &NAND_ALE ) -writeb (cmd, info->reg.gpmc_nand_address); - + reg = info->reg.gpmc_nand_address;else /* NAND_NCE */ -writeb (cmd, info->reg.gpmc_nand_data); + reg = info->reg.gpmc_nand_data; + +if (info->nand.options &NAND_BUSWIDTH_16 ) +writew (cmd, reg); +else +writeb (cmd, reg); } }
Signature · 1 line
1.7.8.6
Re: [PATCH v2] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
Quoted 11 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND.Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Hi Christopher,
Nitpick: I think you should replace 'command' with 'address' in your commit message. The ONFI spec says Host should send _address_ byte NN as 0x00NN. It is OK to send command NN as 0xFFNN, as explicitly mentioned in ONFI 3.1 spec (section 2.16):
2.16. Bus Width Requirements
All NAND Targets per device shall use the same data bus width. All targets shall either have an 8-bit bus width or a 16-bit bus width. Note that devices that support the NV-DDR or NV-DDR2 data interface shall have an 8-bit bus width.
When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h.
Your patch deals with both command and address bytes, which does not hurt. BR,
--
Ivan
Quoted 42 lines
Signed-off-by Christopher Harvey <[email protected]>--- drivers/mtd/nand/omap2.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)drivers/mtd/nand/omap2.c +9
-5@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) {struct omap_nand_info *info =container_of (mtd, struct omap_nand_info, mtd); +void __iomem *reg;if (cmd !=NAND_CMD_NONE ) {if (ctrl &NAND_CLE ) -writeb (cmd, info->reg.gpmc_nand_command); - + reg = info->reg.gpmc_nand_command;else if (ctrl &NAND_ALE ) -writeb (cmd, info->reg.gpmc_nand_address); - + reg = info->reg.gpmc_nand_address;else /* NAND_NCE */ -writeb (cmd, info->reg.gpmc_nand_data); + reg = info->reg.gpmc_nand_data; + +if (info->nand.options &NAND_BUSWIDTH_16 ) +writew (cmd, reg); +else +writeb (cmd, reg); } }Signature · 5 lines
1.7.8.6 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: [PATCH v2] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
Quoted 28 lines · Ivan Djelic
Quoted 11 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the command 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND.Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Hi Christopher,
Nitpick: I think you should replace 'command' with 'address' in your commit message. The ONFI spec says Host should send _address_ byte NN as 0x00NN. It is OK to send command NN as 0xFFNN, as explicitly mentioned in ONFI 3.1 spec (section 2.16):
2.16. Bus Width Requirements
All NAND Targets per device shall use the same data bus width. All targets shall either have an 8-bit bus width or a 16-bit bus width. Note that devices that support the NV-DDR or NV-DDR2 data interface shall have an 8-bit bus width.
When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h.
Quoted 4 lines
Your patch deals with both command and address bytes, which does not hurt. BR,
--
Ivan
Ok, makes sense. Thanks for pointing that out. I'll update the wording.
Quoted 39 lines
Quoted 39 lines
Signed-off-by Christopher Harvey <[email protected]>--- drivers/mtd/nand/omap2.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)drivers/mtd/nand/omap2.c +9
-5@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) {struct omap_nand_info *info =container_of (mtd, struct omap_nand_info, mtd); +void __iomem *reg;if (cmd !=NAND_CMD_NONE ) {if (ctrl &NAND_CLE ) -writeb (cmd, info->reg.gpmc_nand_command); - + reg = info->reg.gpmc_nand_command;else if (ctrl &NAND_ALE ) -writeb (cmd, info->reg.gpmc_nand_address); - + reg = info->reg.gpmc_nand_address;else /* NAND_NCE */ -writeb (cmd, info->reg.gpmc_nand_data); + reg = info->reg.gpmc_nand_data; + +if (info->nand.options &NAND_BUSWIDTH_16 ) +writew (cmd, reg); +else +writeb (cmd, reg); } }Signature · 1 line
1.7.8.6
PATCH v3 1/1 mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
In reply to Christopher HarveyIn 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra 0x0 command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
--- drivers/mtd/nand/omap2.c | 14 +++++++++----- 1 files changed, 9 insertions(+), 5 deletions(-)
drivers/mtd/nand/omap2.c +9 -5
@@ -225,16 +225,20 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl) {struct omap_nand_info *info =container_of (mtd, struct omap_nand_info, mtd); +void __iomem *reg;if (cmd !=NAND_CMD_NONE ) {if (ctrl &NAND_CLE ) -writeb (cmd, info->reg.gpmc_nand_command); - + reg = info->reg.gpmc_nand_command;else if (ctrl &NAND_ALE ) -writeb (cmd, info->reg.gpmc_nand_address); - + reg = info->reg.gpmc_nand_address;else /* NAND_NCE */ -writeb (cmd, info->reg.gpmc_nand_data); + reg = info->reg.gpmc_nand_data; + +if (info->nand.options &NAND_BUSWIDTH_16 ) +writew (cmd, reg); +else +writeb (cmd, reg); } }
Signature · 1 line
1.7.8.6
Artem Bityutskiy
AppliedRe: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
Quoted 10 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.
Quoted 4 lines
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Signed-off-by Christopher Harvey <[email protected]>
Pushed to l2-mtd.git, thanks!
Signature · 2 lines
Best Regards, Artem Bityutskiy
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
Quoted 11 lines · Artem Bityutskiy
Quoted 10 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.
Quoted 6 lines
Quoted 4 lines
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Signed-off-by Christopher Harvey <[email protected]>Pushed to l2-mtd.git, thanks!
!!! Did anybody get around to testing this? I thought this patch had
been abandoned. Will testing get done on an omap chip now that it is in a tree?
I should have prefixed it with RFC.
-C
Signature · 27 lines
CONFIDENTIAL & WITHOUT PREJUDICE This e-mail and any files transmitted with it, is confidential, may be protected under NDA and/or privileged and shall be treated as such. The e-mail and its attachments are intended only for use of the individual(s) or entity(ies) indicated above. Any other person is hereby advised that it strictly forbidden to disclose, distribute or reproduce this message. If you have received this e-mail in error, please advise me by return e-mail or by telephone at 514-822-6000, immediately and destroy the message and its contents immediately. Thank You. CONFIDENTIEL - SANS PRÉJUDICE Ce courriel et tout document qui y est joint, est confidentiel, peut être privilégié et protégé par entente de confidentialité et est à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par téléphone au (514) 822-6000 et détruire ce message et toute copie de celui-ci immédiatement. Merci. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
Quoted 17 lines · Christopher Harvey
Quoted 16 lines · Artem Bityutskiy
Quoted 14 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Signed-off-by Christopher Harvey <[email protected]>
Quoted 7 lines
Quoted 1 line
Pushed to l2-mtd.git, thanks!
!!! Did anybody get around to testing this? I thought this patch had
been abandoned. Will testing get done on an omap chip now that it is in a tree?I should have prefixed it with RFC.
I assume _you_ tested it, and Ivan was happy. But if it is untested, I am dropping it.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
Quoted 20 lines · Artem Bityutskiy
Quoted 19 lines · Christopher Harvey
Quoted 17 lines · Artem Bityutskiy
Quoted 10 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.Quoted 4 lines
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Signed-off-by Christopher Harvey <[email protected]>Pushed to l2-mtd.git, thanks!
Quoted 9 lines
Quoted 5 lines
!!! Did anybody get around to testing this? I thought this patch had
been abandoned. Will testing get done on an omap chip now that it is in a tree?I should have prefixed it with RFC.
I assume _you_ tested it, and Ivan was happy. But if it is untested, I am dropping it.
I'm running a slight variation of it on another version of the kernel. I'm glad you're dropping it though...I have a reputation to maintain as well as a kernel. ;)
-C
Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
In reply to Artem BityutskiyQuoted 20 lines · Artem Bityutskiy
Quoted 19 lines · Christopher Harvey
Quoted 17 lines · Artem Bityutskiy
Quoted 10 lines · Christopher Harvey
In 16bit NAND mode the GPMC would send the address 0xNN as 0xFFNN instead of 0x00NN on the bus. The 0xFFs were actually uninitialized bits that were left unset in the GPMC command output register. The reason they weren't initialized in 16bit mode is that if the same code that writes to this register was used in 8bit mode then 2 commands would be output in 8bit mode. One for the low byte, and an extra
0x0command for the high byte. This commit uses writew if we're using 16bit NAND. This commit also changes the high byte in the command output register, but they are ignored by NAND chips anyway.Quoted 4 lines
Most chips seem fine with the extra 0xFFs, but the ONFI spec says otherwise.
Signed-off-by Christopher Harvey <[email protected]>Pushed to l2-mtd.git, thanks!
Quoted 8 lines
Quoted 5 lines
!!! Did anybody get around to testing this? I thought this patch had
been abandoned. Will testing get done on an omap chip now that it is in a tree?I should have prefixed it with RFC.
I assume _you_ tested it, and Ivan was happy. But if it is untested, I am dropping it.
Unfortunately I can't test it at the moment,
BR,
--
Ivan