From 778e8a1f605fe76051ee0abe32ea8da85cca9a9f Mon Sep 17 00:00:00 2001 From: T Pratham Date: Tue, 2 Dec 2025 15:52:10 +0530 Subject: [PATCH 1/4] fix(linux): pm: restore rtc_ddr doc page Commit f1723aaa ("Power Management: Move under Foundational_Components") moved the Power Management docs under a new header and updated the paths in only K3 devices. Then, during commit 79180141 ("fix(configs): Cleanup SITARA's toc tree") these were cleaned in the toc trees of legacy devices. But it misses correctly renaming the pm_rtc_ddr file in AM437X. This is the only SoC which is using this page. As a result, now this file shows up as an unreachable file. So, commit 5904b7ab ("fix(unreachable): purge all unreachable files") removes this file. Restore the pm_rtc_ddr doc and correctly add it in AM437X's toc tree. This also rectifies some build warnings as this file is still being referenced in other AM437X docs. Signed-off-by: T Pratham --- configs/AM437X/AM437X_linux_toc.txt | 1 + .../Power_Management/pm_rtc_ddr.rst | 94 +++++++++++++++++++ 2 files changed, 95 insertions(+) create mode 100644 source/linux/Foundational_Components/Power_Management/pm_rtc_ddr.rst diff --git a/configs/AM437X/AM437X_linux_toc.txt b/configs/AM437X/AM437X_linux_toc.txt index f203aea8b..2e39b1418 100644 --- a/configs/AM437X/AM437X_linux_toc.txt +++ b/configs/AM437X/AM437X_linux_toc.txt @@ -77,6 +77,7 @@ linux/Foundational_Components/Power_Management/pm_overview linux/Foundational_Components/Power_Management/pm_dvfs linux/Foundational_Components/Power_Management/pm_cpuidle linux/Foundational_Components/Power_Management/pm_suspend_resume +linux/Foundational_Components/Power_Management/pm_rtc_ddr linux/Foundational_Components_Filesystem linux/Foundational_Components_Tools linux/Foundational_Components/Tools/Development_Tools diff --git a/source/linux/Foundational_Components/Power_Management/pm_rtc_ddr.rst b/source/linux/Foundational_Components/Power_Management/pm_rtc_ddr.rst new file mode 100644 index 000000000..aa24425c5 --- /dev/null +++ b/source/linux/Foundational_Components/Power_Management/pm_rtc_ddr.rst @@ -0,0 +1,94 @@ +######################### +RTC-Only and RTC+DDR Mode +######################### + +AM437x supports two RTC modes, RTC+DDR and RTC-Only mode. RTC+DDR Mode is similar to the +Suspend/Resume above but only supports wake by the Power Button present +on the board or from an RTC ALARM2 Event. RTC-Only mode supports the +same wake sources, however DDR context is not maintained so a wake event +causes a cold boot. + +RTC-Only mode is supported on: + +- AM437x GP EVM +- AM437x SK EVM + +RTC+DDR mode is supported on: + +- AM437x GP EVM + +.. rubric:: RTC+DDR Mode + +The first step in using RTC+DDR mode is to enable off mode by typing the +following at the command line: + +.. code-block:: console + + $ echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode + +With off-mode enabled, a command to enter DeepSleep0 will now enter +RTC-Only mode: + +.. code-block:: console + + $ echo mem > /sys/power/state + +This method of entry only supports Power button as the wake source. + +To use the rtc as a wake source, after enabling off mode use the +following command: + +.. code-block:: console + + $ rtcwake -s -d /dev/rtc0 -m mem + +Whether or not your board enters RTC-Only mode or RTC+DDR mode depends +on the regulator configuration and whether or not the regulator that +supplies the DDR is configured to remain on during suspend. This is +supported by the TPS65218 in use of the AM437x boards but not the +TPS65217 or TPS65910 present on AM335x boards. + +.. code-block:: dts + + tps65218: tps65218@24 { + reg = <0x24>; + compatible = "ti,tps65218"; + interrupts = ; /* NMIn */ + interrupt-parent = <&gic>; + interrupt-controller; + #interrupt-cells = <2>; + + ... + + dcdc3: regulator-dcdc3 { + compatible = "ti,tps65218-dcdc3"; + regulator-name = "vdcdc3"; + regulator-suspend-enable; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + ... + + }; + +Another important thing to make sure of is that you are using the proper +u-boot. A certain u-boot is required in order to support RTC+DDR mode +otherwise the following message appears during boot of the kernel: + +``PM: bootloader does not support rtc-only!`` + +When building u-boot, rather than using ``am43xx_evm_config`` you must +use ``am43xx_evm_rtconly_config`` to support either RTC mode. + +.. rubric:: RTC-Only Mode + +RTC-Only mode does not maintain DDR context so placing a board into +RTC-only mode allows for very low power consumption after which a +supported wake source will cause a cold boot. RTC-Only mode is entered +via the poweroff command. + +To wakeup from RTC-Only mode via an RTC alarm, a separate tool must be +used to program an RTC alarm prior to entering poweroff. From d43051b42188e1894138e1c7008c545b7aa96a7a Mon Sep 17 00:00:00 2001 From: T Pratham Date: Tue, 2 Dec 2025 18:23:14 +0530 Subject: [PATCH 2/4] fix(configs): am62d: correct the crypto config values AM62DX has erroneously set CONFIG_crypto to DTHEv2. Correct that to sa2ul. Also add mcrc64. Signed-off-by: T Pratham --- configs/AM62DX/AM62DX_linux_config.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/AM62DX/AM62DX_linux_config.txt b/configs/AM62DX/AM62DX_linux_config.txt index 39aea40d0..6f4539ced 100644 --- a/configs/AM62DX/AM62DX_linux_config.txt +++ b/configs/AM62DX/AM62DX_linux_config.txt @@ -39,4 +39,5 @@ Configuration Values 'CONFIG_image_type' : 'default' 'CONFIG_icss_support' : 'yes' 'CONFIG_rt_linux_support' : 'yes' -'CONFIG_crypto' : 'DTHEv2' +'CONFIG_crypto' : 'sa2ul' +'CONFIG_mcrc64' : 'mcrc64' From 97651715b84ff91ea7db1d6eba25eb8ea9374d7e Mon Sep 17 00:00:00 2001 From: T Pratham Date: Tue, 2 Dec 2025 18:51:19 +0530 Subject: [PATCH 3/4] fix(linux): audio: remove duplicate target names Build complains of duplicate explicit target names. Target names should be unique. Also, names are not needed for rubrics unless they are referenced somewhere else. These duplicates are not referenced anywhere. Remove repeated target names in audio doc. Signed-off-by: T Pratham --- .../Foundational_Components/Kernel/Kernel_Drivers/Audio.rst | 4 ---- 1 file changed, 4 deletions(-) diff --git a/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Audio.rst b/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Audio.rst index 4b1738767..6f07f65a1 100644 --- a/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Audio.rst +++ b/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Audio.rst @@ -463,7 +463,6 @@ Board-specific instructions p1 - playback jack .. rubric:: Kernel config - :name: kernel-config-8 .. code-block:: text @@ -492,7 +491,6 @@ Board-specific instructions } .. rubric:: User space - :name: user-space-8-kernel-audio ``NOTE: Playback volume is HIGH after boot. Do not use headset without lowering it!!!`` @@ -567,7 +565,6 @@ Board-specific instructions HDMI bridge**. .. rubric:: Kernel config - :name: kernel-config-9 .. code-block:: text @@ -582,7 +579,6 @@ Board-specific instructions <*> ASoC Simple sound card support .. rubric:: User space - :name: user-space-9 .. _hdmi_audio: The hardware defaults are correct for audio playback, the routing is OK From 4e7fa2ccff1b3007de07fc685783593c8f92d2c5 Mon Sep 17 00:00:00 2001 From: T Pratham Date: Fri, 5 Dec 2025 16:18:21 +0530 Subject: [PATCH 4/4] fix(linux): display: Correct formatting issues and typos This commit fixes the following formatting issues in DSS7 docs, which were caught from build and AI warnings: - An extra colon at the end of line - Adding a new line after end of list - Indentation at a note. While here corecting indentation, also change the `**note**` to `..note ::` directive. - Correcting typo paritioning to partitioning. Signed-off-by: T Pratham --- ....png => DSS7_resource_partitioning_HW.png} | Bin .../Kernel/Kernel_Drivers/Display/DSS7.rst | 22 ++++++++++-------- 2 files changed, 12 insertions(+), 10 deletions(-) rename source/images/{DSS7_resource_paritioning_HW.png => DSS7_resource_partitioning_HW.png} (100%) diff --git a/source/images/DSS7_resource_paritioning_HW.png b/source/images/DSS7_resource_partitioning_HW.png similarity index 100% rename from source/images/DSS7_resource_paritioning_HW.png rename to source/images/DSS7_resource_partitioning_HW.png diff --git a/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Display/DSS7.rst b/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Display/DSS7.rst index 877bf4fe8..0af529e20 100644 --- a/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Display/DSS7.rst +++ b/source/linux/Foundational_Components/Kernel/Kernel_Drivers/Display/DSS7.rst @@ -137,7 +137,7 @@ SoC Family: |__PART_FAMILY_DEVICE_NAMES__| The DSS7 hardware also supports resource sharing across multiple processing cores with separate register region per sub-component and interrupt duplication for each processing core, thus allowing independent context update for the associated pipelines. - .. Image:: /images/DSS7_resource_paritioning_HW.png + .. Image:: /images/DSS7_resource_partitioning_HW.png Supported Features @@ -287,7 +287,7 @@ Note: this is not a comprehensive list of features supported/not supported, and The device-tree property "ti,dss-shared-mode-vp" can be used by processing core running Linux to enlist one or more video ports being used by it and the ownership related information can be set using ti,dss-shared-mode-owned-vp device-tree property. - To summarize, below is the list of device-tree properties which can be added to display node, using these properties one can set up a resource paritioning scheme tailored as per the desired end use-case:: + To summarize, below is the list of device-tree properties which can be added to display node, using these properties one can set up a resource partitioning scheme tailored as per the desired end use-case: .. ifconfig:: CONFIG_part_variant in ('AM62PX', 'J722S') @@ -304,13 +304,13 @@ Note: this is not a comprehensive list of features supported/not supported, and .. note:: - For display sharing mode to work with chosen resource paritioning between Linux and remote core, the remote core needs to be running appropriate firmware which programs the display hardware by supporting this resource paritioning scheme. + For display sharing mode to work with chosen resource partitioning between Linux and remote core, the remote core needs to be running appropriate firmware which programs the display hardware by supporting this resource partitioning scheme. .. ifconfig:: CONFIG_part_variant in ('AM62PX', 'J722S') More detailed description of these properties can be found at: `Display device-tree file `__ - Also there is a how-to guide available for dss sharing which walks through different examples for resource paritioning using these device-tree properties : + Also there is a how-to guide available for dss sharing which walks through different examples for resource partitioning using these device-tree properties : `How to enable dss sharing between remote core and Linux <../../../../How_to_Guides/Target/How_to_enable_display_sharing_between_remotecore_and_Linux.html>`__ Unsupported Features/Limitations @@ -339,6 +339,7 @@ Unsupported Features/Limitations - **DisplayPort (MHDP)** - MST - 4K@60FPS Resolution + | For 4k@60FPS resolution, sometimes visual artifacts are seen due to Video Sync Loss. | Therefore the maximum supported video resolution as of now is limited to 4K@30FPS (or equivalent) | by limiting the dp phy-link rate to 2700Mbps. @@ -347,6 +348,7 @@ Unsupported Features/Limitations - **DisplayPort (MHDP)** - MST - 4K@60FPS Resolution + | MHDP PHY has only 2 SERDES LANES dedicated to eDP and with the phy-link rate of 5400Mbps, the maximum | data rate it can support is 10.8Gbps which is not sufficient for 4k@60FPS. So the maximum supported | resolution is 4K@30FPS (and equivalent resolutions). @@ -430,12 +432,12 @@ Another option is kms++, a C++11 library for kernel mode setting which includes on the platform. The GPU, if present, associates with the card1, which leaves card2 for DSS1. In a case where GPU driver is not present, DSS1 will take up card1. - - **Note:** Most display applications and windowing managers are programmed in such a way that - they can only access a display DRM card (card0) and a GPU DRM card (card1). This is why, the - second DSS instance, will not show up running Weston or any framebuffer application, even when - GPU is not present, in which case the windowing manager will only use card0. This makes DSS1 - completely available for a 2nd DRM Master. This can be a custom display application, helping out - in the most niche of use-cases. + .. note:: Most display applications and windowing managers are programmed in such a way that + they can only access a display DRM card (card0) and a GPU DRM card (card1). This is why, the + second DSS instance, will not show up running Weston or any framebuffer application, even when + GPU is not present, in which case the windowing manager will only use card0. This makes DSS1 + completely available for a 2nd DRM Master. This can be a custom display application, helping out + in the most niche of use-cases. Testing tidss