[U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access

Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
------------
I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does.
Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later.
Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter.
What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup.
Test results and feedback very welcome.
Thanks, Daniel
Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c | 115 +++++++++++++++++++++++++++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-)

Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address.
The current implementation has two limitations:
a) it only works in 8-bit mode b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zonque@gmail.com --- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c | 115 +++++++++++++++++++++++++++++++++++++++++- include/linux/mtd/omap_gpmc.h | 6 ++- 3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand index 70cf768..6459f2a 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -292,6 +292,11 @@ Platform specific options Thus BCH16 can be supported on 4K page NAND.
+ CONFIG_NAND_OMAP_PREFETCH + On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC), + this options enables the code that uses the prefetch mode to speed up + read operations. + NOTE: =====
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index 1acf06b..e2d57bd 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -446,6 +446,113 @@ static int omap_correct_data_bch(struct mtd_info *mtd, uint8_t *dat, return (err) ? err : error_count; }
+#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH + +#define PREFETCH_CONFIG1_CS_SHIFT 24 +#define PREFETCH_FIFOTHRESHOLD_MAX 0x40 +#define PREFETCH_FIFOTHRESHOLD(val) ((val) << 8) +#define PREFETCH_STATUS_COUNT(val) (val & 0x00003fff) +#define PREFETCH_STATUS_FIFO_CNT(val) ((val >> 24) & 0x7F) +#define ENABLE_PREFETCH (1 << 7) + +/** + * omap_prefetch_enable - configures and starts prefetch transfer + * @fifo_th: fifo threshold to be used for read/ write + * @count: number of bytes to be transferred + * @is_write: prefetch read(0) or write post(1) mode + */ +static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write) +{ + uint32_t val; + + if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX) + return -EINVAL; + + if (readl(&gpmc_cfg->prefetch_control)) + return -EBUSY; + + /* Set the amount of bytes to be prefetched */ + writel(count, &gpmc_cfg->prefetch_config2); + + val = (cs << PREFETCH_CONFIG1_CS_SHIFT) | (is_write & 1) | + PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH; + writel(val, &gpmc_cfg->prefetch_config1); + + /* Start the prefetch engine */ + writel(1, &gpmc_cfg->prefetch_control); + + return 0; +} + +/** + * omap_prefetch_reset - disables and stops the prefetch engine + */ +static void omap_prefetch_reset(void) +{ + writel(0, &gpmc_cfg->prefetch_control); + writel(0, &gpmc_cfg->prefetch_config1); +} + +static int __read_prefetch_aligned(struct nand_chip *chip, uint32_t *buf, int len) +{ + int ret; + uint32_t cnt; + + ret = omap_prefetch_enable(PREFETCH_FIFOTHRESHOLD_MAX, len, 0); + if (ret < 0) + return ret; + + do { + int i; + + cnt = readl(&gpmc_cfg->prefetch_status); + cnt = PREFETCH_STATUS_FIFO_CNT(cnt); + + for (i = 0; i < cnt / 4; i++) { + *buf++ = readl(CONFIG_SYS_NAND_BASE); + len -= 4; + } + } while (len); + + omap_prefetch_reset(); + + return 0; +} + +static void omap_nand_read_prefetch8(struct mtd_info *mtd, uint8_t *buf, int len) +{ + int ret; + uint32_t head, tail; + struct nand_chip *chip = mtd->priv; + + /* + * If the destination buffer is unaligned, start with reading + * the overlap byte-wise. + */ + head = ((uint32_t) buf) % 4; + if (head) { + nand_read_buf(mtd, buf, head); + buf += head; + len -= head; + } + + /* + * Only transfer multiples of 4 bytes in a pre-fetched fashion. + * If there's a residue, care for it byte-wise afterwards. + */ + tail = len % 4; + + ret = __read_prefetch_aligned(chip, (uint32_t *) buf, len - tail); + if (ret < 0) { + /* fallback in case the prefetch engine is busy */ + nand_read_buf(mtd, buf, len); + } else if (tail) { + buf += len - tail; + nand_read_buf(mtd, buf, tail); + } +} +#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */ + /** * omap_read_page_bch - hardware ecc based page read function * @mtd: mtd info structure @@ -883,11 +990,15 @@ int board_nand_init(struct nand_chip *nand) if (err) return err;
-#ifdef CONFIG_SPL_BUILD +#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH + /* TODO: Implement for 16-bit bus width */ if (nand->options & NAND_BUSWIDTH_16) nand->read_buf = nand_read_buf16; else - nand->read_buf = nand_read_buf; + nand->read_buf = omap_nand_read_prefetch8; +#endif + +#ifdef CONFIG_SPL_BUILD nand->dev_ready = omap_spl_dev_ready; #endif
diff --git a/include/linux/mtd/omap_gpmc.h b/include/linux/mtd/omap_gpmc.h index 9a86582..6cbae45 100644 --- a/include/linux/mtd/omap_gpmc.h +++ b/include/linux/mtd/omap_gpmc.h @@ -66,7 +66,11 @@ struct gpmc { u32 status; /* 0x54 */ u8 res5[0x8]; /* 0x58 */ struct gpmc_cs cs[8]; /* 0x60, 0x90, .. */ - u8 res6[0x14]; /* 0x1E0 */ + u32 prefetch_config1; /* 0x1E0 */ + u32 prefetch_config2; /* 0x1E4 */ + u32 res6; /* 0x1E8 */ + u32 prefetch_control; /* 0x1EC */ + u32 prefetch_status; /* 0x1F0 */ u32 ecc_config; /* 0x1F4 */ u32 ecc_control; /* 0x1F8 */ u32 ecc_size_config; /* 0x1FC */

Hi Daniel,
While trying to enable GPMC prefetch myself I ran into your patch and tested it. Here's some comments.
On Wed, Jun 25, 2014 at 02:43:32PM +0200, Daniel Mack wrote:
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address.
The current implementation has two limitations:
a) it only works in 8-bit mode b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zonque@gmail.com
doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c | 115 +++++++++++++++++++++++++++++++++++++++++- include/linux/mtd/omap_gpmc.h | 6 ++- 3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand index 70cf768..6459f2a 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -292,6 +292,11 @@ Platform specific options Thus BCH16 can be supported on 4K page NAND.
- CONFIG_NAND_OMAP_PREFETCH
This doesn't match the actual config in omap_gpmc.c
- On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC),
- this options enables the code that uses the prefetch mode to speed up
- read operations.
NOTE:
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index 1acf06b..e2d57bd 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -446,6 +446,113 @@ static int omap_correct_data_bch(struct mtd_info *mtd, uint8_t *dat, return (err) ? err : error_count; }
+#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
+#define PREFETCH_CONFIG1_CS_SHIFT 24 +#define PREFETCH_FIFOTHRESHOLD_MAX 0x40 +#define PREFETCH_FIFOTHRESHOLD(val) ((val) << 8) +#define PREFETCH_STATUS_COUNT(val) (val & 0x00003fff) +#define PREFETCH_STATUS_FIFO_CNT(val) ((val >> 24) & 0x7F) +#define ENABLE_PREFETCH (1 << 7)
+/**
- omap_prefetch_enable - configures and starts prefetch transfer
- @fifo_th: fifo threshold to be used for read/ write
- @count: number of bytes to be transferred
- @is_write: prefetch read(0) or write post(1) mode
- */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write) +{
- uint32_t val;
- if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX)
return -EINVAL;
- if (readl(&gpmc_cfg->prefetch_control))
return -EBUSY;
- /* Set the amount of bytes to be prefetched */
- writel(count, &gpmc_cfg->prefetch_config2);
- val = (cs << PREFETCH_CONFIG1_CS_SHIFT) | (is_write & 1) |
On a current U-boot "cs" doesn't exist. I think you might want to pass a "struct omap_nand_info *" and use info->cs.
I fixed this last bit, and tested it. It results in 2.5x speed improvements on a Micron NAND. So, thanks :) !
If you resend, you have my Reviewed-by and Tested-by.
PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH;
- writel(val, &gpmc_cfg->prefetch_config1);
- /* Start the prefetch engine */
- writel(1, &gpmc_cfg->prefetch_control);
- return 0;
+}
+/**
- omap_prefetch_reset - disables and stops the prefetch engine
- */
+static void omap_prefetch_reset(void) +{
- writel(0, &gpmc_cfg->prefetch_control);
- writel(0, &gpmc_cfg->prefetch_config1);
+}
+static int __read_prefetch_aligned(struct nand_chip *chip, uint32_t *buf, int len) +{
- int ret;
- uint32_t cnt;
- ret = omap_prefetch_enable(PREFETCH_FIFOTHRESHOLD_MAX, len, 0);
- if (ret < 0)
return ret;
- do {
int i;
cnt = readl(&gpmc_cfg->prefetch_status);
cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
for (i = 0; i < cnt / 4; i++) {
*buf++ = readl(CONFIG_SYS_NAND_BASE);
len -= 4;
}
- } while (len);
- omap_prefetch_reset();
- return 0;
+}
+static void omap_nand_read_prefetch8(struct mtd_info *mtd, uint8_t *buf, int len) +{
- int ret;
- uint32_t head, tail;
- struct nand_chip *chip = mtd->priv;
- /*
* If the destination buffer is unaligned, start with reading
* the overlap byte-wise.
*/
- head = ((uint32_t) buf) % 4;
- if (head) {
nand_read_buf(mtd, buf, head);
buf += head;
len -= head;
- }
- /*
* Only transfer multiples of 4 bytes in a pre-fetched fashion.
* If there's a residue, care for it byte-wise afterwards.
*/
- tail = len % 4;
- ret = __read_prefetch_aligned(chip, (uint32_t *) buf, len - tail);
- if (ret < 0) {
/* fallback in case the prefetch engine is busy */
nand_read_buf(mtd, buf, len);
- } else if (tail) {
buf += len - tail;
nand_read_buf(mtd, buf, tail);
- }
+} +#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
/**
- omap_read_page_bch - hardware ecc based page read function
- @mtd: mtd info structure
@@ -883,11 +990,15 @@ int board_nand_init(struct nand_chip *nand) if (err) return err;
-#ifdef CONFIG_SPL_BUILD +#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
- /* TODO: Implement for 16-bit bus width */ if (nand->options & NAND_BUSWIDTH_16) nand->read_buf = nand_read_buf16; else
nand->read_buf = nand_read_buf;
nand->read_buf = omap_nand_read_prefetch8;
+#endif
+#ifdef CONFIG_SPL_BUILD nand->dev_ready = omap_spl_dev_ready; #endif
diff --git a/include/linux/mtd/omap_gpmc.h b/include/linux/mtd/omap_gpmc.h index 9a86582..6cbae45 100644 --- a/include/linux/mtd/omap_gpmc.h +++ b/include/linux/mtd/omap_gpmc.h @@ -66,7 +66,11 @@ struct gpmc { u32 status; /* 0x54 */ u8 res5[0x8]; /* 0x58 */ struct gpmc_cs cs[8]; /* 0x60, 0x90, .. */
- u8 res6[0x14]; /* 0x1E0 */
- u32 prefetch_config1; /* 0x1E0 */
- u32 prefetch_config2; /* 0x1E4 */
- u32 res6; /* 0x1E8 */
- u32 prefetch_control; /* 0x1EC */
- u32 prefetch_status; /* 0x1F0 */ u32 ecc_config; /* 0x1F4 */ u32 ecc_control; /* 0x1F8 */ u32 ecc_size_config; /* 0x1FC */

Hi Guido,
thanks for your feedback!
On 12/19/2014 05:27 PM, Guido Martínez wrote:
+/**
- omap_prefetch_enable - configures and starts prefetch transfer
- @fifo_th: fifo threshold to be used for read/ write
- @count: number of bytes to be transferred
- @is_write: prefetch read(0) or write post(1) mode
- */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write) +{
- uint32_t val;
- if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX)
return -EINVAL;
- if (readl(&gpmc_cfg->prefetch_control))
return -EBUSY;
- /* Set the amount of bytes to be prefetched */
- writel(count, &gpmc_cfg->prefetch_config2);
- val = (cs << PREFETCH_CONFIG1_CS_SHIFT) | (is_write & 1) |
On a current U-boot "cs" doesn't exist. I think you might want to pass a "struct omap_nand_info *" and use info->cs.
I fixed this last bit, and tested it. It results in 2.5x speed improvements on a Micron NAND. So, thanks :) !
If you resend, you have my Reviewed-by and Tested-by.
That's great to hear. However, I'm not currently working on this project, so I don't have a chance to respin the patch. In case any of the maintainers is interested, I guess that's easy enough to tweak on the fly when merging the patch :)
Thanks, Daniel

