Message ID | 20090427204213.GA4960@ovro.caltech.edu (mailing list archive) |
---|---|
State | Accepted, archived |
Delegated to: | Kumar Gala |
Headers | show |
Adding Kumar to the CC: list, since he might pick up the patch. Ira Snyder wrote: > From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001 > From: Ira W. Snyder <iws@ovro.caltech.edu> > Date: Thu, 23 Apr 2009 16:17:54 -0700 > Subject: [PATCH] fsldma: use PCI Read Multiple command > > By default, the Freescale 83xx DMA controller uses the PCI Read Line > command when reading data over the PCI bus. Setting the controller to use > the PCI Read Multiple command instead allows the controller to read much > larger bursts of data, which provides a drastic speed increase. > > The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI > bridge was between the devices trying to communicate. > > A simple test driver showed an increase from 4MB/sec to 116MB/sec when > performing DMA over the PCI bus. Using DMA to transfer between blocks of > local SDRAM showed no change in performance with this patch. The dmatest > driver was also used to verify the correctness of the transfers, and showed > no errors. > > Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu> Acked-by: Timur Tabi <timur@freescale.com>
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> wrote: > Adding Kumar to the CC: list, since he might pick up the patch. > Acked-by: Dan Williams <dan.j.williams@intel.com> I agree with taking this through Kumar's tree.
On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: > On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> > wrote: >> Adding Kumar to the CC: list, since he might pick up the patch. >> > > Acked-by: Dan Williams <dan.j.williams@intel.com> > > I agree with taking this through Kumar's tree. I'm going through patches for .31.. Should I still pick this up? Going forward should I pick up fsldma patches? - k
On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote: > > On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: > >> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> >> wrote: >>> Adding Kumar to the CC: list, since he might pick up the patch. >>> >> >> Acked-by: Dan Williams <dan.j.williams@intel.com> >> >> I agree with taking this through Kumar's tree. > > I'm going through patches for .31.. Should I still pick this up? Going > forward should I pick up fsldma patches? > I'm fine with that, but you should probably talk to Li Yang (added to CC). He's gotten in contact with me a few times recently. In addition to the PCI Read Multiple patch, I've posted a few more fsldma patches to ppcdev recently: fsldma: enable external start for the 83xx controller fsldma: do not clear bandwidth control bits on the 83xx controller fsldma: Add DMA_SLAVE support The first two are very straightforward. The third probably needs some review before it can be picked up, though. It is well tested, I've been using it for a few weeks without issues. Thanks, Ira
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu> wrote: > On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote: >> >> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: >> >>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> >>> wrote: >>>> Adding Kumar to the CC: list, since he might pick up the patch. >>>> >>> >>> Acked-by: Dan Williams <dan.j.williams@intel.com> >>> >>> I agree with taking this through Kumar's tree. >> >> I'm going through patches for .31.. Should I still pick this up? Going >> forward should I pick up fsldma patches? >> > > I'm fine with that, but you should probably talk to Li Yang (added to > CC). He's gotten in contact with me a few times recently. I am fine with both ways for this patch as it is only related to Freescale register details. But in general I think patches should go through functional subsystem, as they usually would need insight of the subsystem architecture. I prefer the way that the patch acked or signed-off by Freescale guys and push upstream through Dan's tree as most other subsystems did. Unless Dan prefers to ack the subsystem architectural part of each patch and have them pushed other way. - Leo
On Jun 12, 2009, at 4:23 AM, Li Yang wrote: > On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu> > wrote: >> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote: >>> >>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: >>> >>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> >>>> wrote: >>>>> Adding Kumar to the CC: list, since he might pick up the patch. >>>>> >>>> >>>> Acked-by: Dan Williams <dan.j.williams@intel.com> >>>> >>>> I agree with taking this through Kumar's tree. >>> >>> I'm going through patches for .31.. Should I still pick this up? >>> Going >>> forward should I pick up fsldma patches? >>> >> >> I'm fine with that, but you should probably talk to Li Yang (added to >> CC). He's gotten in contact with me a few times recently. > > I am fine with both ways for this patch as it is only related to > Freescale register details. But in general I think patches should go > through functional subsystem, as they usually would need insight of > the subsystem architecture. I prefer the way that the patch acked or > signed-off by Freescale guys and push upstream through Dan's tree as > most other subsystems did. Unless Dan prefers to ack the subsystem > architectural part of each patch and have them pushed other way. I agree w/this and just wanting to see what Dan's preference is. - k
Kumar Gala wrote: > On Jun 12, 2009, at 4:23 AM, Li Yang wrote: > >> On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu> >> wrote: >>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote: >>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: >>>> >>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> >>>>> wrote: >>>>>> Adding Kumar to the CC: list, since he might pick up the patch. >>>>>> >>>>> Acked-by: Dan Williams <dan.j.williams@intel.com> >>>>> >>>>> I agree with taking this through Kumar's tree. >>>> I'm going through patches for .31.. Should I still pick this up? >>>> Going >>>> forward should I pick up fsldma patches? >>>> >>> I'm fine with that, but you should probably talk to Li Yang (added to >>> CC). He's gotten in contact with me a few times recently. >> I am fine with both ways for this patch as it is only related to >> Freescale register details. But in general I think patches should go >> through functional subsystem, as they usually would need insight of >> the subsystem architecture. I prefer the way that the patch acked or >> signed-off by Freescale guys and push upstream through Dan's tree as >> most other subsystems did. Unless Dan prefers to ack the subsystem >> architectural part of each patch and have them pushed other way. > > I agree w/this and just wanting to see what Dan's preference is. I'll take fsldma patches through the dmaengine tree with Leo's ack/sign-off. That last request was a one-off because I had nothing else to push and the discussion was very architecture specific. Thanks, Dan
On Jun 12, 2009, at 12:38 PM, Dan Williams wrote: > Kumar Gala wrote: >> On Jun 12, 2009, at 4:23 AM, Li Yang wrote: >>> On Thu, Jun 11, 2009 at 11:17 PM, Ira >>> Snyder<iws@ovro.caltech.edu> wrote: >>>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote: >>>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote: >>>>> >>>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> >>>>>> wrote: >>>>>>> Adding Kumar to the CC: list, since he might pick up the patch. >>>>>>> >>>>>> Acked-by: Dan Williams <dan.j.williams@intel.com> >>>>>> >>>>>> I agree with taking this through Kumar's tree. >>>>> I'm going through patches for .31.. Should I still pick this >>>>> up? Going >>>>> forward should I pick up fsldma patches? >>>>> >>>> I'm fine with that, but you should probably talk to Li Yang >>>> (added to >>>> CC). He's gotten in contact with me a few times recently. >>> I am fine with both ways for this patch as it is only related to >>> Freescale register details. But in general I think patches should >>> go >>> through functional subsystem, as they usually would need insight of >>> the subsystem architecture. I prefer the way that the patch acked >>> or >>> signed-off by Freescale guys and push upstream through Dan's tree as >>> most other subsystems did. Unless Dan prefers to ack the subsystem >>> architectural part of each patch and have them pushed other way. >> I agree w/this and just wanting to see what Dan's preference is. > > I'll take fsldma patches through the dmaengine tree with Leo's ack/ > sign-off. That last request was a one-off because I had nothing > else to push and the discussion was very architecture specific. Sounds good to me. I expect you to pick up this patch for .31 - k
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index da8a8ed..5943ca8 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -12,6 +12,11 @@ * also fit for MPC8560, MPC8555, MPC8548, MPC8641, and etc. * The support for MPC8349 DMA contorller is also added. * + * This driver instructs the DMA controller to issue the PCI Read Multiple + * command for PCI read operations, instead of using the default PCI Read Line + * command. Please be aware that this setting may result in read pre-fetching + * on some platforms. + * * This is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or @@ -49,9 +54,10 @@ static void dma_init(struct fsl_dma_chan *fsl_chan) case FSL_DMA_IP_83XX: /* Set the channel to below modes: * EOTIE - End-of-transfer interrupt enable + * PRC_RM - PCI read multiple */ - DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE, - 32); + DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE + | FSL_DMA_MR_PRC_RM, 32); break; } diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index 4f21a51..dc7f268 100644 --- a/drivers/dma/fsldma.h +++ b/drivers/dma/fsldma.h @@ -38,6 +38,7 @@ /* Special MR definition for MPC8349 */ #define FSL_DMA_MR_EOTIE 0x00000080 +#define FSL_DMA_MR_PRC_RM 0x00000800 #define FSL_DMA_SR_CH 0x00000020 #define FSL_DMA_SR_PE 0x00000010