From: Kishon Vijay Abraham I <kishon@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
David Daney <david.daney@cavium.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Carlos Palminha <CARLOS.PALMINHA@synopsys.com>,
Thierry Reding <thierry.reding@gmail.com>,
Tanmay Inamdar <tinamdar@apm.com>,
Joao Pinto <Joao.Pinto@synopsys.com>,
Pratyush Anand <pratyush.anand@gmail.com>,
Murali Karicheri <m-karicheri2@ti.com>,
Jason Cooper <jason@lakedaemon.net>,
Simon Horman <horms@verge.net.au>,
"bhelgaas@google.com" <bhelgaas@google.com>,
Mingkai Hu <mingkai.hu@freescale.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Jingoo Han <jingoohan1@gmail.com>,
Richard Zhu <Richard.Zhu@freescale.com>,
linux-kernel@vger.kern
Subject: Re: Support for configurable PCIe endpoint
Date: Mon, 29 Aug 2016 17:17:16 +0530 [thread overview]
Message-ID: <57C420C4.4000004@ti.com> (raw)
In-Reply-To: <1944530.NcryPj8uKU@wuerfel>
Hi Arnd,
On Thursday 25 August 2016 06:29 PM, Arnd Bergmann wrote:
> On Thursday, August 18, 2016 6:44:09 PM CEST Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Thursday 04 August 2016 04:43 PM, Arnd Bergmann wrote:
>>> On Thursday, August 4, 2016 3:32:01 PM CEST Kishon Vijay Abraham I wrote:
>>>> On Wednesday 03 August 2016 07:09 PM, Joao Pinto wrote:
>>>>>
>>>>> You are rising a topic that we are also addressing in Synopsys.
>>>>>
>>>>> For the PCIe RC hardware validation we are currently using the standard
>>>>> pcie-designware and pcie-designware-plat drivers.
>>>>>
>>>>> For the Endpoint we have to use an internal software package. Its main purpose
>>>>> is to initialize the IP registers, eDMA channels and make data transfer to prove
>>>>> that the everything is working properly. This is done in 2 levels, a custom
>>>>> driver built and loaded and an application that makes some ioctl to the driver
>>>>> executing some interesting functions to check the Endpoint status and make some
>>>>> data exchange.
>>>>
>>>> hmm.. the platform I have doesn't have a DMA in PCIe IP
>>>> (http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the
>>>> EP access RC memory? i.e the driver in the RC allocates memory from it's DDR
>>>> and gives it's DDR address to the EP. The EP then transfers data to this
>>>> address. (This is a typical use case with ethernet PCIe cards). IIUC that's not
>>>> simple with configurable EPs. I'd like to know more about your testing though.
>>>
>>>
>>> What's the difference between using the EDMA on that chip or a DMA engine
>>> that is part of the PCIe bridge?
>>
>> Do you mean the difference between using DMA on an EP (like ethernet card or
>> sata card) and DMA on PCI RC system? or is it the difference between eDMA
>> within the PCIe IP and system DMA?
>
> The latter. You write that there is no DMA in the PCIe IP, but from the
> perspective of the RC, it should not matter whether the DMA engine is
> part of the EP logic or behind it.
right, from the RC perspective there is no difference.
What I meant is DMA support in PCIe driver has to be added newly (i.e for
designware) and the the platform I have doesn't have a DMA in PCIe IP. Anyways,
we'll come back to this later after I post my RFC series, maybe by this week end.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
David Daney <david.daney@cavium.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Carlos Palminha <CARLOS.PALMINHA@synopsys.com>,
Thierry Reding <thierry.reding@gmail.com>,
Tanmay Inamdar <tinamdar@apm.com>,
Joao Pinto <Joao.Pinto@synopsys.com>,
Pratyush Anand <pratyush.anand@gmail.com>,
Murali Karicheri <m-karicheri2@ti.com>,
Jason Cooper <jason@lakedaemon.net>,
Simon Horman <horms@verge.net.au>,
"bhelgaas@google.com" <bhelgaas@google.com>,
Mingkai Hu <mingkai.hu@freescale.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Jingoo Han <jingoohan1@gmail.com>,
Richard Zhu <Richard.Zhu@freescale.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stanimir Varbanov <svarbanov@mm-sol.com>,
Minghuan Lian <minghuan.Lian@freescale.com>,
Zhou Wang <wangzhou1@hisilicon.com>,
Ley Foon Tan <lftan@altera.com>,
Roy Zang <tie-fei.zang@freescale.com>,
Lucas Stach <l.stach@pengutronix.de>
Subject: Re: Support for configurable PCIe endpoint
Date: Mon, 29 Aug 2016 17:17:16 +0530 [thread overview]
Message-ID: <57C420C4.4000004@ti.com> (raw)
In-Reply-To: <1944530.NcryPj8uKU@wuerfel>
Hi Arnd,
On Thursday 25 August 2016 06:29 PM, Arnd Bergmann wrote:
> On Thursday, August 18, 2016 6:44:09 PM CEST Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Thursday 04 August 2016 04:43 PM, Arnd Bergmann wrote:
>>> On Thursday, August 4, 2016 3:32:01 PM CEST Kishon Vijay Abraham I wrote:
>>>> On Wednesday 03 August 2016 07:09 PM, Joao Pinto wrote:
>>>>>
>>>>> You are rising a topic that we are also addressing in Synopsys.
>>>>>
>>>>> For the PCIe RC hardware validation we are currently using the standard
>>>>> pcie-designware and pcie-designware-plat drivers.
>>>>>
>>>>> For the Endpoint we have to use an internal software package. Its main purpose
>>>>> is to initialize the IP registers, eDMA channels and make data transfer to prove
>>>>> that the everything is working properly. This is done in 2 levels, a custom
>>>>> driver built and loaded and an application that makes some ioctl to the driver
>>>>> executing some interesting functions to check the Endpoint status and make some
>>>>> data exchange.
>>>>
>>>> hmm.. the platform I have doesn't have a DMA in PCIe IP
>>>> (http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the
>>>> EP access RC memory? i.e the driver in the RC allocates memory from it's DDR
>>>> and gives it's DDR address to the EP. The EP then transfers data to this
>>>> address. (This is a typical use case with ethernet PCIe cards). IIUC that's not
>>>> simple with configurable EPs. I'd like to know more about your testing though.
>>>
>>>
>>> What's the difference between using the EDMA on that chip or a DMA engine
>>> that is part of the PCIe bridge?
>>
>> Do you mean the difference between using DMA on an EP (like ethernet card or
>> sata card) and DMA on PCI RC system? or is it the difference between eDMA
>> within the PCIe IP and system DMA?
>
> The latter. You write that there is no DMA in the PCIe IP, but from the
> perspective of the RC, it should not matter whether the DMA engine is
> part of the EP logic or behind it.
right, from the RC perspective there is no difference.
What I meant is DMA support in PCIe driver has to be added newly (i.e for
designware) and the the platform I have doesn't have a DMA in PCIe IP. Anyways,
we'll come back to this later after I post my RFC series, maybe by this week end.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: Support for configurable PCIe endpoint
Date: Mon, 29 Aug 2016 17:17:16 +0530 [thread overview]
Message-ID: <57C420C4.4000004@ti.com> (raw)
In-Reply-To: <1944530.NcryPj8uKU@wuerfel>
Hi Arnd,
On Thursday 25 August 2016 06:29 PM, Arnd Bergmann wrote:
> On Thursday, August 18, 2016 6:44:09 PM CEST Kishon Vijay Abraham I wrote:
>> Hi Arnd,
>>
>> On Thursday 04 August 2016 04:43 PM, Arnd Bergmann wrote:
>>> On Thursday, August 4, 2016 3:32:01 PM CEST Kishon Vijay Abraham I wrote:
>>>> On Wednesday 03 August 2016 07:09 PM, Joao Pinto wrote:
>>>>>
>>>>> You are rising a topic that we are also addressing in Synopsys.
>>>>>
>>>>> For the PCIe RC hardware validation we are currently using the standard
>>>>> pcie-designware and pcie-designware-plat drivers.
>>>>>
>>>>> For the Endpoint we have to use an internal software package. Its main purpose
>>>>> is to initialize the IP registers, eDMA channels and make data transfer to prove
>>>>> that the everything is working properly. This is done in 2 levels, a custom
>>>>> driver built and loaded and an application that makes some ioctl to the driver
>>>>> executing some interesting functions to check the Endpoint status and make some
>>>>> data exchange.
>>>>
>>>> hmm.. the platform I have doesn't have a DMA in PCIe IP
>>>> (http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf). So in your testing does the
>>>> EP access RC memory? i.e the driver in the RC allocates memory from it's DDR
>>>> and gives it's DDR address to the EP. The EP then transfers data to this
>>>> address. (This is a typical use case with ethernet PCIe cards). IIUC that's not
>>>> simple with configurable EPs. I'd like to know more about your testing though.
>>>
>>>
>>> What's the difference between using the EDMA on that chip or a DMA engine
>>> that is part of the PCIe bridge?
>>
>> Do you mean the difference between using DMA on an EP (like ethernet card or
>> sata card) and DMA on PCI RC system? or is it the difference between eDMA
>> within the PCIe IP and system DMA?
>
> The latter. You write that there is no DMA in the PCIe IP, but from the
> perspective of the RC, it should not matter whether the DMA engine is
> part of the EP logic or behind it.
right, from the RC perspective there is no difference.
What I meant is DMA support in PCIe driver has to be added newly (i.e for
designware) and the the platform I have doesn't have a DMA in PCIe IP. Anyways,
we'll come back to this later after I post my RFC series, maybe by this week end.
Thanks
Kishon
next prev parent reply other threads:[~2016-08-29 11:47 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 6:03 Support for configurable PCIe endpoint Kishon Vijay Abraham I
2016-08-03 6:03 ` Kishon Vijay Abraham I
2016-08-03 6:03 ` Kishon Vijay Abraham I
2016-08-03 7:42 ` Arnd Bergmann
2016-08-03 7:42 ` Arnd Bergmann
2016-08-03 7:42 ` Arnd Bergmann
2016-08-03 7:42 ` Arnd Bergmann
2016-08-04 8:19 ` Kishon Vijay Abraham I
2016-08-04 8:19 ` Kishon Vijay Abraham I
2016-08-04 8:19 ` Kishon Vijay Abraham I
2016-08-03 9:47 ` Christoph Hellwig
2016-08-03 9:47 ` Christoph Hellwig
2016-08-03 9:47 ` Christoph Hellwig
2016-08-03 9:47 ` Christoph Hellwig
2016-08-03 16:03 ` Arnd Bergmann
2016-08-03 16:03 ` Arnd Bergmann
2016-08-03 16:03 ` Arnd Bergmann
2016-08-03 16:03 ` Arnd Bergmann
2016-08-03 17:27 ` Christoph Hellwig
2016-08-03 17:27 ` Christoph Hellwig
2016-08-03 17:27 ` Christoph Hellwig
2016-08-03 17:27 ` Christoph Hellwig
2016-08-03 19:38 ` Arnd Bergmann
2016-08-03 19:38 ` Arnd Bergmann
2016-08-03 19:38 ` Arnd Bergmann
2016-08-03 19:38 ` Arnd Bergmann
2016-08-04 8:49 ` Kishon Vijay Abraham I
2016-08-04 8:49 ` Kishon Vijay Abraham I
2016-08-04 8:49 ` Kishon Vijay Abraham I
2016-08-04 8:49 ` Kishon Vijay Abraham I
2016-08-03 13:39 ` Joao Pinto
2016-08-03 13:39 ` Joao Pinto
2016-08-03 13:39 ` Joao Pinto
2016-08-04 10:02 ` Kishon Vijay Abraham I
2016-08-04 10:02 ` Kishon Vijay Abraham I
2016-08-04 10:02 ` Kishon Vijay Abraham I
2016-08-04 11:13 ` Arnd Bergmann
2016-08-04 11:13 ` Arnd Bergmann
2016-08-04 11:13 ` Arnd Bergmann
2016-08-18 13:14 ` Kishon Vijay Abraham I
2016-08-18 13:14 ` Kishon Vijay Abraham I
2016-08-18 13:14 ` Kishon Vijay Abraham I
2016-08-25 12:59 ` Arnd Bergmann
2016-08-25 12:59 ` Arnd Bergmann
2016-08-25 12:59 ` Arnd Bergmann
2016-08-25 12:59 ` Arnd Bergmann
2016-08-29 11:47 ` Kishon Vijay Abraham I [this message]
2016-08-29 11:47 ` Kishon Vijay Abraham I
2016-08-29 11:47 ` Kishon Vijay Abraham I
2016-08-17 9:49 ` Mingkai Hu
2016-08-17 9:49 ` Mingkai Hu
2016-08-17 9:49 ` Mingkai Hu
2016-08-17 9:49 ` Mingkai Hu
2016-08-18 12:24 ` Kishon Vijay Abraham I
2016-08-18 12:24 ` Kishon Vijay Abraham I
2016-08-18 12:24 ` Kishon Vijay Abraham I
2016-08-18 12:24 ` Kishon Vijay Abraham I
2016-08-29 15:25 ` Roy Zang
2016-08-29 15:25 ` Roy Zang
2016-08-29 15:25 ` Roy Zang
2016-08-29 15:25 ` Roy Zang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57C420C4.4000004@ti.com \
--to=kishon@ti.com \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=Richard.Zhu@freescale.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=gabriele.paoloni@huawei.com \
--cc=horms@verge.net.au \
--cc=jason@lakedaemon.net \
--cc=jingoohan1@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kern \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=mingkai.hu@freescale.com \
--cc=pratyush.anand@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tinamdar@apm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.