dev: ti: mspm0: l: Add common pinmux for MSPM0L111x by heghe · Pull Request #80 · zephyrproject-rtos/hal_ti

heghe · 2026-01-16T09:02:23Z

Based on the TI datasheet.
All pins support being used as GPIO.
Use input-enable for all PIN TYPE I on datasheet + SPI POCI pins.
Define MSPM0_PIN_FUNCTION_ANALOG for every pin which is unconnected state (essentially needed for low power consumption).

Link: https://www.ti.com/lit/ds/symlink/mspm0l1116.pdf

ssekar15

as far I checked most of configuration matches with existing l222x dtsi. Please resuse the existing dtsi file as include and add delta on high variants.

use name as per datasheet e.g . tima_fault1_pa0 not tima_fal1_pa0.

heghe · 2026-01-19T10:44:01Z

I didn't notice that l222x and l111x are that similar. I agree with your suggestion to have a common base for both with delta where appropriate.

As for the naming conventions, I'll use the format of l222x. But I do have a question here. For the SPI CS pins it has the name of spiN_csX_pociX*link. Is this the correct naming? Or was just a mistake and I should fix it.

heghe · 2026-01-19T13:59:40Z

@ssekar15 while in the process of creating the common base, I discover that after PINCM20 the configurations are no longer shared. Do you still want to have this part shared?

Also I notice that in my configuration, IOMUX REG is off, it seems I used PT PIN by mistake, but when I tested this on the EV board, the led was working. I guess it was just a happy coincidence.

Anyway, I'll be waiting for your feedback before continuing the work on this.

ssekar15 · 2026-01-22T13:54:21Z

For the SPI CS pins it has the name of spiN_csX_pociX*link.

The naming conviction is followed from the source/ti/devices/msp/m0p/mspm0l122x.h, please identify whether typo or pin serve two configuration in different SoC on same series.

@ssekar15 while in the process of creating the common base, I discover that after PINCM20 the configurations are no longer shared. Do you still want to have this part shared?

yes, please create common base until PINCM20.

Ayush1325 · 2026-02-25T12:43:44Z

dts/ti/mspm0/l/mspm0l222x-pinctrl.dtsi

-				pinmux = <MSP_PINMUX(74, MSPM0_PIN_FUNCTION_9)>;
-			};
-		};
+	/omit-if-no-ref/ comp0_out_pa27: comp0_out_pa27 {


I think most of the diffs in this file are due to the change in formatting.

the formatting/indentation change is due to the fact that the root and soc nodes were moved into the common dtsi file, and the pinctrl node is reference here only for the additions needed for mspm0l222x variant.

Ayush1325 · 2026-03-06T07:50:57Z

dts/ti/mspm0/l/mspm0l111x-222x-common-pinctrl.dtsi

+				pinmux = <MSP_PINMUX(1, MSPM0_PIN_FUNCTION_2)>;
+			};
+
+			/omit-if-no-ref/ ic20_sda_pa0: ic20_sda_pa0 {


typo should be i2c0_sda_pa0

good catch. fixed

Since MSPM0L111x and MSPM0L222x have a common pin configuration for some of the pins, the mspm0l111x-222x-common-pinctrl.dtsi file is added with the shared pin configuration. The MSPM0L222x dtsi is modified to take advantage of this. The naming convetion was kept from the original 222x variant, with some modifications for SPI CS pins which didn't correctly reflect their function. For example, there was: `spi0_cs3_cd_poci3_pa01: spi0_cs3_cd_poci3_pa01` node for the PINCM2 function 10 which in data sheet is named only SPI0_CS3, and now the node is named: `spi0_cs3_pa01: spi0_cs3_pa01`. As for MSPM0L111x: - All pins support being used as GPIO. - Use input-enable for all PIN TYPE I on datasheet + SPI POCI pins. - Define MSPM0_PIN_FUNCTION_ANALOG for every pin which is unconnected state (essentially needed for low power consumption). Link: https://www.ti.com/lit/ds/symlink/mspm0l1116.pdf Link: https://www.ti.com/lit/ds/symlink/mspm0l2228.pdf Signed-off-by: Razvan Heghedus <razvan.heghedus@protonmail.com>

ssekar15 · 2026-03-13T05:29:41Z

dts/ti/mspm0/l/mspm0l111x-222x-common-pinctrl.dtsi

+				pinmux = <MSP_PINMUX(1, MSPM0_PIN_FUNCTION_3)>;
+				input-enable;
+				drive-open-drain;
+				bias-disable;


Please add only mux setting in common dtsi, driver setting depends on board.

I agree with this. Furthermore, I have concerns about maintainability and tradeoffs with other mspm0l variants. while MSPM0L122 and MSPM0L222X are the same family, MSPM0L111X devices are fundamentally a different family, and there's not a planned compatibility and continuity from the TI side, so I think we're better off keeping these files separate even if there are some similarities.

ssekar15 · 2026-03-16T04:37:27Z

dts/ti/mspm0/l/mspm0l111x-222x-common-pinctrl.dtsi

+				pinmux = <MSP_PINMUX(3, MSPM0_PIN_FUNCTION_5)>;
+				input-enable;
+			};
+


