diff mbox

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

Message ID 1444398323-17354-4-git-send-email-Liviu.Dudau@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Liviu Dudau Oct. 9, 2015, 1:45 p.m. UTC
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(+)

Comments

Rob Herring (Arm) Oct. 9, 2015, 1:54 p.m. UTC | #1
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
Liviu Dudau Oct. 9, 2015, 2:11 p.m. UTC | #2
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
>
Will Deacon Oct. 9, 2015, 2:18 p.m. UTC | #3
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
Mark Rutland Oct. 9, 2015, 3:44 p.m. UTC | #4
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.
Arnd Bergmann Oct. 9, 2015, 3:49 p.m. UTC | #5
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
Liviu Dudau Oct. 9, 2015, 4:09 p.m. UTC | #6
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
>
Mark Rutland Oct. 9, 2015, 4:32 p.m. UTC | #7
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.
Liviu Dudau Oct. 9, 2015, 4:41 p.m. UTC | #8
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.
>
diff mbox

Patch

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 {