Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1420446 > unrolled thread

Re: PCIe EndPoint DMA driver with DMA Framework

Started byVinod Koul <vinod.koul@intel.com>
First post2016-06-13 07:20 +0200
Last post2016-06-14 13:50 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: PCIe EndPoint DMA driver with DMA Framework Vinod Koul <vinod.koul@intel.com> - 2016-06-13 07:20 +0200
    Re: PCIe EndPoint DMA driver with DMA Framework Sinan Kaya <okaya@codeaurora.org> - 2016-06-13 16:10 +0200
      RE: PCIe EndPoint DMA driver with DMA Framework Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> - 2016-06-14 13:50 +0200

#1420446 — Re: PCIe EndPoint DMA driver with DMA Framework

FromVinod Koul <vinod.koul@intel.com>
Date2016-06-13 07:20 +0200
SubjectRe: PCIe EndPoint DMA driver with DMA Framework
Message-ID<rJss2-1NY-5@gated-at.bofh.it>
On Fri, Jun 10, 2016 at 03:39:15PM +0000, Bharat Kumar Gogada wrote:
> Hi,
> 

PLEASE wrap your replied to 80 chars..  I have reflown below..

> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
> targeting x86 machine.  (
> "https://www.kernel.org/doc/Documentation/dmaengine/provider.txt") Our DMA
> controller is part of PCIe End Point.  We are targeting to measure PCIe
> performance with this Framework driver.
> 
> But when I see DMA Framework drivers is kernel source "drivers/dma" most
> of the drivers are platform drivers.

wrong, there are bunch of PCI X86 driver. Look closely dw, ioat etc
> 
> So DMA Framework is mainly targeted for platform drivers?

First it is dmaengine framework.

And your assumption is wrong, btw did you see anything is dmaengine APIs
to make the assumption that dmaengine frameowrk is suited for platform
drivers. The frameworks do not care which type of device you have.

> 
> With current design model we need to have one DMA controller driver and
> PCIe EP client driver?

That depends on what you are trying to do but yes the dmaengine driver
will provide dma services and a client needs to use it

> 
> In which part of kernel source PCIe EP client driver will go?

whatever that client is trying to do DMA for. If its network then it
should go in network.

What exactly are you trying to do?

> 
> Can we use DMA Framework on x86 ?

And asking same question multiple times does not change the answer, which is
yes.

> 
> Thanks & Regards, Bharat
> 
> 
> 
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any attachments
> immediately.

What confidential information you have here?

-- 
~Vinod

[toc] | [next] | [standalone]


#1420885

FromSinan Kaya <okaya@codeaurora.org>
Date2016-06-13 16:10 +0200
Message-ID<rJAIV-7lo-27@gated-at.bofh.it>
In reply to#1420446
On 6/13/2016 1:25 AM, Vinod Koul wrote:
>> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
>> > targeting x86 machine.  (
>> > "https://www.kernel.org/doc/Documentation/dmaengine/provider.txt") Our DMA
>> > controller is part of PCIe End Point.  We are targeting to measure PCIe
>> > performance with this Framework driver.
>> > 
>> > But when I see DMA Framework drivers is kernel source "drivers/dma" most
>> > of the drivers are platform drivers.
> wrong, there are bunch of PCI X86 driver. Look closely dw, ioat etc

I usually see endpoint specific DMA code to reside in the endpoint device
driver not in the dmaengine directory.

I think the main question is who the consumer of this DMA controller is like
Vinod asked.

If it is a general purpose DMA controller then dmaengine would be the right
place. 

If it is specific to your endpoint, then it should be set up and used in your
endpoint device driver.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]


#1421815

FromBharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
Date2016-06-14 13:50 +0200
Message-ID<rJV0Z-4hM-5@gated-at.bofh.it>
In reply to#1420885
Hi Vinod/kanya,

> On 6/13/2016 1:25 AM, Vinod Koul wrote:
> >> We are planning to write a PCIe EndPoint DMA driver with DMA
> >> Framework
> >> > targeting x86 machine.  (
> >> >
> "https://www.kernel.org/doc/Documentation/dmaengine/provider.txt")
> >> > Our DMA controller is part of PCIe End Point.  We are targeting to
> >> > measure PCIe performance with this Framework driver.
> >> >
> >> > But when I see DMA Framework drivers is kernel source "drivers/dma"
> >> > most of the drivers are platform drivers.
> > wrong, there are bunch of PCI X86 driver. Look closely dw, ioat etc
>
> I usually see endpoint specific DMA code to reside in the endpoint device
> driver not in the dmaengine directory.
>
> I think the main question is who the consumer of this DMA controller is like
> Vinod asked.
>
> If it is a general purpose DMA controller then dmaengine would be the right
> place.
>
> If it is specific to your endpoint, then it should be set up and used in your
> endpoint device driver.
>
Our DMA controller is specific to EP.

Thanks a lot kanya and vinod for the clarifications.

Bharat


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web