From: Kishon Vijay Abraham I <kishon@ti.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"Joao.Pinto@synopsys.com" <Joao.Pinto@synopsys.com>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry
Date: Fri, 4 May 2018 11:28:58 +0530 [thread overview]
Message-ID: <aeb80d31-c79e-80a9-5e67-9bf1f277f39a@ti.com> (raw)
In-Reply-To: <20180503141636.GA23270@e107981-ln.cambridge.arm.com>
Hi Lorenzo,
On Thursday 03 May 2018 07:46 PM, Lorenzo Pieralisi wrote:
> On Thu, May 03, 2018 at 12:03:15PM +0530, Kishon Vijay Abraham I wrote:
>
> [...]
>
>>>> Since the linkup notifier and BAR index (where auxiliary registers are
>>>> located) may be configurable and is something platform dependent,
>>>> perhaps the configuration of this variables should be done by module
>>>> parameter and not by configfs, leaving this configuration
>>>> responsibility in charge of each platform.
>>>
>>> They are platform dependent because they depend on the EP controller.
>>> That's why I said that those are EP controller parameters. I do not
>>> think they are module parameters either - they should be part of HW
>>> description in firmware.
>>
>> The problem is because pci-epf-test cannot be described in HW. pci-epf-test is
>> also not automatically bound to the EP controller but is bound by the user like
>> below
>> ln -s functions/pci_epf_test/func1 controllers/51000000.pcie_ep/
>>
>> So given that user anyways has to bind the epf device to the controller, based
>> on the platform the user can use a different configfs entry like below
>> ln -s functions/pci_epf_test_dw/func1 controllers/51000000.pcie_ep/ or
>> ln -s functions/pci_epf_test_k2g/func1 controllers/21800000.pcie-ep/
>>
>> If the epf can be described in dt, then something like below can be done
>> pcie1_ep: pcie_ep@51000000 {
>> compatible = "ti,dra7-pcie-ep";
>> interrupts = <0 232 0x4>;
>> num-lanes = <1>;
>> num-ib-windows = <4>;
>> num-ob-windows = <16>;
>> phys = <&pcie1_phy>;
>> phy-names = "pcie-phy0";
>> pci_epf_test: pci_epf_test@0 {
>> name = "pci_epf_test_dw";
>> <other properties>;
>> }
>> };
>>
>> With this pci-dra7xx.c driver should create pci_epf_device using
>> pci_epf_create("pci_epf_test_dw");
>>
>> Then the driver_data corresponding to "pci_epf_test_dw" will select linkup
>> notifier or BAR index etc.
>
> Those two properties are properties of the EP controller (it is not 100%
> clear to me how the test BAR register is defined), is this correct ?
Right, these properties are specific to a platform. In some of the platforms
like K2G (BAR0 is reserved i.e it is used to map PCIe app registers and cannot
be used by pci_epf_test. In such cases we should use a BAR other than BAR0).
>
> If yes, given that those properties are not useful before an EPF is
> bound to an EPC, can't they be retrieved at bind time from the EPC
> controller data (that we can add through DT bindings) ?
hmm..
We can have quirk in pci_epc, something like below
struct pci_epc {
.
.
unsigned int quirks;
.
.
};
#define EPC_QUIRKS_NO_LINKUP_NOTIFIER BIT(0)
#define EPC_QUIRKS_BAR0_RESERVED BIT(1)
#define EPC_QUIRKS_BAR1_RESERVED BIT(2)
#define EPC_QUIRKS_BAR2_RESERVED BIT(3)
#define EPC_QUIRKS_BAR3_RESERVED BIT(4)
#define EPC_QUIRKS_BAR4_RESERVED BIT(5)
#define EPC_QUIRKS_BAR5_RESERVED BIT(6)
The controller driver can set the appropriate quirks
epc->quirks |= EPC_QUIRKS_NO_LINKUP_NOTIFIER | EPC_QUIRKS_BAR0_RESERVED;
Then pci-epf-test driver can checks the quirks to see the supported EPC features.
Does something like above looks okay to you?
Thanks
Kishon
next prev parent reply other threads:[~2018-05-04 5:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 13:44 [PATCH v7 0/9] Designware EP support and code clean up Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 1/9] bindings: PCI: designware: Example update Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 2/9] PCI: dwc: Add support for endpoint mode Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 3/9] PCI: endpoint: functions/pci-epf-test: Add second entry Gustavo Pimentel
2018-04-26 16:56 ` Lorenzo Pieralisi
2018-04-30 17:32 ` Gustavo Pimentel
2018-05-01 10:07 ` Kishon Vijay Abraham I
2018-05-01 11:54 ` Lorenzo Pieralisi
2018-05-01 12:23 ` Kishon Vijay Abraham I
2018-05-01 14:26 ` Lorenzo Pieralisi
2018-05-02 10:39 ` Gustavo Pimentel
2018-05-02 16:51 ` Lorenzo Pieralisi
2018-05-03 6:33 ` Kishon Vijay Abraham I
2018-05-03 14:16 ` Lorenzo Pieralisi
2018-05-04 5:58 ` Kishon Vijay Abraham I [this message]
2018-05-04 11:18 ` Lorenzo Pieralisi
2018-05-03 15:21 ` Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 4/9] bindings: PCI: designware: Add support for the EP in Designware driver Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 5/9] misc: pci_endpoint_test: Add designware EP entry Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 6/9] PCI: dwc: Define maximum number of vectors Gustavo Pimentel
2018-04-24 14:39 ` Jingoo Han
2018-04-24 13:44 ` [PATCH v7 7/9] PCI: dwc: Replace lower into upper case characters Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 8/9] PCI: dwc: Small computation improvement Gustavo Pimentel
2018-04-24 13:44 ` [PATCH v7 9/9] PCI: dwc: Replace magic number by defines Gustavo Pimentel
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=aeb80d31-c79e-80a9-5e67-9bf1f277f39a@ti.com \
--to=kishon@ti.com \
--cc=Joao.Pinto@synopsys.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.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;
as well as URLs for NNTP newsgroup(s).