[PATCH 0/4] arm64: Juno: Add support for PCIe on R1 board

[PATCH 0/4] arm64: Juno: Add support for PCIe on R1 board

[Liviu Dudau]

Juno R1 board has a working PCIe host bridge that can be enabled and
configured by the firmware and made use of by Linux. For UEFI, the
Linaro releases contain firmware that configure the XpressRICH3 host
bridge correctly. For U-Boot based setups, one needs the patchset
posted here[1].

This patchset adds a quirk for setting the correct class to the host
bridge device and the device tree changes that enable PCIe on Juno R1.
We also update the defconfig to enable the generic PCI host bridge driver.

Best regards,
Liviu

1. http://lists.denx.de/pipermail/u-boot/2015-October/229669.html


Andrew Murray (1):
  pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

Liviu Dudau (3):
  PCI: Add quirk for PLDA's XpressRICH3 host bridge class.
  arm64: Juno: Add support for the PCIe host bridge on Juno R1
  arm64: defconfig: Enable PCI generic host bridge by default

 arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
 arch/arm64/configs/defconfig        |  1 +
 drivers/pci/quirks.c                | 10 ++++++++++
 include/linux/pci_ids.h             |  3 +++
 4 files changed, 34 insertions(+)

-- 
2.6.0

[PATCH 0/4] arm64: Juno: Add support for PCIe on R1 board

[Liviu Dudau]

Juno R1 board has a working PCIe host bridge that can be enabled and
configured by the firmware and made use of by Linux. For UEFI, the
Linaro releases contain firmware that configure the XpressRICH3 host
bridge correctly. For U-Boot based setups, one needs the patchset
posted here[1].

This patchset adds a quirk for setting the correct class to the host
bridge device and the device tree changes that enable PCIe on Juno R1.
We also update the defconfig to enable the generic PCI host bridge driver.

Best regards,
Liviu

1. http://lists.denx.de/pipermail/u-boot/2015-October/229669.html


Andrew Murray (1):
  pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

Liviu Dudau (3):
  PCI: Add quirk for PLDA's XpressRICH3 host bridge class.
  arm64: Juno: Add support for the PCIe host bridge on Juno R1
  arm64: defconfig: Enable PCI generic host bridge by default

 arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
 arch/arm64/configs/defconfig        |  1 +
 drivers/pci/quirks.c                | 10 ++++++++++
 include/linux/pci_ids.h             |  3 +++
 4 files changed, 34 insertions(+)

-- 
2.6.0

[PATCH 0/4] arm64: Juno: Add support for PCIe on R1 board

[Liviu Dudau]

Juno R1 board has a working PCIe host bridge that can be enabled and
configured by the firmware and made use of by Linux. For UEFI, the
Linaro releases contain firmware that configure the XpressRICH3 host
bridge correctly. For U-Boot based setups, one needs the patchset
posted here[1].

This patchset adds a quirk for setting the correct class to the host
bridge device and the device tree changes that enable PCIe on Juno R1.
We also update the defconfig to enable the generic PCI host bridge driver.

Best regards,
Liviu

1. http://lists.denx.de/pipermail/u-boot/2015-October/229669.html


Andrew Murray (1):
  pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

Liviu Dudau (3):
  PCI: Add quirk for PLDA's XpressRICH3 host bridge class.
  arm64: Juno: Add support for the PCIe host bridge on Juno R1
  arm64: defconfig: Enable PCI generic host bridge by default

 arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
 arch/arm64/configs/defconfig        |  1 +
 drivers/pci/quirks.c                | 10 ++++++++++
 include/linux/pci_ids.h             |  3 +++
 4 files changed, 34 insertions(+)

-- 
2.6.0

[PATCH 1/4] pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

[Liviu Dudau]

From: Andrew Murray <Andrew.Murray@arm.com>

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/linux/pci_ids.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..1542b2b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1319,6 +1319,9 @@
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP79_SMBUS     0x0AA2
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP89_SATA	    0x0D85
 
