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 <[email protected]>
---
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 <[email protected]>, 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
On Nov 11, 2010, at 6:16 AM, Li Yang wrote:
> 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 <[email protected]>
> ---
> 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 <[email protected]>, 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));
> +
Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block programming model allows the address to be 64-bits?
> dev_set_drvdata(&op->dev, fdev);
>
> /*
> --
> 1.6.6-rc1.GIT
>
>Subject: Re: [PATCH v2] fsldma: add support to 36-bit physical address
>
>
>On Nov 11, 2010, at 6:16 AM, Li Yang wrote:
>
>> 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 <[email protected]>
>> ---
>> 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 <[email protected]>, 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));
>> +
>
>Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block
>programming model allows the address to be 64-bits?
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
On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala <[email protected]> wrote:
> Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block programming model allows the address to be 64-bits?
Can you explain that? The DMA registers only have room for 36 bits
for the physical address.
--
Timur Tabi
Linux kernel developer at Freescale
On Nov 13, 2010, at 4:43 PM, Timur Tabi wrote:
> On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala <[email protected]> wrote:
>
>> Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block programming model allows the address to be 64-bits?
>
> Can you explain that? The DMA registers only have room for 36 bits
> for the physical address.
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-
On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <[email protected]> wrote:
> 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.
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
On Nov 11, 2010, at 6:16 AM, Li Yang wrote:
> 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 <[email protected]>
> ---
> Add more detailed commit message
>
> drivers/dma/fsldma.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Acked-by: Kumar Gala <[email protected]>
- k
On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:
> On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <[email protected]> wrote:
>
>> 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.
>
> 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?
I was looking at the link addresses. I stand corrected so our max is 48-bits.
- k-
On Mon, 15 Nov 2010 11:43:12 -0600
Kumar Gala <[email protected]> wrote:
>
> On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:
>
> > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <[email protected]> wrote:
> >
> >> 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.
> >
> > 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?
>
> I was looking at the link addresses. I stand corrected so our max is 48-bits.
Looks like 42 bits -- just because bits 16-21 could be used to extend
ESAD doesn't mean that they have been.
-Scott