Expand the dma_mask of fsldma device to 36-bit, indicating that the
DMA engine can deal with 36-bit physical address and does not need
the SWIOTLB to create bounce buffer for it when doing dma_map_*().

Signed-off-by: Li Yang <leoli@freescale.com>
---
Add more detailed commit message

 drivers/dma/fsldma.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index cea08be..8c79b37 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1,7 +1,7 @@
 /*
  * Freescale MPC85xx, MPC83xx DMA Engine support
  *
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007-2010 Freescale Semiconductor, Inc. All rights reserved.
  *
  * Author:
  *   Zhang Wei <wei.zhang@freescale.com>, Jul 2007
@@ -1338,6 +1338,8 @@ static int __devinit fsldma_of_probe(struct platform_device *op,
 	fdev->common.device_control = fsl_dma_device_control;
 	fdev->common.dev = &op->dev;
 
+	dma_set_mask(&(op->dev), DMA_BIT_MASK(36));
+
 	dev_set_drvdata(&op->dev, fdev);
 
 	/*
-- 
1.6.6-rc1.GIT


--

[ message continues ]

--

[ message continues ]

The current code is only verified on chips with 36-bit physical address.  I'm not sure if the driver can work without any change on the 64-bit chip, although the register model suggests it can work well with 64-bit.  If you can confirm that it's compatible with the block on 64-bit chip, then we can change it to 64 bit dma mask.

- Leo

--

[ message continues ]

Can you explain that?  The DMA registers only have room for 36 bits
for the physical address.

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

The programming model (if you look at the free-space in the registers and data structures) supports a 64-bit address.  I'm trying to avoid changing the driver in the future if we have >36-bit.  However this is such a minor worry that I'll stop and just ack the patch as is.

- k--

[ message continues ]

I must still be missing something.  I'm looking at the description of
the SATR register in the MPC8572 RM, and it shows this:

0 - 3 |   4 - 5   |     6     |   7  |   8 - 11  |   12 - 15  | 16-21 | 22-31
 ---  | STFLOWLVL | SPCIORDER | SSME | STRANSINT | SREADTTYPE |  ---  |  ESAD

The most that we can extend ESAD to is 16 bits, for a total of a
48-bit physical address.  Where are the other 16 bits supposed to go?

-- 
Timur Tabi
Linux kernel developer at Freescale
--

[ message continues ]

I was looking at the link addresses.  I stand corrected so our max is 48-bits.

- k--

[ message continues ]

On Mon, 15 Nov 2010 11:43:12 -0600

Looks like 42 bits -- just because bits 16-21 could be used to extend
ESAD doesn't mean that they have been.

-Scott

--

[ message continues ]

Acked-by: Kumar Gala <galak@kernel.crashing.org>

- k
--

[ message continues ]