+#define PCI_VENDOR_ID_PLDA		0x1556
+#define PCI_DEVICE_ID_XR3PCI		0x1100
+
 #define PCI_VENDOR_ID_IMS		0x10e0
 #define PCI_DEVICE_ID_IMS_TT128		0x9128
 #define PCI_DEVICE_ID_IMS_TT3D		0x9135
-- 
2.6.0

[PATCH 1/4] pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

[Liviu Dudau]

From: Andrew Murray <Andrew.Murray@arm.com>

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/linux/pci_ids.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..1542b2b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1319,6 +1319,9 @@
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP79_SMBUS     0x0AA2
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP89_SATA	    0x0D85
 
+#define PCI_VENDOR_ID_PLDA		0x1556
+#define PCI_DEVICE_ID_XR3PCI		0x1100
+
 #define PCI_VENDOR_ID_IMS		0x10e0
 #define PCI_DEVICE_ID_IMS_TT128		0x9128
 #define PCI_DEVICE_ID_IMS_TT3D		0x9135
-- 
2.6.0

[PATCH 1/4] pci: Add PLDA's XpressRICH3 PCIe host bridge PCI ID

[Liviu Dudau]

From: Andrew Murray <Andrew.Murray@arm.com>

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/linux/pci_ids.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..1542b2b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1319,6 +1319,9 @@
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP79_SMBUS     0x0AA2
 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP89_SATA	    0x0D85
 
+#define PCI_VENDOR_ID_PLDA		0x1556
+#define PCI_DEVICE_ID_XR3PCI		0x1100
+
 #define PCI_VENDOR_ID_IMS		0x10e0
 #define PCI_DEVICE_ID_IMS_TT128		0x9128
 #define PCI_DEVICE_ID_IMS_TT3D		0x9135
-- 
2.6.0

[PATCH 2/4] PCI: Add quirk for PLDA's XpressRICH3 host bridge class.

[Liviu Dudau]

The XpressRICH3 host bridge at power up has an unassigned class on
some of ARM Ltd boards, add a quirk to correct that.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/quirks.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b03373f..ae24bb4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4149,3 +4149,13 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
+
+/*
+ * The PLDA's XpressRICH3 doesn't describe itself as a bridge. This is required
+ * for correct/normal enumeration.
+ */
+static void xr3pci_quirk_class(struct pci_dev *pdev)
+{
+	pdev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_PLDA, PCI_DEVICE_ID_XR3PCI, xr3pci_quirk_class);
-- 
2.6.0

[PATCH 2/4] PCI: Add quirk for PLDA's XpressRICH3 host bridge class.

[Liviu Dudau]

