* [PATCH 0/2] pxa3xx: Data buffer dynamic allocation
@ 2013-10-04 18:30 Ezequiel Garcia
2013-10-04 18:30 ` [PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling Ezequiel Garcia
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Ezequiel Garcia @ 2013-10-04 18:30 UTC (permalink / raw)
To: linux-mtd, Daniel Mack
Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Ezequiel Garcia,
Gregory Clement, Brian Norris
As part of my work to support the NAND controllers in Armada 370/XP SoC
here's a tiny set of patches to replace the currently data buffer allocation
based in a hardcoded buffer size, into a dynamic scheme.
We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater
page) and then re-allocate (either with kmalloc or using DMA allocators) using
the detected page size.
The first patch is required to perform the initial NAND operations (READID
and friends) using programmable I/O since the DMA buffers are not ready
at such early stage.
The second patch performs to actual dynamic allocation and it's exactly
the same patch I sent a few weeks ago:
http://patchwork.ozlabs.org/patch/275982/
Daniel: Can you test these two If they look fine we can add them now,
being an improvement to the driver pxa3xx beyond the Armada 370/XP effort.
Thanks!
Ezequiel Garcia (2):
mtd: nand: pxa3xx: Move DMA I/O enabling
mtd: nand: pxa3xx: Allocate data buffer on detected flash size
drivers/mtd/nand/pxa3xx_nand.c | 51 +++++++++++++++++++++++++++++-------------
1 file changed, 35 insertions(+), 16 deletions(-)
--
1.8.1.5
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling 2013-10-04 18:30 [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia @ 2013-10-04 18:30 ` Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size Ezequiel Garcia ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-04 18:30 UTC (permalink / raw) To: linux-mtd, Daniel Mack Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Ezequiel Garcia, Gregory Clement, Brian Norris Instead of setting info->dma each time a command is prepared, we can move it after the DMA buffers are allocated. This is more clear and it's the proper place to enable this, given DMA cannot be turned on and off during runtime. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> --- drivers/mtd/nand/pxa3xx_nand.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index dd03dfd..a47c67f 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -540,7 +540,6 @@ static int prepare_command_pool(struct pxa3xx_nand_info *info, int command, info->oob_size = 0; info->use_ecc = 0; info->use_spare = 1; - info->use_dma = (use_dma) ? 1 : 0; info->is_ready = 0; info->retcode = ERR_NONE; if (info->cs != 0) @@ -950,6 +949,11 @@ static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info) return info->data_dma_ch; } + /* + * Now that DMA buffers are allocated we turn on + * DMA proper for I/O operations. + */ + info->use_dma = 1; return 0; } -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size 2013-10-04 18:30 [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling Ezequiel Garcia @ 2013-10-04 18:30 ` Ezequiel Garcia 2013-10-15 19:41 ` Brian Norris 2013-10-09 11:48 ` [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia 2013-10-15 20:47 ` Brian Norris 3 siblings, 1 reply; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-04 18:30 UTC (permalink / raw) To: linux-mtd, Daniel Mack Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Ezequiel Garcia, Gregory Clement, Brian Norris This commit replaces the currently hardcoded buffer size, by a dynamic detection scheme. First a small 256 bytes buffer is allocated so the device can be detected (using READID and friends commands). After detection, this buffer is released and a new buffer is allocated to acommodate the page size plus out-of-band size. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> --- drivers/mtd/nand/pxa3xx_nand.c | 45 ++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 15 deletions(-) diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index a47c67f..bfb2b9f 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -39,6 +39,13 @@ #define NAND_STOP_DELAY (2 * HZ/50) #define PAGE_CHUNK_SIZE (2048) +/* + * Define a buffer size for the initial command that detects the flash device: + * STATUS, READID and PARAM. The largest of these is the PARAM command, + * needing 256 bytes. + */ +#define INIT_BUFFER_SIZE 256 + /* registers and bit definitions */ #define NDCR (0x00) /* Control register */ #define NDTR0CS0 (0x04) /* Timing Parameter 0 for CS0 */ @@ -164,6 +171,7 @@ struct pxa3xx_nand_info { unsigned int buf_start; unsigned int buf_count; + unsigned int buf_size; /* DMA information */ int drcmr_dat; @@ -911,26 +919,20 @@ static int pxa3xx_nand_detect_config(struct pxa3xx_nand_info *info) return 0; } -/* the maximum possible buffer size for large page with OOB data - * is: 2048 + 64 = 2112 bytes, allocate a page here for both the - * data buffer and the DMA descriptor - */ -#define MAX_BUFF_SIZE PAGE_SIZE - #ifdef ARCH_HAS_DMA static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info) { struct platform_device *pdev = info->pdev; - int data_desc_offset = MAX_BUFF_SIZE - sizeof(struct pxa_dma_desc); + int data_desc_offset = info->buf_size - sizeof(struct pxa_dma_desc); if (use_dma == 0) { - info->data_buff = kmalloc(MAX_BUFF_SIZE, GFP_KERNEL); + info->data_buff = kmalloc(info->buf_size, GFP_KERNEL); if (info->data_buff == NULL) return -ENOMEM; return 0; } - info->data_buff = dma_alloc_coherent(&pdev->dev, MAX_BUFF_SIZE, + info->data_buff = dma_alloc_coherent(&pdev->dev, info->buf_size, &info->data_buff_phys, GFP_KERNEL); if (info->data_buff == NULL) { dev_err(&pdev->dev, "failed to allocate dma buffer\n"); @@ -944,7 +946,7 @@ static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info) pxa3xx_nand_data_dma_irq, info); if (info->data_dma_ch < 0) { dev_err(&pdev->dev, "failed to request data dma\n"); - dma_free_coherent(&pdev->dev, MAX_BUFF_SIZE, + dma_free_coherent(&pdev->dev, info->buf_size, info->data_buff, info->data_buff_phys); return info->data_dma_ch; } @@ -962,7 +964,7 @@ static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info) struct platform_device *pdev = info->pdev; if (use_dma) { pxa_free_dma(info->data_dma_ch); - dma_free_coherent(&pdev->dev, MAX_BUFF_SIZE, + dma_free_coherent(&pdev->dev, info->buf_size, info->data_buff, info->data_buff_phys); } else { kfree(info->data_buff); @@ -971,7 +973,7 @@ static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info) #else static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info) { - info->data_buff = kmalloc(MAX_BUFF_SIZE, GFP_KERNEL); + info->data_buff = kmalloc(info->buf_size, GFP_KERNEL); if (info->data_buff == NULL) return -ENOMEM; return 0; @@ -1085,7 +1087,16 @@ KEEP_CONFIG: else host->col_addr_cycles = 1; + /* release the initial buffer */ + kfree(info->data_buff); + + /* allocate the real data + oob buffer */ + info->buf_size = mtd->writesize + mtd->oobsize; + ret = pxa3xx_nand_init_buff(info); + if (ret) + return ret; info->oob_buff = info->data_buff + mtd->writesize; + if ((mtd->size >> chip->page_shift) > 65536) host->row_addr_cycles = 3; else @@ -1191,9 +1202,13 @@ static int alloc_nand_resource(struct platform_device *pdev) } info->mmio_phys = r->start; - ret = pxa3xx_nand_init_buff(info); - if (ret) + /* Allocate a buffer to allow flash detection */ + info->buf_size = INIT_BUFFER_SIZE; + info->data_buff = kmalloc(info->buf_size, GFP_KERNEL); + if (info->data_buff == NULL) { + ret = -ENOMEM; goto fail_disable_clk; + } /* initialize all interrupts to be disabled */ disable_int(info, NDSR_MASK); @@ -1211,7 +1226,7 @@ static int alloc_nand_resource(struct platform_device *pdev) fail_free_buf: free_irq(irq, info); - pxa3xx_nand_free_buff(info); + kfree(info->data_buff); fail_disable_clk: clk_disable_unprepare(info->clk); return ret; -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size 2013-10-04 18:30 ` [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size Ezequiel Garcia @ 2013-10-15 19:41 ` Brian Norris 2013-10-16 10:25 ` Ezequiel Garcia 0 siblings, 1 reply; 12+ messages in thread From: Brian Norris @ 2013-10-15 19:41 UTC (permalink / raw) To: Ezequiel Garcia Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement On Fri, Oct 04, 2013 at 03:30:38PM -0300, Ezequiel Garcia wrote: > This commit replaces the currently hardcoded buffer size, by a > dynamic detection scheme. First a small 256 bytes buffer is allocated > so the device can be detected (using READID and friends commands). > > After detection, this buffer is released and a new buffer is allocated > to acommodate the page size plus out-of-band size. > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > --- > drivers/mtd/nand/pxa3xx_nand.c | 45 ++++++++++++++++++++++++++++-------------- > 1 file changed, 30 insertions(+), 15 deletions(-) > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c > index a47c67f..bfb2b9f 100644 > --- a/drivers/mtd/nand/pxa3xx_nand.c > +++ b/drivers/mtd/nand/pxa3xx_nand.c > @@ -39,6 +39,13 @@ > #define NAND_STOP_DELAY (2 * HZ/50) > #define PAGE_CHUNK_SIZE (2048) > > +/* > + * Define a buffer size for the initial command that detects the flash device: > + * STATUS, READID and PARAM. The largest of these is the PARAM command, > + * needing 256 bytes. > + */ > +#define INIT_BUFFER_SIZE 256 > + Actually, PARAM tries to get 768 bytes in nand_base.c to retrieve the redundant copies, but your current driver implementation seems to ignore the 2nd and 3rd parameter pages by returning 0xFF. So this is not a criticism of the current patch, but you may want to consider improving your NAND_CMD_PARAM support (also, you don't support NAND_CMD_RNDOUT, which is now used for extended parameter page support). > /* registers and bit definitions */ > #define NDCR (0x00) /* Control register */ > #define NDTR0CS0 (0x04) /* Timing Parameter 0 for CS0 */ [snip] Otherwise, this patch looks good. Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size 2013-10-15 19:41 ` Brian Norris @ 2013-10-16 10:25 ` Ezequiel Garcia 0 siblings, 0 replies; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-16 10:25 UTC (permalink / raw) To: Brian Norris Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement On Tue, Oct 15, 2013 at 12:41:59PM -0700, Brian Norris wrote: > On Fri, Oct 04, 2013 at 03:30:38PM -0300, Ezequiel Garcia wrote: > > This commit replaces the currently hardcoded buffer size, by a > > dynamic detection scheme. First a small 256 bytes buffer is allocated > > so the device can be detected (using READID and friends commands). > > > > After detection, this buffer is released and a new buffer is allocated > > to acommodate the page size plus out-of-band size. > > > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> > > --- > > drivers/mtd/nand/pxa3xx_nand.c | 45 ++++++++++++++++++++++++++++-------------- > > 1 file changed, 30 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c > > index a47c67f..bfb2b9f 100644 > > --- a/drivers/mtd/nand/pxa3xx_nand.c > > +++ b/drivers/mtd/nand/pxa3xx_nand.c > > @@ -39,6 +39,13 @@ > > #define NAND_STOP_DELAY (2 * HZ/50) > > #define PAGE_CHUNK_SIZE (2048) > > > > +/* > > + * Define a buffer size for the initial command that detects the flash device: > > + * STATUS, READID and PARAM. The largest of these is the PARAM command, > > + * needing 256 bytes. > > + */ > > +#define INIT_BUFFER_SIZE 256 > > + > > Actually, PARAM tries to get 768 bytes in nand_base.c to retrieve the > redundant copies, but your current driver implementation seems to ignore > the 2nd and 3rd parameter pages by returning 0xFF. > > So this is not a criticism of the current patch, but you may want to > consider improving your NAND_CMD_PARAM support (also, you don't support > NAND_CMD_RNDOUT, which is now used for extended parameter page support). > Ah, good input. I'll research a bit more and try to cook a patch, it doesn't sound like a lot of work, and it would be nice to have better command support. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-04 18:30 [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size Ezequiel Garcia @ 2013-10-09 11:48 ` Ezequiel Garcia 2013-10-09 12:00 ` Daniel Mack 2013-10-15 20:47 ` Brian Norris 3 siblings, 1 reply; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-09 11:48 UTC (permalink / raw) To: linux-mtd, Daniel Mack Cc: Thomas Petazzoni, Gregory Clement, Lior Amsalem, Brian Norris, Tawfik Bayouk On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > As part of my work to support the NAND controllers in Armada 370/XP SoC > here's a tiny set of patches to replace the currently data buffer allocation > based in a hardcoded buffer size, into a dynamic scheme. > > We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > page) and then re-allocate (either with kmalloc or using DMA allocators) using > the detected page size. > > The first patch is required to perform the initial NAND operations (READID > and friends) using programmable I/O since the DMA buffers are not ready > at such early stage. > > The second patch performs to actual dynamic allocation and it's exactly > the same patch I sent a few weeks ago: > > http://patchwork.ozlabs.org/patch/275982/ > > Daniel: Can you test these two If they look fine we can add them now, > being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. Daniel: sorry to bother, any luck testing this? Brian: do you think the fix might be OK? I'll include this in my future patchset for pxa3xx-nand, but if these two look OK, I think we can just merge them now. Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-09 11:48 ` [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia @ 2013-10-09 12:00 ` Daniel Mack 2013-10-09 14:03 ` Ezequiel Garcia 0 siblings, 1 reply; 12+ messages in thread From: Daniel Mack @ 2013-10-09 12:00 UTC (permalink / raw) To: Ezequiel Garcia Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, linux-mtd, Gregory Clement, Brian Norris On 09.10.2013 13:48, Ezequiel Garcia wrote: > On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: >> As part of my work to support the NAND controllers in Armada 370/XP SoC >> here's a tiny set of patches to replace the currently data buffer allocation >> based in a hardcoded buffer size, into a dynamic scheme. >> >> We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater >> page) and then re-allocate (either with kmalloc or using DMA allocators) using >> the detected page size. >> >> The first patch is required to perform the initial NAND operations (READID >> and friends) using programmable I/O since the DMA buffers are not ready >> at such early stage. >> >> The second patch performs to actual dynamic allocation and it's exactly >> the same patch I sent a few weeks ago: >> >> http://patchwork.ozlabs.org/patch/275982/ >> >> Daniel: Can you test these two If they look fine we can add them now, >> being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. > > Daniel: sorry to bother, any luck testing this? Sorry for the delay, got other things to do lately ... I tested these two patches successfully on my board with both use_dma=0 and =1. Nice :) You can take my Tested-by: Daniel Mack <zonque@gmail.com> I hope I can catch up with my pxa DMA cleanups very soon. Daniel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-09 12:00 ` Daniel Mack @ 2013-10-09 14:03 ` Ezequiel Garcia 2013-10-15 18:29 ` Ezequiel Garcia 0 siblings, 1 reply; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-09 14:03 UTC (permalink / raw) To: Daniel Mack Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, linux-mtd, Gregory Clement, Brian Norris On Wed, Oct 09, 2013 at 02:00:28PM +0200, Daniel Mack wrote: > On 09.10.2013 13:48, Ezequiel Garcia wrote: > > On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > >> As part of my work to support the NAND controllers in Armada 370/XP SoC > >> here's a tiny set of patches to replace the currently data buffer allocation > >> based in a hardcoded buffer size, into a dynamic scheme. > >> > >> We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > >> page) and then re-allocate (either with kmalloc or using DMA allocators) using > >> the detected page size. > >> > >> The first patch is required to perform the initial NAND operations (READID > >> and friends) using programmable I/O since the DMA buffers are not ready > >> at such early stage. > >> > >> The second patch performs to actual dynamic allocation and it's exactly > >> the same patch I sent a few weeks ago: > >> > >> http://patchwork.ozlabs.org/patch/275982/ > >> > >> Daniel: Can you test these two If they look fine we can add them now, > >> being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. > > > > Daniel: sorry to bother, any luck testing this? > > Sorry for the delay, got other things to do lately ... > No problem, thanks for testing. > I tested these two patches successfully on my board with both use_dma=0 > and =1. Nice :) You can take my > > Tested-by: Daniel Mack <zonque@gmail.com> > Good news! Brian: all yours :) > I hope I can catch up with my pxa DMA cleanups very soon. Indeed. BTW: I had some feedback on why the Armada 370/XP SoC can't do DMA on the NAND, I'll reply to the older mail with the information. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-09 14:03 ` Ezequiel Garcia @ 2013-10-15 18:29 ` Ezequiel Garcia 2013-10-15 19:16 ` Brian Norris 0 siblings, 1 reply; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-15 18:29 UTC (permalink / raw) To: Brian Norris Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement On Wed, Oct 09, 2013 at 11:03:13AM -0300, Ezequiel Garcia wrote: > On Wed, Oct 09, 2013 at 02:00:28PM +0200, Daniel Mack wrote: > > On 09.10.2013 13:48, Ezequiel Garcia wrote: > > > On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > > >> As part of my work to support the NAND controllers in Armada 370/XP SoC > > >> here's a tiny set of patches to replace the currently data buffer allocation > > >> based in a hardcoded buffer size, into a dynamic scheme. > > >> > > >> We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > > >> page) and then re-allocate (either with kmalloc or using DMA allocators) using > > >> the detected page size. > > >> > > >> The first patch is required to perform the initial NAND operations (READID > > >> and friends) using programmable I/O since the DMA buffers are not ready > > >> at such early stage. > > >> > > >> The second patch performs to actual dynamic allocation and it's exactly > > >> the same patch I sent a few weeks ago: > > >> > > >> http://patchwork.ozlabs.org/patch/275982/ > > >> > > >> Daniel: Can you test these two If they look fine we can add them now, > > >> being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. > > > > > > Daniel: sorry to bother, any luck testing this? > > > > Sorry for the delay, got other things to do lately ... > > > > No problem, thanks for testing. > > > I tested these two patches successfully on my board with both use_dma=0 > > and =1. Nice :) You can take my > > > > Tested-by: Daniel Mack <zonque@gmail.com> > > > > Good news! Brian: all yours :) > Brian: any chance you pick these two soon? :-) Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-15 18:29 ` Ezequiel Garcia @ 2013-10-15 19:16 ` Brian Norris 0 siblings, 0 replies; 12+ messages in thread From: Brian Norris @ 2013-10-15 19:16 UTC (permalink / raw) To: Ezequiel Garcia Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement Hi Ezequiel, On Tue, Oct 15, 2013 at 03:29:04PM -0300, Ezequiel Garcia wrote: > On Wed, Oct 09, 2013 at 11:03:13AM -0300, Ezequiel Garcia wrote: > > On Wed, Oct 09, 2013 at 02:00:28PM +0200, Daniel Mack wrote: > > > On 09.10.2013 13:48, Ezequiel Garcia wrote: > > > > On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > > > >> As part of my work to support the NAND controllers in Armada 370/XP SoC > > > >> here's a tiny set of patches to replace the currently data buffer allocation > > > >> based in a hardcoded buffer size, into a dynamic scheme. > > > >> > > > >> We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > > > >> page) and then re-allocate (either with kmalloc or using DMA allocators) using > > > >> the detected page size. > > > >> > > > >> The first patch is required to perform the initial NAND operations (READID > > > >> and friends) using programmable I/O since the DMA buffers are not ready > > > >> at such early stage. > > > >> > > > >> The second patch performs to actual dynamic allocation and it's exactly > > > >> the same patch I sent a few weeks ago: > > > >> > > > >> http://patchwork.ozlabs.org/patch/275982/ > > > >> > > > >> Daniel: Can you test these two If they look fine we can add them now, > > > >> being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. > > > > > > > > Daniel: sorry to bother, any luck testing this? > > > > > > Sorry for the delay, got other things to do lately ... > > > > > > > No problem, thanks for testing. > > > > > I tested these two patches successfully on my board with both use_dma=0 > > > and =1. Nice :) You can take my > > > > > > Tested-by: Daniel Mack <zonque@gmail.com> > > > > > > > Good news! Brian: all yours :) > > > > Brian: any chance you pick these two soon? :-) I think I overlooked these once your other gigantic patch set came. I'll take a look at them now. Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-04 18:30 [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia ` (2 preceding siblings ...) 2013-10-09 11:48 ` [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia @ 2013-10-15 20:47 ` Brian Norris 2013-10-16 11:05 ` Ezequiel Garcia 3 siblings, 1 reply; 12+ messages in thread From: Brian Norris @ 2013-10-15 20:47 UTC (permalink / raw) To: Ezequiel Garcia Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement Hi Ezequiel, On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > As part of my work to support the NAND controllers in Armada 370/XP SoC > here's a tiny set of patches to replace the currently data buffer allocation > based in a hardcoded buffer size, into a dynamic scheme. > > We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > page) and then re-allocate (either with kmalloc or using DMA allocators) using > the detected page size. > > The first patch is required to perform the initial NAND operations (READID > and friends) using programmable I/O since the DMA buffers are not ready > at such early stage. > > The second patch performs to actual dynamic allocation and it's exactly > the same patch I sent a few weeks ago: > > http://patchwork.ozlabs.org/patch/275982/ > > Daniel: Can you test these two If they look fine we can add them now, > being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. Thanks for sending these out separately from your other series. They are independently useful and look good to me. And thanks, Daniel, for the testing. Pushed to l2-mtd.git! Brian ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation 2013-10-15 20:47 ` Brian Norris @ 2013-10-16 11:05 ` Ezequiel Garcia 0 siblings, 0 replies; 12+ messages in thread From: Ezequiel Garcia @ 2013-10-16 11:05 UTC (permalink / raw) To: Brian Norris Cc: Thomas Petazzoni, Lior Amsalem, Tawfik Bayouk, Daniel Mack, linux-mtd, Gregory Clement On Tue, Oct 15, 2013 at 01:47:41PM -0700, Brian Norris wrote: > Hi Ezequiel, > > On Fri, Oct 04, 2013 at 03:30:36PM -0300, Ezequiel Garcia wrote: > > As part of my work to support the NAND controllers in Armada 370/XP SoC > > here's a tiny set of patches to replace the currently data buffer allocation > > based in a hardcoded buffer size, into a dynamic scheme. > > > > We first use kmalloc to request a 256 bytes (big enough for the ONFI paramater > > page) and then re-allocate (either with kmalloc or using DMA allocators) using > > the detected page size. > > > > The first patch is required to perform the initial NAND operations (READID > > and friends) using programmable I/O since the DMA buffers are not ready > > at such early stage. > > > > The second patch performs to actual dynamic allocation and it's exactly > > the same patch I sent a few weeks ago: > > > > http://patchwork.ozlabs.org/patch/275982/ > > > > Daniel: Can you test these two If they look fine we can add them now, > > being an improvement to the driver pxa3xx beyond the Armada 370/XP effort. > > Thanks for sending these out separately from your other series. They are > independently useful and look good to me. And thanks, Daniel, for the > testing. > > Pushed to l2-mtd.git! > Great, thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-10-16 11:05 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-04 18:30 [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling Ezequiel Garcia 2013-10-04 18:30 ` [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size Ezequiel Garcia 2013-10-15 19:41 ` Brian Norris 2013-10-16 10:25 ` Ezequiel Garcia 2013-10-09 11:48 ` [PATCH 0/2] pxa3xx: Data buffer dynamic allocation Ezequiel Garcia 2013-10-09 12:00 ` Daniel Mack 2013-10-09 14:03 ` Ezequiel Garcia 2013-10-15 18:29 ` Ezequiel Garcia 2013-10-15 19:16 ` Brian Norris 2013-10-15 20:47 ` Brian Norris 2013-10-16 11:05 ` Ezequiel Garcia
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).