diff mbox

fsldma: use PCI Read Multiple command

Message ID 20090427204213.GA4960@ovro.caltech.edu (mailing list archive)
State Accepted, archived
Delegated to: Kumar Gala
Headers show

Commit Message

Ira Snyder April 27, 2009, 8:42 p.m. UTC 
On Mon, Apr 27, 2009 at 03:26:36PM -0500, Timur Tabi wrote:
> David Hawkins wrote:
> 
> > PRC_RM - PCI read multiple
> >    The default PCI read command used by the DMA controller is
> >    PCI Read (PCI command 6h). When the burst length is 32-bytes
> >    or longer, PCI Read Line (PCI command Eh) is used (undocumented
> >    feature of the controller). Using PCI read multiple
> >    (PCI command Ch) results in high-performance across PCI
> >    bridges. DMA transfers to non-prefetchable PCI registers
> >    should not result in prefetched reads, even when using
> >    the PCI read multiple command.
> 
> I was thinking more along the lines of:
> 
> "This driver tells the DMA controller to use the PCI Read Multiple
> command, instead of the PCI Read Line command, for PCI read operations.
>  Please be aware that this setting may result in read pre-fetching on
> some platforms."
> 

How about the following revised patch? Is it ok to inline it this way,
or should I send another email to the list containing just this patch?

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

v1 -> v2:
* Added comment warning about possible prefetching

 drivers/dma/fsldma.c |   10 ++++++++--
 drivers/dma/fsldma.h |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

Comments

Timur Tabi April 27, 2009, 8:47 p.m. UTC | #1 
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>
Dan Williams April 27, 2009, 8:49 p.m. UTC | #2 
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.
Kumar Gala June 11, 2009, 2:45 a.m. UTC | #3 
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
Ira Snyder June 11, 2009, 3:17 p.m. UTC | #4 
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
Yang Li June 12, 2009, 9:23 a.m. UTC | #5 
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
Kumar Gala June 12, 2009, 3:03 p.m. UTC | #6 
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
Dan Williams June 12, 2009, 5:38 p.m. UTC | #7 
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
Kumar Gala June 12, 2009, 6:01 p.m. UTC | #8 
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 mbox

Patch

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