Re: Support for configurable PCIe endpoint
From: Arnd Bergmann <arnd@arndb.de>
Date: 2016-08-03 07:55:14
Also in:
linux-arm-kernel, linux-omap, lkml
On Wednesday, August 3, 2016 11:33:19 AM CEST 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. Validation or demo is itself a valid use case in my opinion (consider something similar to gadget zero for USB). There can be other use cases as well. The RC can use the SoC with EP mode support as an accelerator to accomplish specific task. Here RC gives data to the EP. The EP processes the data. The processing can be done either in ARM itself or it can use other hardware accelerators (like DSP, IVA-HD etc..) present in the EP system. If HW accelerator is used, the linux kernel running in ARM can be used to accomplish other tasks. Once EP mode support is added, I think more use cases will be added. From the high level this should look _similar_ to the gadget framework of USB. One difference from USB would be this should allow HW components (like DSP, PRU etc.. and maybe even some peripheral) in the EP system to be used by RC system.
(Adding Jon Mason) We have the drivers/ntb framework, which in theory should be able to handle this, but in practice is only used for a very small number of bridge implementations, and is also limited in the way it can be configured (compared to USB gadget)
So these are the high-level steps that I thought would be needed to add EP support in linux. *) move pcie-designware.c out of drivers/pci/host (maybe create a drivers/pci/designware/ folder?). All users of pcie-designware.c should be moved here. This is in preparation for adding EP mode support to designware.
A lot of the other drivers in drivers/pci/host support endpoint mode too, I don't think moving them all elsewhere is helpful or necessary here.
*) Add library functions in pcie-designware.c specific to EP mode like initializing general ecam registers, BAR registers etc.. These functions should be invoked from a *function* driver (function driver should determine the use of a particular EP). *) Add a sample *function* driver that can be used just for validation. This function driver will invoke the previously added functions in PCIe controller to initialize ecam, BAR etc.. This will invoke the PCIe controller functions through *ep-core* layer. That way the same function driver can be made to work with different PCIe controllers. (A PCIe driver corresponding to this function driver should also be implemented in RC side) *) Add *ep-core* layer to bind the function driver to the controller driver and using which the function driver will invoke controller driver callbacks (to initialize ecam, BAR registers etc..)
I think we should first have a rough idea what the framework should look like, and how it handles having multiple hardware implementation and multiple protocol implementations, before we modify a particular driver. So this step here should come a bit earlier than the others.
*) Modify platform driver to support EP mode (in my case pci-dra7xx.c). *) dt binding specific to EP mode should be created.
Right. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel