* [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17
@ 2021-12-17 17:28 ` Vignesh Raghavendra
0 siblings, 0 replies; 18+ messages in thread
From: Vignesh Raghavendra @ 2021-12-17 17:28 UTC (permalink / raw)
To: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC
Cc: Vignesh Raghavendra, arm, Tero Kristo, linux-arm-kernel, linux-kernel
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17
for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c:
arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530)
----------------------------------------------------------------
ARM64 defconfig changes for TI K3 platforms for v5.17 merge window:
- Increase No. of 8250 UARTs supported in System to 16 for J721s2
- Enable USB, PCIe and SERDES drivers on TI K3 SoC
----------------------------------------------------------------
Aswath Govindraju (1):
arm64: defconfig: Increase the maximum number of 8250/16550 serial ports
Vignesh Raghavendra (1):
arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC
arch/arm64/configs/defconfig | 13 ++++++++++
1 file changed, 13 insertions(+)
^ permalink raw reply [flat|nested] 18+ messages in thread* [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-17 17:28 ` Vignesh Raghavendra 0 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-17 17:28 UTC (permalink / raw) To: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC Cc: Vignesh Raghavendra, arm, Tero Kristo, linux-arm-kernel, linux-kernel The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) ---------------------------------------------------------------- ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: - Increase No. of 8250 UARTs supported in System to 16 for J721s2 - Enable USB, PCIe and SERDES drivers on TI K3 SoC ---------------------------------------------------------------- Aswath Govindraju (1): arm64: defconfig: Increase the maximum number of 8250/16550 serial ports Vignesh Raghavendra (1): arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC arch/arm64/configs/defconfig | 13 ++++++++++ 1 file changed, 13 insertions(+) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [GIT PULL 2/2] arm64: dts: TI K3 updates for v5.17 2021-12-17 17:28 ` Vignesh Raghavendra @ 2021-12-17 17:28 ` Vignesh Raghavendra -1 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-17 17:28 UTC (permalink / raw) To: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC Cc: Vignesh Raghavendra, arm, Tero Kristo, linux-arm-kernel, linux-kernel Hi, Please pull the device tree changes for TI K3 platforms for v5.17. Please note: This adds a dtbs_check warning due to missing YAML binding for pinctrl-single compatible. There also a checkpatch error for complex macro usage in dt-bindings header defining pinmux marco which is harmless. The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v5.17 for you to fetch changes up to effb32e931dd4feb8aa3cee7b5b4ddda43c8b701: arch: arm64: ti: Add support J721S2 Common Processor Board (2021-12-13 23:21:22 +0530) ---------------------------------------------------------------- Devicetree changes for TI K3 platforms for v5.17 merge window: * New Platforms: - J721s2 SoC, SoM and Common Processor Board support * New features: - CAN support on AM64 EVM and SK - TimeSync Router on AM64 * Fixes: - Correct d-cache-sets info on J7200 - Fix L2 cache-sets value for J721e/J7200/AM64 - Fixes for dtbs_check warnings wrt serdes_ln_ctrl node on J721e/J7200 - Disable McASP on IoT2050 board to fix dtbs_check warnings ---------------------------------------------------------------- Aswath Govindraju (8): arm64: dts: ti: am654-base-board/am65-iot2050-common: Disable mcan nodes arm64: dts: ti: k3-am64-main: Add support for MCAN arm64: dts: ti: k3-am642-evm/sk: Add support for main domain mcan nodes in EVM and disable them on SK dt-bindings: arm: ti: Add bindings for J721s2 SoC dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2 arm64: dts: ti: Add initial support for J721S2 SoC arm64: dts: ti: Add initial support for J721S2 System on Module arch: arm64: ti: Add support J721S2 Common Processor Board Christian Gmeiner (1): arm64: dts: ti: k3-am64-main: add timesync router node Faiz Abbas (3): arm64: dts: ti: k3-am65-mcu: Add Support for MCAN arm64: dts: ti: k3-j721e: Add support for MCAN nodes arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu and main mcan nodes Jayesh Choudhary (1): arm64: dts: ti: iot2050: Disable mcasp nodes at dtsi level Kishon Vijay Abraham I (2): arm64: dts: ti: j7200-main: Fix 'dtbs_check' serdes_ln_ctrl node arm64: dts: ti: j721e-main: Fix 'dtbs_check' in serdes_ln_ctrl node Nishanth Menon (4): arm64: dts: ti: k3-am642: Fix the L2 cache sets arm64: dts: ti: k3-j7200: Fix the L2 cache sets arm64: dts: ti: k3-j721e: Fix the L2 cache sets arm64: dts: ti: k3-j7200: Correct the d-cache-sets info Peng Fan (1): arm64: dts: ti: k3-j721e: correct cache-sets info Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 + arch/arm64/boot/dts/ti/Makefile | 2 + arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 36 + arch/arm64/boot/dts/ti/k3-am642-evm.dts | 40 + arch/arm64/boot/dts/ti/k3-am642-sk.dts | 8 + arch/arm64/boot/dts/ti/k3-am642.dtsi | 2 +- arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 20 + arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 + arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 8 + arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 2 +- arch/arm64/boot/dts/ti/k3-j7200.dtsi | 6 +- arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 155 ++ arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 198 +- arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 28 + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 6 +- arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 421 +++++ arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 937 ++++++++++ arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 302 +++ arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 175 ++ arch/arm64/boot/dts/ti/k3-j721s2.dtsi | 189 ++ include/dt-bindings/pinctrl/k3.h | 3 + 21 files changed, 2565 insertions(+), 9 deletions(-) create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2.dtsi ^ permalink raw reply [flat|nested] 18+ messages in thread
* [GIT PULL 2/2] arm64: dts: TI K3 updates for v5.17 @ 2021-12-17 17:28 ` Vignesh Raghavendra 0 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-17 17:28 UTC (permalink / raw) To: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC Cc: Vignesh Raghavendra, arm, Tero Kristo, linux-arm-kernel, linux-kernel Hi, Please pull the device tree changes for TI K3 platforms for v5.17. Please note: This adds a dtbs_check warning due to missing YAML binding for pinctrl-single compatible. There also a checkpatch error for complex macro usage in dt-bindings header defining pinmux marco which is harmless. The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v5.17 for you to fetch changes up to effb32e931dd4feb8aa3cee7b5b4ddda43c8b701: arch: arm64: ti: Add support J721S2 Common Processor Board (2021-12-13 23:21:22 +0530) ---------------------------------------------------------------- Devicetree changes for TI K3 platforms for v5.17 merge window: * New Platforms: - J721s2 SoC, SoM and Common Processor Board support * New features: - CAN support on AM64 EVM and SK - TimeSync Router on AM64 * Fixes: - Correct d-cache-sets info on J7200 - Fix L2 cache-sets value for J721e/J7200/AM64 - Fixes for dtbs_check warnings wrt serdes_ln_ctrl node on J721e/J7200 - Disable McASP on IoT2050 board to fix dtbs_check warnings ---------------------------------------------------------------- Aswath Govindraju (8): arm64: dts: ti: am654-base-board/am65-iot2050-common: Disable mcan nodes arm64: dts: ti: k3-am64-main: Add support for MCAN arm64: dts: ti: k3-am642-evm/sk: Add support for main domain mcan nodes in EVM and disable them on SK dt-bindings: arm: ti: Add bindings for J721s2 SoC dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721S2 arm64: dts: ti: Add initial support for J721S2 SoC arm64: dts: ti: Add initial support for J721S2 System on Module arch: arm64: ti: Add support J721S2 Common Processor Board Christian Gmeiner (1): arm64: dts: ti: k3-am64-main: add timesync router node Faiz Abbas (3): arm64: dts: ti: k3-am65-mcu: Add Support for MCAN arm64: dts: ti: k3-j721e: Add support for MCAN nodes arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu and main mcan nodes Jayesh Choudhary (1): arm64: dts: ti: iot2050: Disable mcasp nodes at dtsi level Kishon Vijay Abraham I (2): arm64: dts: ti: j7200-main: Fix 'dtbs_check' serdes_ln_ctrl node arm64: dts: ti: j721e-main: Fix 'dtbs_check' in serdes_ln_ctrl node Nishanth Menon (4): arm64: dts: ti: k3-am642: Fix the L2 cache sets arm64: dts: ti: k3-j7200: Fix the L2 cache sets arm64: dts: ti: k3-j721e: Fix the L2 cache sets arm64: dts: ti: k3-j7200: Correct the d-cache-sets info Peng Fan (1): arm64: dts: ti: k3-j721e: correct cache-sets info Documentation/devicetree/bindings/arm/ti/k3.yaml | 6 + arch/arm64/boot/dts/ti/Makefile | 2 + arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 36 + arch/arm64/boot/dts/ti/k3-am642-evm.dts | 40 + arch/arm64/boot/dts/ti/k3-am642-sk.dts | 8 + arch/arm64/boot/dts/ti/k3-am642.dtsi | 2 +- arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 20 + arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 30 + arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 8 + arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 2 +- arch/arm64/boot/dts/ti/k3-j7200.dtsi | 6 +- arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts | 155 ++ arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 198 +- arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 28 + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 6 +- arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 421 +++++ arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 937 ++++++++++ arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 302 +++ arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 175 ++ arch/arm64/boot/dts/ti/k3-j721s2.dtsi | 189 ++ include/dt-bindings/pinctrl/k3.h | 3 + 21 files changed, 2565 insertions(+), 9 deletions(-) create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2.dtsi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-17 17:28 ` Vignesh Raghavendra @ 2021-12-20 15:27 ` Arnd Bergmann -1 siblings, 0 replies; 18+ messages in thread From: Arnd Bergmann @ 2021-12-20 15:27 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: > > Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 > > for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: > > arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) > > ---------------------------------------------------------------- > ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: > > - Increase No. of 8250 UARTs supported in System to 16 for J721s2 This looks a little excessive, I'm holding off on this pull request for now, as I'm not sure exactly what the downsides are. I see that your dtsi file has + aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + serial4 = &main_uart2; + serial5 = &main_uart3; + serial6 = &main_uart4; + serial7 = &main_uart5; + serial8 = &main_uart6; + serial9 = &main_uart7; + serial10 = &main_uart8; + serial11 = &main_uart9; + mmc0 = &main_sdhci0; + mmc1 = &main_sdhci1; + can0 = &main_mcan16; + can1 = &mcu_mcan0; + can2 = &mcu_mcan1; + can3 = &main_mcan3; + can4 = &main_mcan5; + }; which I think is the underlying problem here. The aliases are really meant to be board specific, and I would assume that none of the boards actually uses all the uart and can bus devices, usually this isn't even possible due to pinctrl constraints, so please follow up by moving these to the .dts files listing only the actually used devices instead of working around it in the defconfig. > - Enable USB, PCIe and SERDES drivers on TI K3 SoC I see the PCIe driver is built-in here. Is that necessary for booting? If not, please make it a loadable module. Arnd ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-20 15:27 ` Arnd Bergmann 0 siblings, 0 replies; 18+ messages in thread From: Arnd Bergmann @ 2021-12-20 15:27 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Nishanth Menon, Arnd Bergmann, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: > > Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 > > for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: > > arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) > > ---------------------------------------------------------------- > ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: > > - Increase No. of 8250 UARTs supported in System to 16 for J721s2 This looks a little excessive, I'm holding off on this pull request for now, as I'm not sure exactly what the downsides are. I see that your dtsi file has + aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + serial4 = &main_uart2; + serial5 = &main_uart3; + serial6 = &main_uart4; + serial7 = &main_uart5; + serial8 = &main_uart6; + serial9 = &main_uart7; + serial10 = &main_uart8; + serial11 = &main_uart9; + mmc0 = &main_sdhci0; + mmc1 = &main_sdhci1; + can0 = &main_mcan16; + can1 = &mcu_mcan0; + can2 = &mcu_mcan1; + can3 = &main_mcan3; + can4 = &main_mcan5; + }; which I think is the underlying problem here. The aliases are really meant to be board specific, and I would assume that none of the boards actually uses all the uart and can bus devices, usually this isn't even possible due to pinctrl constraints, so please follow up by moving these to the .dts files listing only the actually used devices instead of working around it in the defconfig. > - Enable USB, PCIe and SERDES drivers on TI K3 SoC I see the PCIe driver is built-in here. Is that necessary for booting? If not, please make it a loadable module. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-20 15:27 ` Arnd Bergmann @ 2021-12-20 17:40 ` Vignesh Raghavendra -1 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-20 17:40 UTC (permalink / raw) To: Arnd Bergmann Cc: Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List Hi Arnd, On 20/12/21 8:57 pm, Arnd Bergmann wrote: > On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> >> The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: >> >> Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) >> >> are available in the Git repository at: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 >> >> for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: >> >> arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) >> >> ---------------------------------------------------------------- >> ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: >> >> - Increase No. of 8250 UARTs supported in System to 16 for J721s2 > > This looks a little excessive, I'm holding off on this pull request > for now, as I'm > not sure exactly what the downsides are. > > I see that your dtsi file has > > + aliases { > + serial0 = &wkup_uart0; > + serial1 = &mcu_uart0; > + serial2 = &main_uart0; > + serial3 = &main_uart1; > + serial4 = &main_uart2; > + serial5 = &main_uart3; > + serial6 = &main_uart4; > + serial7 = &main_uart5; > + serial8 = &main_uart6; > + serial9 = &main_uart7; > + serial10 = &main_uart8; > + serial11 = &main_uart9; > + mmc0 = &main_sdhci0; > + mmc1 = &main_sdhci1; > + can0 = &main_mcan16; > + can1 = &mcu_mcan0; > + can2 = &mcu_mcan1; > + can3 = &main_mcan3; > + can4 = &main_mcan5; > + }; > > which I think is the underlying problem here. The aliases are really meant to > be board specific, and I would assume that none of the boards actually > uses all the > uart and can bus devices, usually this isn't even possible due to pinctrl > constraints, so please follow up by moving these to the .dts files listing only > the actually used devices instead of working around it in the defconfig. Yes indeed, aliases can be trimmed and moved to board dts. With that, defconfig patch in question can be dropped. Thanks for the hint. > >> - Enable USB, PCIe and SERDES drivers on TI K3 SoC > > I see the PCIe driver is built-in here. Is that necessary for booting? > If not, please > make it a loadable module. > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as modules (symbols are bool only). PCIe is not necessary for basic boot either. So, I can drop these configs until these drivers are build able as modules, if you prefer. Will respin the PRs with comments addressed. Sorry for the trouble. Regards Vignesh ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-20 17:40 ` Vignesh Raghavendra 0 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-20 17:40 UTC (permalink / raw) To: Arnd Bergmann Cc: Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List Hi Arnd, On 20/12/21 8:57 pm, Arnd Bergmann wrote: > On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> >> The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: >> >> Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) >> >> are available in the Git repository at: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 >> >> for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: >> >> arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) >> >> ---------------------------------------------------------------- >> ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: >> >> - Increase No. of 8250 UARTs supported in System to 16 for J721s2 > > This looks a little excessive, I'm holding off on this pull request > for now, as I'm > not sure exactly what the downsides are. > > I see that your dtsi file has > > + aliases { > + serial0 = &wkup_uart0; > + serial1 = &mcu_uart0; > + serial2 = &main_uart0; > + serial3 = &main_uart1; > + serial4 = &main_uart2; > + serial5 = &main_uart3; > + serial6 = &main_uart4; > + serial7 = &main_uart5; > + serial8 = &main_uart6; > + serial9 = &main_uart7; > + serial10 = &main_uart8; > + serial11 = &main_uart9; > + mmc0 = &main_sdhci0; > + mmc1 = &main_sdhci1; > + can0 = &main_mcan16; > + can1 = &mcu_mcan0; > + can2 = &mcu_mcan1; > + can3 = &main_mcan3; > + can4 = &main_mcan5; > + }; > > which I think is the underlying problem here. The aliases are really meant to > be board specific, and I would assume that none of the boards actually > uses all the > uart and can bus devices, usually this isn't even possible due to pinctrl > constraints, so please follow up by moving these to the .dts files listing only > the actually used devices instead of working around it in the defconfig. Yes indeed, aliases can be trimmed and moved to board dts. With that, defconfig patch in question can be dropped. Thanks for the hint. > >> - Enable USB, PCIe and SERDES drivers on TI K3 SoC > > I see the PCIe driver is built-in here. Is that necessary for booting? > If not, please > make it a loadable module. > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as modules (symbols are bool only). PCIe is not necessary for basic boot either. So, I can drop these configs until these drivers are build able as modules, if you prefer. Will respin the PRs with comments addressed. Sorry for the trouble. Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-20 17:40 ` Vignesh Raghavendra @ 2021-12-21 15:32 ` Tom Rini -1 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-21 15:32 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > Hi Arnd, > > On 20/12/21 8:57 pm, Arnd Bergmann wrote: > > On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> > >> The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: > >> > >> Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) > >> > >> are available in the Git repository at: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 > >> > >> for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: > >> > >> arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) > >> > >> ---------------------------------------------------------------- > >> ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: > >> > >> - Increase No. of 8250 UARTs supported in System to 16 for J721s2 > > > > This looks a little excessive, I'm holding off on this pull request > > for now, as I'm > > not sure exactly what the downsides are. > > > > I see that your dtsi file has > > > > + aliases { > > + serial0 = &wkup_uart0; > > + serial1 = &mcu_uart0; > > + serial2 = &main_uart0; > > + serial3 = &main_uart1; > > + serial4 = &main_uart2; > > + serial5 = &main_uart3; > > + serial6 = &main_uart4; > > + serial7 = &main_uart5; > > + serial8 = &main_uart6; > > + serial9 = &main_uart7; > > + serial10 = &main_uart8; > > + serial11 = &main_uart9; > > + mmc0 = &main_sdhci0; > > + mmc1 = &main_sdhci1; > > + can0 = &main_mcan16; > > + can1 = &mcu_mcan0; > > + can2 = &mcu_mcan1; > > + can3 = &main_mcan3; > > + can4 = &main_mcan5; > > + }; > > > > which I think is the underlying problem here. The aliases are really meant to > > be board specific, and I would assume that none of the boards actually > > uses all the > > uart and can bus devices, usually this isn't even possible due to pinctrl > > constraints, so please follow up by moving these to the .dts files listing only > > the actually used devices instead of working around it in the defconfig. > > Yes indeed, aliases can be trimmed and moved to board dts. With that, > defconfig patch in question can be dropped. Thanks for the hint. > > > > >> - Enable USB, PCIe and SERDES drivers on TI K3 SoC > > > > I see the PCIe driver is built-in here. Is that necessary for booting? > > If not, please > > make it a loadable module. > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > modules (symbols are bool only). > PCIe is not necessary for basic boot either. So, I can drop these > configs until these drivers are build able as modules, if you prefer. Is PCIe required for basic boot for the other platforms in the defconfig which do enable it in the defconfig today? It is required for non-basic boot (whatever storage one puts in a PCIe slot). If someone is going to be fixing the PCIe driver to be able to be modular, that's fine too but I ran in to this trying to see what works out of the box in the defconfig, on this platform and hit both of these rather large omissions. -- Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-21 15:32 ` Tom Rini 0 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-21 15:32 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > Hi Arnd, > > On 20/12/21 8:57 pm, Arnd Bergmann wrote: > > On Fri, Dec 17, 2021 at 6:28 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> > >> The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: > >> > >> Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) > >> > >> are available in the Git repository at: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-config-for-v5.17 > >> > >> for you to fetch changes up to 8d73aedca28cbed8030067b0d9423a0694139b9c: > >> > >> arm64: defconfig: Enable USB, PCIe and SERDES drivers for TI K3 SoC (2021-12-14 16:22:25 +0530) > >> > >> ---------------------------------------------------------------- > >> ARM64 defconfig changes for TI K3 platforms for v5.17 merge window: > >> > >> - Increase No. of 8250 UARTs supported in System to 16 for J721s2 > > > > This looks a little excessive, I'm holding off on this pull request > > for now, as I'm > > not sure exactly what the downsides are. > > > > I see that your dtsi file has > > > > + aliases { > > + serial0 = &wkup_uart0; > > + serial1 = &mcu_uart0; > > + serial2 = &main_uart0; > > + serial3 = &main_uart1; > > + serial4 = &main_uart2; > > + serial5 = &main_uart3; > > + serial6 = &main_uart4; > > + serial7 = &main_uart5; > > + serial8 = &main_uart6; > > + serial9 = &main_uart7; > > + serial10 = &main_uart8; > > + serial11 = &main_uart9; > > + mmc0 = &main_sdhci0; > > + mmc1 = &main_sdhci1; > > + can0 = &main_mcan16; > > + can1 = &mcu_mcan0; > > + can2 = &mcu_mcan1; > > + can3 = &main_mcan3; > > + can4 = &main_mcan5; > > + }; > > > > which I think is the underlying problem here. The aliases are really meant to > > be board specific, and I would assume that none of the boards actually > > uses all the > > uart and can bus devices, usually this isn't even possible due to pinctrl > > constraints, so please follow up by moving these to the .dts files listing only > > the actually used devices instead of working around it in the defconfig. > > Yes indeed, aliases can be trimmed and moved to board dts. With that, > defconfig patch in question can be dropped. Thanks for the hint. > > > > >> - Enable USB, PCIe and SERDES drivers on TI K3 SoC > > > > I see the PCIe driver is built-in here. Is that necessary for booting? > > If not, please > > make it a loadable module. > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > modules (symbols are bool only). > PCIe is not necessary for basic boot either. So, I can drop these > configs until these drivers are build able as modules, if you prefer. Is PCIe required for basic boot for the other platforms in the defconfig which do enable it in the defconfig today? It is required for non-basic boot (whatever storage one puts in a PCIe slot). If someone is going to be fixing the PCIe driver to be able to be modular, that's fine too but I ran in to this trying to see what works out of the box in the defconfig, on this platform and hit both of these rather large omissions. -- Tom _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-21 15:32 ` Tom Rini @ 2021-12-21 15:55 ` Arnd Bergmann -1 siblings, 0 replies; 18+ messages in thread From: Arnd Bergmann @ 2021-12-21 15:55 UTC (permalink / raw) To: Tom Rini Cc: Vignesh Raghavendra, Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > > modules (symbols are bool only). > > PCIe is not necessary for basic boot either. So, I can drop these > > configs until these drivers are build able as modules, if you prefer. > > Is PCIe required for basic boot for the other platforms in the defconfig > which do enable it in the defconfig today? It is required for non-basic > boot (whatever storage one puts in a PCIe slot). If someone is going to > be fixing the PCIe driver to be able to be modular, that's fine too but > I ran in to this trying to see what works out of the box in the > defconfig, on this platform and hit both of these rather large > omissions. If PCI is often used for storage, then that's ok. There are a number of other platforms where PCIe is only used for wireless networking or other secondary devices, but they are still built-in because they got added before it became possible for PCIe host drivers to be loadable modules. I would like to eventually go through and turn those into loadable modules, but for the moment it would be good to only add built-in drivers where this is actually useful. Arnd ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-21 15:55 ` Arnd Bergmann 0 siblings, 0 replies; 18+ messages in thread From: Arnd Bergmann @ 2021-12-21 15:55 UTC (permalink / raw) To: Tom Rini Cc: Vignesh Raghavendra, Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > > modules (symbols are bool only). > > PCIe is not necessary for basic boot either. So, I can drop these > > configs until these drivers are build able as modules, if you prefer. > > Is PCIe required for basic boot for the other platforms in the defconfig > which do enable it in the defconfig today? It is required for non-basic > boot (whatever storage one puts in a PCIe slot). If someone is going to > be fixing the PCIe driver to be able to be modular, that's fine too but > I ran in to this trying to see what works out of the box in the > defconfig, on this platform and hit both of these rather large > omissions. If PCI is often used for storage, then that's ok. There are a number of other platforms where PCIe is only used for wireless networking or other secondary devices, but they are still built-in because they got added before it became possible for PCIe host drivers to be loadable modules. I would like to eventually go through and turn those into loadable modules, but for the moment it would be good to only add built-in drivers where this is actually useful. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-21 15:55 ` Arnd Bergmann @ 2021-12-21 16:09 ` Tom Rini -1 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-21 16:09 UTC (permalink / raw) To: Arnd Bergmann Cc: Vignesh Raghavendra, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 2473 bytes --] On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > > On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > > > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > > > modules (symbols are bool only). > > > PCIe is not necessary for basic boot either. So, I can drop these > > > configs until these drivers are build able as modules, if you prefer. > > > > Is PCIe required for basic boot for the other platforms in the defconfig > > which do enable it in the defconfig today? It is required for non-basic > > boot (whatever storage one puts in a PCIe slot). If someone is going to > > be fixing the PCIe driver to be able to be modular, that's fine too but > > I ran in to this trying to see what works out of the box in the > > defconfig, on this platform and hit both of these rather large > > omissions. > > If PCI is often used for storage, then that's ok. There are a number of > other platforms where PCIe is only used for wireless networking or > other secondary devices, but they are still built-in because they got > added before it became possible for PCIe host drivers to be loadable > modules. I would like to eventually go through and turn those into > loadable modules, but for the moment it would be good to only add > built-in drivers where this is actually useful. That's good to know. My question tho is, what's actually useful? The EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super useful, arbitrary devices are expected to work" or "not useful, arbitrary devices are not expected to work". Is the functional definition of what's in the defconfig vs left up to users, distributions, etc, to find and enabled defined, or at least well known / explained somewhere? Where I'm coming from on this is that these platforms practically are, and can be SystemReady IR certified. So what's needed here to ensure there's a good experience distros to enable what needs enabling for full functionality? What we hit was "lets throw some stuff at this board to test it out and.. wait, PCIe isn't enabled at all? USB host isn't enabled at all?" And all that said, if someone is going to be fixing the PCIe drivers to be enabled as modules soon, and just getting it handled that way in the next appropriately timed merge window, OK, fine, good enough. -- Tom [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-21 16:09 ` Tom Rini 0 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-21 16:09 UTC (permalink / raw) To: Arnd Bergmann Cc: Vignesh Raghavendra, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2473 bytes --] On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > > On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > > > > > > Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > > > modules (symbols are bool only). > > > PCIe is not necessary for basic boot either. So, I can drop these > > > configs until these drivers are build able as modules, if you prefer. > > > > Is PCIe required for basic boot for the other platforms in the defconfig > > which do enable it in the defconfig today? It is required for non-basic > > boot (whatever storage one puts in a PCIe slot). If someone is going to > > be fixing the PCIe driver to be able to be modular, that's fine too but > > I ran in to this trying to see what works out of the box in the > > defconfig, on this platform and hit both of these rather large > > omissions. > > If PCI is often used for storage, then that's ok. There are a number of > other platforms where PCIe is only used for wireless networking or > other secondary devices, but they are still built-in because they got > added before it became possible for PCIe host drivers to be loadable > modules. I would like to eventually go through and turn those into > loadable modules, but for the moment it would be good to only add > built-in drivers where this is actually useful. That's good to know. My question tho is, what's actually useful? The EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super useful, arbitrary devices are expected to work" or "not useful, arbitrary devices are not expected to work". Is the functional definition of what's in the defconfig vs left up to users, distributions, etc, to find and enabled defined, or at least well known / explained somewhere? Where I'm coming from on this is that these platforms practically are, and can be SystemReady IR certified. So what's needed here to ensure there's a good experience distros to enable what needs enabling for full functionality? What we hit was "lets throw some stuff at this board to test it out and.. wait, PCIe isn't enabled at all? USB host isn't enabled at all?" And all that said, if someone is going to be fixing the PCIe drivers to be enabled as modules soon, and just getting it handled that way in the next appropriately timed merge window, OK, fine, good enough. -- Tom [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-21 16:09 ` Tom Rini @ 2021-12-22 7:26 ` Vignesh Raghavendra -1 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-22 7:26 UTC (permalink / raw) To: Tom Rini, Arnd Bergmann Cc: Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List, KISHON VIJAY ABRAHAM On 21/12/21 9:39 pm, Tom Rini wrote: > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: >>>> >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as >>>> modules (symbols are bool only). >>>> PCIe is not necessary for basic boot either. So, I can drop these >>>> configs until these drivers are build able as modules, if you prefer. >>> >>> Is PCIe required for basic boot for the other platforms in the defconfig >>> which do enable it in the defconfig today? It is required for non-basic >>> boot (whatever storage one puts in a PCIe slot). If someone is going to >>> be fixing the PCIe driver to be able to be modular, that's fine too but >>> I ran in to this trying to see what works out of the box in the >>> defconfig, on this platform and hit both of these rather large >>> omissions. >> >> If PCI is often used for storage, then that's ok. There are a number of >> other platforms where PCIe is only used for wireless networking or >> other secondary devices, but they are still built-in because they got >> added before it became possible for PCIe host drivers to be loadable >> modules. I would like to eventually go through and turn those into >> loadable modules, but for the moment it would be good to only add >> built-in drivers where this is actually useful. > > That's good to know. My question tho is, what's actually useful? The > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > useful, arbitrary devices are expected to work" or "not useful, > arbitrary devices are not expected to work". Is the functional > definition of what's in the defconfig vs left up to users, > distributions, etc, to find and enabled defined, or at least well known > / explained somewhere? Where I'm coming from on this is that these > platforms practically are, and can be SystemReady IR certified. So > what's needed here to ensure there's a good experience distros to enable > what needs enabling for full functionality? What we hit was "lets throw > some stuff at this board to test it out and.. wait, PCIe isn't enabled > at all? USB host isn't enabled at all?" > > And all that said, if someone is going to be fixing the PCIe drivers to > be enabled as modules soon, and just getting it handled that way in the > next appropriately timed merge window, OK, fine, good enough. > Looks like its not a big effort to convert J7 PCIe driver to build as module and can be done for v5.18 Merge Window. So how about we enable only USB controller drivers now and then enable PCIe after its build-able as module? Regards Vignesh ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-22 7:26 ` Vignesh Raghavendra 0 siblings, 0 replies; 18+ messages in thread From: Vignesh Raghavendra @ 2021-12-22 7:26 UTC (permalink / raw) To: Tom Rini, Arnd Bergmann Cc: Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List, KISHON VIJAY ABRAHAM On 21/12/21 9:39 pm, Tom Rini wrote: > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: >>>> >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as >>>> modules (symbols are bool only). >>>> PCIe is not necessary for basic boot either. So, I can drop these >>>> configs until these drivers are build able as modules, if you prefer. >>> >>> Is PCIe required for basic boot for the other platforms in the defconfig >>> which do enable it in the defconfig today? It is required for non-basic >>> boot (whatever storage one puts in a PCIe slot). If someone is going to >>> be fixing the PCIe driver to be able to be modular, that's fine too but >>> I ran in to this trying to see what works out of the box in the >>> defconfig, on this platform and hit both of these rather large >>> omissions. >> >> If PCI is often used for storage, then that's ok. There are a number of >> other platforms where PCIe is only used for wireless networking or >> other secondary devices, but they are still built-in because they got >> added before it became possible for PCIe host drivers to be loadable >> modules. I would like to eventually go through and turn those into >> loadable modules, but for the moment it would be good to only add >> built-in drivers where this is actually useful. > > That's good to know. My question tho is, what's actually useful? The > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > useful, arbitrary devices are expected to work" or "not useful, > arbitrary devices are not expected to work". Is the functional > definition of what's in the defconfig vs left up to users, > distributions, etc, to find and enabled defined, or at least well known > / explained somewhere? Where I'm coming from on this is that these > platforms practically are, and can be SystemReady IR certified. So > what's needed here to ensure there's a good experience distros to enable > what needs enabling for full functionality? What we hit was "lets throw > some stuff at this board to test it out and.. wait, PCIe isn't enabled > at all? USB host isn't enabled at all?" > > And all that said, if someone is going to be fixing the PCIe drivers to > be enabled as modules soon, and just getting it handled that way in the > next appropriately timed merge window, OK, fine, good enough. > Looks like its not a big effort to convert J7 PCIe driver to build as module and can be done for v5.18 Merge Window. So how about we enable only USB controller drivers now and then enable PCIe after its build-able as module? Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 2021-12-22 7:26 ` Vignesh Raghavendra @ 2021-12-22 16:40 ` Tom Rini -1 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-22 16:40 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List, KISHON VIJAY ABRAHAM On Wed, Dec 22, 2021 at 12:56:06PM +0530, Vignesh Raghavendra wrote: > > > On 21/12/21 9:39 pm, Tom Rini wrote: > > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > >>>> > >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > >>>> modules (symbols are bool only). > >>>> PCIe is not necessary for basic boot either. So, I can drop these > >>>> configs until these drivers are build able as modules, if you prefer. > >>> > >>> Is PCIe required for basic boot for the other platforms in the defconfig > >>> which do enable it in the defconfig today? It is required for non-basic > >>> boot (whatever storage one puts in a PCIe slot). If someone is going to > >>> be fixing the PCIe driver to be able to be modular, that's fine too but > >>> I ran in to this trying to see what works out of the box in the > >>> defconfig, on this platform and hit both of these rather large > >>> omissions. > >> > >> If PCI is often used for storage, then that's ok. There are a number of > >> other platforms where PCIe is only used for wireless networking or > >> other secondary devices, but they are still built-in because they got > >> added before it became possible for PCIe host drivers to be loadable > >> modules. I would like to eventually go through and turn those into > >> loadable modules, but for the moment it would be good to only add > >> built-in drivers where this is actually useful. > > > > That's good to know. My question tho is, what's actually useful? The > > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > > useful, arbitrary devices are expected to work" or "not useful, > > arbitrary devices are not expected to work". Is the functional > > definition of what's in the defconfig vs left up to users, > > distributions, etc, to find and enabled defined, or at least well known > > / explained somewhere? Where I'm coming from on this is that these > > platforms practically are, and can be SystemReady IR certified. So > > what's needed here to ensure there's a good experience distros to enable > > what needs enabling for full functionality? What we hit was "lets throw > > some stuff at this board to test it out and.. wait, PCIe isn't enabled > > at all? USB host isn't enabled at all?" > > > > And all that said, if someone is going to be fixing the PCIe drivers to > > be enabled as modules soon, and just getting it handled that way in the > > next appropriately timed merge window, OK, fine, good enough. > > > > Looks like its not a big effort to convert J7 PCIe driver to build as > module and can be done for v5.18 Merge Window. So how about we enable > only USB controller drivers now and then enable PCIe after its > build-able as module? Works for me, thanks! -- Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 @ 2021-12-22 16:40 ` Tom Rini 0 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2021-12-22 16:40 UTC (permalink / raw) To: Vignesh Raghavendra Cc: Arnd Bergmann, Nishanth Menon, Olof Johansson, SoC, arm-soc, Tero Kristo, Linux ARM, Linux Kernel Mailing List, KISHON VIJAY ABRAHAM On Wed, Dec 22, 2021 at 12:56:06PM +0530, Vignesh Raghavendra wrote: > > > On 21/12/21 9:39 pm, Tom Rini wrote: > > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > >>>> > >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > >>>> modules (symbols are bool only). > >>>> PCIe is not necessary for basic boot either. So, I can drop these > >>>> configs until these drivers are build able as modules, if you prefer. > >>> > >>> Is PCIe required for basic boot for the other platforms in the defconfig > >>> which do enable it in the defconfig today? It is required for non-basic > >>> boot (whatever storage one puts in a PCIe slot). If someone is going to > >>> be fixing the PCIe driver to be able to be modular, that's fine too but > >>> I ran in to this trying to see what works out of the box in the > >>> defconfig, on this platform and hit both of these rather large > >>> omissions. > >> > >> If PCI is often used for storage, then that's ok. There are a number of > >> other platforms where PCIe is only used for wireless networking or > >> other secondary devices, but they are still built-in because they got > >> added before it became possible for PCIe host drivers to be loadable > >> modules. I would like to eventually go through and turn those into > >> loadable modules, but for the moment it would be good to only add > >> built-in drivers where this is actually useful. > > > > That's good to know. My question tho is, what's actually useful? The > > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > > useful, arbitrary devices are expected to work" or "not useful, > > arbitrary devices are not expected to work". Is the functional > > definition of what's in the defconfig vs left up to users, > > distributions, etc, to find and enabled defined, or at least well known > > / explained somewhere? Where I'm coming from on this is that these > > platforms practically are, and can be SystemReady IR certified. So > > what's needed here to ensure there's a good experience distros to enable > > what needs enabling for full functionality? What we hit was "lets throw > > some stuff at this board to test it out and.. wait, PCIe isn't enabled > > at all? USB host isn't enabled at all?" > > > > And all that said, if someone is going to be fixing the PCIe drivers to > > be enabled as modules soon, and just getting it handled that way in the > > next appropriately timed merge window, OK, fine, good enough. > > > > Looks like its not a big effort to convert J7 PCIe driver to build as > module and can be done for v5.18 Merge Window. So how about we enable > only USB controller drivers now and then enable PCIe after its > build-able as module? Works for me, thanks! -- Tom _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-12-22 16:42 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-17 17:28 [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 Vignesh Raghavendra 2021-12-17 17:28 ` Vignesh Raghavendra 2021-12-17 17:28 ` [GIT PULL 2/2] arm64: dts: TI K3 updates " Vignesh Raghavendra 2021-12-17 17:28 ` Vignesh Raghavendra 2021-12-20 15:27 ` [GIT PULL 1/2] arm64: TI K3 SoC configs changes " Arnd Bergmann 2021-12-20 15:27 ` Arnd Bergmann 2021-12-20 17:40 ` Vignesh Raghavendra 2021-12-20 17:40 ` Vignesh Raghavendra 2021-12-21 15:32 ` Tom Rini 2021-12-21 15:32 ` Tom Rini 2021-12-21 15:55 ` Arnd Bergmann 2021-12-21 15:55 ` Arnd Bergmann 2021-12-21 16:09 ` Tom Rini 2021-12-21 16:09 ` Tom Rini 2021-12-22 7:26 ` Vignesh Raghavendra 2021-12-22 7:26 ` Vignesh Raghavendra 2021-12-22 16:40 ` Tom Rini 2021-12-22 16:40 ` Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.