All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Christoph Hellwig <hch@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>,
	Thierry Reding <thierry.reding@gmail.com>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Joao Pinto <jpinto@synopsys.com>,
	Pratyush Anand <pratyush.anand@gmail.com>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Jason Cooper <jason@lakedaemon.net>,
	"arnd@arndb.de" <arnd@arndb.de>,
	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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.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 <sva>
Subject: Re: Support for configurable PCIe endpoint
Date: Thu, 4 Aug 2016 14:19:07 +0530	[thread overview]
Message-ID: <57A30183.2060800@ti.com> (raw)
In-Reply-To: <20160803094747.GA10170@infradead.org>

Hi,

On Wednesday 03 August 2016 03:17 PM, Christoph Hellwig wrote:
> On Wed, Aug 03, 2016 at 11:33:19AM +0530, 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.
> 
> I disagree.  It's highly useful for rapid prototyping of hardware
> interfaces, and I've been looking into PCIe EP drivers for exactly
> that reason recently.  Going a little offtopic: any good DRA7 eval
> boards you'd recommend to try for this purpose?

I think the only publicly available DRA7 based board with PCIe (mPCIe slot) is
AM572x EVM (http://www.ti.com/tool/TMDSEVM572X). The board comes only with a
female PCIe slot. So a special cable would be required to connect it to a PCIe
host.

However for my development I'm planning to use dra7-evm which has standard
female PCIe connector and I'll use a cable like PE-FLEX1 male-to-male (in
http://www.adexelec.com/pciexp.htm) to connect back-to-back boards.
> 
> We already have a EP driver in the tree:
> 
> drivers/misc/spear13xx_pcie_gadget.c
> 
> but as far as I can tell it doesn't really work at the moment.

Okay. I wasn't aware of that. I'll take a look at that one.
> 
>> 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.
> 
> That sounds useful as well.
> 
>> >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.
> 
> Indeed.
> 
>> 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.
> 
> I'd use a new drivers/pci/controller.  Or maybe just skip the rename
> for now and see how this evolves.

Sure. That makes more sense.
> 
> The rest of the plan sounds fine to me.

cool.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Christoph Hellwig <hch@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>,
	Thierry Reding <thierry.reding@gmail.com>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Joao Pinto <jpinto@synopsys.com>,
	Pratyush Anand <pratyush.anand@gmail.com>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Jason Cooper <jason@lakedaemon.net>,
	"arnd@arndb.de" <arnd@arndb.de>,
	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>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.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: Thu, 4 Aug 2016 14:19:07 +0530	[thread overview]
Message-ID: <57A30183.2060800@ti.com> (raw)
In-Reply-To: <20160803094747.GA10170@infradead.org>

Hi,

On Wednesday 03 August 2016 03:17 PM, Christoph Hellwig wrote:
> On Wed, Aug 03, 2016 at 11:33:19AM +0530, 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.
> 
> I disagree.  It's highly useful for rapid prototyping of hardware
> interfaces, and I've been looking into PCIe EP drivers for exactly
> that reason recently.  Going a little offtopic: any good DRA7 eval
> boards you'd recommend to try for this purpose?

I think the only publicly available DRA7 based board with PCIe (mPCIe slot) is
AM572x EVM (http://www.ti.com/tool/TMDSEVM572X). The board comes only with a
female PCIe slot. So a special cable would be required to connect it to a PCIe
host.

However for my development I'm planning to use dra7-evm which has standard
female PCIe connector and I'll use a cable like PE-FLEX1 male-to-male (in
http://www.adexelec.com/pciexp.htm) to connect back-to-back boards.
> 
> We already have a EP driver in the tree:
> 
> drivers/misc/spear13xx_pcie_gadget.c
> 
> but as far as I can tell it doesn't really work at the moment.

Okay. I wasn't aware of that. I'll take a look at that one.
> 
>> 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.
> 
> That sounds useful as well.
> 
>> >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.
> 
> Indeed.
> 
>> 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.
> 
> I'd use a new drivers/pci/controller.  Or maybe just skip the rename
> for now and see how this evolves.

Sure. That makes more sense.
> 
> The rest of the plan sounds fine to me.

cool.

Thanks
Kishon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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: Thu, 4 Aug 2016 14:19:07 +0530	[thread overview]
Message-ID: <57A30183.2060800@ti.com> (raw)
In-Reply-To: <20160803094747.GA10170@infradead.org>

Hi,

On Wednesday 03 August 2016 03:17 PM, Christoph Hellwig wrote:
> On Wed, Aug 03, 2016 at 11:33:19AM +0530, 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.
> 
> I disagree.  It's highly useful for rapid prototyping of hardware
> interfaces, and I've been looking into PCIe EP drivers for exactly
> that reason recently.  Going a little offtopic: any good DRA7 eval
> boards you'd recommend to try for this purpose?

I think the only publicly available DRA7 based board with PCIe (mPCIe slot) is
AM572x EVM (http://www.ti.com/tool/TMDSEVM572X). The board comes only with a
female PCIe slot. So a special cable would be required to connect it to a PCIe
host.

However for my development I'm planning to use dra7-evm which has standard
female PCIe connector and I'll use a cable like PE-FLEX1 male-to-male (in
http://www.adexelec.com/pciexp.htm) to connect back-to-back boards.
> 
> We already have a EP driver in the tree:
> 
> drivers/misc/spear13xx_pcie_gadget.c
> 
> but as far as I can tell it doesn't really work at the moment.

Okay. I wasn't aware of that. I'll take a look at that one.
> 
>> 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.
> 
> That sounds useful as well.
> 
>> >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.
> 
> Indeed.
> 
>> 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.
> 
> I'd use a new drivers/pci/controller.  Or maybe just skip the rename
> for now and see how this evolves.

Sure. That makes more sense.
> 
> The rest of the plan sounds fine to me.

cool.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Jingoo Han <jingoohan1@gmail.com>,
	Pratyush Anand <pratyush.anand@gmail.com>,
	Ley Foon Tan <lftan@altera.com>, Rob Herring <robh@kernel.org>,
	Tanmay Inamdar <tinamdar@apm.com>,
	Roy Zang <tie-fei.zang@freescale.com>,
	Mingkai Hu <mingkai.hu@freescale.com>,
	Minghuan Lian <minghuan.Lian@freescale.com>,
	Richard Zhu <Richard.Zhu@freescale.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Murali Karicheri <m-karicheri2@ti.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Thierry Reding <thierry.reding@gmail.com>,
	Simon Horman <horms@verge.net.au>,
	Joao Pinto <jpinto@synopsys.com>,
	Zhou Wang <wangzhou1@hisilicon.com>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Stanimir Varbanov <svarbanov@mm-sol.com>,
	David Daney <david.daney@cavium.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: Support for configurable PCIe endpoint
Date: Thu, 4 Aug 2016 14:19:07 +0530	[thread overview]
Message-ID: <57A30183.2060800@ti.com> (raw)
In-Reply-To: <20160803094747.GA10170@infradead.org>

Hi,

On Wednesday 03 August 2016 03:17 PM, Christoph Hellwig wrote:
> On Wed, Aug 03, 2016 at 11:33:19AM +0530, 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.
> 
> I disagree.  It's highly useful for rapid prototyping of hardware
> interfaces, and I've been looking into PCIe EP drivers for exactly
> that reason recently.  Going a little offtopic: any good DRA7 eval
> boards you'd recommend to try for this purpose?

I think the only publicly available DRA7 based board with PCIe (mPCIe slot) is
AM572x EVM (http://www.ti.com/tool/TMDSEVM572X). The board comes only with a
female PCIe slot. So a special cable would be required to connect it to a PCIe
host.

However for my development I'm planning to use dra7-evm which has standard
female PCIe connector and I'll use a cable like PE-FLEX1 male-to-male (in
http://www.adexelec.com/pciexp.htm) to connect back-to-back boards.
> 
> We already have a EP driver in the tree:
> 
> drivers/misc/spear13xx_pcie_gadget.c
> 
> but as far as I can tell it doesn't really work at the moment.

Okay. I wasn't aware of that. I'll take a look at that one.
> 
>> 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.
> 
> That sounds useful as well.
> 
>> >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.
> 
> Indeed.
> 
>> 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.
> 
> I'd use a new drivers/pci/controller.  Or maybe just skip the rename
> for now and see how this evolves.

Sure. That makes more sense.
> 
> The rest of the plan sounds fine to me.

cool.

Thanks
Kishon

  parent reply	other threads:[~2016-08-04  8:49 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 [this message]
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
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=57A30183.2060800@ti.com \
    --to=kishon@ti.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=hch@infradead.org \
    --cc=horms@verge.net.au \
    --cc=jason@lakedaemon.net \
    --cc=jingoohan1@gmail.com \
    --cc=jpinto@synopsys.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.