The XpressRICH3 host bridge at power up has an unassigned class on
some of ARM Ltd boards, add a quirk to correct that.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/quirks.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b03373f..ae24bb4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4149,3 +4149,13 @@ static void quirk_intel_qat_vf_cap(struct pci_dev *pdev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
+
+/*
+ * The PLDA's XpressRICH3 doesn't describe itself as a bridge. This is required
+ * for correct/normal enumeration.
+ */
+static void xr3pci_quirk_class(struct pci_dev *pdev)
+{
+	pdev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_PLDA, PCI_DEVICE_ID_XR3PCI, xr3pci_quirk_class);
-- 
2.6.0

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

Juno R1 board sports a functional PCIe host bridge that is
compliant with the SBSA standard found here[1]. With the right
firmware that initialises the XpressRICH3 controller one can
use the generic Host Bridge driver to use the PCIe hardware.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
---
 arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index c627511..a702a6b 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -109,6 +109,26 @@
 
 	#include "juno-base.dtsi"
 
+	pcie-controller@40000000 {
+		compatible = "pci-host-ecam-generic";
+		device_type = "pci";
+		reg = <0 0x40000000 0 0x10000000>;	/* ECAM config space */
+		bus-range = <0 255>;
+		linux,pci-domain = <0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		dma-coherent;
+		ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
+			  0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
+			  0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
+				 0 0 0 2 &gic 0 0 0 137 4
+				 0 0 0 3 &gic 0 0 0 138 4
+				 0 0 0 4 &gic 0 0 0 139 4>;
+		msi-parent = <&v2m_0>;
+	};
 };
 
 &memtimer {
-- 
2.6.0

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

Juno R1 board sports a functional PCIe host bridge that is
compliant with the SBSA standard found here[1]. With the right
firmware that initialises the XpressRICH3 controller one can
use the generic Host Bridge driver to use the PCIe hardware.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
---
 arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
index c627511..a702a6b 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -109,6 +109,26 @@
 
 	#include "juno-base.dtsi"
 
+	pcie-controller at 40000000 {
+		compatible = "pci-host-ecam-generic";
+		device_type = "pci";
+		reg = <0 0x40000000 0 0x10000000>;	/* ECAM config space */
+		bus-range = <0 255>;
+		linux,pci-domain = <0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		dma-coherent;
+		ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
+			  0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
+			  0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
+				 0 0 0 2 &gic 0 0 0 137 4
+				 0 0 0 3 &gic 0 0 0 138 4
+				 0 0 0 4 &gic 0 0 0 139 4>;
+		msi-parent = <&v2m_0>;
+	};
 };
 
 &memtimer {
-- 
2.6.0

[PATCH 4/4] arm64: defconfig: Enable PCI generic host bridge by default

[Liviu Dudau]

Now that pci-host-generic can be used under arm64, enable it by
default so that SBSA compliant systems can use it.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 34d71dd..7c9455a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -49,6 +49,7 @@ CONFIG_ARCH_XGENE=y
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
+CONFIG_PCI_HOST_GENERIC=y
 CONFIG_PCI_XGENE=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
-- 
2.6.0

[PATCH 4/4] arm64: defconfig: Enable PCI generic host bridge by default

[Liviu Dudau]

Now that pci-host-generic can be used under arm64, enable it by
default so that SBSA compliant systems can use it.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 34d71dd..7c9455a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -49,6 +49,7 @@ CONFIG_ARCH_XGENE=y
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
+CONFIG_PCI_HOST_GENERIC=y
 CONFIG_PCI_XGENE=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
-- 
2.6.0

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Rob Herring]

On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Juno R1 board sports a functional PCIe host bridge that is
> compliant with the SBSA standard found here[1]. With the right
> firmware that initialises the XpressRICH3 controller one can
> use the generic Host Bridge driver to use the PCIe hardware.
>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> ---
>  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index c627511..a702a6b 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -109,6 +109,26 @@
>
>         #include "juno-base.dtsi"
>
> +       pcie-controller@40000000 {
> +               compatible = "pci-host-ecam-generic";

I think this is the first case of real h/w using this. We should have
a specific compatible here additionally. Perhaps the firmware did not
setup something correctly.

> +               device_type = "pci";
> +               reg = <0 0x40000000 0 0x10000000>;      /* ECAM config space */
> +               bus-range = <0 255>;
> +               linux,pci-domain = <0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               dma-coherent;
> +               ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
> +                         0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
> +                         0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> +               #interrupt-cells = <1>;
> +               interrupt-map-mask = <0 0 0 7>;
> +               interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
> +                                0 0 0 2 &gic 0 0 0 137 4
> +                                0 0 0 3 &gic 0 0 0 138 4
> +                                0 0 0 4 &gic 0 0 0 139 4>;
> +               msi-parent = <&v2m_0>;
> +       };
>  };
>
>  &memtimer {
> --
> 2.6.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Rob Herring]