On Wed, Jun 25, 2014 at 02:43:32PM +0200, Daniel Mack wrote:
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address.
The current implementation has two limitations:
a) it only works in 8-bit mode b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zonque@gmail.com
Applied to u-boot-ti/master, after adding the change Guido talked about and adding his Tested/Reviewed tags, thanks!

That memory area is not used except for the first location, so it doesn't matter. However, with the length configured to 256MiB, U-Boot crased when accessing contents of the map.
Signed-off-by: Daniel Mack zonque@gmail.com --- arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c b/arch/arm/cpu/armv7/omap-common/mem-common.c index 944ef84..3595806 100644 --- a/arch/arm/cpu/armv7/omap-common/mem-common.c +++ b/arch/arm/cpu/armv7/omap-common/mem-common.c @@ -99,7 +99,7 @@ void gpmc_init(void) M_NAND_GPMC_CONFIG6, 0 }; - u32 size = GPMC_SIZE_256M; + u32 size = GPMC_SIZE_16M; u32 base = CONFIG_SYS_NAND_BASE; #elif defined(CONFIG_CMD_ONENAND) const u32 gpmc_regs[GPMC_MAX_REG] = { ONENAND_GPMC_CONFIG1,

On Wed, Jun 25, 2014 at 02:43:31PM +0200, Daniel Mack wrote:
Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
Sorry, I intended to play with it, but got busy. Can you do a v3 where you also enable this on am335x_evm which is where I assume you did, or at least can, test the code? Thanks!

