* [U-Boot] [PATCH v5 1/5] mtd: nand: don't use read_buf for 8-bit ONFI transfers
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
@ 2014-05-05 19:16 ` Pekon Gupta
2014-06-06 21:54 ` [U-Boot] [U-Boot, v5, " Tom Rini
2014-05-05 19:16 ` [U-Boot] [PATCH v5 2/5] mtd: nand: force NAND_CMD_READID onto 8-bit bus Pekon Gupta
` (4 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Pekon Gupta @ 2014-05-05 19:16 UTC (permalink / raw)
To: u-boot
From: Brian Norris <computersforpeace@gmail.com>
Porting below commit from linux-tree, preserving original authorship & commit log
commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
Author: Brian Norris <computersforpeace@gmail.com>
mtd: nand: don't use read_buf for 8-bit ONFI transfers
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree)
Author: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().
Signed-off-by: Pekon Gupta <pekon@ti.com>
---
drivers/mtd/nand/nand_base.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1ce55fd..5d3232c 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2582,7 +2582,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
int *busw)
{
struct nand_onfi_params *p = &chip->onfi_params;
- int i;
+ int i, j;
int val;
/* Try ONFI for unknown chip or LP */
@@ -2593,7 +2593,8 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
for (i = 0; i < 3; i++) {
- chip->read_buf(mtd, (uint8_t *)p, sizeof(*p));
+ for (j = 0; j < sizeof(*p); j++)
+ ((uint8_t *)p)[j] = chip->read_byte(mtd);
if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
le16_to_cpu(p->crc)) {
pr_info("ONFI param page %d valid\n", i);
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 16+ messages in thread* [U-Boot] [U-Boot, v5, 1/5] mtd: nand: don't use read_buf for 8-bit ONFI transfers
2014-05-05 19:16 ` [U-Boot] [PATCH v5 1/5] mtd: nand: don't use read_buf for 8-bit ONFI transfers Pekon Gupta
@ 2014-06-06 21:54 ` Tom Rini
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rini @ 2014-06-06 21:54 UTC (permalink / raw)
To: u-boot
On Tue, May 06, 2014 at 12:46:16AM +0530, pekon gupta wrote:
> From: Brian Norris <computersforpeace@gmail.com>
>
> Porting below commit from linux-tree, preserving original authorship & commit log
> commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
> Author: Brian Norris <computersforpeace@gmail.com>
> mtd: nand: don't use read_buf for 8-bit ONFI transfers
>
> Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
> devices, we need to avoid the upper I/O[16:9] bits. See the following
> commit for reference:
>
> commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree)
> Author: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Date: Thu Dec 5 22:22:04 2013 +0100
>
> mtd: nand: don't use {read,write}_buf for 8-bit transfers
>
> Now, I think that all barriers to probing ONFI on x16 devices are
> removed, so remove the check from nand_flash_detect_onfi().
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
Applied to u-boot-ti/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140606/031bbec8/attachment.pgp>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] [PATCH v5 2/5] mtd: nand: force NAND_CMD_READID onto 8-bit bus
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
2014-05-05 19:16 ` [U-Boot] [PATCH v5 1/5] mtd: nand: don't use read_buf for 8-bit ONFI transfers Pekon Gupta
@ 2014-05-05 19:16 ` Pekon Gupta
2014-06-06 21:54 ` [U-Boot] [U-Boot, v5, " Tom Rini
2014-05-05 19:16 ` [U-Boot] [PATCH v5 3/5] mtd: nand: fix GET/SET_FEATURES address on 16-bit devices Pekon Gupta
` (3 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Pekon Gupta @ 2014-05-05 19:16 UTC (permalink / raw)
To: u-boot
From: Brian Norris <computersforpeace@gmail.com>
As per following Sections in ONFI Spec, NAND_CMD_READID should use only
lower 8-bit for transfering command, address and data even on x16 NAND device.
*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus. The host shall not issue commands that use a word data width on x16
devices until the host determines the device supports a 16-bit data bus width
in the parameter page."
*Section: Bus Width Requirements*
"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."
Thus porting following commit from linux-kernel to ensure that column address
is not altered to align to x16 bus when issuing NAND_CMD_READID command.
commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
mtd: nand: force NAND_CMD_READID onto 8-bit bus
Author: Brian Norris <computersforpeace@gmail.com> (preserving authorship)
The NAND command helpers tend to automatically shift the column address
for x16 bus devices, since most commands expect a word address, not a
byte address. The Read ID command, however, expects an 8-bit address
(i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
0x20).
This fixes the column address for a few drivers which imitate the
nand_base defaults.
Signed-off-by: Pekon Gupta <pekon@ti.com>
---
drivers/mtd/nand/am335x_spl_bch.c | 2 +-
drivers/mtd/nand/atmel_nand.c | 2 +-
drivers/mtd/nand/nand_base.c | 6 ++++--
drivers/mtd/nand/nand_spl_simple.c | 2 +-
include/linux/mtd/nand.h | 10 ++++++++++
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/am335x_spl_bch.c b/drivers/mtd/nand/am335x_spl_bch.c
index c84851b..86572a2 100644
--- a/drivers/mtd/nand/am335x_spl_bch.c
+++ b/drivers/mtd/nand/am335x_spl_bch.c
@@ -55,7 +55,7 @@ static int nand_command(int block, int page, uint32_t offs,
}
/* Shift the offset from byte addressing to word addressing. */
- if (this->options & NAND_BUSWIDTH_16)
+ if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd))
offs >>= 1;
/* Set ALE and clear CLE to start address cycle */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index e1fc48f..e73834d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1195,7 +1195,7 @@ static int nand_command(int block, int page, uint32_t offs, u8 cmd)
hwctrl(&mtd, cmd, NAND_CTRL_CLE | NAND_CTRL_CHANGE);
- if (this->options & NAND_BUSWIDTH_16)
+ if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd))
offs >>= 1;
hwctrl(&mtd, offs & 0xff, NAND_CTRL_ALE | NAND_CTRL_CHANGE);
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5d3232c..376976d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -575,7 +575,8 @@ static void nand_command(struct mtd_info *mtd, unsigned int command,
/* Serially input address */
if (column != -1) {
/* Adjust columns for 16 bit buswidth */
- if (chip->options & NAND_BUSWIDTH_16)
+ if ((chip->options & NAND_BUSWIDTH_16) &&
+ !nand_opcode_8bits(command))
column >>= 1;
chip->cmd_ctrl(mtd, column, ctrl);
ctrl &= ~NAND_CTRL_CHANGE;
@@ -668,7 +669,8 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command,
/* Serially input address */
if (column != -1) {
/* Adjust columns for 16 bit buswidth */
- if (chip->options & NAND_BUSWIDTH_16)
+ if ((chip->options & NAND_BUSWIDTH_16) &&
+ !nand_opcode_8bits(command))
column >>= 1;
chip->cmd_ctrl(mtd, column, ctrl);
ctrl &= ~NAND_CTRL_CHANGE;
diff --git a/drivers/mtd/nand/nand_spl_simple.c b/drivers/mtd/nand/nand_spl_simple.c
index cead4b5..700ca32 100644
--- a/drivers/mtd/nand/nand_spl_simple.c
+++ b/drivers/mtd/nand/nand_spl_simple.c
@@ -78,7 +78,7 @@ static int nand_command(int block, int page, uint32_t offs,
}
/* Shift the offset from byte addressing to word addressing. */
- if (this->options & NAND_BUSWIDTH_16)
+ if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd))
offs >>= 1;
/* Begin command latch cycle */
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 0546565..4be8858 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -719,4 +719,14 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip)
}
#endif
+/**
+ * Check if the opcode's address should be sent only on the lower 8 bits
+ * @command: opcode to check
+ */
+static inline int nand_opcode_8bits(unsigned int command)
+{
+ return command == NAND_CMD_READID;
+}
+
+
#endif /* __LINUX_MTD_NAND_H */
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 16+ messages in thread* [U-Boot] [U-Boot, v5, 2/5] mtd: nand: force NAND_CMD_READID onto 8-bit bus
2014-05-05 19:16 ` [U-Boot] [PATCH v5 2/5] mtd: nand: force NAND_CMD_READID onto 8-bit bus Pekon Gupta
@ 2014-06-06 21:54 ` Tom Rini
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rini @ 2014-06-06 21:54 UTC (permalink / raw)
To: u-boot
On Tue, May 06, 2014 at 12:46:17AM +0530, pekon gupta wrote:
> From: Brian Norris <computersforpeace@gmail.com>
>
> As per following Sections in ONFI Spec, NAND_CMD_READID should use only
> lower 8-bit for transfering command, address and data even on x16 NAND device.
>
> *Section: Target Initialization"
> "The Read ID and Read Parameter Page commands only use the lower 8-bits of the
> data bus. The host shall not issue commands that use a word data width on x16
> devices until the host determines the device supports a 16-bit data bus width
> in the parameter page."
>
> *Section: Bus Width Requirements*
> "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."
>
> Thus porting following commit from linux-kernel to ensure that column address
> is not altered to align to x16 bus when issuing NAND_CMD_READID command.
>
> commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
> mtd: nand: force NAND_CMD_READID onto 8-bit bus
> Author: Brian Norris <computersforpeace@gmail.com> (preserving authorship)
>
> The NAND command helpers tend to automatically shift the column address
> for x16 bus devices, since most commands expect a word address, not a
> byte address. The Read ID command, however, expects an 8-bit address
> (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
> 0x20).
>
> This fixes the column address for a few drivers which imitate the
> nand_base defaults.
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
Applied to u-boot-ti/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140606/f6752c41/attachment.pgp>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] [PATCH v5 3/5] mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
2014-05-05 19:16 ` [U-Boot] [PATCH v5 1/5] mtd: nand: don't use read_buf for 8-bit ONFI transfers Pekon Gupta
2014-05-05 19:16 ` [U-Boot] [PATCH v5 2/5] mtd: nand: force NAND_CMD_READID onto 8-bit bus Pekon Gupta
@ 2014-05-05 19:16 ` Pekon Gupta
2014-06-06 21:54 ` [U-Boot] [U-Boot, v5, " Tom Rini
2014-05-05 19:16 ` [U-Boot] [PATCH v5 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width Pekon Gupta
` (2 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Pekon Gupta @ 2014-05-05 19:16 UTC (permalink / raw)
To: u-boot
From: David Mosberger <davidm@egauge.net>
As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need
byte-addressing on 16-bit devices.
*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus. The host shall not issue commands that use a word data width on x16
devices until the host determines the device supports a 16-bit data bus width
in the parameter page."
*Section: Bus Width Requirements*
"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."
So porting following commit from linux kernel
commit e34fcb07a6d57411de6e15a47724fbe92c5caa42
Author: David Mosberger <davidm@egauge.net> (preserving authorship)
mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
Signed-off-by: Pekon Gupta <pekon@ti.com>
---
include/linux/mtd/nand.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 4be8858..991bd8e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -725,7 +725,16 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip)
*/
static inline int nand_opcode_8bits(unsigned int command)
{
- return command == NAND_CMD_READID;
+ switch (command) {
+ case NAND_CMD_READID:
+ case NAND_CMD_PARAM:
+ case NAND_CMD_GET_FEATURES:
+ case NAND_CMD_SET_FEATURES:
+ return 1;
+ default:
+ break;
+ }
+ return 0;
}
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 16+ messages in thread* [U-Boot] [U-Boot, v5, 3/5] mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
2014-05-05 19:16 ` [U-Boot] [PATCH v5 3/5] mtd: nand: fix GET/SET_FEATURES address on 16-bit devices Pekon Gupta
@ 2014-06-06 21:54 ` Tom Rini
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rini @ 2014-06-06 21:54 UTC (permalink / raw)
To: u-boot
On Tue, May 06, 2014 at 12:46:18AM +0530, pekon gupta wrote:
> From: David Mosberger <davidm@egauge.net>
>
> As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need
> byte-addressing on 16-bit devices.
>
> *Section: Target Initialization"
> "The Read ID and Read Parameter Page commands only use the lower 8-bits of the
> data bus. The host shall not issue commands that use a word data width on x16
> devices until the host determines the device supports a 16-bit data bus width
> in the parameter page."
>
> *Section: Bus Width Requirements*
> "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."
>
> So porting following commit from linux kernel
> commit e34fcb07a6d57411de6e15a47724fbe92c5caa42
> Author: David Mosberger <davidm@egauge.net> (preserving authorship)
> mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
Applied to u-boot-ti/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140606/5881bd43/attachment.pgp>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] [PATCH v5 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
` (2 preceding siblings ...)
2014-05-05 19:16 ` [U-Boot] [PATCH v5 3/5] mtd: nand: fix GET/SET_FEATURES address on 16-bit devices Pekon Gupta
@ 2014-05-05 19:16 ` Pekon Gupta
2014-06-06 21:54 ` [U-Boot] [U-Boot, v5, " Tom Rini
2014-05-05 19:16 ` [U-Boot] [PATCH v5 5/5] omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT Pekon Gupta
2014-05-27 11:48 ` [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Gupta, Pekon
5 siblings, 1 reply; 16+ messages in thread
From: Pekon Gupta @ 2014-05-05 19:16 UTC (permalink / raw)
To: u-boot
GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL: SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
which is called before probing for devices, hence any ONFI parameter
information is not available during GPMC initialization.
Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.
This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.
Signed-off-by: Pekon Gupta <pekon@ti.com>
---
doc/README.nand | 18 ++++++++++++++++++
drivers/mtd/nand/omap_gpmc.c | 13 +++++++++----
include/configs/am3517_crane.h | 1 +
include/configs/devkit8000.h | 1 +
include/configs/dig297.h | 1 +
include/configs/omap3_beagle.h | 1 +
include/configs/omap3_evm_common.h | 2 +-
include/configs/omap3_igep00x0.h | 1 +
include/configs/omap3_logic.h | 1 +
include/configs/omap3_overo.h | 1 +
include/configs/omap3_zoom1.h | 1 +
include/configs/tam3517-common.h | 1 +
include/configs/tao3530.h | 1 +
13 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand
index b91f198..2bc5b39 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -190,6 +190,24 @@ Configuration Options:
This is used by SoC platforms which do not have built-in ELM
hardware engine required for BCH ECC correction.
+ CONFIG_SYS_NAND_BUSWIDTH_16BIT
+ Indicates that NAND device has 16-bit wide data-bus. In absence of this
+ config, bus-width of NAND device is assumed to be either 8-bit and later
+ determined by reading ONFI params.
+ Above config is useful when NAND device's bus-width information cannot
+ be determined from on-chip ONFI params, like in following scenarios:
+ - SPL boot does not support reading of ONFI parameters. This is done to
+ keep SPL code foot-print small.
+ - In current U-Boot flow using nand_init(), driver initialization
+ happens in board_nand_init() which is called before any device probe
+ (nand_scan_ident + nand_scan_tail), thus device's ONFI parameters are
+ not available while configuring controller. So a static CONFIG_NAND_xx
+ is needed to know the device's bus-width in advance.
+ Some drivers using above config are:
+ drivers/mtd/nand/mxc_nand.c
+ drivers/mtd/nand/ndfc.c
+ drivers/mtd/nand/omap_gpmc.c
+
Platform specific options
=========================
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 325ebfd..89f8c0a 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -782,13 +782,18 @@ int board_nand_init(struct nand_chip *nand)
nand->priv = &omap_nand_info;
nand->cmd_ctrl = omap_nand_hwcontrol;
nand->options |= NAND_NO_PADDING | NAND_CACHEPRG;
- /* If we are 16 bit dev, our gpmc config tells us that */
- if ((readl(&gpmc_cfg->cs[cs].config1) & 0x3000) == 0x1000)
- nand->options |= NAND_BUSWIDTH_16;
-
nand->chip_delay = 100;
nand->ecc.layout = &omap_ecclayout;
+ /* configure driver and controller based on NAND device bus-width */
+ gpmc_config = readl(&gpmc_cfg->cs[cs].config1);
+#if defined(CONFIG_SYS_NAND_BUSWIDTH_16BIT)
+ nand->options |= NAND_BUSWIDTH_16;
+ writel(gpmc_config | (0x1 << 12), &gpmc_cfg->cs[cs].config1);
+#else
+ nand->options &= ~NAND_BUSWIDTH_16;
+ writel(gpmc_config & ~(0x1 << 12), &gpmc_cfg->cs[cs].config1);
+#endif
/* select ECC scheme */
#if defined(CONFIG_NAND_OMAP_ECCSCHEME)
err = omap_select_ecc_scheme(nand, CONFIG_NAND_OMAP_ECCSCHEME,
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 4407b45..ad4cbd8 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -329,6 +329,7 @@
#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 16a00eb..5308790 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -314,6 +314,7 @@
#define CONFIG_SPL_BSS_MAX_SIZE 0x80000
/* NAND boot config */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index af6f56b..ce205e9 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -138,6 +138,7 @@
* Board NAND Info.
*/
#define CONFIG_NAND_OMAP_GPMC
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */
/* to access nand */
#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 0b57421..793d651 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -422,6 +422,7 @@
#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
diff --git a/include/configs/omap3_evm_common.h b/include/configs/omap3_evm_common.h
index 7f3424b..ae4ce63 100644
--- a/include/configs/omap3_evm_common.h
+++ b/include/configs/omap3_evm_common.h
@@ -120,7 +120,7 @@
/* Max number of NAND devices */
#define CONFIG_SYS_MAX_NAND_DEVICE 1
-
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
/* Timeout values (in ticks) */
#define CONFIG_SYS_FLASH_ERASE_TOUT (100 * CONFIG_SYS_HZ)
#define CONFIG_SYS_FLASH_WRITE_TOUT (100 * CONFIG_SYS_HZ)
diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h
index d56d5b0..79daabd 100644
--- a/include/configs/omap3_igep00x0.h
+++ b/include/configs/omap3_igep00x0.h
@@ -187,6 +187,7 @@
/* NAND boot config */
#ifdef CONFIG_NAND
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
index 0d03c75..8dcbba3 100644
--- a/include/configs/omap3_logic.h
+++ b/include/configs/omap3_logic.h
@@ -141,6 +141,7 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
/* NAND devices */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_JFFS2_NAND
/* nand device jffs2 lives on */
#define CONFIG_JFFS2_DEV "nand0"
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 007e27f..661d2ec 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -312,6 +312,7 @@
#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index f0fa96e..e4c50af 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -140,6 +140,7 @@
/* CS0 */
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */
/* devices */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_JFFS2_NAND
/* nand device jffs2 lives on */
#define CONFIG_JFFS2_DEV "nand0"
diff --git a/include/configs/tam3517-common.h b/include/configs/tam3517-common.h
index 3522c1a..eda536b 100644
--- a/include/configs/tam3517-common.h
+++ b/include/configs/tam3517-common.h
@@ -249,6 +249,7 @@
#define CONFIG_SPL_BSS_MAX_SIZE 0x80000
/* NAND boot config */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
#define CONFIG_SYS_NAND_PAGE_COUNT 64
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
#define CONFIG_SYS_NAND_OOBSIZE 64
diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h
index 9c04c23..4471935 100644
--- a/include/configs/tao3530.h
+++ b/include/configs/tao3530.h
@@ -141,6 +141,7 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */
/* devices */
+#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16
/* Environment information */
#define CONFIG_BOOTDELAY 3
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 16+ messages in thread* [U-Boot] [U-Boot, v5, 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width
2014-05-05 19:16 ` [U-Boot] [PATCH v5 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width Pekon Gupta
@ 2014-06-06 21:54 ` Tom Rini
0 siblings, 0 replies; 16+ messages in thread
From: Tom Rini @ 2014-06-06 21:54 UTC (permalink / raw)
To: u-boot
On Tue, May 06, 2014 at 12:46:19AM +0530, pekon gupta wrote:
> GPMC controller needs to be configured based on bus-width of the NAND device
> connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
> parameters is not possible in following situations:
> SPL: SPL NAND drivers does not support ONFI parameter reading.
> U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
> which is called before probing for devices, hence any ONFI parameter
> information is not available during GPMC initialization.
>
> Thus, OMAP NAND driver expected board developers to explicitely write GPMC
> configurations specific to NAND device attached on board in board files itself.
> But this was troublesome for board manufacturers as they need to dive into
> lengthy platform & SoC documents to find details of GPMC registers and
> appropriate configurations to get NAND device working.
>
> This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
> hich indicates that connected NAND device has x16 bus-width. And then based on
> this config GPMC driver itself initializes itself based on NAND bus-width. This
> keeps board developers free from knowing GPMC controller specific internals.
>
> Signed-off-by: Pekon Gupta <pekon@ti.com>
Applied to u-boot-ti/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140606/06653532/attachment.pgp>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] [PATCH v5 5/5] omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
` (3 preceding siblings ...)
2014-05-05 19:16 ` [U-Boot] [PATCH v5 4/5] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width Pekon Gupta
@ 2014-05-05 19:16 ` Pekon Gupta
2014-06-06 21:54 ` [U-Boot] [U-Boot, v5, " Tom Rini
2014-05-27 11:48 ` [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Gupta, Pekon
5 siblings, 1 reply; 16+ messages in thread
From: Pekon Gupta @ 2014-05-05 19:16 UTC (permalink / raw)
To: u-boot
OMAP3 used GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT macros
to configure GPMC controller for x7 or x8 bit device connected to its interface.
Now this information is encoded in CONFIG_SYS_NAND_DEVICE_WIDTH macro, so above
macros can be completely removed.
Signed-off-by: Pekon Gupta <pekon@ti.com>
---
arch/arm/cpu/armv7/omap3/mem.c | 12 ------------
arch/arm/include/asm/arch-omap3/mem.h | 8 --------
board/compulab/cm_t35/cm_t35.c | 12 ++++++------
include/configs/cm_t335.h | 1 -
include/configs/cm_t35.h | 1 -
include/configs/pengwyn.h | 1 -
include/configs/tao3530.h | 1 -
include/configs/tseries.h | 1 -
8 files changed, 6 insertions(+), 31 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/mem.c b/arch/arm/cpu/armv7/omap3/mem.c
index e649409..1832aff 100644
--- a/arch/arm/cpu/armv7/omap3/mem.c
+++ b/arch/arm/cpu/armv7/omap3/mem.c
@@ -21,17 +21,6 @@
struct gpmc *gpmc_cfg;
#if defined(CONFIG_CMD_NAND)
-#if defined(GPMC_NAND_ECC_SP_x8_LAYOUT) || defined(GPMC_NAND_ECC_LP_x8_LAYOUT)
-static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
- SMNAND_GPMC_CONFIG1,
- SMNAND_GPMC_CONFIG2,
- SMNAND_GPMC_CONFIG3,
- SMNAND_GPMC_CONFIG4,
- SMNAND_GPMC_CONFIG5,
- SMNAND_GPMC_CONFIG6,
- 0,
-};
-#else
static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG1,
M_NAND_GPMC_CONFIG2,
@@ -40,7 +29,6 @@ static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
M_NAND_GPMC_CONFIG5,
M_NAND_GPMC_CONFIG6, 0
};
-#endif
#endif /* CONFIG_CMD_NAND */
#if defined(CONFIG_CMD_ONENAND)
diff --git a/arch/arm/include/asm/arch-omap3/mem.h b/arch/arm/include/asm/arch-omap3/mem.h
index 1804191..d90fe16 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -353,14 +353,6 @@ enum {
#define GPMC_CS_ENABLE 0x1
-#define SMNAND_GPMC_CONFIG1 0x00000800
-#define SMNAND_GPMC_CONFIG2 0x00141400
-#define SMNAND_GPMC_CONFIG3 0x00141400
-#define SMNAND_GPMC_CONFIG4 0x0F010F01
-#define SMNAND_GPMC_CONFIG5 0x010C1414
-#define SMNAND_GPMC_CONFIG6 0x1F0F0A80
-#define SMNAND_GPMC_CONFIG7 0x00000C44
-
#define M_NAND_GPMC_CONFIG1 0x00001800
#define M_NAND_GPMC_CONFIG2 0x00141400
#define M_NAND_GPMC_CONFIG3 0x00141400
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 00bcf41..0944903 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -54,12 +54,12 @@ static u32 gpmc_net_config[GPMC_MAX_REG] = {
};
static u32 gpmc_nand_config[GPMC_MAX_REG] = {
- SMNAND_GPMC_CONFIG1,
- SMNAND_GPMC_CONFIG2,
- SMNAND_GPMC_CONFIG3,
- SMNAND_GPMC_CONFIG4,
- SMNAND_GPMC_CONFIG5,
- SMNAND_GPMC_CONFIG6,
+ M_NAND_GPMC_CONFIG1,
+ M_NAND_GPMC_CONFIG2,
+ M_NAND_GPMC_CONFIG3,
+ M_NAND_GPMC_CONFIG4,
+ M_NAND_GPMC_CONFIG5,
+ M_NAND_GPMC_CONFIG6,
0,
};
diff --git a/include/configs/cm_t335.h b/include/configs/cm_t335.h
index 26b615b..4d1dd28 100644
--- a/include/configs/cm_t335.h
+++ b/include/configs/cm_t335.h
@@ -141,7 +141,6 @@
#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x200000
#define CONFIG_CMD_NAND
-#define GPMC_NAND_ECC_LP_x8_LAYOUT
#define MTDIDS_DEFAULT "nand0=nand"
#define MTDPARTS_DEFAULT "mtdparts=nand:2m(spl)," \
"1m(u-boot),1m(u-boot-env)," \
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index aae05e0..8c60e22 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -158,7 +158,6 @@
/* CS0 */
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */
/* devices */
-#define GPMC_NAND_ECC_LP_x8_LAYOUT
/* Environment information */
#define CONFIG_BOOTDELAY 3
diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h
index fc25966..8510405 100644
--- a/include/configs/pengwyn.h
+++ b/include/configs/pengwyn.h
@@ -149,7 +149,6 @@
#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x80000
-#define GPMC_NAND_ECC_LP_x8_LAYOUT 1
#define MTDIDS_DEFAULT "nand0=omap2-nand.0"
#define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:128k(SPL)," \
"128k(SPL.backup1)," \
diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h
index 4471935..1b0fee9 100644
--- a/include/configs/tao3530.h
+++ b/include/configs/tao3530.h
@@ -137,7 +137,6 @@
#define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */
/* to access nand at */
/* CS0 */
-#define GPMC_NAND_ECC_LP_x16_LAYOUT
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */
/* devices */
diff --git a/include/configs/tseries.h b/include/configs/tseries.h
index 8fb87ac..948f88a 100644
--- a/include/configs/tseries.h
+++ b/include/configs/tseries.h
@@ -157,7 +157,6 @@
/* don't change OMAP_ELM, ECCSCHEME. ROM code only supports this */
#define CONFIG_NAND_OMAP_ELM
#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW
-#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024)
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
--
1.8.5.1.163.gd7aced9
^ permalink raw reply related [flat|nested] 16+ messages in thread* [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices
2014-05-05 19:16 [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Pekon Gupta
` (4 preceding siblings ...)
2014-05-05 19:16 ` [U-Boot] [PATCH v5 5/5] omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT Pekon Gupta
@ 2014-05-27 11:48 ` Gupta, Pekon
2014-05-27 17:21 ` [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices) Scott Wood
5 siblings, 1 reply; 16+ messages in thread
From: Gupta, Pekon @ 2014-05-27 11:48 UTC (permalink / raw)
To: u-boot
Hello Scott, Tom,
>From: Gupta, Pekon
>
>*changes v4 -> v5*
>[PATCH 1/5] <no change>
>[PATCH 2/5] fixed compilation error for OMAP3 platforms
>[PATCH 3/5] <no change>
>[PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to
>indicate NAND device bus-width
> instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate
>NAND device bus-width
>[PATCH 5/5] additional cleanup in include/configs/cm_t35.h
>Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
>Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
>
This series few other patch series are awaiting response from
long time. In particular without this series many of the platforms
will _not_ work out-of-the box with x16 NAND device. Hence,
please give these patches a look and accept them if all okay.
Also, another series which has simple changes and clean-up is
awaiting acceptance from long.
[PATCH v2 0/7] mtd: nand: omap: clean up of omap_elm and omap_gpmc driver
This all will save some effort in resolving merge conflicts and rebases,
while moving forward with new patches.
with regards, pekon
>
>*changes v3 -> v4*
>[PATCH 1/5] <no update>
>[PATCH 2/5] <new> mtd: nand: force NAND_CMD_READID onto 8-bit bus
>[PATCH 3/5] <new> mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
>[PATCH 4/5] same as [PATCH v2 2/3] rebased over http://lists.denx.de/pipermail/u-boot/2014-
>April/177323.html
>[PATCH 5/5] <no update>
>
>
>*changes v2 -> v3*
>[PATCH v3 1/3] (new) porting Brian Norri's patch from linux tree
> This patch allows reading of ONFI params independent of controller configuration
> and NAND device width.
>[PATCH v3 2/2] rebase [PATCH v2 2/4] on latest release
>[PATCH v3 3/3] (new) cleaned remaining GPMC_NAND_ECC_LP_xx macros from OMAP3 platform
>Compile Tested#> ./MAKEALL -s omap3 -s omap4 -s omap5 -s dra7xx -s am33xx
>
>
>*changes v1 -> v2*
>[PATCH v2 1/4]:
> - dropped NAND_BUSWIDTH_AUTO, instead using CONFIG_SYS_NAND_ONFI_DETECTION
> - added check in nand_flash_detect_onfi() for x8 mode
>[PATCH v2 2/4]: (new) Adds CONFIG_SYS_NAND_DEVICE_WIDTH
> - updated for auto-detection of bus-width in non-SPL and ONFI_DETECTION mode
> Refer: http://lists.denx.de/pipermail/u-boot/2013-September/163748.html
>[PATCH v2 3/4] <no update>
>[PATCH v2 4/4] disabled Pulls on output only I/O pads.
> - updated commit description to add details about NAND cape
>
>
>*original v1*
>This series includes independent patch-sets aiming to enable x16 NAND
>support on AM33xx boards (like beaglebone-LT).
>[PATCH 1/4]: This patch is ported from linux driver/mtd/nand to allow detection
> device-width of NAND by reading ONFI parameter page.
>[PATCH 2/4]: enable NAND_BUSWIDTH_AUTO feature in omap_nand.c
>[PATCH 3/4]: cleaning of GPMC configs for NAND and NOR
>
>Brian Norris (2):
> mtd: nand: don't use read_buf for 8-bit ONFI transfers
> mtd: nand: force NAND_CMD_READID onto 8-bit bus
>
>David Mosberger (1):
> mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
>
>Pekon Gupta (2):
> mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND
> device bus-width
> omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and
> GPMC_NAND_ECC_LP_x16_LAYOUT
>
> arch/arm/cpu/armv7/omap3/mem.c | 12 ------------
> arch/arm/include/asm/arch-omap3/mem.h | 8 --------
> board/compulab/cm_t35/cm_t35.c | 12 ++++++------
> doc/README.nand | 18 ++++++++++++++++++
> drivers/mtd/nand/am335x_spl_bch.c | 2 +-
> drivers/mtd/nand/atmel_nand.c | 2 +-
> drivers/mtd/nand/nand_base.c | 11 +++++++----
> drivers/mtd/nand/nand_spl_simple.c | 2 +-
> drivers/mtd/nand/omap_gpmc.c | 13 +++++++++----
> include/configs/am3517_crane.h | 1 +
> include/configs/cm_t335.h | 1 -
> include/configs/cm_t35.h | 1 -
> include/configs/devkit8000.h | 1 +
> include/configs/dig297.h | 1 +
> include/configs/omap3_beagle.h | 1 +
> include/configs/omap3_evm_common.h | 2 +-
> include/configs/omap3_igep00x0.h | 1 +
> include/configs/omap3_logic.h | 1 +
> include/configs/omap3_overo.h | 1 +
> include/configs/omap3_zoom1.h | 1 +
> include/configs/pengwyn.h | 1 -
> include/configs/tam3517-common.h | 1 +
> include/configs/tao3530.h | 2 +-
> include/configs/tseries.h | 1 -
> include/linux/mtd/nand.h | 19 +++++++++++++++++++
> 25 files changed, 73 insertions(+), 43 deletions(-)
>
>--
>1.8.5.1.163.gd7aced9
^ permalink raw reply [flat|nested] 16+ messages in thread* [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices)
2014-05-27 11:48 ` [U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices Gupta, Pekon
@ 2014-05-27 17:21 ` Scott Wood
2014-05-28 21:00 ` Tom Rini
0 siblings, 1 reply; 16+ messages in thread
From: Scott Wood @ 2014-05-27 17:21 UTC (permalink / raw)
To: u-boot
On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
> Hello Scott, Tom,
>
>
> >From: Gupta, Pekon
> >
> >*changes v4 -> v5*
> >[PATCH 1/5] <no change>
> >[PATCH 2/5] fixed compilation error for OMAP3 platforms
> >[PATCH 3/5] <no change>
> >[PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to
> >indicate NAND device bus-width
> > instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate
> >NAND device bus-width
> >[PATCH 5/5] additional cleanup in include/configs/cm_t35.h
> >Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
> >Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
> >
>
> This series few other patch series are awaiting response from
> long time.
Sorry for the delay -- I've been fairly busy, and don't usually get
around to processing U-Boot patches until after the merge window closes.
The IRC channel topic has been lying and saying the merge window is
still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that
the merge window is open and will close in negative 24 days).
Given that I don't do much with NAND myself these days, that the patch
volume is higher than when I started as NAND custodian, and that I now
have maintainership duties in Linux competing for my time, I'm wondering
if someone else (maybe you or Heiko?) wants to step into the NAND
custodian role.
-Scott
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices)
2014-05-27 17:21 ` [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices) Scott Wood
@ 2014-05-28 21:00 ` Tom Rini
2014-05-29 5:28 ` Heiko Schocher
0 siblings, 1 reply; 16+ messages in thread
From: Tom Rini @ 2014-05-28 21:00 UTC (permalink / raw)
To: u-boot
On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
> On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
> > Hello Scott, Tom,
> >
> >
> > >From: Gupta, Pekon
> > >
> > >*changes v4 -> v5*
> > >[PATCH 1/5] <no change>
> > >[PATCH 2/5] fixed compilation error for OMAP3 platforms
> > >[PATCH 3/5] <no change>
> > >[PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to
> > >indicate NAND device bus-width
> > > instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate
> > >NAND device bus-width
> > >[PATCH 5/5] additional cleanup in include/configs/cm_t35.h
> > >Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
> > >Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
> > >
> >
> > This series few other patch series are awaiting response from
> > long time.
>
> Sorry for the delay -- I've been fairly busy, and don't usually get
> around to processing U-Boot patches until after the merge window closes.
> The IRC channel topic has been lying and saying the merge window is
> still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that
> the merge window is open and will close in negative 24 days).
Bah, I always forget to update those parts as well, beyond the actual
releases...
> Given that I don't do much with NAND myself these days, that the patch
> volume is higher than when I started as NAND custodian, and that I now
> have maintainership duties in Linux competing for my time, I'm wondering
> if someone else (maybe you or Heiko?) wants to step into the NAND
> custodian role.
It's been a pleasure working with you. Pekon? Heiko? Either of you
interested in this particular role? Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140528/68240243/attachment.pgp>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices)
2014-05-28 21:00 ` Tom Rini
@ 2014-05-29 5:28 ` Heiko Schocher
2014-05-30 4:54 ` Gupta, Pekon
0 siblings, 1 reply; 16+ messages in thread
From: Heiko Schocher @ 2014-05-29 5:28 UTC (permalink / raw)
To: u-boot
Hello Tom,
Am 28.05.2014 23:00, schrieb Tom Rini:
> On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
>> On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
>>> Hello Scott, Tom,
>>>
>>>
>>>> From: Gupta, Pekon
>>>>
>>>> *changes v4 -> v5*
>>>> [PATCH 1/5]<no change>
>>>> [PATCH 2/5] fixed compilation error for OMAP3 platforms
>>>> [PATCH 3/5]<no change>
>>>> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to
>>>> indicate NAND device bus-width
>>>> instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate
>>>> NAND device bus-width
>>>> [PATCH 5/5] additional cleanup in include/configs/cm_t35.h
>>>> Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
>>>> Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
>>>>
>>>
>>> This series few other patch series are awaiting response from
>>> long time.
>>
>> Sorry for the delay -- I've been fairly busy, and don't usually get
>> around to processing U-Boot patches until after the merge window closes.
>> The IRC channel topic has been lying and saying the merge window is
>> still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that
>> the merge window is open and will close in negative 24 days).
>
> Bah, I always forget to update those parts as well, beyond the actual
> releases...
>
>> Given that I don't do much with NAND myself these days, that the patch
>> volume is higher than when I started as NAND custodian, and that I now
>> have maintainership duties in Linux competing for my time, I'm wondering
>> if someone else (maybe you or Heiko?) wants to step into the NAND
>> custodian role.
>
> It's been a pleasure working with you. Pekon? Heiko? Either of you
> interested in this particular role? Thanks!
I am not a NAND expert and I am little bit under water currently...
(but if nobody else volunteers I can try it ...)
Pekon?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] NAND custodian (was Re: [PATCH v5 0/5] enable support for x16 NAND devices)
2014-05-29 5:28 ` Heiko Schocher
@ 2014-05-30 4:54 ` Gupta, Pekon
0 siblings, 0 replies; 16+ messages in thread
From: Gupta, Pekon @ 2014-05-30 4:54 UTC (permalink / raw)
To: u-boot
>From: Heiko Schocher [mailto:hs at denx.de]
>>Am 28.05.2014 23:00, schrieb Tom Rini:
>>> On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
>>>> On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
[...]
>>>> This series few other patch series are awaiting response from
>>>> long time.
>>>
>>> Sorry for the delay -- I've been fairly busy, and don't usually get
>>> around to processing U-Boot patches until after the merge window closes.
>>> The IRC channel topic has been lying and saying the merge window is
>>> still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that
>>> the merge window is open and will close in negative 24 days).
>>
>> Bah, I always forget to update those parts as well, beyond the actual
>> releases...
>>
>>> Given that I don't do much with NAND myself these days, that the patch
>>> volume is higher than when I started as NAND custodian, and that I now
>>> have maintainership duties in Linux competing for my time, I'm wondering
>>> if someone else (maybe you or Heiko?) wants to step into the NAND
>>> custodian role.
>>
>> It's been a pleasure working with you. Pekon? Heiko? Either of you
>> interested in this particular role? Thanks!
>
>I am not a NAND expert and I am little bit under water currently...
>(but if nobody else volunteers I can try it ...)
>
>Pekon?
>
>bye,
>Heiko
Yes, Heiko please proceed.
I might be transitioning to new work soon. So for few months I don't
want to commit for something which I might not be able to fulfill.
But I'll surely help in reviewing the patches, apart from OMAP ones.
Also looping "Stefan Roese <sr@denx.de>" CFI flash custodian [1] as he
has helped in reviewing many OMAP and MTD/NAND patches.
Stefan ?
It would be good, if the custodianship is transferred bit gradually at
stable release, so that we don't miss any old reviews and feedback.
[1] http://www.denx.de/wiki/U-Boot/Custodians
with regards, pekon
^ permalink raw reply [flat|nested] 16+ messages in thread