[PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Ezequiel Garcia]

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

[PATCH 1/2] mtd: nand: pxa3xx: Move DMA I/O enabling

[Ezequiel Garcia]

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

[PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size

[Ezequiel Garcia]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Ezequiel Garcia]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Daniel Mack]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Ezequiel Garcia]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Ezequiel Garcia]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Brian Norris]

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

Re: [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size

[Brian Norris]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Brian Norris]

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

Re: [PATCH 2/2] mtd: nand: pxa3xx: Allocate data buffer on detected flash size

[Ezequiel Garcia]

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

Re: [PATCH 0/2] pxa3xx: Data buffer dynamic allocation

[Ezequiel Garcia]

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