Hi Tom,
On 06/25/2014 03:00 PM, Tom Rini wrote:
On Wed, Jun 25, 2014 at 02:43:31PM +0200, Daniel Mack wrote:
Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
Sorry, I intended to play with it, but got busy.
No problem. I just don't want it to get lost.
Can you do a v3 where you also enable this on am335x_evm which is where I assume you did, or at least can, test the code? Thanks!
No, I only successfully tested this on an own board implementation. I didn't know whether am335x_evm has 8-bit or 16-bit NAND. I didn't touch the config of any board I don't have access to as I can't test such a change :)
Can you just add
#define CONFIG_NAND_OMAP_GPMC_PREFETCH
in your config and commit it with your S-o-b if it works for you?
Thanks, Daniel

Hi Daniel,
From: Daniel Mack [mailto:zonque@gmail.com]
Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
I plan to test this, but there is still a long pending list of patches which for me to test in kernel and u-boot. So it might take bit time. But really thanks much for this feature addition.
Just a minor feedback, if you like it... GPMC controller support various transfer modes - POLLED: <default mode> - PREFETCH_POLLED : <as added in this patch> - PREFETCH_IRQ: <not implemented/required> - PREFETCH_DMA: <not implemented/required>
(1) Will it be okay to use following config names, this would be synonymous to the xfer-modes DT binding used in kernel ? CONFIG_NAND_OMAP_XFER_MODE_POLLED CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED
(2) It would be good if you can make "PREFETCH_POLLED" mode as "default" And instead make "POLLED" mode selectable. #ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED /* old behavior */ #else /* /* default PREFETCH_POLLED mode */ #endif
However, let me first test your patch, and these minor nit-picks (if required) can be done later.
Thanks.. with regards, pekon
I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does.
Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later.
Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter.
What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup.
Test results and feedback very welcome.
Thanks, Daniel
Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c | 115 +++++++++++++++++++++++++++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-)
-- 1.9.3

