Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1329003 > unrolled thread

[RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-02-08 13:50 +0100
    Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant Arnd Bergmann <arnd@arndb.de> - 2016-02-08 14:50 +0100
      RE: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host  controller ECAM compliant Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-02-08 17:00 +0100
        Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant Arnd Bergmann <arnd@arndb.de> - 2016-02-08 17:40 +0100
          RE: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host  controller ECAM compliant Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-02-08 18:30 +0100

#1329003 — [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant

From: gabriele paoloni <gabriele.paoloni@huawei.com>

This patch modifies the current Hip05/Hip06 PCIe host controller
driver to make it ECAM compliant. This is needed in preparation
for the ACPI based driver to allow both DT and ACPI drivers to
use the same BIOS (that configure the Designware iATUs).

Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
---
 drivers/pci/host/pcie-designware.c |  4 +---
 drivers/pci/host/pcie-designware.h |  2 ++
 drivers/pci/host/pcie-hisi.c       | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 2171682..5f19ea4 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -69,8 +69,6 @@
 #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET		0x91C
 
-static struct pci_ops dw_pcie_ops;
-
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
 	if ((uintptr_t)addr & (size - 1)) {
@@ -690,7 +688,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
 	return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
 	.read = dw_pcie_rd_conf,
 	.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index 2356d29..3f42655 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -80,4 +80,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
+
 #endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 458d0f8..eb3201a 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,18 @@ struct pcie_soc_ops {
 	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
 };
 
+static inline int hisi_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 *value)
+{
+	return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 value)
+{
+	return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
 static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
 		int size, u32 *val)
 {
@@ -67,11 +79,24 @@ static int hisi_pcie_link_up(struct pcie_port *pp)
 }
 
 struct pcie_host_ops hisi_pcie_host_ops = {
+		.rd_other_conf = hisi_rd_other_conf,
+		.wr_other_conf = hisi_wr_other_conf,
 		.rd_own_conf = hisi_pcie_cfg_read,
 		.wr_own_conf = hisi_pcie_cfg_write,
 		.link_up = hisi_pcie_link_up,
 };
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+					     unsigned int devfn,
+					     int where)
+{
+	void __iomem *addr;
+	struct pcie_port *pp = bus->sysdata;
+
+	addr = pp->va_cfg1_base + where;
+
+	return addr;
+}
 
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
@@ -92,6 +117,8 @@ static int hisi_add_pcie_port(struct pcie_port *pp,
 
 	pp->ops = &hisi_pcie_host_ops;
 
+	dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
+
 	ret = dw_pcie_host_init(pp);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to initialize host\n");
@@ -137,6 +164,14 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 
 	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
 
+	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
+	hisi_pcie->pp.va_cfg0_base = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
+		dev_err(pp->dev, "cannot get ecam-cfg\n");
+		return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
+	}
+	hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
+
 	ret = hisi_add_pcie_port(pp, pdev);
 	if (ret)
 		return ret;
-- 
1.9.1

[toc] | [next] | [standalone]

#1329063

On Monday 08 February 2016 12:41:03 Gabriele Paoloni wrote:
> From: gabriele paoloni <gabriele.paoloni@huawei.com>
> 
> This patch modifies the current Hip05/Hip06 PCIe host controller
> driver to make it ECAM compliant. This is needed in preparation
> for the ACPI based driver to allow both DT and ACPI drivers to
> use the same BIOS (that configure the Designware iATUs).
> 
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> 

Doesn't this break backwards compatibility?

I think you need to use a new compatible string in the firmware
if you change the register layout, and then change the driver
to support both the old and the new layout.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1329224 — RE: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 08 February 2016 13:48
> To: linux-arm-kernel@lists.infradead.org
> Cc: Gabriele Paoloni; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> (C); Linuxarm; qiujiang; bhelgaas@google.com;
> Lorenzo.Pieralisi@arm.com; tn@semihalf.com; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; xuwei (O); linux-acpi@vger.kernel.org;
> jcm@redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 12:41:03 Gabriele Paoloni wrote:
> > From: gabriele paoloni <gabriele.paoloni@huawei.com>
> >
> > This patch modifies the current Hip05/Hip06 PCIe host controller
> > driver to make it ECAM compliant. This is needed in preparation
> > for the ACPI based driver to allow both DT and ACPI drivers to
> > use the same BIOS (that configure the Designware iATUs).
> >
> > Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> > Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> >
> 
> Doesn't this break backwards compatibility?

