Message ID | 1289477789-10651-1-git-send-email-leoli@freescale.com (mailing list archive) |
---|---|
State | Accepted, archived |
Delegated to: | Kumar Gala |
Headers | show |
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
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); /*
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(-)