Hi,
On 06/26/2014 08:08 AM, Gupta, Pekon wrote:
From: Daniel Mack [mailto:zonque@gmail.com]
Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
I plan to test this, but there is still a long pending list of patches which for me to test in kernel and u-boot. So it might take bit time. But really thanks much for this feature addition.
Just a minor feedback, if you like it... GPMC controller support various transfer modes
- POLLED: <default mode>
- PREFETCH_POLLED : <as added in this patch>
- PREFETCH_IRQ: <not implemented/required>
- PREFETCH_DMA: <not implemented/required>
(1) Will it be okay to use following config names, this would be synonymous to the xfer-modes DT binding used in kernel ? CONFIG_NAND_OMAP_XFER_MODE_POLLED CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED
Yes, I've seen that, but decided for shorter names as we will never support DMA or IRQ modes from U-Boot. But I can of course change that, I'd ultimately leave such decisions up to you :)
(2) It would be good if you can make "PREFETCH_POLLED" mode as "default" And instead make "POLLED" mode selectable. #ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED /* old behavior */ #else /* /* default PREFETCH_POLLED mode */ #endif
Ok, but then we'd need something that selects PREFETCH_POLLED automatically if nothing else is selected in the config. I wanted to avoid yet another mandatory config symbol that have to be patched into all existing configs. Could you lay out how that would be done?
However, let me first test your patch, and these minor nit-picks (if required) can be done later.
Alright. I'm in no hurry with this. Good to know it's on your list.
Thanks, Daniel

