Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 6:43 PM, Olof Johansson wrote: > On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit > wrote: >> Hi Olof, >> >> On 1/28/2016 3:39 PM, Olof Johansson wrote: >>> >>> Hi Suravee, >>> >>> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit >>> wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. >>> >>> >>> My Overdrive comes with DT provided by firmware, so there's no need to >>> have a in-kernel-tree DT source. >> >> >> You are correct that the FW comes with DT, and in typical case, you wouldn't >> need this. >> >>> Are you aware of other reasons to have it here? I just foresee >>> divergence and conflicts between the two. It was quite obvious before >>> this update when the FW-provided DT was a lot more complete than what >>> we had in the kernel tree. >> >> >> However, there are still new/updated drivers being developed, and sometimes >> requires new/changes in DT binding. So, the DT that comes with the FW can >> get out of date, and will lack the support for new drivers. > > Note that it's expected that the driver will cope with the old DT > contents, i.e. it needs to go with defaults that made sense before the > binding was updated. > > It, however, doesn't have to enable new features. In other words, > booting with an old DT needs to continue working. You can't require a > user to update DT to avoid getting driver breakage. > > (The opposite is not enforced: Booting with a DT that is newer than > the kernel isn't guaranteed to always work). > >> Certain version of the FW allows overriding the DT that comes with the FW. >> So, we are providing the in-kernel DT to allow developers to provide the >> updated device tree for newer kernels. This patch series is bringing the >> in-kernel DT closer to what the latest FW is providing to avoid potential >> conflicts. > > I do appreciate keeping the kernel one up to date with what firmware > provides if it's truly needed, but I'd even more prefer that it > wasn't. After all, it's how the ACPI-based booting works (no > overriding table provided with the kernel), so it's a model you should > already be somewhat familiar with. :) > > I'm not doing a hard NAK on this, but I would like to get a bit more > understanding of why it's considered needed. > > > -Olof I would strongly encourage the inclusion of the dts file in the kernel source tree, even if the dtb is delivered with the firmware for several reasons. The dts provides a reference for other developers who are supporting new boards that are similar. The dts might be reviewed. We hope to have tools that will validate the dts against the documented bindings. (Yes, this effort has stalled, but I am optimistic that it is not dead.) If someone has the board (any board, not just this one) that the kernel does not boot on, then it might not be possible to retrieve the dtb from the board (which can then be de-compiled to a dts) for the purpose of debugging or properly configuring the kernel. (The boot loader may provide the ability to get the dtb or it might not.) -Frank
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 8:43 PM, Olof Johansson wrote: On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit wrote: Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. You are correct that the FW comes with DT, and in typical case, you wouldn't need this. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. However, there are still new/updated drivers being developed, and sometimes requires new/changes in DT binding. So, the DT that comes with the FW can get out of date, and will lack the support for new drivers. Note that it's expected that the driver will cope with the old DT contents, i.e. it needs to go with defaults that made sense before the binding was updated. It, however, doesn't have to enable new features. In other words, booting with an old DT needs to continue working. You can't require a user to update DT to avoid getting driver breakage. (The opposite is not enforced: Booting with a DT that is newer than the kernel isn't guaranteed to always work). Ok. I understand your point that driver will not break the existing DT. :) Certain version of the FW allows overriding the DT that comes with the FW. So, we are providing the in-kernel DT to allow developers to provide the updated device tree for newer kernels. This patch series is bringing the in-kernel DT closer to what the latest FW is providing to avoid potential conflicts. I do appreciate keeping the kernel one up to date with what firmware provides if it's truly needed, but I'd even more prefer that it wasn't. After all, it's how the ACPI-based booting works (no overriding table provided with the kernel), so it's a model you should already be somewhat familiar with. :) Agree. This is true in the x86 world where things are mostly stable. However, in the ARM64 cases, there are still newer supports being added. Often that I have been asked by folks to provide a base DT that they can extend (e.g. to add support for platform device pass-through, PCI pass-through, SBSA GWDT, etc). Eventually, this in-kernel DT would not be needed as the more stable DT would have already been in the later version of the FW. But in the meantime, it seems useful to have this in one accessible place. Thanks, Suravee I'm not doing a hard NAK on this, but I would like to get a bit more understanding of why it's considered needed. -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 6:43 PM, Olof Johansson wrote: > On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit >wrote: >> Hi Olof, >> >> On 1/28/2016 3:39 PM, Olof Johansson wrote: >>> >>> Hi Suravee, >>> >>> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit >>> wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. >>> >>> >>> My Overdrive comes with DT provided by firmware, so there's no need to >>> have a in-kernel-tree DT source. >> >> >> You are correct that the FW comes with DT, and in typical case, you wouldn't >> need this. >> >>> Are you aware of other reasons to have it here? I just foresee >>> divergence and conflicts between the two. It was quite obvious before >>> this update when the FW-provided DT was a lot more complete than what >>> we had in the kernel tree. >> >> >> However, there are still new/updated drivers being developed, and sometimes >> requires new/changes in DT binding. So, the DT that comes with the FW can >> get out of date, and will lack the support for new drivers. > > Note that it's expected that the driver will cope with the old DT > contents, i.e. it needs to go with defaults that made sense before the > binding was updated. > > It, however, doesn't have to enable new features. In other words, > booting with an old DT needs to continue working. You can't require a > user to update DT to avoid getting driver breakage. > > (The opposite is not enforced: Booting with a DT that is newer than > the kernel isn't guaranteed to always work). > >> Certain version of the FW allows overriding the DT that comes with the FW. >> So, we are providing the in-kernel DT to allow developers to provide the >> updated device tree for newer kernels. This patch series is bringing the >> in-kernel DT closer to what the latest FW is providing to avoid potential >> conflicts. > > I do appreciate keeping the kernel one up to date with what firmware > provides if it's truly needed, but I'd even more prefer that it > wasn't. After all, it's how the ACPI-based booting works (no > overriding table provided with the kernel), so it's a model you should > already be somewhat familiar with. :) > > I'm not doing a hard NAK on this, but I would like to get a bit more > understanding of why it's considered needed. > > > -Olof I would strongly encourage the inclusion of the dts file in the kernel source tree, even if the dtb is delivered with the firmware for several reasons. The dts provides a reference for other developers who are supporting new boards that are similar. The dts might be reviewed. We hope to have tools that will validate the dts against the documented bindings. (Yes, this effort has stalled, but I am optimistic that it is not dead.) If someone has the board (any board, not just this one) that the kernel does not boot on, then it might not be possible to retrieve the dtb from the board (which can then be de-compiled to a dts) for the purpose of debugging or properly configuring the kernel. (The boot loader may provide the ability to get the dtb or it might not.) -Frank
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On 1/28/2016 8:43 PM, Olof Johansson wrote: On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanitwrote: Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. You are correct that the FW comes with DT, and in typical case, you wouldn't need this. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. However, there are still new/updated drivers being developed, and sometimes requires new/changes in DT binding. So, the DT that comes with the FW can get out of date, and will lack the support for new drivers. Note that it's expected that the driver will cope with the old DT contents, i.e. it needs to go with defaults that made sense before the binding was updated. It, however, doesn't have to enable new features. In other words, booting with an old DT needs to continue working. You can't require a user to update DT to avoid getting driver breakage. (The opposite is not enforced: Booting with a DT that is newer than the kernel isn't guaranteed to always work). Ok. I understand your point that driver will not break the existing DT. :) Certain version of the FW allows overriding the DT that comes with the FW. So, we are providing the in-kernel DT to allow developers to provide the updated device tree for newer kernels. This patch series is bringing the in-kernel DT closer to what the latest FW is providing to avoid potential conflicts. I do appreciate keeping the kernel one up to date with what firmware provides if it's truly needed, but I'd even more prefer that it wasn't. After all, it's how the ACPI-based booting works (no overriding table provided with the kernel), so it's a model you should already be somewhat familiar with. :) Agree. This is true in the x86 world where things are mostly stable. However, in the ARM64 cases, there are still newer supports being added. Often that I have been asked by folks to provide a base DT that they can extend (e.g. to add support for platform device pass-through, PCI pass-through, SBSA GWDT, etc). Eventually, this in-kernel DT would not be needed as the more stable DT would have already been in the later version of the FW. But in the meantime, it seems useful to have this in one accessible place. Thanks, Suravee I'm not doing a hard NAK on this, but I would like to get a bit more understanding of why it's considered needed. -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanit wrote: > Hi Olof, > > On 1/28/2016 3:39 PM, Olof Johansson wrote: >> >> Hi Suravee, >> >> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit >> wrote: >>> >>> From: Suravee Suthikulpanit >>> >>> This patch series contains several updates for the AMD Seattle SOC DTS >>> files. >>> It also adds new board files for newer Overdrive and Linaro 96boards >>> (Husky) >>> platforms. >> >> >> My Overdrive comes with DT provided by firmware, so there's no need to >> have a in-kernel-tree DT source. > > > You are correct that the FW comes with DT, and in typical case, you wouldn't > need this. > >> Are you aware of other reasons to have it here? I just foresee >> divergence and conflicts between the two. It was quite obvious before >> this update when the FW-provided DT was a lot more complete than what >> we had in the kernel tree. > > > However, there are still new/updated drivers being developed, and sometimes > requires new/changes in DT binding. So, the DT that comes with the FW can > get out of date, and will lack the support for new drivers. Note that it's expected that the driver will cope with the old DT contents, i.e. it needs to go with defaults that made sense before the binding was updated. It, however, doesn't have to enable new features. In other words, booting with an old DT needs to continue working. You can't require a user to update DT to avoid getting driver breakage. (The opposite is not enforced: Booting with a DT that is newer than the kernel isn't guaranteed to always work). > Certain version of the FW allows overriding the DT that comes with the FW. > So, we are providing the in-kernel DT to allow developers to provide the > updated device tree for newer kernels. This patch series is bringing the > in-kernel DT closer to what the latest FW is providing to avoid potential > conflicts. I do appreciate keeping the kernel one up to date with what firmware provides if it's truly needed, but I'd even more prefer that it wasn't. After all, it's how the ACPI-based booting works (no overriding table provided with the kernel), so it's a model you should already be somewhat familiar with. :) I'm not doing a hard NAK on this, but I would like to get a bit more understanding of why it's considered needed. -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. You are correct that the FW comes with DT, and in typical case, you wouldn't need this. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. However, there are still new/updated drivers being developed, and sometimes requires new/changes in DT binding. So, the DT that comes with the FW can get out of date, and will lack the support for new drivers. Certain version of the FW allows overriding the DT that comes with the FW. So, we are providing the in-kernel DT to allow developers to provide the updated device tree for newer kernels. This patch series is bringing the in-kernel DT closer to what the latest FW is providing to avoid potential conflicts. Regards, Suravee -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit > > This patch series contains several updates for the AMD Seattle SOC DTS files. > It also adds new board files for newer Overdrive and Linaro 96boards (Husky) > platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
Hi Olof, On 1/28/2016 3:39 PM, Olof Johansson wrote: Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanitwrote: From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. You are correct that the FW comes with DT, and in typical case, you wouldn't need this. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. However, there are still new/updated drivers being developed, and sometimes requires new/changes in DT binding. So, the DT that comes with the FW can get out of date, and will lack the support for new drivers. Certain version of the FW allows overriding the DT that comes with the FW. So, we are providing the in-kernel DT to allow developers to provide the updated device tree for newer kernels. This patch series is bringing the in-kernel DT closer to what the latest FW is providing to avoid potential conflicts. Regards, Suravee -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
Hi Suravee, On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanitwrote: > From: Suravee Suthikulpanit > > This patch series contains several updates for the AMD Seattle SOC DTS files. > It also adds new board files for newer Overdrive and Linaro 96boards (Husky) > platforms. My Overdrive comes with DT provided by firmware, so there's no need to have a in-kernel-tree DT source. Are you aware of other reasons to have it here? I just foresee divergence and conflicts between the two. It was quite obvious before this update when the FW-provided DT was a lot more complete than what we had in the kernel tree. -Olof
Re: [PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
On Thu, Jan 28, 2016 at 2:20 PM, Suravee Suthikulanitwrote: > Hi Olof, > > On 1/28/2016 3:39 PM, Olof Johansson wrote: >> >> Hi Suravee, >> >> On Wed, Jan 27, 2016 at 1:11 PM, Suravee Suthikulpanit >> wrote: >>> >>> From: Suravee Suthikulpanit >>> >>> This patch series contains several updates for the AMD Seattle SOC DTS >>> files. >>> It also adds new board files for newer Overdrive and Linaro 96boards >>> (Husky) >>> platforms. >> >> >> My Overdrive comes with DT provided by firmware, so there's no need to >> have a in-kernel-tree DT source. > > > You are correct that the FW comes with DT, and in typical case, you wouldn't > need this. > >> Are you aware of other reasons to have it here? I just foresee >> divergence and conflicts between the two. It was quite obvious before >> this update when the FW-provided DT was a lot more complete than what >> we had in the kernel tree. > > > However, there are still new/updated drivers being developed, and sometimes > requires new/changes in DT binding. So, the DT that comes with the FW can > get out of date, and will lack the support for new drivers. Note that it's expected that the driver will cope with the old DT contents, i.e. it needs to go with defaults that made sense before the binding was updated. It, however, doesn't have to enable new features. In other words, booting with an old DT needs to continue working. You can't require a user to update DT to avoid getting driver breakage. (The opposite is not enforced: Booting with a DT that is newer than the kernel isn't guaranteed to always work). > Certain version of the FW allows overriding the DT that comes with the FW. > So, we are providing the in-kernel DT to allow developers to provide the > updated device tree for newer kernels. This patch series is bringing the > in-kernel DT closer to what the latest FW is providing to avoid potential > conflicts. I do appreciate keeping the kernel one up to date with what firmware provides if it's truly needed, but I'd even more prefer that it wasn't. After all, it's how the ACPI-based booting works (no overriding table provided with the kernel), so it's a model you should already be somewhat familiar with. :) I'm not doing a hard NAK on this, but I would like to get a bit more understanding of why it's considered needed. -Olof
[PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
From: Suravee Suthikulpanit This patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. Thanks, Suravee Brijesh Singh (2): dtb: amd: Fix GICv2 hypervisor and virtual interface sizes dtb: amd: Add KCS device tree node Suravee Suthikulpanit (10): MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree dtb: amd: Fix DMA ranges in device tree dtb: amd: Fix typo in SPI device nodes dtb: amd: Misc changes for I2C device nodes dtb: amd: Misc changes for SATA device tree nodes dtb: amd: Misc changes for GPIO devices dtb: amd: Add PERF CCN-504 device tree node dtb: amd: Add PCIe SMMU device tree node dtb: amd: Add support for new AMD Overdrive boards dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board Tom Lendacky (1): dtb: amd: Add AMD XGBE device tree file MAINTAINERS | 9 ++ arch/arm64/boot/dts/amd/Makefile | 4 +- arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts | 87 +++ arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts | 91 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 128 --- arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi | 117 + arch/arm64/boot/dts/amd/husky.dts| 83 +++ 7 files changed, 505 insertions(+), 14 deletions(-) create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi create mode 100644 arch/arm64/boot/dts/amd/husky.dts -- 2.5.0
[PATCH 00/13] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
From: Suravee SuthikulpanitThis patch series contains several updates for the AMD Seattle SOC DTS files. It also adds new board files for newer Overdrive and Linaro 96boards (Husky) platforms. Thanks, Suravee Brijesh Singh (2): dtb: amd: Fix GICv2 hypervisor and virtual interface sizes dtb: amd: Add KCS device tree node Suravee Suthikulpanit (10): MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree dtb: amd: Fix DMA ranges in device tree dtb: amd: Fix typo in SPI device nodes dtb: amd: Misc changes for I2C device nodes dtb: amd: Misc changes for SATA device tree nodes dtb: amd: Misc changes for GPIO devices dtb: amd: Add PERF CCN-504 device tree node dtb: amd: Add PCIe SMMU device tree node dtb: amd: Add support for new AMD Overdrive boards dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition Server board Tom Lendacky (1): dtb: amd: Add AMD XGBE device tree file MAINTAINERS | 9 ++ arch/arm64/boot/dts/amd/Makefile | 4 +- arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts | 87 +++ arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts | 91 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 128 --- arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi | 117 + arch/arm64/boot/dts/amd/husky.dts| 83 +++ 7 files changed, 505 insertions(+), 14 deletions(-) create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi create mode 100644 arch/arm64/boot/dts/amd/husky.dts -- 2.5.0