- 15 Jun, 2023 40 commits
-
-
Nishanth Menon authored
Define the wakeup uart pin-mux for completeness. This allows the device tree usage in bootloader and firmwares that can configure the same appropriately. Signed-off-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20230601183151.1000157-7-nm@ti.comSigned-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Nishanth Menon authored
Enable wakeup_i2c and use un-used pinmux. While at it, describe the board detection eeprom present on the board. Signed-off-by:
-
Nishanth Menon authored
Explicitly define the pinmux rather than depend on bootloader configured pinmux for the platform. Signed-off-by:
-
Nishanth Menon authored
Add product links to get reference to schematics and design files Signed-off-by:
-
Nishanth Menon authored
Enable wakeup_i2c and use un-used pinmux. While at it, describe the board detection eeprom present on the board. Signed-off-by:
-
Nishanth Menon authored
Rather than depend on the default pinmuxes, explicitly describe the pinmux Signed-off-by:
-
Andrew Davis authored
Using a phandle makes it clear which UART we are choosing without needing to resolve through an alias first. Especially useful for boards like the TI J721s2-EVM where the alias is "serial2" but it actually resolves to the 8th UART instance(main_uart8). Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20230601184933.358731-2-afd@ti.comSigned-off-by:
-
Andrew Davis authored
As the binding for "current-speed" states, this should only be used when the baud rate of an attached device cannot be detected. This is the case for our attached on-board USB-to-UART converter used for early kernel console. For all other unconnected/disabled ports this can be configured in userspace later, DT is not the place for device configuration, especially when there are already standard ways to set serial baud in userspace. Remove setting baud for all disabled serial ports and move setting it for the couple enabled ports down into the board files. Signed-off-by:
-
Dasnavis Sabiya authored
Add pinmux required to bring out the i2c and gpios on 40 pin RPi expansion header on AM69 SK board. Signed-off-by:
Dasnavis Sabiya <sabiya.d@ti.com> Signed-off-by:
Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20230602214937.2349545-9-nm@ti.comSigned-off-by:
-
Nishanth Menon authored
Enable wakeup_i2c and use un-used pinmux. While at it, describe the board detection eeprom present on the board. Signed-off-by:
-
Nishanth Menon authored
Add wakeup and MCU uart. This allows the device tree usage in bootloader and firmwares that can configure the same appropriately. Signed-off-by:
-
Nishanth Menon authored
Enable networking for NFS and basic networking functionality. Signed-off-by:
-
Nishanth Menon authored
main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5 SPL attempting to reuse the same definition in the common board detection logic as it looks for the first i2c instance as the bus on which to detect the eeprom to understand the board variant involved. Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0 and potentially space for mcu_i2c instances in the gap for follow on patches. Fixes: 635fb18b ("arch: arm64: dts: Add support for AM69 Starter Kit") Signed-off-by:
-
Nishanth Menon authored
Enable wakeup_i2c and use un-used pinmux. While at it, describe the board detection eeprom present on the board. Signed-off-by:
-
Nishanth Menon authored
Add wakeup and MCU uart. This allows the device tree usage in bootloader and firmwares that can configure the same appropriately. Signed-off-by:
-
Thejasvi Konduru authored
The wkup_pmx register region in j784s4 has multiple non-addressable regions, hence the existing wkup_pmx region is split as follows to avoid the non-addressable regions. The pinctrl node offsets are also corrected as per the newly split wkup_pmx* nodes. wkup_pmx0 -> 13 pins (WKUP_PADCONFIG 0 - 12) wkup_pmx1 -> 11 pins (WKUP_PADCONFIG 14 - 24) wkup_pmx2 -> 72 pins (WKUP_PADCONFIG 26 - 97) wkup_pmx3 -> 1 pin (WKUP_PADCONFIG 100) Fixes: 4664ebd8 ("arm64: dts: ti: Add initial support for J784S4 SoC") Signed-off-by:
Thejasvi Konduru <t-konduru@ti.com> Reviewed-by:
-
Nishanth Menon authored
main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5 SPL attempting to reuse the same definition in the common board detection logic as it looks for the first i2c instance as the bus on which to detect the eeprom to understand the board variant involved. Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0 and potentially space for mcu_i2c instances in the gap for follow on patches. Fixes: e20a06ac ("arm64: dts: ti: Add support for J784S4 EVM board") Signed-off-by:
-
Neha Malcom Francis authored
MAIN_PLL0 has a flag set in DM (Device Manager) that removes it's capability to re-initialise clock frequencies. CPTS and RGMII has MAIN_PLL3 as their parent which does not have this flag. While RGMII needs this reinitialisation to default frequency to be able to get 250MHz with its divider, CPTS can not get its required 200MHz with its divider. Thus, move CPTS clock parent on J721S2 from MAIN_PLL3_HSDIV1 to MAIN_PLL0_HSDIV6. (Note: even GTC will be moved from MAIN_PLL3 to MAIN_PLL0 in U-Boot side for the same reason) Signed-off-by:
Neha Malcom Francis <n-francis@ti.com> Link: https://lore.kernel.org/r/20230605110443.84568-1-n-francis@ti.comSigned-off-by:
-
Dasnavis Sabiya authored
Add support for eMMC card connected to main sdhci0 instance. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Cc: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Cc: Wadim Egorov <w.egorov@phytec.de> Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Cc: Robert Nelson <robertcnelson@gmail.com> Signed-off-by:
-
Nishanth Menon authored
Move the eeprom WP GPIO mux configuration to be part of the eeprom node instead of the I2C node. Cc: Robert Nelson <robertcnelson@gmail.com> Suggested-by:
-
Nishanth Menon authored
Move the GPIO mux configuration needed for camera module to work to the GPIO node instead of the I2C node. Camera nodes are maintained as overlay files, but the common mux is always needed to ensure that camera probes fine and ensuring the mux is configured as part of the GPIO module allows for the multiple overlay files to be simpler. Cc: Robert Nelson <robertcnelson@gmail.com> Suggested-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
When referring to array of phandles, using <> to separate the array entries is better notation as it makes potential errors with phandle and cell arguments easier to catch. Fix the outliers to be consistent with the rest of the usage. Signed-off-by:
-
Nishanth Menon authored
There are timer IO pads in the MCU domain, and in the MAIN domain. These pads can be muxed for the related timers. The details of the multiplexing can be found in the register documentation and Technical Reference Manual[1]. These are similar to J721e/J7200, but have different mux capabilities. [1] http://www.ti.com/lit/zip/spruj52Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230531213215.602395-7-nm@ti.comSigned-off-by:
-
Nishanth Menon authored
There are 20 general purpose timers on j784s4 that can be used for things like PWM using pwm-omap-dmtimer driver. There are also additional ten timers in the MCU domain which are meant for MCU firmware usage and hence marked reserved by default. Though the count is similar to J721e/J7200/j721s2, the device IDs and clocks used in j784s4 are different with the option of certain clocks having options of additional clock muxes. Since there is very minimal reuse, it is cleaner to integrate as part of SoC files itself. The defaults are configured for clocking the timers from system clock(HFOSC0). Signed-off-by:
-
Nishanth Menon authored
There are timer IO pads in the MCU domain, and in the MAIN domain. These pads can be muxed for the related timers. The details of the multiplexing can be found in the register documentation and Technical Reference Manual[1]. These are similar to J721e/J7200, but have different mux capabilities. [1] https://www.ti.com/lit/zip/spruj28Signed-off-by:
-
Nishanth Menon authored
There are 20 general purpose timers on j721s2 that can be used for things like PWM using pwm-omap-dmtimer driver. There are also additional ten timers in the MCU domain which are meant for MCU firmware usage and hence marked reserved by default. Though the count is similar to J721e/J7200, the device IDs and clocks used in j721s2 are different with the option of certain clocks having options of additional clock muxes. Since there is very minimal reuse, it is cleaner to integrate as part of SoC files itself. The defaults are configured for clocking the timers from system clock(HFOSC0). Signed-off-by:
-
Nishanth Menon authored
There are timer IO pads in the MCU domain, and in the MAIN domain. These pads can be muxed for the related timers. There are timer IO control registers for input and output. The registers for CTRLMMR_TIMER*_CTRL and CTRLMMR_MCU_TIMER*_CTRL are used to control the input. The registers for CTCTRLMMR_TIMERIO*_CTRL and CTRLMMR_MCU_TIMERIO*_CTRL the output. The multiplexing is documented in Technical Reference Manual[1] under "Timer IO Muxing Control Registers" and "Timer IO Muxing Control Registers", and the "Timers Overview" chapters. We do not expose the cascade_en bit due to the racy usage of independent 32 bit registers in-line with the timer instantiation in the device tree. The MCU timer controls are also marked as reserved for usage by the MCU firmware. [1] http://www.ti.com/lit/pdf/spruil1Signed-off-by:
-
Nishanth Menon authored
There are 20 general purpose timers on j721e that can be used for things like PWM using pwm-omap-dmtimer driver. There are also additional ten timers in the MCU domain which are meant for MCU firmware usage and hence marked reserved by default. The odd numbered timers have the option of being cascaded to even timers to create a 64 bit non-atomic counter which is racy in simple usage, hence the clock muxes are explicitly setup to individual 32 bit counters driven off system crystal (HFOSC) as default. These instantiation differs from J7200 and other SoCs with the device IDs and clocks involved for muxing. Signed-off-by:
-
Nishanth Menon authored
Security Management Subsystem(SMS) has it's own unique secure proxy as part of Security Accelerator (SA3) module. This is used for communicating with ROM and for special usecases such as HSM operations. In addition MCU island has it's own secure proxy for usecases involving the MCU micro controllers. These are in addition to the one in the main domain DMSS subsystem that is used for general purpose communication. Describe the nodes for use with bootloaders and firmware that require these communication paths which uses interrupts to corresponding micro controller interrupt controller. Mark the node as disabled since these instances do not have interrupts routed to the main processor by default for a complete description of the node. Signed-off-by:
-
