[v2] fsldma: add support to 36-bit physical address

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(-)

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 <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));
> +

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 <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));
>> +
>
>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 <galak@kernel.crashing.org> 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.

On Nov 13, 2010, at 4:43 PM, Timur Tabi wrote:

> On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala <galak@kernel.crashing.org> 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 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 <leoli@freescale.com>
> ---
> Add more detailed commit message
> 
> drivers/dma/fsldma.c |    4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)

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

- k

On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <galak@kernel.crashing.org> 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?

On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:

> On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <galak@kernel.crashing.org> 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 <galak@kernel.crashing.org> wrote:

> 
> On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:
> 
> > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala <galak@kernel.crashing.org> 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