Well Hip05/Hip06 SoCs are used into evaluation boards
For the Estuary project.

https://github.com/hisilicon/estuary

As this new driver gets upstream we'll merge this new driver into estuary
and release a new version of the firmware to support it.

> 
> I think you need to use a new compatible string in the firmware
> if you change the register layout, and then change the driver
> to support both the old and the new layout.

You are right, for some reason in this patchset I missed the Documentation
update that I posted in the previous one, i.e.:

--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -23,8 +23,8 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
 	pcie@0xb0080000 {
 		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
-		reg-names = "rc_dbi", "config";
+		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0 0x0f00000>;
+		reg-names = "rc_dbi", "ecam-cfg";

I will fix this in v3

Thanks

Gab 


> 
> 	Arnd

[toc] | [prev] | [next] | [standalone]

#1329288

On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > Doesn't this break backwards compatibility?
> 
> Well Hip05/Hip06 SoCs are used into evaluation boards
> For the Estuary project.
> 
> https://github.com/hisilicon/estuary
> 
> As this new driver gets upstream we'll merge this new driver into estuary
> and release a new version of the firmware to support it.

So what happens to folks running the old firmware then?

> > I think you need to use a new compatible string in the firmware
> > if you change the register layout, and then change the driver
> > to support both the old and the new layout.
> 
> You are right, for some reason in this patchset I missed the Documentation
> update that I posted in the previous one, i.e.:
> 
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -23,8 +23,8 @@ Optional properties:
>  Hip05 Example (note that Hip06 is the same except compatible):
>         pcie@0xb0080000 {
>                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
> -               reg-names = "rc_dbi", "config";
> +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0 0x0f00000>;
> +               reg-names = "rc_dbi", "ecam-cfg";
> 

That is not the compatible string, it's an undocumented register set.
You can either define the a new compatible string that gives the "config"
registers a new meaning, or you change the binding to allow two either
a "config" or an "ecam-cfg" register set, and let the driver handle both.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1329384 — RE: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant

Hi Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 08 February 2016 16:30
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas@google.com;
> Lorenzo.Pieralisi@arm.com; tn@semihalf.com; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; xuwei (O); linux-acpi@vger.kernel.org;
> jcm@redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > > Doesn't this break backwards compatibility?
> >
> > Well Hip05/Hip06 SoCs are used into evaluation boards
> > For the Estuary project.
> >
> > https://github.com/hisilicon/estuary
> >
> > As this new driver gets upstream we'll merge this new driver into
> estuary
> > and release a new version of the firmware to support it.
> 
> So what happens to folks running the old firmware then?

So far we haven't released the PCIe nodes dtsi upstream and we think
we can handle the firmware upgrade for our current users either
by pointing them to the updated Estuary branch or by internal 
channels  

> 
> > > I think you need to use a new compatible string in the firmware
> > > if you change the register layout, and then change the driver
> > > to support both the old and the new layout.
> >
> > You are right, for some reason in this patchset I missed the
> Documentation
> > update that I posted in the previous one, i.e.:
> >
> > --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > @@ -23,8 +23,8 @@ Optional properties:
> >  Hip05 Example (note that Hip06 is the same except compatible):
> >         pcie@0xb0080000 {
> >                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> > -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0
> 0x2000>;
> > -               reg-names = "rc_dbi", "config";
> > +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0
> 0x0f00000>;
> > +               reg-names = "rc_dbi", "ecam-cfg";
> >
> 
> That is not the compatible string, it's an undocumented register set.

Sorry, I misunderstood here, got it now :)

> You can either define the a new compatible string that gives the
> "config"
> registers a new meaning, or you change the binding to allow two either
> a "config" or an "ecam-cfg" register set, and let the driver handle
> both.

As per reply above I think that it would be quite easy for us to
let out current users update the BIOS so I don't think there is any
value in maintaining two version of the drivers one of which will
not be used.

What do you think?

Thanks

Gab

> 
> 	Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web