soc: ti: introduce ti,control-module for MMR partition unlocking#103330
Merged
nashif merged 5 commits intozephyrproject-rtos:mainfrom Mar 12, 2026
Merged
soc: ti: introduce ti,control-module for MMR partition unlocking#103330nashif merged 5 commits intozephyrproject-rtos:mainfrom
nashif merged 5 commits intozephyrproject-rtos:mainfrom
Conversation
zephyrbot
added
area: ARM64
natto1784
force-pushed
the
control_module
branch
2 times, most recently
from
89cdc05 to
e6b09ae
Compare
pablofsmelo
reviewed
Feb 2, 2026
pablofsmelo
left a comment
pablofsmelo
left a comment
There was a problem hiding this comment.
Modify the PR title to something like "soc: ti: introduce ti,control-module for MMR partition unlocking" to maintain compatibility.
natto1784
changed the title
glneo
reviewed
Feb 2, 2026
natto1784
force-pushed
the
control_module
branch
2 times, most recently
from
b33f1ea to
e49392e
Compare
glneo
reviewed
Feb 3, 2026
glneo
reviewed
Feb 3, 2026
natto1784
force-pushed
the
control_module
branch
from
e49392e to
ec47bbb
Compare
natto1784
force-pushed
the
control_module
branch
from
ec47bbb to
489c4b8
Compare
glneo
reviewed
Feb 18, 2026
Contributor
Author
natto1784
force-pushed
the
control_module
branch
from
ff42b8d to
dc9d9f2
Compare
natto1784
force-pushed
the
control_module
branch
from
dc9d9f2 to
2922cdb
Compare
This binding is for TI devices that use control modules for configuring registers and information related to control MMRs, power, reset and clocking. These control modules consist of regions that require writing specific values to specific kick registers to unlock that region. This is provided as ti,unlock-offsets property. Signed-off-by: Amneesh Singh <amneesh@ti.com>
Currently we maintain addresses and values as static configurations using static configurations and macros in ctrl_partitions.c. Instead use the new ti,control-module binding to get these values from the device tree and unlock the partitions during early init. Only compile and call `k3_unlock_all_ctrl_partitions` if at least one node with status okay and compatible "ti,control-module" is present. Also make sure to map and unmap the regions in case MMU is present. Signed-off-by: Amneesh Singh <amneesh@ti.com>
Allow unlocking partitions as part of early_init_hook if the device tree contains an unlock configuration as part of ti,control-module. Signed-off-by: Amneesh Singh <amneesh@ti.com>
Allow providing an unlock configuration for unlocking the padcfg region as part of the ti,control-module node. Map the child pinctrl node using the `ranges` property to the base address space. Signed-off-by: Amneesh Singh <amneesh@ti.com>
Allow providing an unlock configuration for unlocking the padcfg region as part of the ti,control-module node. Map the child pinctrl node using the `ranges` property to the base address space. Signed-off-by: Amneesh Singh <amneesh@ti.com>
natto1784
force-pushed
the
control_module
branch
from
2922cdb to
c2b9189
Compare
16 tasks
Contributor
|
Yeah the last two patches are good examples but feel very un-related. Plus one is giving a bunch Doxygen warnings. Better to just move those to a different PR. Everything else looks good to me. |
natto1784
force-pushed
the
control_module
branch
from
c2b9189 to
18fa10e
Compare
Contributor
Author
Dropped the last two patches, will be moved to a separate PR. |
|
glneo
approved these changes
Mar 12, 2026
dnltz
approved these changes
Mar 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This binding is for TI devices that use control modules for configuring
registers and information related to control MMRs, power, reset and
clocking.
These control modules consist of regions that require writing specific
values to specific kick registers to unlock that region. This is provided
as ti,unlock-offsets property.
Currently we maintain addresses and values as static configurations using
static configurations and macros in ctrl_partitions.c. Instead use the
new ti,control-module binding to get these values from the device tree and
unlock the partitions during early init.
Rationale behind driver-less DT binding
I am aware that this is not a preferred thing in the codebase, however writing a driver separately for doing a couple of I/O operations makes little sense in this case. It would pretty much just be the same as the generic syscon driver with a different
init()API.Usecases
One usecase is already addressed in this PR which is unlocking of pinctrl/pinmux regions.
There are several more usecases for other MMR regions that are not currently in the DT. These involve having something like
compatible = "ti,control-module", "syscon";to enable the syscon driver as well.In general, it would be used as a generic syscon driver for many peripheral configurations (or in case of pinctrl, syscon-less for reduced complexity) in addition to the unlocking mechanism in early init hook.
Testing
Built for
Ran on