| Message ID | 20200827065144.17683-1-lokeshvutla@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Initial support for Texas Instrument's J7200 Platform | expand |
On 27/08/2020 09:51, Lokesh Vutla wrote: > This series adds initial support for latest new SoC, J7200, from Texas Instruments. > > The J7200 SoC is a part of the K3 Multicore SoC architecture platform. > It is targeted for for automotive gateway, vehicle compute systems, > Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. > The SoC aims to meet the complex processing needs of modern embedded products. > > See J7200 Technical Reference Manual (SPRUIU1, June 2020) > for further details: https://www.ti.com/lit/pdf/spruiu1 > > Changes since v1: > - Swapped Patch 1 and 2 as suggested by Nishanth. > - Added description for each SoC in yaml bindings. > > Testing: > - ./scripts/checkpatch --strict > - Few warningns about Line length exceeding 100 columns. > But these are corresponding to comments > - v8make dtbs_check > - DT_SCHEMA_FLAGS="-u" > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > v8make dtbs_check > - DT_SCHEMA_FLAGS="-u" > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > v8make dt_binding_check > > > Lokesh Vutla (4): > dt-bindings: arm: ti: Convert K3 board/soc bindings to DT schema > dt-bindings: arm: ti: Add bindings for J7200 SoC > arm64: dts: ti: Add support for J7200 SoC > arm64: dts: ti: Add support for J7200 Common Processor Board > > .../devicetree/bindings/arm/ti/k3.txt | 26 --- > .../devicetree/bindings/arm/ti/k3.yaml | 35 +++ > MAINTAINERS | 2 +- > arch/arm64/boot/dts/ti/Makefile | 3 +- > .../dts/ti/k3-j7200-common-proc-board.dts | 64 ++++++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 199 ++++++++++++++++++ > .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 84 ++++++++ > arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 29 +++ > arch/arm64/boot/dts/ti/k3-j7200.dtsi | 165 +++++++++++++++ > 9 files changed, 579 insertions(+), 28 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt > create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.yaml > create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts > create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-j7200.dtsi > Thank you Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Hi, On 27/08/20 12:21 pm, Lokesh Vutla wrote: > This series adds initial support for latest new SoC, J7200, from Texas Instruments. > > The J7200 SoC is a part of the K3 Multicore SoC architecture platform. > It is targeted for for automotive gateway, vehicle compute systems, > Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. > The SoC aims to meet the complex processing needs of modern embedded products. > > See J7200 Technical Reference Manual (SPRUIU1, June 2020) > for further details: https://www.ti.com/lit/pdf/spruiu1 > > Changes since v1: > - Swapped Patch 1 and 2 as suggested by Nishanth. > - Added description for each SoC in yaml bindings. > > Testing: > - ./scripts/checkpatch --strict > - Few warningns about Line length exceeding 100 columns. > But these are corresponding to comments > - v8make dtbs_check > - DT_SCHEMA_FLAGS="-u" > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > v8make dtbs_check > - DT_SCHEMA_FLAGS="-u" > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > v8make dt_binding_check This series has been lying around for soo long with no major comments. It will be nice to get this merged. I understand we are waiting for Acks on yaml documentation but it would be bad to miss a merge window for a new platform because we are waiting for Acks on yaml conversion. Thanks and regards, Lokesh
On 17:32-20200907, Lokesh Vutla wrote: > Hi, > > On 27/08/20 12:21 pm, Lokesh Vutla wrote: > > This series adds initial support for latest new SoC, J7200, from Texas Instruments. > > > > The J7200 SoC is a part of the K3 Multicore SoC architecture platform. > > It is targeted for for automotive gateway, vehicle compute systems, > > Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. > > The SoC aims to meet the complex processing needs of modern embedded products. > > > > See J7200 Technical Reference Manual (SPRUIU1, June 2020) > > for further details: https://www.ti.com/lit/pdf/spruiu1 > > > > Changes since v1: > > - Swapped Patch 1 and 2 as suggested by Nishanth. > > - Added description for each SoC in yaml bindings. > > > > Testing: > > - ./scripts/checkpatch --strict > > - Few warningns about Line length exceeding 100 columns. > > But these are corresponding to comments > > - v8make dtbs_check > > - DT_SCHEMA_FLAGS="-u" > > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > > v8make dtbs_check > > - DT_SCHEMA_FLAGS="-u" > > DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" > > v8make dt_binding_check > > This series has been lying around for soo long with no major comments. It will > be nice to get this merged. I understand we are waiting for Acks on yaml > documentation but it would be bad to miss a merge window for a new platform > because we are waiting for Acks on yaml conversion. I do require Rob / DT maintainer to ack the DT yaml conversion and the j7200 binding addition. Besides yaml and compatibility acks, there are a few ancillary comments to fix up.. Kconfig -> I think we should either stay with status quo and create a new config option per SoC OR rename the config to be generic (using j7200 with j721e SoC config is not very consistent). In addition, around the stuff that is going to next in parallel, the dts is generating additional warnings as well (DSS etc). I think it might be easier if we wait for DT maintainer ack on bindings prior to giving further cosmetic comments (To allow for any additional changes to come in to -next).
On 07/09/20 7:44 pm, Nishanth Menon wrote: > On 17:32-20200907, Lokesh Vutla wrote: >> Hi, >> >> On 27/08/20 12:21 pm, Lokesh Vutla wrote: >>> This series adds initial support for latest new SoC, J7200, from Texas Instruments. >>> >>> The J7200 SoC is a part of the K3 Multicore SoC architecture platform. >>> It is targeted for for automotive gateway, vehicle compute systems, >>> Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. >>> The SoC aims to meet the complex processing needs of modern embedded products. >>> >>> See J7200 Technical Reference Manual (SPRUIU1, June 2020) >>> for further details: https://www.ti.com/lit/pdf/spruiu1 >>> >>> Changes since v1: >>> - Swapped Patch 1 and 2 as suggested by Nishanth. >>> - Added description for each SoC in yaml bindings. >>> >>> Testing: >>> - ./scripts/checkpatch --strict >>> - Few warningns about Line length exceeding 100 columns. >>> But these are corresponding to comments >>> - v8make dtbs_check >>> - DT_SCHEMA_FLAGS="-u" >>> DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" >>> v8make dtbs_check >>> - DT_SCHEMA_FLAGS="-u" >>> DT_SCHEMA_FILES="Documentation/devicetree/bindings/arm/ti/k3.yaml" >>> v8make dt_binding_check >> >> This series has been lying around for soo long with no major comments. It will >> be nice to get this merged. I understand we are waiting for Acks on yaml >> documentation but it would be bad to miss a merge window for a new platform >> because we are waiting for Acks on yaml conversion. > > I do require Rob / DT maintainer to ack the DT yaml conversion and the > j7200 binding addition. > > Besides yaml and compatibility acks, there are a few ancillary > comments to fix up.. Kconfig -> I think we should either stay with > status quo and create a new config option per SoC OR rename the > config to be generic (using j7200 with j721e SoC config is not very Please suggest your preference here. I guess separate defconfig for J7200? > consistent). In addition, around the stuff that is going to next in > parallel, the dts is generating additional warnings as well (DSS hmm..there is no DSS being added in this series. There is one checkpatch warning for PATCH 1: WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst This can be ignored. > etc). I think it might be easier if we wait for DT maintainer ack on > bindings prior to giving further cosmetic comments (To allow for any > additional changes to come in to -next). > okay. Thanks and regards, Lokesh
On 19:53-20200907, Lokesh Vutla wrote: [... I should have responded to the correct patch..] > > Besides yaml and compatibility acks, there are a few ancillary > > comments to fix up.. Kconfig -> I think we should either stay with > > status quo and create a new config option per SoC OR rename the > > config to be generic (using j7200 with j721e SoC config is not very > > Please suggest your preference here. I guess separate defconfig for J7200? I was just scanning through remaining arm64 additions to see what others have done. We seem to have two options here: a) Just use ARCH_K3 and no specific SoC configs b) Specific SoC configs In both cases, use += instead of \ to incrementally add dtbs We have been going with (b) so far, Tero: any specific preference here? (a) has the aspect of simplicity and reduced dependencies. (b) Allows downstream kernels to save just a little bit and focus purely on SoC of interest.
On 08/09/2020 02:48, Nishanth Menon wrote: > On 19:53-20200907, Lokesh Vutla wrote: > > [... I should have responded to the correct patch..] >>> Besides yaml and compatibility acks, there are a few ancillary >>> comments to fix up.. Kconfig -> I think we should either stay with >>> status quo and create a new config option per SoC OR rename the >>> config to be generic (using j7200 with j721e SoC config is not very >> >> Please suggest your preference here. I guess separate defconfig for J7200? > > > I was just scanning through remaining arm64 additions to see what others have > done. We seem to have two options here: > a) Just use ARCH_K3 and no specific SoC configs > b) Specific SoC configs > In both cases, use += instead of \ to incrementally add dtbs > > We have been going with (b) so far, Tero: any specific preference here? > > (a) has the aspect of simplicity and reduced dependencies. > (b) Allows downstream kernels to save just a little bit and focus purely > on SoC of interest. If possible, I think we should aim for a) at least for now. We have the soc type detection code in place anyways that can be used on driver level. Creating compile time flags should be avoided imo as much as possible and just go with runtime detection. I can't see why saving maybe a megabyte of memory with SoC specific kernels would be of any importance on K3 arch with the memory amounts we have in our disposal. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 12:55-20200908, Tero Kristo wrote: > On 08/09/2020 02:48, Nishanth Menon wrote: > > On 19:53-20200907, Lokesh Vutla wrote: > > > > [... I should have responded to the correct patch..] > > > > Besides yaml and compatibility acks, there are a few ancillary > > > > comments to fix up.. Kconfig -> I think we should either stay with > > > > status quo and create a new config option per SoC OR rename the > > > > config to be generic (using j7200 with j721e SoC config is not very > > > > > > Please suggest your preference here. I guess separate defconfig for J7200? > > > > > > I was just scanning through remaining arm64 additions to see what others have > > done. We seem to have two options here: > > a) Just use ARCH_K3 and no specific SoC configs > > b) Specific SoC configs > > In both cases, use += instead of \ to incrementally add dtbs > > > > We have been going with (b) so far, Tero: any specific preference here? > > > > (a) has the aspect of simplicity and reduced dependencies. > > (b) Allows downstream kernels to save just a little bit and focus purely > > on SoC of interest. > > If possible, I think we should aim for a) at least for now. We have the soc > type detection code in place anyways that can be used on driver level. > Creating compile time flags should be avoided imo as much as possible and > just go with runtime detection. I can't see why saving maybe a megabyte of > memory with SoC specific kernels would be of any importance on K3 arch with > the memory amounts we have in our disposal. Agreed on (a). I see one other user (SND) beyond dtb Makefile, So, to order this right, lets first switch the users over from SOC config builds to ARCH_K3, before we drop the Kconfig definition/defconfig update in a follow on rc/version.