On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Juno R1 board sports a functional PCIe host bridge that is
> compliant with the SBSA standard found here[1]. With the right
> firmware that initialises the XpressRICH3 controller one can
> use the generic Host Bridge driver to use the PCIe hardware.
>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> ---
>  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index c627511..a702a6b 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -109,6 +109,26 @@
>
>         #include "juno-base.dtsi"
>
> +       pcie-controller at 40000000 {
> +               compatible = "pci-host-ecam-generic";

I think this is the first case of real h/w using this. We should have
a specific compatible here additionally. Perhaps the firmware did not
setup something correctly.

> +               device_type = "pci";
> +               reg = <0 0x40000000 0 0x10000000>;      /* ECAM config space */
> +               bus-range = <0 255>;
> +               linux,pci-domain = <0>;
> +               #address-cells = <3>;
> +               #size-cells = <2>;
> +               dma-coherent;
> +               ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
> +                         0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
> +                         0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> +               #interrupt-cells = <1>;
> +               interrupt-map-mask = <0 0 0 7>;
> +               interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
> +                                0 0 0 2 &gic 0 0 0 137 4
> +                                0 0 0 3 &gic 0 0 0 138 4
> +                                0 0 0 4 &gic 0 0 0 139 4>;
> +               msi-parent = <&v2m_0>;
> +       };
>  };
>
>  &memtimer {
> --
> 2.6.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > Juno R1 board sports a functional PCIe host bridge that is
> > compliant with the SBSA standard found here[1]. With the right
> > firmware that initialises the XpressRICH3 controller one can
> > use the generic Host Bridge driver to use the PCIe hardware.
> >
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >
> > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > ---
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > index c627511..a702a6b 100644
> > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -109,6 +109,26 @@
> >
> >         #include "juno-base.dtsi"
> >
> > +       pcie-controller@40000000 {
> > +               compatible = "pci-host-ecam-generic";
> 
> I think this is the first case of real h/w using this. We should have
> a specific compatible here additionally.

Or maybe I can claim the use of the string on account on being the first on arm64 ;)

I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
*because* it is trying to be a generic driver.

>  Perhaps the firmware did not setup something correctly.

Hope not :) I no longer have that much input into the UEFI firmware, but for U-Boot is
is all in the open and can be fixed at any time (?).

Thanks for reviewing this!

Best regards,
Liviu

> 
> > +               device_type = "pci";
> > +               reg = <0 0x40000000 0 0x10000000>;      /* ECAM config space */
> > +               bus-range = <0 255>;
> > +               linux,pci-domain = <0>;
> > +               #address-cells = <3>;
> > +               #size-cells = <2>;
> > +               dma-coherent;
> > +               ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
> > +                         0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
> > +                         0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> > +               #interrupt-cells = <1>;
> > +               interrupt-map-mask = <0 0 0 7>;
> > +               interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
> > +                                0 0 0 2 &gic 0 0 0 137 4
> > +                                0 0 0 3 &gic 0 0 0 138 4
> > +                                0 0 0 4 &gic 0 0 0 139 4>;
> > +               msi-parent = <&v2m_0>;
> > +       };
> >  };
> >
> >  &memtimer {
> > --
> > 2.6.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > Juno R1 board sports a functional PCIe host bridge that is
> > compliant with the SBSA standard found here[1]. With the right
> > firmware that initialises the XpressRICH3 controller one can
> > use the generic Host Bridge driver to use the PCIe hardware.
> >
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >
> > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > ---
> >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > index c627511..a702a6b 100644
> > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > @@ -109,6 +109,26 @@
> >
> >         #include "juno-base.dtsi"
> >
> > +       pcie-controller at 40000000 {
> > +               compatible = "pci-host-ecam-generic";
> 
> I think this is the first case of real h/w using this. We should have
> a specific compatible here additionally.

Or maybe I can claim the use of the string on account on being the first on arm64 ;)

I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
*because* it is trying to be a generic driver.

>  Perhaps the firmware did not setup something correctly.

Hope not :) I no longer have that much input into the UEFI firmware, but for U-Boot is
is all in the open and can be fixed at any time (?).

Thanks for reviewing this!

Best regards,
Liviu

> 
> > +               device_type = "pci";
> > +               reg = <0 0x40000000 0 0x10000000>;      /* ECAM config space */
> > +               bus-range = <0 255>;
> > +               linux,pci-domain = <0>;
> > +               #address-cells = <3>;
> > +               #size-cells = <2>;
> > +               dma-coherent;
> > +               ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000
> > +                         0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000
> > +                         0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
> > +               #interrupt-cells = <1>;
> > +               interrupt-map-mask = <0 0 0 7>;
> > +               interrupt-map = <0 0 0 1 &gic 0 0 0 136 4
> > +                                0 0 0 2 &gic 0 0 0 137 4
> > +                                0 0 0 3 &gic 0 0 0 138 4
> > +                                0 0 0 4 &gic 0 0 0 139 4>;
> > +               msi-parent = <&v2m_0>;
> > +       };
> >  };
> >
> >  &memtimer {
> > --
> > 2.6.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Will Deacon]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > >         #include "juno-base.dtsi"
> > >
> > > +       pcie-controller@40000000 {
> > > +               compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first
> on arm64 ;)

