Re: [PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
On Thu, Nov 15, 2012 at 01:02:09PM +0200, Artem Bityutskiy wrote: On Mon, 2012-10-29 at 15:51 -0400, Christopher Harvey wrote: 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 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. Signed-off-by: Christopher Harvey char...@matrox.com 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 -- 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 majord...@vger.kernel.org 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
On Thu, Nov 15, 2012 at 05:18:44PM +0200, Artem Bityutskiy wrote: On Thu, 2012-11-15 at 09:48 -0500, Christopher Harvey wrote: On Thu, Nov 15, 2012 at 01:02:09PM +0200, Artem Bityutskiy wrote: On Mon, 2012-10-29 at 15:51 -0400, Christopher Harvey wrote: 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 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. Signed-off-by: Christopher Harvey char...@matrox.com 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. 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
On Mon, Oct 29, 2012 at 02:49:03PM +0100, Ivan Djelic wrote:
On Fri, Oct 26, 2012 at 08:36:43PM +0100, Christopher Harvey wrote:
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.
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
Ok, makes sense. Thanks for pointing that out. I'll update the wording.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -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);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND addresses
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 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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -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);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] mtd: omap: nand: Remove 0xFF's that prefixed 16bit NAND commands
On Fri, Oct 19, 2012 at 01:42:52PM -0400, Christopher Harvey wrote:
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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..6e1c1e5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -232,16 +232,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);
}
}
Ping?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] 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(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] 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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -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);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] 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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b31386..ae6738f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -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);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..9f429dc 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -232,16 +232,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 = cmd, info-reg.gpmc_nand_data;
+
+ if (info-nand.options NAND_BUSWIDTH_16)
+ writew(cmd, reg);
+ else
+ writeb(cmd, reg);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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.
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/mtd/nand/omap2.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..6e1c1e5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -232,16 +232,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);
}
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] 16 bit NAND fix, request for testers
just a small patch to access 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. 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(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] usb: musb: adding multi instance support
On Thu, Aug 02, 2012 at 05:42:43PM +0530, Ravi Babu wrote: This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to linux-omap (master branch) + Vaibhav baseport patches on his tree at [3] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [1] + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] + Damodar's recent patch at [2] and have been tested on Beaglebone board. Any hints as to if or when this will be applied to the following repository? http://arago-project.org/git/projects/linux-omap3.git?p=projects/linux-omap3.git;a=summary thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
