Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi, On Tuesday 28 August 2018 06:52 AM, Nishanth Menon wrote: > On 15:55-20180827, Tony Lindgren wrote: >> * Kishon Vijay Abraham I [180827 03:06]: >>> Hi Tony, >>> >>> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I [180808 06:35]: > On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >> Really need 64-bit addresses and sizes? Use ranges to limit the >> address space if possible. > > We now have address-cells as <1>, > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > However each PCIe instance has 2 data regions and one of the regions > (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > specified > in the "MAIN Domain Memory Map" table of TRM > http://www.ti.com/lit/pdf/spruid7) > is above the 32bit region and requires 2 cells to specify the start > address. > This region is used to access MEM_SPACE of PCIe endpoint when operating > in root > complex mode and access memory of PCI root complex when operating in > endpoint mode. > > In order to describe this, should we change the address-cells back to <2> > or do > you suggest any other alternatives? It's probably best to have the top level cbass interconnect use #size-cells = <2> and then have it's child interconnects have #size-cells = <1> if they don't need ranges above 4GB. >>> >>> PCIe has a region starting at 0x40_ and size 4GB. We need 2 address >>> cells and 2 size cells to describe this no? >> >> Yes. >> BTW, what's the difference between all these three similar PCIE ranges? PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB >>> >>> This is the register space for the two instances of PCIe controller. PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB >>> >>> The above are regions which can be used by CPU/DMA to access the PCIe >>> address >>> space. The mapping from the above regions to the PCIe address space will be >>> programmed in the PCIe controller. >> >> OK so not just somethng for dma-ranges but also accessible by >> the CPU. >> > > Kishon, Sekhar: > > Can you guys post patches based on v4.19-rc1 for fixing this? I do have > a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the > changes. Sure, I'll post that today. Thanks Kishon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi, On Tuesday 28 August 2018 06:52 AM, Nishanth Menon wrote: > On 15:55-20180827, Tony Lindgren wrote: >> * Kishon Vijay Abraham I [180827 03:06]: >>> Hi Tony, >>> >>> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I [180808 06:35]: > On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >> Really need 64-bit addresses and sizes? Use ranges to limit the >> address space if possible. > > We now have address-cells as <1>, > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > However each PCIe instance has 2 data regions and one of the regions > (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > specified > in the "MAIN Domain Memory Map" table of TRM > http://www.ti.com/lit/pdf/spruid7) > is above the 32bit region and requires 2 cells to specify the start > address. > This region is used to access MEM_SPACE of PCIe endpoint when operating > in root > complex mode and access memory of PCI root complex when operating in > endpoint mode. > > In order to describe this, should we change the address-cells back to <2> > or do > you suggest any other alternatives? It's probably best to have the top level cbass interconnect use #size-cells = <2> and then have it's child interconnects have #size-cells = <1> if they don't need ranges above 4GB. >>> >>> PCIe has a region starting at 0x40_ and size 4GB. We need 2 address >>> cells and 2 size cells to describe this no? >> >> Yes. >> BTW, what's the difference between all these three similar PCIE ranges? PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB >>> >>> This is the register space for the two instances of PCIe controller. PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB >>> >>> The above are regions which can be used by CPU/DMA to access the PCIe >>> address >>> space. The mapping from the above regions to the PCIe address space will be >>> programmed in the PCIe controller. >> >> OK so not just somethng for dma-ranges but also accessible by >> the CPU. >> > > Kishon, Sekhar: > > Can you guys post patches based on v4.19-rc1 for fixing this? I do have > a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the > changes. Sure, I'll post that today. Thanks Kishon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 15:55-20180827, Tony Lindgren wrote: > * Kishon Vijay Abraham I [180827 03:06]: > > Hi Tony, > > > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > > * Kishon Vijay Abraham I [180808 06:35]: > > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > > >>> address space if possible. > > >> > > >> We now have address-cells as <1>, > > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > >> > > >> However each PCIe instance has 2 data regions and one of the regions > > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > > >> specified > > >> in the "MAIN Domain Memory Map" table of TRM > > >> http://www.ti.com/lit/pdf/spruid7) > > >> is above the 32bit region and requires 2 cells to specify the start > > >> address. > > >> This region is used to access MEM_SPACE of PCIe endpoint when operating > > >> in root > > >> complex mode and access memory of PCI root complex when operating in > > >> endpoint mode. > > >> > > >> In order to describe this, should we change the address-cells back to > > >> <2> or do > > >> you suggest any other alternatives? > > > > > > It's probably best to have the top level cbass interconnect use > > > #size-cells = <2> and then have it's child interconnects have > > > #size-cells = <1> if they don't need ranges above 4GB. > > > > PCIe has a region starting at 0x40_ and size 4GB. We need 2 address > > cells and 2 size cells to describe this no? > > Yes. > > > > BTW, what's the difference between all these three similar PCIE > > > ranges? > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB > > > > This is the register space for the two instances of PCIe controller. > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB > > > > The above are regions which can be used by CPU/DMA to access the PCIe > > address > > space. The mapping from the above regions to the PCIe address space will be > > programmed in the PCIe controller. > > OK so not just somethng for dma-ranges but also accessible by > the CPU. > Kishon, Sekhar: Can you guys post patches based on v4.19-rc1 for fixing this? I do have a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the changes. -- Regards, Nishanth Menon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 15:55-20180827, Tony Lindgren wrote: > * Kishon Vijay Abraham I [180827 03:06]: > > Hi Tony, > > > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > > * Kishon Vijay Abraham I [180808 06:35]: > > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > > >>> address space if possible. > > >> > > >> We now have address-cells as <1>, > > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > >> > > >> However each PCIe instance has 2 data regions and one of the regions > > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > > >> specified > > >> in the "MAIN Domain Memory Map" table of TRM > > >> http://www.ti.com/lit/pdf/spruid7) > > >> is above the 32bit region and requires 2 cells to specify the start > > >> address. > > >> This region is used to access MEM_SPACE of PCIe endpoint when operating > > >> in root > > >> complex mode and access memory of PCI root complex when operating in > > >> endpoint mode. > > >> > > >> In order to describe this, should we change the address-cells back to > > >> <2> or do > > >> you suggest any other alternatives? > > > > > > It's probably best to have the top level cbass interconnect use > > > #size-cells = <2> and then have it's child interconnects have > > > #size-cells = <1> if they don't need ranges above 4GB. > > > > PCIe has a region starting at 0x40_ and size 4GB. We need 2 address > > cells and 2 size cells to describe this no? > > Yes. > > > > BTW, what's the difference between all these three similar PCIE > > > ranges? > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB > > > > This is the register space for the two instances of PCIe controller. > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB > > > > The above are regions which can be used by CPU/DMA to access the PCIe > > address > > space. The mapping from the above regions to the PCIe address space will be > > programmed in the PCIe controller. > > OK so not just somethng for dma-ranges but also accessible by > the CPU. > Kishon, Sekhar: Can you guys post patches based on v4.19-rc1 for fixing this? I do have a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the changes. -- Regards, Nishanth Menon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Kishon Vijay Abraham I [180827 03:06]: > Hi Tony, > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [180808 06:35]: > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > >>> address space if possible. > >> > >> We now have address-cells as <1>, > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > >> > >> However each PCIe instance has 2 data regions and one of the regions > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > >> specified > >> in the "MAIN Domain Memory Map" table of TRM > >> http://www.ti.com/lit/pdf/spruid7) > >> is above the 32bit region and requires 2 cells to specify the start > >> address. > >> This region is used to access MEM_SPACE of PCIe endpoint when operating in > >> root > >> complex mode and access memory of PCI root complex when operating in > >> endpoint mode. > >> > >> In order to describe this, should we change the address-cells back to <2> > >> or do > >> you suggest any other alternatives? > > > > It's probably best to have the top level cbass interconnect use > > #size-cells = <2> and then have it's child interconnects have > > #size-cells = <1> if they don't need ranges above 4GB. > > PCIe has a region starting at 0x40_ and size 4GB. We need 2 address > cells and 2 size cells to describe this no? Yes. > > BTW, what's the difference between all these three similar PCIE > > ranges? > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB > > This is the register space for the two instances of PCIe controller. > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB > > The above are regions which can be used by CPU/DMA to access the PCIe address > space. The mapping from the above regions to the PCIe address space will be > programmed in the PCIe controller. OK so not just somethng for dma-ranges but also accessible by the CPU. Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Kishon Vijay Abraham I [180827 03:06]: > Hi Tony, > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [180808 06:35]: > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > >>> address space if possible. > >> > >> We now have address-cells as <1>, > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > >> > >> However each PCIe instance has 2 data regions and one of the regions > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 > >> specified > >> in the "MAIN Domain Memory Map" table of TRM > >> http://www.ti.com/lit/pdf/spruid7) > >> is above the 32bit region and requires 2 cells to specify the start > >> address. > >> This region is used to access MEM_SPACE of PCIe endpoint when operating in > >> root > >> complex mode and access memory of PCI root complex when operating in > >> endpoint mode. > >> > >> In order to describe this, should we change the address-cells back to <2> > >> or do > >> you suggest any other alternatives? > > > > It's probably best to have the top level cbass interconnect use > > #size-cells = <2> and then have it's child interconnects have > > #size-cells = <1> if they don't need ranges above 4GB. > > PCIe has a region starting at 0x40_ and size 4GB. We need 2 address > cells and 2 size cells to describe this no? Yes. > > BTW, what's the difference between all these three similar PCIE > > ranges? > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB > > This is the register space for the two instances of PCIe controller. > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB > > The above are regions which can be used by CPU/DMA to access the PCIe address > space. The mapping from the above regions to the PCIe address space will be > programmed in the PCIe controller. OK so not just somethng for dma-ranges but also accessible by the CPU. Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Tony, On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I [180808 06:35]: >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>> Really need 64-bit addresses and sizes? Use ranges to limit the >>> address space if possible. >> >> We now have address-cells as <1>, >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >> >> However each PCIe instance has 2 data regions and one of the regions >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 >> specified >> in the "MAIN Domain Memory Map" table of TRM >> http://www.ti.com/lit/pdf/spruid7) >> is above the 32bit region and requires 2 cells to specify the start address. >> This region is used to access MEM_SPACE of PCIe endpoint when operating in >> root >> complex mode and access memory of PCI root complex when operating in >> endpoint mode. >> >> In order to describe this, should we change the address-cells back to <2> or >> do >> you suggest any other alternatives? > > It's probably best to have the top level cbass interconnect use > #size-cells = <2> and then have it's child interconnects have > #size-cells = <1> if they don't need ranges above 4GB. PCIe has a region starting at 0x40_ and size 4GB. We need 2 address cells and 2 size cells to describe this no? > > BTW, what's the difference between all these three similar PCIE > ranges? > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB This is the register space for the two instances of PCIe controller. > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB The above are regions which can be used by CPU/DMA to access the PCIe address space. The mapping from the above regions to the PCIe address space will be programmed in the PCIe controller. Thanks Kishon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Tony, On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I [180808 06:35]: >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>> Really need 64-bit addresses and sizes? Use ranges to limit the >>> address space if possible. >> >> We now have address-cells as <1>, >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >> >> However each PCIe instance has 2 data regions and one of the regions >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 >> specified >> in the "MAIN Domain Memory Map" table of TRM >> http://www.ti.com/lit/pdf/spruid7) >> is above the 32bit region and requires 2 cells to specify the start address. >> This region is used to access MEM_SPACE of PCIe endpoint when operating in >> root >> complex mode and access memory of PCI root complex when operating in >> endpoint mode. >> >> In order to describe this, should we change the address-cells back to <2> or >> do >> you suggest any other alternatives? > > It's probably best to have the top level cbass interconnect use > #size-cells = <2> and then have it's child interconnects have > #size-cells = <1> if they don't need ranges above 4GB. PCIe has a region starting at 0x40_ and size 4GB. We need 2 address cells and 2 size cells to describe this no? > > BTW, what's the difference between all these three similar PCIE > ranges? > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB This is the register space for the two instances of PCIe controller. > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB The above are regions which can be used by CPU/DMA to access the PCIe address space. The mapping from the above regions to the PCIe address space will be programmed in the PCIe controller. Thanks Kishon
Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Kishon Vijay Abraham I [180808 06:35]: > On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > Really need 64-bit addresses and sizes? Use ranges to limit the > > address space if possible. > > We now have address-cells as <1>, > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > However each PCIe instance has 2 data regions and one of the regions > (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified > in the "MAIN Domain Memory Map" table of TRM > http://www.ti.com/lit/pdf/spruid7) > is above the 32bit region and requires 2 cells to specify the start address. > This region is used to access MEM_SPACE of PCIe endpoint when operating in > root > complex mode and access memory of PCI root complex when operating in endpoint > mode. > > In order to describe this, should we change the address-cells back to <2> or > do > you suggest any other alternatives? It's probably best to have the top level cbass interconnect use #size-cells = <2> and then have it's child interconnects have #size-cells = <1> if they don't need ranges above 4GB. BTW, what's the difference between all these three similar PCIE ranges? PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB Regards, Tony
Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Kishon Vijay Abraham I [180808 06:35]: > On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > Really need 64-bit addresses and sizes? Use ranges to limit the > > address space if possible. > > We now have address-cells as <1>, > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > However each PCIe instance has 2 data regions and one of the regions > (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified > in the "MAIN Domain Memory Map" table of TRM > http://www.ti.com/lit/pdf/spruid7) > is above the 32bit region and requires 2 cells to specify the start address. > This region is used to access MEM_SPACE of PCIe endpoint when operating in > root > complex mode and access memory of PCI root complex when operating in endpoint > mode. > > In order to describe this, should we change the address-cells back to <2> or > do > you suggest any other alternatives? It's probably best to have the top level cbass interconnect use #size-cells = <2> and then have it's child interconnects have #size-cells = <1> if they don't need ranges above 4GB. BTW, what's the difference between all these three similar PCIE ranges? PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x000550 0x000560 1 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x000560 0x000570 1 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001000 0x001800 128 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x001800 0x002000 128 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x40 0x41 4 GB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x41 0x42 4 GB Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Sekhar Nori [180615 13:41]: > > How well we can reuse individual interconnect segments is something I > have to think about / experiment. Will have to be wary of any "short > paths" or "cross connections". These short paths and cross connections are almost certainly just additional ranges from the parent interconnect. See for example what we have in Linux next for wdt3 in omap4.dtsi for separate ranges for L4 and L3 interconnects. Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Sekhar Nori [180615 13:41]: > > How well we can reuse individual interconnect segments is something I > have to think about / experiment. Will have to be wary of any "short > paths" or "cross connections". These short paths and cross connections are almost certainly just additional ranges from the parent interconnect. See for example what we have in Linux next for wdt3 in omap4.dtsi for separate ranges for L4 and L3 interconnects. Regards, Tony
Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Rob, On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: >> The AM654 SoC is a lead device of the K3 Multicore SoC architecture >> platform, targeted for broad market and industrial control with aim to >> meet the complex processing needs of modern embedded products. >> >> Some highlights of this SoC are: >> * Quad ARMv8 A53 cores split over two clusters >> * GICv3 compliant GIC500 >> * Configurable L3 Cache and IO-coherent architecture >> * Dual lock-step capable R5F uC for safety-critical applications >> * High data throughput capable distributed DMA architecture under NAVSS >> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual >> PRUs and dual RTUs >> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL >> * Centralized System Controller for Security, Power, and Resource >> management. >> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD >> * Flash subystem with OSPI and Hyperbus interfaces >> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP >> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, >> GPIO >> >> See AM65x Technical Reference Manual (SPRUID7, April 2018) >> for further details: http://www.ti.com/lit/pdf/spruid7 >> >> We introduce the Kconfig symbol for the SoC along with this patch since >> it is logically relevant point, however the usage is in subsequent >> patches. >> >> NOTE: AM654 is the first of the device variants, hence we introduce a >> generic am6.dtsi. >> >> Signed-off-by: Benjamin Fair >> Signed-off-by: Nishanth Menon >> --- >> MAINTAINERS | 1 + >> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 >> +++ >> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 >> drivers/soc/ti/Kconfig | 14 >> 4 files changed, 276 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi >> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index cfb35b252ac7..5f5c4eddec7a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2092,6 +2092,7 @@ M:Nishanth Menon >> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >> S: Supported >> F: Documentation/devicetree/bindings/arm/ti/k3.txt >> +F: arch/arm64/boot/dts/ti/k3-* >> >> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE >> M: Santosh Shilimkar >> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi >> b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> new file mode 100644 >> index ..cdfa12173aac >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> @@ -0,0 +1,144 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Device Tree Source for AM6 SoC Family >> + * >> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - >> http://www.ti.com/ >> + */ >> + >> +#include >> +#include >> +#include >> + >> +/ { >> + model = "Texas Instruments K3 AM654 SoC"; >> + compatible = "ti,am654"; >> + interrupt-parent = <>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + aliases { >> + serial0 = _uart0; >> + serial1 = _uart0; >> + serial2 = _uart0; >> + serial3 = _uart1; >> + serial4 = _uart2; >> + }; >> + >> + chosen { }; >> + >> + firmware { >> + optee { >> + compatible = "linaro,optee-tz"; >> + method = "smc"; >> + }; >> + >> + psci: psci { >> + compatible = "arm,psci-1.0"; >> + method = "smc"; >> + }; >> + }; >> + >> + soc0: soc0 { >> + compatible = "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. We now have address-cells as <1>, https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 However each PCIe instance has 2 data regions and one of the regions (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) is above the 32bit region and requires 2 cells to specify the start address. This region is used to access MEM_SPACE of PCIe endpoint when operating in root complex mode and access memory of PCI root complex when operating in endpoint mode. In order to describe this, should we change the address-cells back to <2> or do you suggest any other alternatives? Thanks Kishon
Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Rob, On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: >> The AM654 SoC is a lead device of the K3 Multicore SoC architecture >> platform, targeted for broad market and industrial control with aim to >> meet the complex processing needs of modern embedded products. >> >> Some highlights of this SoC are: >> * Quad ARMv8 A53 cores split over two clusters >> * GICv3 compliant GIC500 >> * Configurable L3 Cache and IO-coherent architecture >> * Dual lock-step capable R5F uC for safety-critical applications >> * High data throughput capable distributed DMA architecture under NAVSS >> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual >> PRUs and dual RTUs >> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL >> * Centralized System Controller for Security, Power, and Resource >> management. >> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD >> * Flash subystem with OSPI and Hyperbus interfaces >> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP >> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, >> GPIO >> >> See AM65x Technical Reference Manual (SPRUID7, April 2018) >> for further details: http://www.ti.com/lit/pdf/spruid7 >> >> We introduce the Kconfig symbol for the SoC along with this patch since >> it is logically relevant point, however the usage is in subsequent >> patches. >> >> NOTE: AM654 is the first of the device variants, hence we introduce a >> generic am6.dtsi. >> >> Signed-off-by: Benjamin Fair >> Signed-off-by: Nishanth Menon >> --- >> MAINTAINERS | 1 + >> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 >> +++ >> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 >> drivers/soc/ti/Kconfig | 14 >> 4 files changed, 276 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi >> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index cfb35b252ac7..5f5c4eddec7a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2092,6 +2092,7 @@ M:Nishanth Menon >> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) >> S: Supported >> F: Documentation/devicetree/bindings/arm/ti/k3.txt >> +F: arch/arm64/boot/dts/ti/k3-* >> >> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE >> M: Santosh Shilimkar >> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi >> b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> new file mode 100644 >> index ..cdfa12173aac >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> @@ -0,0 +1,144 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Device Tree Source for AM6 SoC Family >> + * >> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - >> http://www.ti.com/ >> + */ >> + >> +#include >> +#include >> +#include >> + >> +/ { >> + model = "Texas Instruments K3 AM654 SoC"; >> + compatible = "ti,am654"; >> + interrupt-parent = <>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + aliases { >> + serial0 = _uart0; >> + serial1 = _uart0; >> + serial2 = _uart0; >> + serial3 = _uart1; >> + serial4 = _uart2; >> + }; >> + >> + chosen { }; >> + >> + firmware { >> + optee { >> + compatible = "linaro,optee-tz"; >> + method = "smc"; >> + }; >> + >> + psci: psci { >> + compatible = "arm,psci-1.0"; >> + method = "smc"; >> + }; >> + }; >> + >> + soc0: soc0 { >> + compatible = "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. We now have address-cells as <1>, https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 However each PCIe instance has 2 data regions and one of the regions (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) is above the 32bit region and requires 2 cells to specify the start address. This region is used to access MEM_SPACE of PCIe endpoint when operating in root complex mode and access memory of PCI root complex when operating in endpoint mode. In order to describe this, should we change the address-cells back to <2> or do you suggest any other alternatives? Thanks Kishon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Tony, On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote: > * Nishanth Menon [180614 13:07]: >> On 12:38-20180614, Tony Lindgren wrote: >> From A53 view, a more accurate view might be - from an interconnect >> view of the world (still simplified - i have ignored the sub bus >> segments in the representations below): >> >> msmc { >> navss_main { >> cbass_main{ >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> }; >> }; >> }; >> }; >> >> From R5 view, the view will be very different ofcourse: >> view of the world (still simplified): >> >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> cbass_main{ >> navss_main { >> msmc { >> }; >> }; >> }; >> }; > > Well if we follow the hardware representation of the interconnects, > it should not matter from which processor view you're looking at things. > There are just different ranges provided. AFAIK, the root node needs to have the CPU which is using the DT. So, the hierarchy will change based on CPU view (if we describe it fully). How well we can reuse individual interconnect segments is something I have to think about / experiment. Will have to be wary of any "short paths" or "cross connections". Thanks, Sekhar
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi Tony, On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote: > * Nishanth Menon [180614 13:07]: >> On 12:38-20180614, Tony Lindgren wrote: >> From A53 view, a more accurate view might be - from an interconnect >> view of the world (still simplified - i have ignored the sub bus >> segments in the representations below): >> >> msmc { >> navss_main { >> cbass_main{ >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> }; >> }; >> }; >> }; >> >> From R5 view, the view will be very different ofcourse: >> view of the world (still simplified): >> >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> cbass_main{ >> navss_main { >> msmc { >> }; >> }; >> }; >> }; > > Well if we follow the hardware representation of the interconnects, > it should not matter from which processor view you're looking at things. > There are just different ranges provided. AFAIK, the root node needs to have the CPU which is using the DT. So, the hierarchy will change based on CPU view (if we describe it fully). How well we can reuse individual interconnect segments is something I have to think about / experiment. Will have to be wary of any "short paths" or "cross connections". Thanks, Sekhar
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Nishanth Menon [180614 13:07]: > On 12:38-20180614, Tony Lindgren wrote: > > Some comments on the ranges below. > > Thanks for reviewing in detail (I understand we are in the middle of > merge window, so thanks for the extra effort). > > > > > * Nishanth Menon [180607 16:41]: > > > + soc0: soc0 { > > > + compatible = "simple-bus"; > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + ranges; > > > > I suggest you leave out the soc0, that's not real. Just make > > Why is that so, on a more complex board representation with multiple > SoCs, this is a clear node indicating what the main SoC is in the final > dtb representation. It does not have a real reg or range. > > the cbass@0 the top level interconnect. It can then provide > > ranges to mcu interconnect which can provide ranges to the wkup > > interconnect. So just model it after what's in the hardware :) > > That might blow up things quite a bit - it is like the comment in: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 That comment at the link above not true I've found. What we have there as "ocp" should be just "l3" and then the "l4" instances are children of "l3". The direct ports from some "l4" devices are just ranges at the parent "l3". And this will get changed slowly over next few merge cycles. > The trees are pretty deep with many interconnections (example main does > have direct connections to wkup as well, which is simplified off in > top level diagram) - basically it is not a direct one dimensional > relationship. But then, the same is the case for other SoCs.. In the above example the connection from main to wkup is just a range provided by main so not a problem. > we can represent NAVSS as a bus segment as well. Well ideally each module on the interconnects would be set up separately to prevent drivers trying to ioremap ranges from multiple modules. This is important as flushing posted write to one module will not flush it for the other module. > > I found the following ranges based on a quick look at the TRM, > > they could be split further if needed for power domains for > > genpd for example. > > genpd is not really an issue, since it is handled in system firmware and > OSes dont have a visibility into the permitted ranges that the OS is > allowed to use. There are other reasons beyond genpd too. Flushing posted writes to modules is one. Getting rid of pointless deferred probe is another one. Preventing device drivers trying to ioremap multiple module is yet another one.. > I think it is just how accurate a representation is it worth. The dts really is intended to describe the hardware :) So let's not repeat the same mistake again with imaginary ranges. > > > > main covers > > 0x00 - 0x540200 > > > > main provides at least the following ranges for mcu > > 0x002838 - 0x002bc0 > > 0x004008 - 0x0041c8 > > 0x004510 - 0x004518 > > 0x004560 - 0x004564 > > 0x004581 - 0x004586 > > 0x004595 - 0x0045950400 > > 0x0045a5 - 0x0045a50400 > > 0x0045b04000 - 0x0045b06400 > > 0x0045d1 - 0x0045d24000 > > 0x004600 - 0x006000 > > 0x04 - 0x08 > > 0x4c3c02 - 0x4c3c03 > > 0x4c3e00 - 0x4c3e04 > > 0x54 - 0x540200 > > > > then mcu provides the following ranges for wkup > > 0x004200 - 0x0044410020 > > 0x004500 - 0x004503 > > 0x004508 - 0x00450a > > 0x0045808000 - 0x0045808800 > > 0x0045b0 - 0x0045b02400 > > > > This based on looking at "figure 1-1. device top-level > > block diagram" and the memory map in TRM. > > Thanks for researching. I did debate something like: > > From A53 view, a more accurate view might be - from an interconnect > view of the world (still simplified - i have ignored the sub bus > segments in the representations below): > > msmc { > navss_main { > cbass_main{ > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > }; > }; > }; > }; > > From R5 view, the view will be very different ofcourse: > view of the world (still simplified): > > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > cbass_main{ > navss_main { > msmc { > }; > }; > }; > }; Well if we follow the hardware representation of the interconnects, it should not matter from which processor view you're looking at things. There are just different ranges provided. > Do we really need this level of representation, I am not sure I had seen > this detailed a representation in other aarch64 SoCs (I am sure they are > as complex as TI SoCs as well). Based on my experience yes. See also the reasons I listed
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Nishanth Menon [180614 13:07]: > On 12:38-20180614, Tony Lindgren wrote: > > Some comments on the ranges below. > > Thanks for reviewing in detail (I understand we are in the middle of > merge window, so thanks for the extra effort). > > > > > * Nishanth Menon [180607 16:41]: > > > + soc0: soc0 { > > > + compatible = "simple-bus"; > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + ranges; > > > > I suggest you leave out the soc0, that's not real. Just make > > Why is that so, on a more complex board representation with multiple > SoCs, this is a clear node indicating what the main SoC is in the final > dtb representation. It does not have a real reg or range. > > the cbass@0 the top level interconnect. It can then provide > > ranges to mcu interconnect which can provide ranges to the wkup > > interconnect. So just model it after what's in the hardware :) > > That might blow up things quite a bit - it is like the comment in: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 That comment at the link above not true I've found. What we have there as "ocp" should be just "l3" and then the "l4" instances are children of "l3". The direct ports from some "l4" devices are just ranges at the parent "l3". And this will get changed slowly over next few merge cycles. > The trees are pretty deep with many interconnections (example main does > have direct connections to wkup as well, which is simplified off in > top level diagram) - basically it is not a direct one dimensional > relationship. But then, the same is the case for other SoCs.. In the above example the connection from main to wkup is just a range provided by main so not a problem. > we can represent NAVSS as a bus segment as well. Well ideally each module on the interconnects would be set up separately to prevent drivers trying to ioremap ranges from multiple modules. This is important as flushing posted write to one module will not flush it for the other module. > > I found the following ranges based on a quick look at the TRM, > > they could be split further if needed for power domains for > > genpd for example. > > genpd is not really an issue, since it is handled in system firmware and > OSes dont have a visibility into the permitted ranges that the OS is > allowed to use. There are other reasons beyond genpd too. Flushing posted writes to modules is one. Getting rid of pointless deferred probe is another one. Preventing device drivers trying to ioremap multiple module is yet another one.. > I think it is just how accurate a representation is it worth. The dts really is intended to describe the hardware :) So let's not repeat the same mistake again with imaginary ranges. > > > > main covers > > 0x00 - 0x540200 > > > > main provides at least the following ranges for mcu > > 0x002838 - 0x002bc0 > > 0x004008 - 0x0041c8 > > 0x004510 - 0x004518 > > 0x004560 - 0x004564 > > 0x004581 - 0x004586 > > 0x004595 - 0x0045950400 > > 0x0045a5 - 0x0045a50400 > > 0x0045b04000 - 0x0045b06400 > > 0x0045d1 - 0x0045d24000 > > 0x004600 - 0x006000 > > 0x04 - 0x08 > > 0x4c3c02 - 0x4c3c03 > > 0x4c3e00 - 0x4c3e04 > > 0x54 - 0x540200 > > > > then mcu provides the following ranges for wkup > > 0x004200 - 0x0044410020 > > 0x004500 - 0x004503 > > 0x004508 - 0x00450a > > 0x0045808000 - 0x0045808800 > > 0x0045b0 - 0x0045b02400 > > > > This based on looking at "figure 1-1. device top-level > > block diagram" and the memory map in TRM. > > Thanks for researching. I did debate something like: > > From A53 view, a more accurate view might be - from an interconnect > view of the world (still simplified - i have ignored the sub bus > segments in the representations below): > > msmc { > navss_main { > cbass_main{ > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > }; > }; > }; > }; > > From R5 view, the view will be very different ofcourse: > view of the world (still simplified): > > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > cbass_main{ > navss_main { > msmc { > }; > }; > }; > }; Well if we follow the hardware representation of the interconnects, it should not matter from which processor view you're looking at things. There are just different ranges provided. > Do we really need this level of representation, I am not sure I had seen > this detailed a representation in other aarch64 SoCs (I am sure they are > as complex as TI SoCs as well). Based on my experience yes. See also the reasons I listed
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 12:38-20180614, Tony Lindgren wrote: > Some comments on the ranges below. Thanks for reviewing in detail (I understand we are in the middle of merge window, so thanks for the extra effort). > > * Nishanth Menon [180607 16:41]: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > I suggest you leave out the soc0, that's not real. Just make Why is that so, on a more complex board representation with multiple SoCs, this is a clear node indicating what the main SoC is in the final dtb representation. > the cbass@0 the top level interconnect. It can then provide > ranges to mcu interconnect which can provide ranges to the wkup > interconnect. So just model it after what's in the hardware :) That might blow up things quite a bit - it is like the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 The trees are pretty deep with many interconnections (example main does have direct connections to wkup as well, which is simplified off in top level diagram) - basically it is not a direct one dimensional relationship. But then, the same is the case for other SoCs.. we can represent NAVSS as a bus segment as well. > > I found the following ranges based on a quick look at the TRM, > they could be split further if needed for power domains for > genpd for example. genpd is not really an issue, since it is handled in system firmware and OSes dont have a visibility into the permitted ranges that the OS is allowed to use. I think it is just how accurate a representation is it worth. > > main covers > 0x00 - 0x540200 > > main provides at least the following ranges for mcu > 0x002838 - 0x002bc0 > 0x004008 - 0x0041c8 > 0x004510 - 0x004518 > 0x004560 - 0x004564 > 0x004581 - 0x004586 > 0x004595 - 0x0045950400 > 0x0045a5 - 0x0045a50400 > 0x0045b04000 - 0x0045b06400 > 0x0045d1 - 0x0045d24000 > 0x004600 - 0x006000 > 0x04 - 0x08 > 0x4c3c02 - 0x4c3c03 > 0x4c3e00 - 0x4c3e04 > 0x54 - 0x540200 > > then mcu provides the following ranges for wkup > 0x004200 - 0x0044410020 > 0x004500 - 0x004503 > 0x004508 - 0x00450a > 0x0045808000 - 0x0045808800 > 0x0045b0 - 0x0045b02400 > > This based on looking at "figure 1-1. device top-level > block diagram" and the memory map in TRM. Thanks for researching. I did debate something like: >From A53 view, a more accurate view might be - from an interconnect view of the world (still simplified - i have ignored the sub bus segments in the representations below): msmc { navss_main { cbass_main{ cbass_mcu { navss_mcu { }; cbass_wkup{ }; }; }; }; }; >From R5 view, the view will be very different ofcourse: view of the world (still simplified): cbass_mcu { navss_mcu { }; cbass_wkup{ }; cbass_main{ navss_main { msmc { }; }; }; }; Do we really need this level of representation, I am not sure I had seen this detailed a representation in other aarch64 SoCs (I am sure they are as complex as TI SoCs as well). I am trying to understand the direction and logic why we'd want to have such a detailed representation. A more flatter representation of just the main segments allow for dts reuse between r5 and a53 as well (but that is minor). Thoughts? -- Regards, Nishanth Menon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 12:38-20180614, Tony Lindgren wrote: > Some comments on the ranges below. Thanks for reviewing in detail (I understand we are in the middle of merge window, so thanks for the extra effort). > > * Nishanth Menon [180607 16:41]: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > I suggest you leave out the soc0, that's not real. Just make Why is that so, on a more complex board representation with multiple SoCs, this is a clear node indicating what the main SoC is in the final dtb representation. > the cbass@0 the top level interconnect. It can then provide > ranges to mcu interconnect which can provide ranges to the wkup > interconnect. So just model it after what's in the hardware :) That might blow up things quite a bit - it is like the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 The trees are pretty deep with many interconnections (example main does have direct connections to wkup as well, which is simplified off in top level diagram) - basically it is not a direct one dimensional relationship. But then, the same is the case for other SoCs.. we can represent NAVSS as a bus segment as well. > > I found the following ranges based on a quick look at the TRM, > they could be split further if needed for power domains for > genpd for example. genpd is not really an issue, since it is handled in system firmware and OSes dont have a visibility into the permitted ranges that the OS is allowed to use. I think it is just how accurate a representation is it worth. > > main covers > 0x00 - 0x540200 > > main provides at least the following ranges for mcu > 0x002838 - 0x002bc0 > 0x004008 - 0x0041c8 > 0x004510 - 0x004518 > 0x004560 - 0x004564 > 0x004581 - 0x004586 > 0x004595 - 0x0045950400 > 0x0045a5 - 0x0045a50400 > 0x0045b04000 - 0x0045b06400 > 0x0045d1 - 0x0045d24000 > 0x004600 - 0x006000 > 0x04 - 0x08 > 0x4c3c02 - 0x4c3c03 > 0x4c3e00 - 0x4c3e04 > 0x54 - 0x540200 > > then mcu provides the following ranges for wkup > 0x004200 - 0x0044410020 > 0x004500 - 0x004503 > 0x004508 - 0x00450a > 0x0045808000 - 0x0045808800 > 0x0045b0 - 0x0045b02400 > > This based on looking at "figure 1-1. device top-level > block diagram" and the memory map in TRM. Thanks for researching. I did debate something like: >From A53 view, a more accurate view might be - from an interconnect view of the world (still simplified - i have ignored the sub bus segments in the representations below): msmc { navss_main { cbass_main{ cbass_mcu { navss_mcu { }; cbass_wkup{ }; }; }; }; }; >From R5 view, the view will be very different ofcourse: view of the world (still simplified): cbass_mcu { navss_mcu { }; cbass_wkup{ }; cbass_main{ navss_main { msmc { }; }; }; }; Do we really need this level of representation, I am not sure I had seen this detailed a representation in other aarch64 SoCs (I am sure they are as complex as TI SoCs as well). I am trying to understand the direction and logic why we'd want to have such a detailed representation. A more flatter representation of just the main segments allow for dts reuse between r5 and a53 as well (but that is minor). Thoughts? -- Regards, Nishanth Menon
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi, Some comments on the ranges below. * Nishanth Menon [180607 16:41]: > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; I suggest you leave out the soc0, that's not real. Just make the cbass@0 the top level interconnect. It can then provide ranges to mcu interconnect which can provide ranges to the wkup interconnect. So just model it after what's in the hardware :) I found the following ranges based on a quick look at the TRM, they could be split further if needed for power domains for genpd for example. main covers 0x00 - 0x540200 main provides at least the following ranges for mcu 0x002838 - 0x002bc0 0x004008 - 0x0041c8 0x004510 - 0x004518 0x004560 - 0x004564 0x004581 - 0x004586 0x004595 - 0x0045950400 0x0045a5 - 0x0045a50400 0x0045b04000 - 0x0045b06400 0x0045d1 - 0x0045d24000 0x004600 - 0x006000 0x04 - 0x08 0x4c3c02 - 0x4c3c03 0x4c3e00 - 0x4c3e04 0x54 - 0x540200 then mcu provides the following ranges for wkup 0x004200 - 0x0044410020 0x004500 - 0x004503 0x004508 - 0x00450a 0x0045808000 - 0x0045808800 0x0045b0 - 0x0045b02400 This based on looking at "figure 1-1. device top-level block diagram" and the memory map in TRM. Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
Hi, Some comments on the ranges below. * Nishanth Menon [180607 16:41]: > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; I suggest you leave out the soc0, that's not real. Just make the cbass@0 the top level interconnect. It can then provide ranges to mcu interconnect which can provide ranges to the wkup interconnect. So just model it after what's in the hardware :) I found the following ranges based on a quick look at the TRM, they could be split further if needed for power domains for genpd for example. main covers 0x00 - 0x540200 main provides at least the following ranges for mcu 0x002838 - 0x002bc0 0x004008 - 0x0041c8 0x004510 - 0x004518 0x004560 - 0x004564 0x004581 - 0x004586 0x004595 - 0x0045950400 0x0045a5 - 0x0045a50400 0x0045b04000 - 0x0045b06400 0x0045d1 - 0x0045d24000 0x004600 - 0x006000 0x04 - 0x08 0x4c3c02 - 0x4c3c03 0x4c3e00 - 0x4c3e04 0x54 - 0x540200 then mcu provides the following ranges for wkup 0x004200 - 0x0044410020 0x004500 - 0x004503 0x004508 - 0x00450a 0x0045808000 - 0x0045808800 0x0045b0 - 0x0045b02400 This based on looking at "figure 1-1. device top-level block diagram" and the memory map in TRM. Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 14:05-20180605, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: [...] > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. Done -> overall the addresses are really in the 64bit addresses, but used bus segments and ranges to reduce to 32bit maps where possible. OSPI, PCIE, FSS (Flash subsystem) , CPTS are some of the ones that probably will need some level of cleanups when those are introduced later. Unfortunately, there is a lot of interleaved addressing between bus segments themselves, I have tried to keep the ranges as clean as reasonably possible. I also tried to use 1-1 map for children nodes to maintain some level of sanity as we add more device nodes. There might be a few exceptions, but overall the ranges currently map 1-1 physical 32bit address - OSPI, CPTS, FSS will however have to have a different mapping. See [1] > > > + > > + a53_timer0: timer-cl0-cpu0 { > > + compatible = "arm,armv8-timer"; > > + interrupts = , /* > > cntpsirq */ > > +, /* > > cntpnsirq */ > > +, /* > > cntvirq */ > > +; /* > > cnthpirq */ > > + }; > > + > > + pmu: pmu { > > + compatible = "arm,armv8-pmuv3"; > > + /* Recommendation from GIC500 TRM Table A.3 */ > > + interrupts = ; > > + }; > > These 2 nodes aren't on the bus, so move them up a level. Thanks. oversight on my end. I have fixed it (see [1]) > > > + > > + gic: interrupt-controller@180 { > > + compatible = "arm,gic-v3"; > > gic-500? Yes, GIC500. > > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > + #interrupt-cells = <3>; > > + interrupt-controller; > > + /* > > +* NOTE: we are NOT gicv2 backward compat, so no > > GICC, > > +* GICH or GICV > > The compatible should imply this. GIC500 at SoC design instantiation takes a parameter "are_option" -> this is set to no-compatibility for V2 for AM6. This is indeed discovered by the driver, However, Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt just notes that GICC, GICH, GICV as optional.. With backward compatibility disabled, these are'nt even present. I have dropped the comment, was helpful for me when I was first adding support for GIC500, It is pretty common knowledge now for other ARMV8 developers, so no point in retaining newbie info as comment. [...] > > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi > > b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > new file mode 100644 > > index ..d9b70081daba > > --- /dev/null > > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > @@ -0,0 +1,117 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Device Tree Source for AM6 SoC family in Quad core configuration > > + * > > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > > http://www.ti.com/ > > + */ > > + > > +#include "k3-am6.dtsi" > > + > > +/ { > > + cpus: cpus { > > Really need a label? Thanks. Dropped. > > > + #address-cells = <1>; > > + #size-cells = <0>; > > + cpu-map { > > IIRC, this goes at the top level. Documentation/devicetree/bindings/arm/topology.txt States to keep in cpus node. Quote: | The ARM CPU topology is defined within the cpu-map node, which is a direct | child of the cpus node and provides a container where the actual topology | nodes are listed. Retained as is to stay in sync with binding. > > + cpu0: cpu@0 { > > + compatible = "arm,cortex-a53","arm,armv8"; > > space between compatibles. Oops. Fixed. thanks. > > > + reg = <0x000>; > > + device_type = "cpu"; > > + enable-method = "psci"; > > > + i-cache-size = <0x8000>; > > + i-cache-line-size = <64>; > > + i-cache-sets = <256>; > > + d-cache-size = <0x8000>; > > + d-cache-line-size = <64>; > > + d-cache-sets = <128>; > > All this should be discoverable. Unfortunately no. Previously CCSIDR_EL1 was a good place to lookup this data. But as Sudeep pointed me offline: commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing") and commit 9a802431c527 ("arm64: cacheinfo: add support to override cache levels
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 14:05-20180605, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: [...] > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. Done -> overall the addresses are really in the 64bit addresses, but used bus segments and ranges to reduce to 32bit maps where possible. OSPI, PCIE, FSS (Flash subsystem) , CPTS are some of the ones that probably will need some level of cleanups when those are introduced later. Unfortunately, there is a lot of interleaved addressing between bus segments themselves, I have tried to keep the ranges as clean as reasonably possible. I also tried to use 1-1 map for children nodes to maintain some level of sanity as we add more device nodes. There might be a few exceptions, but overall the ranges currently map 1-1 physical 32bit address - OSPI, CPTS, FSS will however have to have a different mapping. See [1] > > > + > > + a53_timer0: timer-cl0-cpu0 { > > + compatible = "arm,armv8-timer"; > > + interrupts = , /* > > cntpsirq */ > > +, /* > > cntpnsirq */ > > +, /* > > cntvirq */ > > +; /* > > cnthpirq */ > > + }; > > + > > + pmu: pmu { > > + compatible = "arm,armv8-pmuv3"; > > + /* Recommendation from GIC500 TRM Table A.3 */ > > + interrupts = ; > > + }; > > These 2 nodes aren't on the bus, so move them up a level. Thanks. oversight on my end. I have fixed it (see [1]) > > > + > > + gic: interrupt-controller@180 { > > + compatible = "arm,gic-v3"; > > gic-500? Yes, GIC500. > > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > + #interrupt-cells = <3>; > > + interrupt-controller; > > + /* > > +* NOTE: we are NOT gicv2 backward compat, so no > > GICC, > > +* GICH or GICV > > The compatible should imply this. GIC500 at SoC design instantiation takes a parameter "are_option" -> this is set to no-compatibility for V2 for AM6. This is indeed discovered by the driver, However, Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt just notes that GICC, GICH, GICV as optional.. With backward compatibility disabled, these are'nt even present. I have dropped the comment, was helpful for me when I was first adding support for GIC500, It is pretty common knowledge now for other ARMV8 developers, so no point in retaining newbie info as comment. [...] > > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi > > b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > new file mode 100644 > > index ..d9b70081daba > > --- /dev/null > > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > @@ -0,0 +1,117 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Device Tree Source for AM6 SoC family in Quad core configuration > > + * > > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > > http://www.ti.com/ > > + */ > > + > > +#include "k3-am6.dtsi" > > + > > +/ { > > + cpus: cpus { > > Really need a label? Thanks. Dropped. > > > + #address-cells = <1>; > > + #size-cells = <0>; > > + cpu-map { > > IIRC, this goes at the top level. Documentation/devicetree/bindings/arm/topology.txt States to keep in cpus node. Quote: | The ARM CPU topology is defined within the cpu-map node, which is a direct | child of the cpus node and provides a container where the actual topology | nodes are listed. Retained as is to stay in sync with binding. > > + cpu0: cpu@0 { > > + compatible = "arm,cortex-a53","arm,armv8"; > > space between compatibles. Oops. Fixed. thanks. > > > + reg = <0x000>; > > + device_type = "cpu"; > > + enable-method = "psci"; > > > + i-cache-size = <0x8000>; > > + i-cache-line-size = <64>; > > + i-cache-sets = <256>; > > + d-cache-size = <0x8000>; > > + d-cache-line-size = <64>; > > + d-cache-sets = <128>; > > All this should be discoverable. Unfortunately no. Previously CCSIDR_EL1 was a good place to lookup this data. But as Sudeep pointed me offline: commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing") and commit 9a802431c527 ("arm64: cacheinfo: add support to override cache levels
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Rob Herring [180605 14:08]: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. And in addition to using ranges, please set up separate bus instances for the interconnects. This will then allow you to probe WKUP or similar instance first and the other bus instances after. And that pretty much allows you to get rid of the annoying -EPROBE_DEFER ping pong and allows making clocks proper device drivers ;) Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
* Rob Herring [180605 14:08]: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. And in addition to using ranges, please set up separate bus instances for the interconnects. This will then allow you to probe WKUP or similar instance first and the other bus instances after. And that pretty much allows you to get rid of the annoying -EPROBE_DEFER ping pong and allows making clocks proper device drivers ;) Regards, Tony
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: > The AM654 SoC is a lead device of the K3 Multicore SoC architecture > platform, targeted for broad market and industrial control with aim to > meet the complex processing needs of modern embedded products. > > Some highlights of this SoC are: > * Quad ARMv8 A53 cores split over two clusters > * GICv3 compliant GIC500 > * Configurable L3 Cache and IO-coherent architecture > * Dual lock-step capable R5F uC for safety-critical applications > * High data throughput capable distributed DMA architecture under NAVSS > * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual > PRUs and dual RTUs > * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL > * Centralized System Controller for Security, Power, and Resource > management. > * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD > * Flash subystem with OSPI and Hyperbus interfaces > * Multimedia capability with CAL, DSS7-UL, SGX544, McASP > * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, > GPIO > > See AM65x Technical Reference Manual (SPRUID7, April 2018) > for further details: http://www.ti.com/lit/pdf/spruid7 > > We introduce the Kconfig symbol for the SoC along with this patch since > it is logically relevant point, however the usage is in subsequent > patches. > > NOTE: AM654 is the first of the device variants, hence we introduce a > generic am6.dtsi. > > Signed-off-by: Benjamin Fair > Signed-off-by: Nishanth Menon > --- > MAINTAINERS | 1 + > arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 > +++ > arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 > drivers/soc/ti/Kconfig | 14 > 4 files changed, 276 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index cfb35b252ac7..5f5c4eddec7a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2092,6 +2092,7 @@ M:Nishanth Menon > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/arm/ti/k3.txt > +F: arch/arm64/boot/dts/ti/k3-* > > ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE > M: Santosh Shilimkar > diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi > b/arch/arm64/boot/dts/ti/k3-am6.dtsi > new file mode 100644 > index ..cdfa12173aac > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi > @@ -0,0 +1,144 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Device Tree Source for AM6 SoC Family > + * > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > http://www.ti.com/ > + */ > + > +#include > +#include > +#include > + > +/ { > + model = "Texas Instruments K3 AM654 SoC"; > + compatible = "ti,am654"; > + interrupt-parent = <>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + aliases { > + serial0 = _uart0; > + serial1 = _uart0; > + serial2 = _uart0; > + serial3 = _uart1; > + serial4 = _uart2; > + }; > + > + chosen { }; > + > + firmware { > + optee { > + compatible = "linaro,optee-tz"; > + method = "smc"; > + }; > + > + psci: psci { > + compatible = "arm,psci-1.0"; > + method = "smc"; > + }; > + }; > + > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; Really need 64-bit addresses and sizes? Use ranges to limit the address space if possible. > + > + a53_timer0: timer-cl0-cpu0 { > + compatible = "arm,armv8-timer"; > + interrupts = , /* > cntpsirq */ > +, /* > cntpnsirq */ > +, /* > cntvirq */ > +; /* > cnthpirq */ > + }; > + > + pmu: pmu { > + compatible = "arm,armv8-pmuv3"; > + /* Recommendation from GIC500 TRM Table A.3 */ > + interrupts = ; > + }; These 2 nodes aren't on the bus, so move them up a level. > + > + gic: interrupt-controller@180 { > + compatible = "arm,gic-v3"; gic-500? > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + #interrupt-cells = <3>; > + interrupt-controller; > + /* > +* NOTE: we are NOT gicv2 backward compat, so no GICC, > +
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote: > The AM654 SoC is a lead device of the K3 Multicore SoC architecture > platform, targeted for broad market and industrial control with aim to > meet the complex processing needs of modern embedded products. > > Some highlights of this SoC are: > * Quad ARMv8 A53 cores split over two clusters > * GICv3 compliant GIC500 > * Configurable L3 Cache and IO-coherent architecture > * Dual lock-step capable R5F uC for safety-critical applications > * High data throughput capable distributed DMA architecture under NAVSS > * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual > PRUs and dual RTUs > * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL > * Centralized System Controller for Security, Power, and Resource > management. > * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD > * Flash subystem with OSPI and Hyperbus interfaces > * Multimedia capability with CAL, DSS7-UL, SGX544, McASP > * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, > GPIO > > See AM65x Technical Reference Manual (SPRUID7, April 2018) > for further details: http://www.ti.com/lit/pdf/spruid7 > > We introduce the Kconfig symbol for the SoC along with this patch since > it is logically relevant point, however the usage is in subsequent > patches. > > NOTE: AM654 is the first of the device variants, hence we introduce a > generic am6.dtsi. > > Signed-off-by: Benjamin Fair > Signed-off-by: Nishanth Menon > --- > MAINTAINERS | 1 + > arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 > +++ > arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 > drivers/soc/ti/Kconfig | 14 > 4 files changed, 276 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index cfb35b252ac7..5f5c4eddec7a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2092,6 +2092,7 @@ M:Nishanth Menon > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/arm/ti/k3.txt > +F: arch/arm64/boot/dts/ti/k3-* > > ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE > M: Santosh Shilimkar > diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi > b/arch/arm64/boot/dts/ti/k3-am6.dtsi > new file mode 100644 > index ..cdfa12173aac > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi > @@ -0,0 +1,144 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Device Tree Source for AM6 SoC Family > + * > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - > http://www.ti.com/ > + */ > + > +#include > +#include > +#include > + > +/ { > + model = "Texas Instruments K3 AM654 SoC"; > + compatible = "ti,am654"; > + interrupt-parent = <>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + aliases { > + serial0 = _uart0; > + serial1 = _uart0; > + serial2 = _uart0; > + serial3 = _uart1; > + serial4 = _uart2; > + }; > + > + chosen { }; > + > + firmware { > + optee { > + compatible = "linaro,optee-tz"; > + method = "smc"; > + }; > + > + psci: psci { > + compatible = "arm,psci-1.0"; > + method = "smc"; > + }; > + }; > + > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; Really need 64-bit addresses and sizes? Use ranges to limit the address space if possible. > + > + a53_timer0: timer-cl0-cpu0 { > + compatible = "arm,armv8-timer"; > + interrupts = , /* > cntpsirq */ > +, /* > cntpnsirq */ > +, /* > cntvirq */ > +; /* > cnthpirq */ > + }; > + > + pmu: pmu { > + compatible = "arm,armv8-pmuv3"; > + /* Recommendation from GIC500 TRM Table A.3 */ > + interrupts = ; > + }; These 2 nodes aren't on the bus, so move them up a level. > + > + gic: interrupt-controller@180 { > + compatible = "arm,gic-v3"; gic-500? > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + #interrupt-cells = <3>; > + interrupt-controller; > + /* > +* NOTE: we are NOT gicv2 backward compat, so no GICC, > +
[RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * Dual lock-step capable R5F uC for safety-critical applications * High data throughput capable distributed DMA architecture under NAVSS * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * Centralized System Controller for Security, Power, and Resource management. * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD * Flash subystem with OSPI and Hyperbus interfaces * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO See AM65x Technical Reference Manual (SPRUID7, April 2018) for further details: http://www.ti.com/lit/pdf/spruid7 We introduce the Kconfig symbol for the SoC along with this patch since it is logically relevant point, however the usage is in subsequent patches. NOTE: AM654 is the first of the device variants, hence we introduce a generic am6.dtsi. Signed-off-by: Benjamin Fair Signed-off-by: Nishanth Menon --- MAINTAINERS | 1 + arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++ arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 drivers/soc/ti/Kconfig | 14 4 files changed, 276 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi diff --git a/MAINTAINERS b/MAINTAINERS index cfb35b252ac7..5f5c4eddec7a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M:Nishanth Menon L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M: Santosh Shilimkar diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi new file mode 100644 index ..cdfa12173aac --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,144 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC Family + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include +#include +#include + +/ { + model = "Texas Instruments K3 AM654 SoC"; + compatible = "ti,am654"; + interrupt-parent = <>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = _uart0; + serial1 = _uart0; + serial2 = _uart0; + serial3 = _uart1; + serial4 = _uart2; + }; + + chosen { }; + + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + + psci: psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + a53_timer0: timer-cl0-cpu0 { + compatible = "arm,armv8-timer"; + interrupts = , /* cntpsirq */ +, /* cntpnsirq */ +, /* cntvirq */ +; /* cnthpirq */ + }; + + pmu: pmu { + compatible = "arm,armv8-pmuv3"; + /* Recommendation from GIC500 TRM Table A.3 */ + interrupts = ; + }; + + gic: interrupt-controller@180 { + compatible = "arm,gic-v3"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + /* +* NOTE: we are NOT gicv2 backward compat, so no GICC, +* GICH or GICV +*/ + reg = <0x0 0x0180 0x0 0x1>, /* GICD */ + <0x0 0x0188 0x0 0x9>; /* GICR */ + + /* +* vcpumntirq: +* virtual CPU interface maintenance interrupt +*/ + interrupts = ; + + gic_its: gic-its@100 { +
[RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * Dual lock-step capable R5F uC for safety-critical applications * High data throughput capable distributed DMA architecture under NAVSS * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * Centralized System Controller for Security, Power, and Resource management. * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD * Flash subystem with OSPI and Hyperbus interfaces * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO See AM65x Technical Reference Manual (SPRUID7, April 2018) for further details: http://www.ti.com/lit/pdf/spruid7 We introduce the Kconfig symbol for the SoC along with this patch since it is logically relevant point, however the usage is in subsequent patches. NOTE: AM654 is the first of the device variants, hence we introduce a generic am6.dtsi. Signed-off-by: Benjamin Fair Signed-off-by: Nishanth Menon --- MAINTAINERS | 1 + arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++ arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 drivers/soc/ti/Kconfig | 14 4 files changed, 276 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi diff --git a/MAINTAINERS b/MAINTAINERS index cfb35b252ac7..5f5c4eddec7a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M:Nishanth Menon L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M: Santosh Shilimkar diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi new file mode 100644 index ..cdfa12173aac --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,144 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC Family + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include +#include +#include + +/ { + model = "Texas Instruments K3 AM654 SoC"; + compatible = "ti,am654"; + interrupt-parent = <>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = _uart0; + serial1 = _uart0; + serial2 = _uart0; + serial3 = _uart1; + serial4 = _uart2; + }; + + chosen { }; + + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + + psci: psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + a53_timer0: timer-cl0-cpu0 { + compatible = "arm,armv8-timer"; + interrupts = , /* cntpsirq */ +, /* cntpnsirq */ +, /* cntvirq */ +; /* cnthpirq */ + }; + + pmu: pmu { + compatible = "arm,armv8-pmuv3"; + /* Recommendation from GIC500 TRM Table A.3 */ + interrupts = ; + }; + + gic: interrupt-controller@180 { + compatible = "arm,gic-v3"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + /* +* NOTE: we are NOT gicv2 backward compat, so no GICC, +* GICH or GICV +*/ + reg = <0x0 0x0180 0x0 0x1>, /* GICD */ + <0x0 0x0188 0x0 0x9>; /* GICR */ + + /* +* vcpumntirq: +* virtual CPU interface maintenance interrupt +*/ + interrupts = ; + + gic_its: gic-its@100 { +