diff mbox

[V6,4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version

Message ID 1473449047-10499-5-git-send-email-tn@semihalf.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tomasz Nowicki Sept. 9, 2016, 7:24 p.m. UTC 
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see pci_thunder_pem_ops) and custom configuration space granulation
(see bus_shift = 24). In order to access configuration space and
probe PEM as ACPI based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
   code.
2. New quirk entries for each PEM segment. Each contains platform IDs,
   mentioned pci_thunder_pem_ops and CFG resources.

Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 drivers/acpi/pci_mcfg.c            | 27 +++++++++++++++++++++++++++
 drivers/pci/host/pci-thunder-pem.c |  2 +-
 include/linux/pci-ecam.h           |  4 ++++
 3 files changed, 32 insertions(+), 1 deletion(-)

Comments

Bjorn Helgaas Sept. 19, 2016, 3:45 p.m. UTC | #1 
On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> compliant with ECAM standard. It uses non-standard configuration space
> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> (see bus_shift = 24). In order to access configuration space and
> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
> infrastructure. This involves:
> 1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>    code.
> 2. New quirk entries for each PEM segment. Each contains platform IDs,
>    mentioned pci_thunder_pem_ops and CFG resources.
> 
> Quirk is considered for ThunderX silicon pass2.x only which is identified
> via MCFG revision 1.

Is it really the case that silicon pass2.x has MCFG revision 1, and
silicon pass1.x has MCFG revision 2?  That just seems backwards.

> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
>  drivers/acpi/pci_mcfg.c            | 27 +++++++++++++++++++++++++++
>  drivers/pci/host/pci-thunder-pem.c |  2 +-
>  include/linux/pci-ecam.h           |  4 ++++
>  3 files changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 2b8acc7..1f73d7b 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -51,6 +51,33 @@ struct mcfg_fixup {
>  
>  static struct mcfg_fixup mcfg_quirks[] = {
>  /*	{ OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +	/* SoC pass2.x */
> +	{ "CAVIUM", "THUNDERX", 1, 4, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x88001f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 5, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x884057000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 6, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x88808f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 7, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x89001f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 8, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x894057000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 9, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x89808f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 14, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x98001f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 15, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x984057000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 16, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x98808f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 17, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x99001f000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 18, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x994057000000UL, 0x39 * SZ_16M) },
> +	{ "CAVIUM", "THUNDERX", 1, 19, MCFG_BUS_ANY, &pci_thunder_pem_ops,
> +	  DEFINE_RES_MEM(0x99808f000000UL, 0x39 * SZ_16M) },
> +#endif
>  };
>  
>  static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> index b048761..d7c10cc 100644
> --- a/drivers/pci/host/pci-thunder-pem.c
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -367,7 +367,7 @@ static int thunder_pem_init(struct pci_config_window *cfg)
>  	return 0;
>  }
>  
> -static struct pci_ecam_ops pci_thunder_pem_ops = {
> +struct pci_ecam_ops pci_thunder_pem_ops = {
>  	.bus_shift	= 24,
>  	.init		= thunder_pem_init,
>  	.pci_ops	= {
> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
> index 7adad20..65505ea 100644
> --- a/include/linux/pci-ecam.h
> +++ b/include/linux/pci-ecam.h
> @@ -58,6 +58,10 @@ void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
>  			       int where);
>  /* default ECAM ops */
>  extern struct pci_ecam_ops pci_generic_ecam_ops;
> +/* ECAM ops for known quirks */
> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
> +extern struct pci_ecam_ops pci_thunder_pem_ops;
> +#endif
>  
>  #ifdef CONFIG_PCI_HOST_GENERIC
>  /* for DT-based PCI controllers that support ECAM */
> -- 
> 1.9.1
>
Tomasz Nowicki Sept. 20, 2016, 7:06 a.m. UTC | #2 
On 19.09.2016 17:45, Bjorn Helgaas wrote:
> On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
>> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
>> compliant with ECAM standard. It uses non-standard configuration space
>> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
>> (see bus_shift = 24). In order to access configuration space and
>> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
>> infrastructure. This involves:
>> 1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>>    code.
>> 2. New quirk entries for each PEM segment. Each contains platform IDs,
>>    mentioned pci_thunder_pem_ops and CFG resources.
>>
>> Quirk is considered for ThunderX silicon pass2.x only which is identified
>> via MCFG revision 1.
>
> Is it really the case that silicon pass2.x has MCFG revision 1, and
> silicon pass1.x has MCFG revision 2?  That just seems backwards.

It is weird but silicon pass2.x is more common and it had MCFG revision 
1 from the beginning. Unless it is allowed to use MCFG revision 0 ? Then 
we could use MCFG revision 0 for pass1.x

Tomasz
Bjorn Helgaas Sept. 20, 2016, 1:08 p.m. UTC | #3 
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
> On 19.09.2016 17:45, Bjorn Helgaas wrote:
> >On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
> >>ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
> >>compliant with ECAM standard. It uses non-standard configuration space
> >>accessors (see pci_thunder_pem_ops) and custom configuration space granulation
> >>(see bus_shift = 24). In order to access configuration space and
> >>probe PEM as ACPI based PCI host controller we need to add MCFG quirk
> >>infrastructure. This involves:
> >>1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
> >>   code.
> >>2. New quirk entries for each PEM segment. Each contains platform IDs,
> >>   mentioned pci_thunder_pem_ops and CFG resources.
> >>
> >>Quirk is considered for ThunderX silicon pass2.x only which is identified
> >>via MCFG revision 1.
> >
> >Is it really the case that silicon pass2.x has MCFG revision 1, and
> >silicon pass1.x has MCFG revision 2?  That just seems backwards.
> 
> It is weird but silicon pass2.x is more common and it had MCFG
> revision 1 from the beginning. Unless it is allowed to use MCFG
> revision 0 ? Then we could use MCFG revision 0 for pass1.x

There's no reason to avoid revision 0.  The question is really what
firmware is already in the field.  We need to accommodate that.  We don't
want a situation where kernel version X only works with firmware version Y,
but kernel version X+1 only works with firmware version Y+1.

Bjorn
Tomasz Nowicki Sept. 21, 2016, 8:05 a.m. UTC | #4 
On 20.09.2016 15:08, Bjorn Helgaas wrote:
> On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
>> On 19.09.2016 17:45, Bjorn Helgaas wrote:
>>> On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
>>>> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
>>>> compliant with ECAM standard. It uses non-standard configuration space
>>>> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
>>>> (see bus_shift = 24). In order to access configuration space and
>>>> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
>>>> infrastructure. This involves:
>>>> 1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>>>>   code.
>>>> 2. New quirk entries for each PEM segment. Each contains platform IDs,
>>>>   mentioned pci_thunder_pem_ops and CFG resources.
>>>>
>>>> Quirk is considered for ThunderX silicon pass2.x only which is identified
>>>> via MCFG revision 1.
>>>
>>> Is it really the case that silicon pass2.x has MCFG revision 1, and
>>> silicon pass1.x has MCFG revision 2?  That just seems backwards.
>>
>> It is weird but silicon pass2.x is more common and it had MCFG
>> revision 1 from the beginning. Unless it is allowed to use MCFG
>> revision 0 ? Then we could use MCFG revision 0 for pass1.x
>
> There's no reason to avoid revision 0.  The question is really what
> firmware is already in the field.  We need to accommodate that.  We don't
> want a situation where kernel version X only works with firmware version Y,
> but kernel version X+1 only works with firmware version Y+1.

Yes I agree. We have already deployed the firmware where:
pass2.x has MCFG revision 1
pass1.x has MCFG revision 2
so we need to stick to this.

Thanks,
Tomasz
diff mbox

Patch

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 2b8acc7..1f73d7b 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -51,6 +51,33 @@  struct mcfg_fixup {
 
 static struct mcfg_fixup mcfg_quirks[] = {
 /*	{ OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+#ifdef CONFIG_PCI_HOST_THUNDER_PEM
+	/* SoC pass2.x */
+	{ "CAVIUM", "THUNDERX", 1, 4, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x88001f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 5, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x884057000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 6, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x88808f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 7, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x89001f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 8, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x894057000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 9, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x89808f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 14, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x98001f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 15, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x984057000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 16, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x98808f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 17, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x99001f000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 18, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x994057000000UL, 0x39 * SZ_16M) },
+	{ "CAVIUM", "THUNDERX", 1, 19, MCFG_BUS_ANY, &pci_thunder_pem_ops,
+	  DEFINE_RES_MEM(0x99808f000000UL, 0x39 * SZ_16M) },
+#endif
 };
 
 static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
index b048761..d7c10cc 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -367,7 +367,7 @@  static int thunder_pem_init(struct pci_config_window *cfg)
 	return 0;
 }
 
-static struct pci_ecam_ops pci_thunder_pem_ops = {
+struct pci_ecam_ops pci_thunder_pem_ops = {
 	.bus_shift	= 24,
 	.init		= thunder_pem_init,
 	.pci_ops	= {
diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
index 7adad20..65505ea 100644
--- a/include/linux/pci-ecam.h
+++ b/include/linux/pci-ecam.h
@@ -58,6 +58,10 @@  void __iomem *pci_ecam_map_bus(struct pci_bus *bus, unsigned int devfn,
 			       int where);
 /* default ECAM ops */
 extern struct pci_ecam_ops pci_generic_ecam_ops;
+/* ECAM ops for known quirks */
+#ifdef CONFIG_PCI_HOST_THUNDER_PEM
+extern struct pci_ecam_ops pci_thunder_pem_ops;
+#endif
 
 #ifdef CONFIG_PCI_HOST_GENERIC
 /* for DT-based PCI controllers that support ECAM */