This is already being used on arm64 with kvmtool, qemu, the ARM fastmodel
and AMD Seattle.

Will

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Will Deacon]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > >         #include "juno-base.dtsi"
> > >
> > > +       pcie-controller@40000000 {
> > > +               compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first
> on arm64 ;)

This is already being used on arm64 with kvmtool, qemu, the ARM fastmodel
and AMD Seattle.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Will Deacon]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > >         #include "juno-base.dtsi"
> > >
> > > +       pcie-controller at 40000000 {
> > > +               compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first
> on arm64 ;)

This is already being used on arm64 with kvmtool, qemu, the ARM fastmodel
and AMD Seattle.

Will

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > >         #include "juno-base.dtsi"
> > >
> > > +       pcie-controller@40000000 {
> > > +               compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first on arm64 ;)
> 
> I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> *because* it is trying to be a generic driver.

The point here is to have the string ready if we need it later, so it's
fine that it's not used currently.

Rob's suggestion is that the compatible list should look something like:

compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";

We can match on "pci-host-ecam-generic" for now (and hopefully forever),
but if for some reason we need to special-case this host controller (or
Juno's integration thereof), we can do that based on the compatible
string.

Thanks,
Mark.

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > On Fri, Oct 9, 2015 at 8:45 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > > Juno R1 board sports a functional PCIe host bridge that is
> > > compliant with the SBSA standard found here[1]. With the right
> > > firmware that initialises the XpressRICH3 controller one can
> > > use the generic Host Bridge driver to use the PCIe hardware.
> > >
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > >
> > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
> > > ---
> > >  arch/arm64/boot/dts/arm/juno-r1.dts | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > index c627511..a702a6b 100644
> > > --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> > > @@ -109,6 +109,26 @@
> > >
> > >         #include "juno-base.dtsi"
> > >
> > > +       pcie-controller at 40000000 {
> > > +               compatible = "pci-host-ecam-generic";
> > 
> > I think this is the first case of real h/w using this. We should have
> > a specific compatible here additionally.
> 
> Or maybe I can claim the use of the string on account on being the first on arm64 ;)
> 
> I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> *because* it is trying to be a generic driver.

The point here is to have the string ready if we need it later, so it's
fine that it's not used currently.

Rob's suggestion is that the compatible list should look something like:

compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";

We can match on "pci-host-ecam-generic" for now (and hopefully forever),
but if for some reason we need to special-case this host controller (or
Juno's integration thereof), we can do that based on the compatible
string.

Thanks,
Mark.

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Arnd Bergmann]

On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > Or maybe I can claim the use of the string on account on being the first on arm64 
> > 
> > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > *because* it is trying to be a generic driver.
> 
> The point here is to have the string ready if we need it later, so it's
> fine that it's not used currently.
> 
> Rob's suggestion is that the compatible list should look something like:
> 
> compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> 
> We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> but if for some reason we need to special-case this host controller (or
> Juno's integration thereof), we can do that based on the compatible
> string.

Sounds good to me, it certainly can't hurt.

	Arnd

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Arnd Bergmann]

On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > Or maybe I can claim the use of the string on account on being the first on arm64 
> > 
> > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > *because* it is trying to be a generic driver.
> 
> The point here is to have the string ready if we need it later, so it's
> fine that it's not used currently.
> 
> Rob's suggestion is that the compatible list should look something like:
> 
> compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> 
> We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> but if for some reason we need to special-case this host controller (or
> Juno's integration thereof), we can do that based on the compatible
> string.

Sounds good to me, it certainly can't hurt.

	Arnd

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > 
> > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > *because* it is trying to be a generic driver.
> > 
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> > 
> > Rob's suggestion is that the compatible list should look something like:
> > 
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > 
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
> 
> Sounds good to me, it certainly can't hurt.
> 
> 	Arnd

Hmm, I'm sorry, but this time I'm going to disagree.

I understand the principle that the DTS is a description of the hardware and it should
not have any built in knowledge of how a driver works but describe the physical properties
of the device (where such description makes sense, in this case it does).

However, when ARM has created the Juno platform it has also created a standard called
SBSA and has claimed that Juno is compliant with that standard. My current position (and
it used to be MarkR's as well when we have argued internally the pros and cons of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.

Otherwise, I could've posted months ago the other public driver[1] that I've wrote that
doesn't depend on firmware and could have been done with this long time ago.

Best regards,
Liviu

1. https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c


> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > 
> > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > *because* it is trying to be a generic driver.
> > 
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> > 
> > Rob's suggestion is that the compatible list should look something like:
> > 
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > 
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
> 
> Sounds good to me, it certainly can't hurt.
> 
> 	Arnd

Hmm, I'm sorry, but this time I'm going to disagree.

I understand the principle that the DTS is a description of the hardware and it should
not have any built in knowledge of how a driver works but describe the physical properties
of the device (where such description makes sense, in this case it does).

However, when ARM has created the Juno platform it has also created a standard called
SBSA and has claimed that Juno is compliant with that standard. My current position (and
it used to be MarkR's as well when we have argued internally the pros and cons of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.

Otherwise, I could've posted months ago the other public driver[1] that I've wrote that
doesn't depend on firmware and could have been done with this long time ago.

Best regards,
Liviu

1. https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c


> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > 
> > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > *because* it is trying to be a generic driver.
> > 
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> > 
> > Rob's suggestion is that the compatible list should look something like:
> > 
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > 
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
> 
> Sounds good to me, it certainly can't hurt.
> 
> 	Arnd

Hmm, I'm sorry, but this time I'm going to disagree.

I understand the principle that the DTS is a description of the hardware and it should
not have any built in knowledge of how a driver works but describe the physical properties
of the device (where such description makes sense, in this case it does).

However, when ARM has created the Juno platform it has also created a standard called
SBSA and has claimed that Juno is compliant with that standard. My current position (and
it used to be MarkR's as well when we have argued internally the pros and cons of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.

Otherwise, I could've posted months ago the other public driver[1] that I've wrote that
doesn't depend on firmware and could have been done with this long time ago.

Best regards,
Liviu

1. https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c


> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > > 
> > > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > > *because* it is trying to be a generic driver.
> > > 
> > > The point here is to have the string ready if we need it later, so it's
> > > fine that it's not used currently.
> > > 
> > > Rob's suggestion is that the compatible list should look something like:
> > > 
> > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > > 
> > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > but if for some reason we need to special-case this host controller (or
> > > Juno's integration thereof), we can do that based on the compatible
> > > string.
> > 
> > Sounds good to me, it certainly can't hurt.
> > 
> > 	Arnd
> 
> Hmm, I'm sorry, but this time I'm going to disagree.
> 
> I understand the principle that the DTS is a description of the
> hardware and it should not have any built in knowledge of how a driver
> works but describe the physical properties of the device (where such
> description makes sense, in this case it does).
> 
> However, when ARM has created the Juno platform it has also created a
> standard called SBSA and has claimed that Juno is compliant with that
> standard. My current position (and it used to be MarkR's as well when
> we have argued internally the pros and cons of having a bespoke driver
> for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> expected behaviour and if the device doesn't conform it needs to be
> fixed in firmware.

We are not arguing for a bespoke driver, and in fact we hope to never
have to use the addition strings.

However, experience shows that we might not be lucky, and if we
encounter some bizarre quirk in future we might need to handle that by
knowing what the hardware is.

> Otherwise, I could've posted months ago the other public driver[1]
> that I've wrote that doesn't depend on firmware and could have been
> done with this long time ago.

We're not arguing for kernel support code. What we're arguing for is
data in the DTB that ideally turns out to be irrelevant.

I can't see why you object to that.

Mark.

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Mark Rutland]

On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > > 
> > > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > > *because* it is trying to be a generic driver.
> > > 
> > > The point here is to have the string ready if we need it later, so it's
> > > fine that it's not used currently.
> > > 
> > > Rob's suggestion is that the compatible list should look something like:
> > > 
> > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > > 
> > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > but if for some reason we need to special-case this host controller (or
> > > Juno's integration thereof), we can do that based on the compatible
> > > string.
> > 
> > Sounds good to me, it certainly can't hurt.
> > 
> > 	Arnd
> 
> Hmm, I'm sorry, but this time I'm going to disagree.
> 
> I understand the principle that the DTS is a description of the
> hardware and it should not have any built in knowledge of how a driver
> works but describe the physical properties of the device (where such
> description makes sense, in this case it does).
> 
> However, when ARM has created the Juno platform it has also created a
> standard called SBSA and has claimed that Juno is compliant with that
> standard. My current position (and it used to be MarkR's as well when
> we have argued internally the pros and cons of having a bespoke driver
> for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> expected behaviour and if the device doesn't conform it needs to be
> fixed in firmware.

We are not arguing for a bespoke driver, and in fact we hope to never
have to use the addition strings.

However, experience shows that we might not be lucky, and if we
encounter some bizarre quirk in future we might need to handle that by
knowing what the hardware is.

> Otherwise, I could've posted months ago the other public driver[1]
> that I've wrote that doesn't depend on firmware and could have been
> done with this long time ago.

We're not arguing for kernel support code. What we're arguing for is
data in the DTB that ideally turns out to be irrelevant.

I can't see why you object to that.

Mark.

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:32:52PM +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > > > 
> > > > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > > > *because* it is trying to be a generic driver.
> > > > 
> > > > The point here is to have the string ready if we need it later, so it's
> > > > fine that it's not used currently.
> > > > 
> > > > Rob's suggestion is that the compatible list should look something like:
> > > > 
> > > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > > > 
> > > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > > but if for some reason we need to special-case this host controller (or
> > > > Juno's integration thereof), we can do that based on the compatible
> > > > string.
> > > 
> > > Sounds good to me, it certainly can't hurt.
> > > 
> > > 	Arnd
> > 
> > Hmm, I'm sorry, but this time I'm going to disagree.
> > 
> > I understand the principle that the DTS is a description of the
> > hardware and it should not have any built in knowledge of how a driver
> > works but describe the physical properties of the device (where such
> > description makes sense, in this case it does).
> > 
> > However, when ARM has created the Juno platform it has also created a
> > standard called SBSA and has claimed that Juno is compliant with that
> > standard. My current position (and it used to be MarkR's as well when
> > we have argued internally the pros and cons of having a bespoke driver
> > for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> > expected behaviour and if the device doesn't conform it needs to be
> > fixed in firmware.
> 
> We are not arguing for a bespoke driver, and in fact we hope to never
> have to use the addition strings.
> 
> However, experience shows that we might not be lucky, and if we
> encounter some bizarre quirk in future we might need to handle that by
> knowing what the hardware is.
> 
> > Otherwise, I could've posted months ago the other public driver[1]
> > that I've wrote that doesn't depend on firmware and could have been
> > done with this long time ago.
> 
> We're not arguing for kernel support code. What we're arguing for is
> data in the DTB that ideally turns out to be irrelevant.
> 
> I can't see why you object to that.

It is not a strong objection but I don't want to ever have to add bespoke
code to the pci-host-generic.c driver so adding a compatible property that
is going to be ignored is kind of pointless. Yes, one will have a better
idea on what the hardware actually is, but so what?

I will send a v2 with the added values.

Best regards,
Liviu

> 
> Mark.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:32:52PM +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > > > 
> > > > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > > > *because* it is trying to be a generic driver.
> > > > 
> > > > The point here is to have the string ready if we need it later, so it's
> > > > fine that it's not used currently.
> > > > 
> > > > Rob's suggestion is that the compatible list should look something like:
> > > > 
> > > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > > > 
> > > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > > but if for some reason we need to special-case this host controller (or
> > > > Juno's integration thereof), we can do that based on the compatible
> > > > string.
> > > 
> > > Sounds good to me, it certainly can't hurt.
> > > 
> > > 	Arnd
> > 
> > Hmm, I'm sorry, but this time I'm going to disagree.
> > 
> > I understand the principle that the DTS is a description of the
> > hardware and it should not have any built in knowledge of how a driver
> > works but describe the physical properties of the device (where such
> > description makes sense, in this case it does).
> > 
> > However, when ARM has created the Juno platform it has also created a
> > standard called SBSA and has claimed that Juno is compliant with that
> > standard. My current position (and it used to be MarkR's as well when
> > we have argued internally the pros and cons of having a bespoke driver
> > for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> > expected behaviour and if the device doesn't conform it needs to be
> > fixed in firmware.
> 
> We are not arguing for a bespoke driver, and in fact we hope to never
> have to use the addition strings.
> 
> However, experience shows that we might not be lucky, and if we
> encounter some bizarre quirk in future we might need to handle that by
> knowing what the hardware is.
> 
> > Otherwise, I could've posted months ago the other public driver[1]
> > that I've wrote that doesn't depend on firmware and could have been
> > done with this long time ago.
> 
> We're not arguing for kernel support code. What we're arguing for is
> data in the DTB that ideally turns out to be irrelevant.
> 
> I can't see why you object to that.

It is not a strong objection but I don't want to ever have to add bespoke
code to the pci-host-generic.c driver so adding a compatible property that
is going to be ignored is kind of pointless. Yes, one will have a better
idea on what the hardware actually is, but so what?

I will send a v2 with the added values.

Best regards,
Liviu

> 
> Mark.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

[Liviu Dudau]

On Fri, Oct 09, 2015 at 05:32:52PM +0100, Mark Rutland wrote:
> On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote:
> > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > > > Or maybe I can claim the use of the string on account on being the first on arm64 
> > > > > 
> > > > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it 
> > > > > *because* it is trying to be a generic driver.
> > > > 
> > > > The point here is to have the string ready if we need it later, so it's
> > > > fine that it's not used currently.
> > > > 
> > > > Rob's suggestion is that the compatible list should look something like:
> > > > 
> > > > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> > > > 
> > > > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > > > but if for some reason we need to special-case this host controller (or
> > > > Juno's integration thereof), we can do that based on the compatible
> > > > string.
> > > 
> > > Sounds good to me, it certainly can't hurt.
> > > 
> > > 	Arnd
> > 
> > Hmm, I'm sorry, but this time I'm going to disagree.
> > 
> > I understand the principle that the DTS is a description of the
> > hardware and it should not have any built in knowledge of how a driver
> > works but describe the physical properties of the device (where such
> > description makes sense, in this case it does).
> > 
> > However, when ARM has created the Juno platform it has also created a
> > standard called SBSA and has claimed that Juno is compliant with that
> > standard. My current position (and it used to be MarkR's as well when
> > we have argued internally the pros and cons of having a bespoke driver
> > for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the
> > expected behaviour and if the device doesn't conform it needs to be
> > fixed in firmware.
> 
> We are not arguing for a bespoke driver, and in fact we hope to never
> have to use the addition strings.
> 
> However, experience shows that we might not be lucky, and if we
> encounter some bizarre quirk in future we might need to handle that by
> knowing what the hardware is.
> 
> > Otherwise, I could've posted months ago the other public driver[1]
> > that I've wrote that doesn't depend on firmware and could have been
> > done with this long time ago.
> 
> We're not arguing for kernel support code. What we're arguing for is
> data in the DTB that ideally turns out to be irrelevant.
> 
> I can't see why you object to that.

It is not a strong objection but I don't want to ever have to add bespoke
code to the pci-host-generic.c driver so adding a compatible property that
is going to be ignored is kind of pointless. Yes, one will have a better
idea on what the hardware actually is, but so what?

I will send a v2 with the added values.

Best regards,
Liviu

> 
> Mark.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?