Hi Daniel,
From: Gupta, Pekon
Hi Daniel,
From: Daniel Mack [mailto:zonque@gmail.com]
Resending this since I got no replies on the first version. I also fixed up the commit log of #1.
I plan to test this, but there is still a long pending list of patches which for me to test in kernel and u-boot. So it might take bit time. But really thanks much for this feature addition.
Just a minor feedback, if you like it... GPMC controller support various transfer modes
- POLLED: <default mode>
- PREFETCH_POLLED : <as added in this patch>
- PREFETCH_IRQ: <not implemented/required>
- PREFETCH_DMA: <not implemented/required>
(1) Will it be okay to use following config names, this would be synonymous to the xfer-modes DT binding used in kernel ? CONFIG_NAND_OMAP_XFER_MODE_POLLED CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED
(2) It would be good if you can make "PREFETCH_POLLED" mode as "default" And instead make "POLLED" mode selectable. #ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED /* old behavior */ #else /* /* default PREFETCH_POLLED mode */ #endif
However, let me first test your patch, and these minor nit-picks (if required) can be done later.
Thanks.. with regards, pekon
I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does.
Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later.
Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter.
What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup.
Test results and feedback very welcome.
Thanks, Daniel
Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c | 115 +++++++++++++++++++++++++++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-)
-- 1.9.3
My apologies, sorry I'm unable to test this patch-set. But as I have already reviewed it. And apart from minor comments for rest of things Reviewed-by: Pekon Gupta pekon@ti.com
with regards, pekon
participants (5)
-
Daniel Mack
-
Daniel Mack
-
Guido Martínez
-
Gupta, Pekon
-
Tom Rini