- 03 Jul, 2024 2 commits
-
-
Devarsh Thakkar authored
Reserve 576MiB of CMA as global CMA pool starting after initial 1GiB of DDR. AM62ax has different multimedia components such as Camera, Display, H.264 VPU and JPEG Encoder which use CMA for buffer allocations. The 12x 720x480 realtime VPU decode use-case requires 544MiB of CMA, additional 32MiB is kept as buffer in case some other peripheral also require it while VPU is running. The reason to choose latter 1GiB is to not overlap with existing memory map which is utilizing initial 1GiB for remoteproc firmwares as shared here [1]. Also some drivers such as JPEG require 32bit addressing so not allocating from higher DDR address. Link: https://lore.kernel.org/all/20240605124859.3034-5-hnagalla@ti.com [1] Signed-off-by:
Devarsh Thakkar <devarsht@ti.com> Tested-by:
Brandon Brnich <b-brnich@ti.com> Reviewed-by:
Randolph Sapp <rs@ti.com> Link: https://lore.kernel.org/r/20240613150902.2173582-3-devarsht@ti.comSigned-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Devarsh Thakkar authored
Reserve 128MiB of global CMA which is also marked as re-usable so that OS can also use the same if peripheral drivers are not using the same. AM62x supports multimedia components such as GPU, dual Display and Camera. Assuming the worst-case scenario where all 3 are run in parallel below is the calculation : 1) OV5640 camera sensor supports 1920x1080 resolution -> 1920 width x 1080 height x 2 bytesperpixel x 8 buffers (default in yavta) : 32MiB 2) 1920x1200 Microtips LVDS panel supported -> 1920 width x 1080 height x 4 bytesperpixel x 2 buffers : 16 MiB 3) 1920x1080 HDMI display supported -> 1920 width x 1080 height x 4 bytesperpixel x 2 buffers : 15.82 MiB which is ~16 MiB 4) IMG GPU shares with display allocated buffers while rendering but in case some dedicated operation viz color conversion, keeping same window of ~16 MiB for GPU too. Total is 80 MiB and adding 32 MiB for other peripherals and extra 16 MiB to keep as buffer for fragmentation thus rounding total to 128 MiB. Signed-off-by:
-
- 01 Jul, 2024 28 commits
-
-
Dhruva Gole authored
Fix the following warnings when compiling dtbs with W=1: ../arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi:343.10-353.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/tps6598x@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary ../arch/arm64/boot/dts/ti/k3-am62-main.dtsi:633.22-643.5: Warning (graph_child_address): /bus@f0000/dwc3-usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary Cc: Roger Quadros <rogerq@kernel.org> Signed-off-by:
Dhruva Gole <d-gole@ti.com> Tested-by:
Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20240626101520.1782320-3-d-gole@ti.comSigned-off-by:
-
Dhruva Gole authored
Fix the following warnings that are thrown when building dtbs with W=1: ../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:367.10-376.6: Warning (graph_child_address): /bus@f0000/i2c@20000000/usb-power-controller@3f/connector/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary ../arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi:647.22-657.5: Warning (graph_child_address): /bus@f0000/usb@f900000/usb@31000000: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary also defined at ../arch/arm64/boot/dts/ti/k3-am62p5-sk.dts:517.7-528.3 Cc: Roger Quadros <rogerq@kernel.org> Signed-off-by:
-
Jared McArthur authored
The AM67A/J722S/TDA4AEN platform is a derivative of AM62P platform and we have no single 1:1 relation regarding index of GPIO and pin controller. The GPIOs and pin controller registers have mapping and holes in the map. These have been extracted from the J722S data sheet. The MCU mapping is carried forward as is with J722S, however the main GPIO block has differences that needs to be accounted for. Mux mode input is selected as it is bi-directional. In case a specific pull type or a specific pin level drive setting is desired, the board device tree files will have to explicitly mux those pins for the GPIO with the desired setting. Ref: J722S Data sheet https://www.ti.com/lit/gpn/tda4aen-q1Signed-off-by:
Jared McArthur <j-mcarthur@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20240627162539.691223-4-nm@ti.comSigned-off-by:
-
Nishanth Menon authored
On the AM62P platform we have no single 1:1 relation regarding index of GPIO and pin controller. The GPIOs and pin controller registers have mapping and holes in the map. These have been extracted from the AM62P data sheet. MCU pinctrl definition is shared as it is common between AM62P and J722S, but that is not the case for main domain. Ref: AM62P Data sheet https://www.ti.com/lit/gpn/am62pSigned-off-by:
-
Nishanth Menon authored
Introduce a GPIO mux mode macro for easier readability. All K3 devices use mux mode 7 to switch to GPIO mux and this allows the gpio-ranges to be defined for pinctrl-single clearly. Signed-off-by:
-
Andrew Davis authored
The WKUP system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240628151518.40100-8-afd@ti.comSigned-off-by:
-
Andrew Davis authored
The WKUP system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Andrew Davis authored
The MCU system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Andrew Davis authored
The MCU system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Andrew Davis authored
The MCU system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Andrew Davis authored
The MCU system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Andrew Davis authored
The MCU system controller address region contains an eFuse block with MAC addresses to be used by the Ethernet controller. The property “ti,syscon-efuse” contains a phandle to a syscon region and an offset into this region where the MAC addresses can be found. Currently "ti,syscon-efuse" points to the entire system controller address space node with an offset to the eFuse IP address. Instead add a cpsw-mac-efuse node to describe the exact eFuse area. Then point the Ethernet controller directly to this region, no offset needed. This makes it so the system controller memory area does not need to be one big syscon area, describe this bus address area as the simple-bus it is. Signed-off-by:
-
Roger Quadros authored
NAND boot would require these nodes to be present at early stage. Ensure that by adding "bootph-all" to relevant nodes. Signed-off-by:
-
Garrett Giordano authored
The phyCORE-AM62Ax [1] is a SoM (System on Module) featuring TI's AM62Ax SoC. It can be used in combination with different carrier boards. This module can come with different sizes and models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM62Ax family. A development Kit, called phyBOARD-Lyra [2] is used as a carrier board reference design with a mapper board being used to allow the phyCORE-AM62Ax to fit the phyBOARD-Lyra. Supported features: * Debug UART * SPI NOR Flash * eMMC * 2x Ethernet * Micro SD card * I2C EEPROM * I2C RTC * GPIO Expander * LEDs * USB * HDMI * USB-C * Audio For more details, see: [1] Product page SoM: https://www.phytec.com/product/phycore-am62a [2] Product page CB: https://www.phytec.com/product/phyboard-am62aSigned-off-by:
Garrett Giordano <ggiordano@phytec.com> Reviewed-by:
Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240626155244.3311436-4-ggiordano@phytec.comSigned-off-by:
-
Garrett Giordano authored
Add devicetree bindings for AM62Ax based phyCORE-AM62A7 SoM and phyBOARD-Lyra RDK. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240626155244.3311436-3-ggiordano@phytec.comSigned-off-by:
-
Garrett Giordano authored
PHYTECs phyBOARD-Lyra carrier board is able to accomidate multiple SoMs. Refactor k3-am625-phyboard-lyra-rdk.dts into an include file so it can be reused in combination with our phyCORE-AM62Ax SoM. Signed-off-by:
-
Garrett Giordano authored
On AM62a SoCs the AUDIO_REFCLKx clocks can be used as an input to external peripherals when configured through CTRL_MMR, so add the clock nodes. Based on: Link: https://lore.kernel.org/lkml/20230807202159.13095-2-francesco@dolcini.it/Signed-off-by:
-
Jayesh Choudhary authored
The audio support on J784S4-EVM is using PCM3168A[0] codec connected to McASP0 serializers. - Add the nodes for sound-card, audio codec, MAIN_I2C3 and McASP0. - Add pinmux for I2C3, McASP0 and AUDIO_EXT_REFCLK1. - Add necessary GPIO hogs to route the MAIN_I2C3 lines and McASP serializer. - Add idle-state as 1 in mux1 to route McASP clock signals. [0]: <https://www.ti.com/lit/gpn/pcm3168a> Signed-off-by:
Jayesh Choudhary <j-choudhary@ti.com> Link: https://lore.kernel.org/r/20240626101645.36764-4-j-choudhary@ti.comSigned-off-by:
-
Jayesh Choudhary authored
On J784S4 SoC, the AUDIO_REFCLK1 can be used as input to external peripherals when configured through CTRL_MMR. Add audio_refclk1 node which would be used as system clock for audio codec PCM3168A. Signed-off-by:
-
Jayesh Choudhary authored
Add McASP 0-4 instances and keep them disabled because several required properties are missing as they are board specific. Signed-off-by:
-
Roger Quadros authored
The NAND expansion card (PROC143E1) connects over the User/MCU/PRU Expansion port on the am62-lp-sk EVM. The following pins are shared between McASP1 and GPMC-NAND so both cannot work simultaneously. Pin name McASP1 function GPMC function ======== =============== ============= J17 MCASP1_AXR0 GPMC0_WEN P21 MCASP1_AFSX GPMC0_WAIT0 K17 MCASP1_ACLKX GPMC0_BE0N_CLE K20 MCASP1_AXR2 GPMC0_ADVN_ALE The factory default sets the pins for McASP1 use. (i.e. Resistor Array RA1 installed, RA4 not installed). For NAND use, RA1 has to be removed and RA4 must be installed. Signed-off-by:
-
Nitin Yadav authored
Add GPMC and ELM device tree nodes for AM62 SoC family. Signed-off-by:
Nitin Yadav <n-yadav@ti.com> Signed-off-by:
-
Jayesh Choudhary authored
The audio support on J722S-EVM is using TLV320AIC3106[0] codec connected to McASP1 serializers. - Add the nodes for sound-card, audio codec and McASP1. - Add hog for TRC_MUX_SEL to select between McASP and TRACE signals - Add hogs for GPIO_AUD_RSTn and MCASP1_FET_SEL which is used to switch between HDMI audio and codec audio. - Add pinmux for MCASP1 and AUDIO_EXT_REFCLK1. [0]: <https://www.ti.com/lit/gpn/TLV320AIC3106> Signed-off-by:
Jai Luthra <j-luthra@ti.com> Link: https://lore.kernel.org/r/20240625113301.217369-3-j-choudhary@ti.comSigned-off-by:
-
Jayesh Choudhary authored
On J722S SoC, the AUDIO_REFCLK1 can be used as input to external peripherals when configured through CTRL_MMR. Add audio_refclk1 node which would be used as system clock for the audio codec TLV320AIC3106. Signed-off-by:
-
Sinthu Raja authored
AM68 SK has an OSPI NOR flash on its SOM connected to OSPI0 instance. Enable support for the same. Also, describe the OSPI flash partition information through the device tree, according to the offsets in the bootloader. Signed-off-by:
Sinthu Raja <sinthu.raja@ti.com> Signed-off-by:
Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20240622161835.3610348-1-u-kumar1@ti.comSigned-off-by:
-
Nathan Morrisson authored
Add an overlay to change from the default OSPI NOR to QSPI NOR for all am6xx-phycore-som boards. The EEPROM on am6xx-phycore-soms contains information about the configuration of the SOM. The standard configuration of the SOM has an ospi nor, but if qspi nor is populated, the EEPROM will indicate that change and we can use this overlay to cleanly change to qspi nor. Signed-off-by:
Nathan Morrisson <nmorrisson@phytec.com> Link: https://lore.kernel.org/r/20240621233143.2077941-1-nmorrisson@phytec.comSigned-off-by:
-
Matthias Schiffer authored
MIT license was added to the AM64x SoC DTSIs in commit 6248b20e ("arm64: dts: ti: k3-am64: Add MIT license along with GPL-2.0"). Apply the same license change to the TQMa64xxL SoM and MBaX4XxL baseboard Device Trees. The copyright year is updated to indicate the license change. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20240625110244.9881-1-matthias.schiffer@ew.tq-group.comSigned-off-by:
-
Andrejs Cainikovs authored
In current configuration, nau8822 codec on development carrier board provides distorted audio output. This happens due to reference clock is fixed to 25MHz and no PLL is enabled. Following is the calculation of deviation error for different frequencies: 44100Hz: fs = 256 (fixed) prescaler = 2 target frequency = 44100 * 256 * 2 = 22579200 deviation = 22579200 vs 25000000 = 9.6832% 48000Hz: fs = 256 (fixed) prescaler = 2 target frequency = 48000 * 256 * 2 = 24576000 deviation = 24576000 vs 25000000 = 1.696% Enabling nau822 PLL via providing mclk-fs property to simple-audio-card configures clocks properly, but also adjusts audio reference clock (mclk), which in case of TI AM62 should be avoided, as it only supports 25MHz output [1][2]. This change enables PLL on nau8822 by providing mclk-fs, and moves away audio reference clock from DAI configuration, which prevents simple-audio-card to adjust it before every playback [3]. [1]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175479/processor-sdk-am62x-output-audio_ext_refclk0-as-mclk-for-codec-and-mcbsp/4444986#4444986 [2]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1188051/am625-audio_ext_refclk1-clock-output---dts-support/4476322#4476322 [3]: sound/soc/generic/simple-card-utils.c#L441 Signed-off-by:
Andrejs Cainikovs <andrejs.cainikovs@toradex.com> Reviewed-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20240418105730.120913-1-andrejs.cainikovs@gmail.comSigned-off-by:
-
- 22 Jun, 2024 2 commits
-
-
Kamlesh Gurudasani authored
As there is no child node in crypto node, remove the properties that are not needed. Signed-off-by:
Kamlesh Gurudasani <kamlesh@ti.com> Link: https://lore.kernel.org/r/20240618-remove-ranges-v1-1-35d68147e9bf@ti.comSigned-off-by:
-
Kamlesh Gurudasani authored
Add the node for sa3ul crypto accelerator. Signed-off-by:
-
- 19 Jun, 2024 8 commits
-
-
MD Danish Anwar authored
The IEP0 SYNC_OUT0 pins are used for PPS out on AM64 EVM. Configure its PINMUX here. Signed-off-by:
MD Danish Anwar <danishanwar@ti.com> Link: https://lore.kernel.org/r/20240614100829.3919008-1-danishanwar@ti.comSigned-off-by:
-
Devarsh Thakkar authored
I2C1 controller controls io-expander which provides power to voltage regulator vdd_mmc1 for MMC SD using a gpio line. Add bootph-all to the pinmux node for this instance, as this is used during SPL stage too by the bootloader while using SD boot mode as without this the SD boot mode fails with below error when using this device-tree in u-boot: "Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured Timed out in wait_for_event: status=0000 Check if pads/pull-ups of bus are properly configured " Signed-off-by:
-
Siddharth Vadapalli authored
Certain device-tree node properties of shared device-tree nodes are different between the AM62P and J722S SoCs. To avoid overriding the properties and to avoid redefining the nodes in the k3-{soc}-main.dtsi having such SoC specific properties, move the properties to the SoC specific k3-{soc}-main.dtsi files. Signed-off-by:Siddharth Vadapalli <s-vadapalli@ti.com> Acked-by:
-
Siddharth Vadapalli authored
Enable PCIe0 instance of PCIe in Root Complex mode of operation with Lane 0 of the SERDES1 instance of SERDES. Also enable USB0 instance of USB to interface with the Type-C port via the USB hub, by configuring the pin P05 of the GPIO expander on the EVM. Enable USB1 instance of USB in SuperSpeed mode of operation with Lane 0 of the SERDES0 instance of SERDES. Co-developed-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Signed-off-by:
-
Siddharth Vadapalli authored
J722S SoC has two instances of SERDES namely SERDES0 and SERDES1 and one instance of PCIe namely PCIe0. Both SERDES0 and SERDES1 are single lane SERDES. The PCIe0 instance of PCIe is a Gen3 single lane PCIe controller. Since SERDES and PCIe are not present on AM62P SoC, add the device-tree nodes corresponding to them in the J722S SoC specific "k3-j722s-main.dtsi" file. Co-developed-by:
-
Siddharth Vadapalli authored
The SERDES0 and SERDES1 instances of SERDES on J722S are single lane SERDES which are individually muxed across different peripherals. LANE0 of SERDES0 is muxed between USB and CPSW while LANE0 of SERDES1 is muxed between PCIe and CPSW. Define the lane-muxing macros to be used as the idle state values. Co-developed-by:
-
Siddharth Vadapalli authored
Update "k3-j722s.dtsi" to include "k3-am62p-j722s-common-{}".dtsi files in order to reuse the nodes shared with AM62P. Also include the J722S specific "k3-j722s-main.dtsi". Since the J7 family of SoCs has the k3-{soc}.dtsi file organized as: k3-{soc}.dtsi = CPU + Cache + CBASS-Ranges + "Peripheral-Includes" switch the "k3-j722s.dtsi" file to the same convention. Signed-off-by: -
Siddharth Vadapalli authored
Introduce the "k3-j722s-main.dtsi" file to contain main domain peripherals that are specific to J722S SoC and are not shared with AM62P. The USB1 instance of the USB controller on J722S is different from that on AM62P. Thus, add the USB1 node in "k3-j722s-main.dtsi". Co-developed-by:
-
