From: Joao.Pinto@synopsys.com (Joao Pinto)
To: linux-arm-kernel@lists.infradead.org
Subject: Support for configurable PCIe endpoint
Date: Wed, 3 Aug 2016 14:39:00 +0100 [thread overview]
Message-ID: <7c696488-eb78-d6d9-dc70-49fa5b4e3317@synopsys.com> (raw)
In-Reply-To: <57A18927.9070003@ti.com>
Hi Kishon,
On 8/3/2016 7:03 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> The PCIe controller present in TI's DRA7 SoC is capable of operating either in
> Root Complex mode or Endpoint mode. (It uses Synopsys Designware Core). I'd
> assume most of the PCIe controllers on other platforms that use Designware core
> should also be capable to operate in endpoint mode. But linux kernel right now
> supports only RC mode.
>
> PCIe endpoint support discussion came up briefly before [1] but it was felt the
> practical use case will find firmware more suitable and endpoint support in
> kernel can be used only for validation or demo.
>
> *) Modify platform driver to support EP mode (in my case pci-dra7xx.c).
>
> *) dt binding specific to EP mode should be created.
>
> Once I complete the implementation and start posting RFC patches, a lot of
> these will become clear. But I want to check if this sounds okay to you guys
> before starting the implementation.
>
> Let me know if you have some other ideas too.
>
> Cheers
> Kishon
>
> [1] -> http://www.spinics.net/lists/linux-pci/msg26026.html
>
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.
We are very interest in the subject and we are available to participate in the
development.
I would suggest that also the IP eDMA initialization and manipulation be
included in the framework and maybe produce a standard tool to test the endpoint.
Thanks
Joao
next prev parent reply other threads:[~2016-08-03 13:39 UTC|newest]
Thread overview: 17+ 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 7:42 ` Arnd Bergmann
2016-08-04 8:19 ` Kishon Vijay Abraham I
2016-08-03 9:47 ` Christoph Hellwig
2016-08-03 16:03 ` Arnd Bergmann
2016-08-03 17:27 ` Christoph Hellwig
2016-08-03 19:38 ` Arnd Bergmann
2016-08-04 8:49 ` Kishon Vijay Abraham I
2016-08-03 13:39 ` Joao Pinto [this message]
2016-08-04 10:02 ` Kishon Vijay Abraham I
2016-08-04 11:13 ` Arnd Bergmann
2016-08-18 13:14 ` Kishon Vijay Abraham I
2016-08-25 12:59 ` Arnd Bergmann
2016-08-29 11:47 ` Kishon Vijay Abraham I
2016-08-17 9:49 ` Mingkai Hu
2016-08-18 12:24 ` Kishon Vijay Abraham I
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=7c696488-eb78-d6d9-dc70-49fa5b4e3317@synopsys.com \
--to=joao.pinto@synopsys.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox