| Message ID | 1444398323-17354-4-git-send-email-Liviu.Dudau@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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 >
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
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.
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
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 >
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.
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 --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 {
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(+)