Patchwork [3/3] MTD/atmel_nand: Fix support for CPUs that do not support DMA access

login
register
mail settings
Submitter Xu, Hong
Date March 30, 2011, 8:26 a.m.
Message ID <1301473601-29570-3-git-send-email-hong.xu@atmel.com>
Download mbox | patch
Permalink /patch/88884/
State Accepted
Commit cb457a4ddd4eeac9c81792a1e6a5d59b1b44abe1
Headers show

Comments

Xu, Hong - March 30, 2011, 8:26 a.m.
use_dma was always "1" even if the CPU does not support DMA

Tested on AT91SAM9261EK by Jean-Christophe PLAGNIOL-VILLARD

Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Hong Xu <hong.xu@atmel.com>
---
 drivers/mtd/nand/atmel_nand.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Artem Bityutskiy - April 1, 2011, 12:54 p.m.
On Wed, 2011-03-30 at 16:26 +0800, Hong Xu wrote:
> use_dma was always "1" even if the CPU does not support DMA
> 
> Tested on AT91SAM9261EK by Jean-Christophe PLAGNIOL-VILLARD
> 
> Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Hong Xu <hong.xu@atmel.com>

Pushed to l2-mtd-2.6.git tree. This looks like a candidate for the
stable tree - should it be sent there?
Nicolas Ferre - April 1, 2011, 1:37 p.m.
Le 01/04/2011 14:54, Artem Bityutskiy :
> On Wed, 2011-03-30 at 16:26 +0800, Hong Xu wrote:
>> use_dma was always "1" even if the CPU does not support DMA
>>
>> Tested on AT91SAM9261EK by Jean-Christophe PLAGNIOL-VILLARD
>>
>> Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>> Signed-off-by: Hong Xu <hong.xu@atmel.com>
> 
> Pushed to l2-mtd-2.6.git tree. This looks like a candidate for the
> stable tree - should it be sent there?

Well, definitively the whole series is a candidate for .39-xx (also with
the "[PATCH] MTD: atmel_nand: Fall back to CPU I/O when buffer is in
vmalloc(ed) region" that follows.

But, as DMA access was not included in .38, stable tree should not be
impacted.

Best regards,
Artem Bityutskiy - April 1, 2011, 1:37 p.m.
On Fri, 2011-04-01 at 15:37 +0200, Nicolas Ferre wrote:
> Le 01/04/2011 14:54, Artem Bityutskiy :
> > On Wed, 2011-03-30 at 16:26 +0800, Hong Xu wrote:
> >> use_dma was always "1" even if the CPU does not support DMA
> >>
> >> Tested on AT91SAM9261EK by Jean-Christophe PLAGNIOL-VILLARD
> >>
> >> Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> >> Signed-off-by: Hong Xu <hong.xu@atmel.com>
> > 
> > Pushed to l2-mtd-2.6.git tree. This looks like a candidate for the
> > stable tree - should it be sent there?
> 
> Well, definitively the whole series is a candidate for .39-xx (also with
> the "[PATCH] MTD: atmel_nand: Fall back to CPU I/O when buffer is in
> vmalloc(ed) region" that follows.
> 
> But, as DMA access was not included in .38, stable tree should not be
> impacted.

I see, then this is not -stable material. But should be merged this
merge window.
Artem Bityutskiy - April 1, 2011, 2:17 p.m.
On Fri, 2011-04-01 at 15:37 +0200, Nicolas Ferre wrote:
> Le 01/04/2011 14:54, Artem Bityutskiy :
> > On Wed, 2011-03-30 at 16:26 +0800, Hong Xu wrote:
> >> use_dma was always "1" even if the CPU does not support DMA
> >>
> >> Tested on AT91SAM9261EK by Jean-Christophe PLAGNIOL-VILLARD
> >>
> >> Reported-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> >> Signed-off-by: Hong Xu <hong.xu@atmel.com>
> > 
> > Pushed to l2-mtd-2.6.git tree. This looks like a candidate for the
> > stable tree - should it be sent there?
> 
> Well, definitively the whole series is a candidate for .39-xx (also with
> the "[PATCH] MTD: atmel_nand: Fall back to CPU I/O when buffer is in
> vmalloc(ed) region" that follows.

Thanks for pointing this, I could miss that patch.

Patch

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index c36ea50..1b43654 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -599,7 +599,10 @@  static int __init atmel_nand_probe(struct platform_device *pdev)
 		nand_chip->options |= NAND_USE_FLASH_BBT;
 	}
 
-	if (cpu_has_dma() && use_dma) {
+	if (!cpu_has_dma())
+		use_dma = 0;
+
+	if (use_dma) {
 		dma_cap_mask_t mask;
 
 		dma_cap_zero(mask);