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 > --- > 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 , 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 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] fsldma: add support to 36-bit physical address
>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 >> --- >> 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 , 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Nov 13, 2010, at 4:43 PM, Timur Tabi wrote: > On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 > --- > Add more detailed commit message > > drivers/dma/fsldma.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote: > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: add support to 36-bit physical address
On Mon, 15 Nov 2010 11:43:12 -0600 Kumar Gala wrote: > > On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote: > > > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