PINMUX_6 is missing

JFMSP

One note about structure, I don't know if the common file is the right approach here across different families.

There are other MSPM0L devices that can get added such as L1306 where deriving a clean common file will become really tricky.

JFMSP · 2026-03-16T20:35:51Z

dts/ti/mspm0/l/mspm0l111x-222x-common-pinctrl.dtsi

+				pinmux = <MSP_PINMUX(1, MSPM0_PIN_FUNCTION_3)>;
+				input-enable;
+				drive-open-drain;
+				bias-disable;


I agree with this. Furthermore, I have concerns about maintainability and tradeoffs with other mspm0l variants. while MSPM0L122 and MSPM0L222X are the same family, MSPM0L111X devices are fundamentally a different family, and there's not a planned compatibility and continuity from the TI side, so I think we're better off keeping these files separate even if there are some similarities.

ssekar15 · 2026-03-17T15:44:26Z

One note about structure, I don't know if the common file is the right approach here across different families.

There are other MSPM0L devices that can get added such as L1306 where deriving a clean common file will become really tricky.

@JFMSP
Common pinctrl is to avoid mistakes with multiple effort, streamline only difference for better understanding. Most of MSPM0 family shares the same baseline. Nevertherless completely incompatible new SoC shall have separate entity.

JFMSP · 2026-03-17T21:47:22Z

One note about structure, I don't know if the common file is the right approach here across different families.
There are other MSPM0L devices that can get added such as L1306 where deriving a clean common file will become really tricky.

@JFMSP Common pinctrl is to avoid mistakes with multiple effort, streamline only difference for better understanding. Most of MSPM0 family shares the same baseline. Nevertherless completely incompatible new SoC shall have separate entity.

My point here is I think mistakes are actually more likely because this common file won't scale to other MPSM0L devices. The presence of other pin functions apart from analog and GPIO as the first two is not shared because the rest of the peripheral elements are very different. So if we were to add MSPM0L1306, for example, the PA0 functions for that are:
0. analog (same)

gpio (same)
uart1 TX (different uart instance)
i2c0 sda (same)
timg1 ccp0 (different)
spi0 cs1 (different)
sysctl fcc in (same)

and this starts to break the commonality in more places. Then either we ignore the common file for additional devices which then becomes clunky or we have to re-work the common file with each new device, neither of which I'm a big fan of.

I think we have much more maintainable code long term if we deal with some duplication across different devices, because there's not any shared commonality we're enforcing from the TI side.

heghe mentioned this pull request Jan 16, 2026

Add TI LP-MSPM0L1117 board zephyrproject-rtos/zephyr#102398

Draft

ssekar15 self-requested a review January 16, 2026 15:16

ssekar15 self-assigned this Jan 16, 2026

ssekar15 requested changes Jan 16, 2026

View reviewed changes

heghe force-pushed the mspm0l111x branch from 29b4c18 to 2e42ab3 Compare February 4, 2026 09:33

Ayush1325 reviewed Feb 25, 2026

View reviewed changes

Ayush1325 suggested changes Mar 6, 2026

View reviewed changes

heghe force-pushed the mspm0l111x branch from 2e42ab3 to a3b39c0 Compare March 9, 2026 12:28

ssekar15 requested changes Mar 16, 2026

View reviewed changes

JFMSP reviewed Mar 16, 2026

View reviewed changes

Conversation

heghe commented Jan 16, 2026

Uh oh!

ssekar15 left a comment

Choose a reason for hiding this comment

Uh oh!

heghe commented Jan 19, 2026

Uh oh!

heghe commented Jan 19, 2026

Uh oh!

ssekar15 commented Jan 22, 2026

Uh oh!

Ayush1325 Feb 25, 2026

Choose a reason for hiding this comment

Uh oh!

heghe Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

Ayush1325 Mar 6, 2026

Choose a reason for hiding this comment

Uh oh!

heghe Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

ssekar15 Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

JFMSP Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ssekar15 Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

JFMSP left a comment

Choose a reason for hiding this comment

Uh oh!

JFMSP Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ssekar15 commented Mar 17, 2026

Uh oh!

JFMSP commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

JFMSP Mar 16, 2026 •

edited

Loading

JFMSP Mar 16, 2026 •

edited

Loading