drivers: add i2c driver support for MSPM0 by d-philpot · Pull Request #94627 · zephyrproject-rtos/zephyr

d-philpot · 2025-08-19T03:21:51Z

Adds I2C controller and target support for MSPM0. Includes driver changes, dts and board updates.

drivers/i2c/i2c_mspm0.c

comment addressed

parthitce

This driver needs lot of re-factor. In summary,

ISR context is handling all the data path, which needs to be abstracted.
Target and Controller support needs to be split.
Multi target support needs to be compile time based on devicetree target nodes.
Current usage of data section is high and needs to be optimized based on rodata / data place-holding.

Current code base is not compilable as well. So IMO it makes sense to put in DRAFT until it's ready for review.

teburd

There's some confusing things going on, maybe because the HAL is handling interrupts? It's unclear, but those should be handled by Zephyr not by the HAL if that's the case.

teburd · 2025-08-21T15:36:14Z

drivers/i2c/i2c_mspm0.c

+	DL_I2C_startControllerTransfer(config->base, data->addr, DL_I2C_CONTROLLER_DIRECTION_TX,
+				       data->msg.len);
+
+	while (!(DL_I2C_getControllerStatus(config->base) & DL_I2C_CONTROLLER_STATUS_IDLE)) {


Tight polling loops like this aren't inherently wrong but typically there's an interrupt signal available.

Would recommend changing the driver, if possible, to use an interrupt (event driven) state machine that is kicked off by the transfer function, and completed when the state machine signals back to the thread that had called transfer blocking on a k_sem_take by giving a semaphore.

If you really want the tight poll loop here instead, or there's no other option, use a WAIT_FOR() macro with a timeout such that even given a faulty i2c transfer the caller isn't blocked forever and instead may get an error.

https://docs.zephyrproject.org/latest/doxygen/html/group__sys-util.html#ga68eb35df6b4715714312df90209accee

Looking into refactoring transfer to use semaphores

teburd · 2025-08-21T15:36:38Z

drivers/i2c/i2c_mspm0.c

+	while (!(DL_I2C_getControllerStatus(config->base) & DL_I2C_CONTROLLER_STATUS_IDLE)) {
+	}
+
+	if (data->state == I2C_MSPM0_TIMEOUT) {


And I maybe spoke too soon if there's a hardware timeout available.

There is a configurable SCL low hardware timeout available

teburd · 2025-08-21T15:39:03Z

dts/bindings/i2c/ti,mspm0-i2c.yaml

+  reg:
+    required: true
+
+  interrupts:


I don't see the interrupts being used?

teburd · 2025-08-21T15:39:13Z

dts/arm/ti/mspm0/l/mspm0lx22x.dtsi

+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x400f2000 0x2000>;
+			interrupts = <26 0>;


It doesn't seem like the driver supports interrupts

Interrupts are used for controller and target logic

d-philpot · 2025-08-22T19:22:32Z

This driver needs lot of re-factor. In summary,

ISR context is handling all the data path, which needs to be abstracted.

Target and Controller support needs to be split.

Multi target support needs to be compile time based on devicetree target nodes.

Current usage of data section is high and needs to be optimized based on rodata / data place-holding.

Current code base is not compilable as well. So IMO it makes sense to put in DRAFT until it's ready for review.

The code base is compliable. Target support is split and optional from controller via kconfig define. Multi target support is compile time based on Kconfig defines

d-philpot · 2025-08-27T19:27:47Z

@teburd Ping for re-review. Refactored transmit logic to use semaphores instead of busy wait looping

tbursztyka

ISR handler would gain in clarity being split: irq types handled in dedicated inline functions and as noted already: target stuff being on their own as well.

drivers/i2c/i2c_mspm0.c

github-actions · 2025-09-11T21:47:55Z

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

lsd-he360 · 2025-12-01T03:59:59Z

drivers/i2c/i2c_mspm0.c

+/* Driverlib includes */
+#include <ti/driverlib/dl_i2c.h>
+
+#define TI_MSPM0_CONTROLLER_INTERRUPTS                                                             \


Can you add an "I2C" prefix in the name?

lsd-he360 · 2025-12-01T04:00:06Z

drivers/i2c/i2c_mspm0.c

+	 DL_I2C_INTERRUPT_CONTROLLER_RXFIFO_TRIGGER | DL_I2C_INTERRUPT_CONTROLLER_STOP |        \
+	 DL_I2C_INTERRUPT_CONTROLLER_TX_DONE | DL_I2C_INTERRUPT_TIMEOUT_A)
+
+#define TI_MSPM0_TARGET_INTERRUPTS                                                                 \


Can you add an "I2C" prefix in the name?

lsd-he360 · 2025-12-01T04:08:56Z

I am trying to use the I2C shell to scan, read, and write on the LP_MSPM0G3519 board as well as a custom board. It simply hangs for me with this driver implementation. ULPCLK frequency is 40 MHz. I2C controller is configured for 100 kHz.

lsd-he360 · 2025-12-03T14:17:45Z

drivers/i2c/i2c_mspm0.c

+
+	data->state = I2C_MSPM0_IDLE;
+
+sem_give:


This generates warning: label 'sem_give' defined but not used warning when CONFIG_I2C_SCL_LOW_TIMEOUT is 0.

Changing the value of the timeout as a default to 1 second removes this issue and follows best practices. I believe no further action is necessary

lsd-he360 · 2025-12-04T15:19:30Z

drivers/i2c/i2c_mspm0.c

+#include <soc.h>
+
+#include <zephyr/logging/log.h>
+LOG_MODULE_REGISTER(i2c_mspm0, CONFIG_I2C_LOG_LEVEL);


Can you please move this to be after the header includes?

Moved below all headers

lsd-he360 · 2025-12-04T15:20:08Z

drivers/i2c/i2c_mspm0.c

+	I2C_MSPM0_TARGET_TX_INPROGRESS,
+	I2C_MSPM0_TARGET_RX_INPROGRESS,
+	I2C_MSPM0_TIMEOUT,
+	I2C_MSPM0_ERROR


Nit...

Suggested change

I2C_MSPM0_ERROR

I2C_MSPM0_ERROR,

d-philpot · 2025-12-04T21:31:02Z

I am trying to use the I2C shell to scan, read, and write on the LP_MSPM0G3519 board as well as a custom board. It simply hangs for me with this driver implementation. ULPCLK frequency is 40 MHz. I2C controller is configured for 100 kHz.

@lsd-he360 Can you provide more detail on your setup? Have you provided sufficient pull ups? I am able to scan for devices, read and write

lsd-he360 · 2025-12-05T15:08:03Z

I am trying to use the I2C shell to scan, read, and write on the LP_MSPM0G3519 board as well as a custom board. It simply hangs for me with this driver implementation. ULPCLK frequency is 40 MHz. I2C controller is configured for 100 kHz.

@lsd-he360 Can you provide more detail on your setup? Have you provided sufficient pull ups? I am able to scan for devices, read and write

@d-philpot, did you have to modify the LP_MSPM0G3519 board or did it just work out of the gate for you?

On the custom board, we have 10K pull-ups on SCL/SDA lines. FWIW, we have the ability to make another MCU (RPI PICO for now) the controller, and it works okay with the RPI PICO I2C driver.

One other thing I wanted to mention is that if I reverse the order of powerenable and reset calls in init() and make it just like in the implementation linked below, it seems to work. Even though reset and then powerenable works, this order does not make sense to me because I would think you should enable the core before you reset.

https://github.com/msp-ti/zephyr/blob/mspm0_dev_stable/drivers/i2c/i2c_mspm0.c

mshawkyVT · 2025-12-05T15:29:40Z

I am trying to use the I2C shell to scan, read, and write on the LP_MSPM0G3519 board as well as a custom board. It simply hangs for me with this driver implementation. ULPCLK frequency is 40 MHz. I2C controller is configured for 100 kHz.

@lsd-he360 Can you provide more detail on your setup? Have you provided sufficient pull ups? I am able to scan for devices, read and write

@d-philpot, did you have to modify the LP_MSPM0G3519 board or did it just work out of the gate for you?

On the custom board, we have 10K pull-ups on SCL/SDA lines. FWIW, we have the ability to make another MCU (RPI PICO for now) the controller, and it works okay with the RPI PICO I2C driver.

One other thing I wanted to mention is that if I reverse the order of powerenable and reset calls in init() and make it just like in the implementation linked below, it seems to work. Even though reset and then powerenable works, this order does not make sense to me because I would think you should enable the core before you reset.

https://github.com/msp-ti/zephyr/blob/mspm0_dev_stable/drivers/i2c/i2c_mspm0.c

@d-philpot we have also scoped the I2C lines and no data or clock come out with the new implementation. This makes it seem unlikely that the pull-up resistors are the culprits. I'm curious on your setup and how the code was tested. Can you provide more details on that?

lsd-he360 · 2025-12-05T18:33:19Z

drivers/i2c/i2c_mspm0.c

+		transaction_msg.buf = transaction_buf;
+		transaction_msg.len = transaction_len;
+
+		k_sem_take(data->i2c_busy_sem, K_FOREVER);


I think you could hang here forever if you are doing an i2c_write_read for example

https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/i2c.h#L1495

In the second iteration of the for loop (for the second message), you would attempt to take the sem, but it is not reelased/given until you are out of the loop on line 420.

lsd-he360 · 2025-12-05T21:59:44Z

I am trying to use the I2C shell to scan, read, and write on the LP_MSPM0G3519 board as well as a custom board. It simply hangs for me with this driver implementation. ULPCLK frequency is 40 MHz. I2C controller is configured for 100 kHz.

@lsd-he360 Can you provide more detail on your setup? Have you provided sufficient pull ups? I am able to scan for devices, read and write

@d-philpot, did you have to modify the LP_MSPM0G3519 board or did it just work out of the gate for you?

On the custom board, we have 10K pull-ups on SCL/SDA lines. FWIW, we have the ability to make another MCU (RPI PICO for now) the controller, and it works okay with the RPI PICO I2C driver.

One other thing I wanted to mention is that if I reverse the order of powerenable and reset calls in init() and make it just like in the implementation linked below, it seems to work. Even though reset and then powerenable works, this order does not make sense to me because I would think you should enable the core before you reset.

https://github.com/msp-ti/zephyr/blob/mspm0_dev_stable/drivers/i2c/i2c_mspm0.c

@d-philpot, the TRM does recommend doing a RESET and then ENABLE just like the code I linked did.

d-philpot · 2025-12-09T17:34:28Z

@lsd-he360 @mshawkyVT I am not performing any additional modification the LP_MSPM0G3519 board. I have tested this implementation with various sensors and an application running the I2C shell.

How are you configuring the pins in the overlay? The pins need to be set for input, open drain, and bias disable.

lsd-he360 · 2025-12-09T17:48:45Z

@lsd-he360 @mshawkyVT I am not performing any additional modification the LP_MSPM0G3519 board. I have tested this implementation with various sensors and an application running the I2C shell.

How are you configuring the pins in the overlay? The pins need to be set for input, open drain, and bias disable.

I am just using the pin configs from here:

https://github.com/lsd-he360/hal_ti/blob/194bf73c8607e303ed5700ab1c247ff9ddda27f3/dts/ti/mspm0/g/mspm0gx51x-pinctrl.dtsi#L2301

https://github.com/lsd-he360/hal_ti/blob/194bf73c8607e303ed5700ab1c247ff9ddda27f3/dts/ti/mspm0/g/mspm0gx51x-pinctrl.dtsi#L2270

d-philpot · 2025-12-09T21:36:07Z

@lsd-he360 Updated PR w.r.t reset consideration.

Also, can you provide more details on how your setup is failing? Do the transfers timeout? I've just tested it now with a LED driver sensor and see no issues reading or writing. I am glad to hop on a call if you would like.

sonarqubecloud · 2025-12-09T21:58:05Z

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

d-philpot · 2025-12-16T16:47:51Z

@teburd @parthitce @ssekar15 @tbursztyka ping for review

lsd-he360 · 2025-12-16T17:39:53Z

@lsd-he360 Updated PR w.r.t reset consideration.

Also, can you provide more details on how your setup is failing? Do the transfers timeout? I've just tested it now with a LED driver sensor and see no issues reading or writing. I am glad to hop on a call if you would like.

It was hanging with your older implementation where there were two issues:

enabling and THEN resetting but TRM recommended resetting and THEN enabling
not releasing semaphore in the loop

I can give it a try again with your most recent changes

fabiobaltieri · 2025-12-17T11:10:56Z

drivers/i2c/i2c_mspm0.c

+#define I2C_TI_MSPM0_CONTROLLER_INTERRUPTS                                                     \
+	(DL_I2C_INTERRUPT_CONTROLLER_ARBITRATION_LOST | DL_I2C_INTERRUPT_CONTROLLER_NACK |         \
+	 DL_I2C_INTERRUPT_CONTROLLER_RXFIFO_TRIGGER | DL_I2C_INTERRUPT_CONTROLLER_STOP |           \
+	 DL_I2C_INTERRUPT_CONTROLLER_TX_DONE | DL_I2C_INTERRUPT_TIMEOUT_A)
+
+#define I2C_TI_MSPM0_TARGET_INTERRUPTS                                                         \
+	(DL_I2C_INTERRUPT_TARGET_RX_DONE | DL_I2C_INTERRUPT_TARGET_TXFIFO_EMPTY |                  \
+	 DL_I2C_INTERRUPT_TARGET_START | DL_I2C_INTERRUPT_TARGET_STOP |                            \
+	 DL_I2C_INTERRUPT_TIMEOUT_A)


nit: align the \

Aligned at 4 tab indent to line 80

Scratch that, aligned with 8-tab indent but using spaces after coding content as per clang-format suggestions

fabiobaltieri · 2025-12-17T11:12:44Z

drivers/i2c/i2c_mspm0.c

+	uint32_t transfer_count;
+	uint32_t transfer_len;
+	uint8_t *msg_buf;
+#if (IS_ENABLED(CONFIG_I2C_TARGET))


these should all be ifdef CONFIG_I2C_TARGET. IS_ENABLED is for use in code like if (IS_ENABLED(...

fabiobaltieri · 2025-12-17T11:14:46Z

drivers/i2c/i2c_mspm0.c

+	bool is_target;
+};
+
+#if (CONFIG_I2C_SCL_LOW_TIMEOUT != 0)


nit: no need for the parenthesis

fabiobaltieri · 2025-12-17T11:16:03Z

drivers/i2c/i2c_mspm0.c

+		ret = -EINVAL;
+		goto out;


just return -EINVAL? why the goto, there's nothing to unwind, same everywhere in this function

Noted. Change made with goto out removed

fabiobaltieri · 2025-12-17T11:17:37Z

drivers/i2c/i2c_mspm0.c

+	 * This function works out to be ceil(clockRate/(desiredSpeed*10)) - 1
+	 */
+	period = clock_rate / (desired_speed * 10);
+	period -= (clock_rate % (desired_speed * 10) == 0) ? 1 : 0;


bit confused, why is the -1 only on the modulo condition? can't wrap my head around it

I cleaned this up to be more clearly a ceiling round

fabiobaltieri · 2025-12-17T11:28:03Z

drivers/i2c/i2c_mspm0.c

+	static const struct mspm0_sys_clock mspm0_i2c_clockSys##index =                            \
+		MSPM0_CLOCK_SUBSYS_FN(index);                                                      \
+                                                                                                   \
+	I2C_MSPM0_CONFIG_IRQ_FUNC_DECLARE(index);                                                  \


just use I2C_MSPM0_CONFIG_IRQ_FUNC here then you don't have to declare it in the first place

Fixed in the latest version. DECLARE removed

fabiobaltieri · 2025-12-17T11:32:29Z

drivers/i2c/i2c_mspm0.c

+#define MERGE_BUF_SIZE(index)                                                                      \
+	COND_CODE_1(DT_NODE_HAS_PROP(DT_NODELABEL(i2c##index), merge_buf_size),			\
+			(DT_PROP(DT_NODELABEL(i2c##index), merge_buf_size)), (0))


index here should only be used with INST macros, here you are adding wrong assumptions, imagine if you had i2c0 i2c1 i2c2 labels and i2c1 is disabled, then i2c2 would get index 1 and this would start picking properties from the wrong devices in very hard to debug way

DT_INST_NODE_HAS_PROP(index, merge_buf_size) (if I understand what you are trying to do correctly)

fabiobaltieri · 2025-12-17T11:34:56Z

drivers/i2c/i2c_mspm0.c

+	IF_ENABLED(USES_MERGE_BUF(index),                                                          \
+		(static uint8_t mspm0_i2c_msg_buf_##index[MERGE_BUF_SIZE(index)];));       \


I suggest indenting this as if it was an #IF, as it stand it's hard to track, I"d do

IF_ENABLED(USES_MERGE_BUF(index), ( \ static uint8_t mspm0_i2c_msg_buf_##index[MERGE_BUF_SIZE(index)]; \ )); \ \ static const struct i2c_mspm0_config i2c_mspm0_cfg_##index = { \

fabiobaltieri · 2025-12-17T11:35:23Z

drivers/i2c/i2c_mspm0.c

+		.merge_buf_size = MERGE_BUF_SIZE(index),                                           \
+		IF_ENABLED(USES_MERGE_BUF(index),                                                  \
+			(.merge_buf = mspm0_i2c_msg_buf_##index,)) .pinctrl =      \
+						   PINCTRL_DT_INST_DEV_CONFIG_GET(index),          \
+					  .irq_config_func = i2c_mspm0_irq_config_func_##index,    \
+					  .i2c_clock_config = {                                    \
+						  .clockSel = MSPM0_CLOCK_PERIPH_REG_MASK(         \
+							  DT_INST_CLOCKS_CELL(index, clk)),        \
+						  .divideRatio = DL_I2C_CLOCK_DIVIDE_1,            \
+					  }};                                                      \
+                                                                                                   \


the indentation here is all over the place

fabiobaltieri · 2025-12-17T11:37:35Z

drivers/i2c/i2c_mspm0.c

+	static K_SEM_DEFINE(i2c_busy_sem##index, 1, 1);                                            \
+	static K_SEM_DEFINE(device_sync_sem##index, 0, 1);                                         \
+	static struct i2c_mspm0_data i2c_mspm0_data_##index = {                                    \
+		.i2c_busy_sem = &i2c_busy_sem##index,                                              \
+		.device_sync_sem = &device_sync_sem##index,                                        \
+	};                                                                                         \


drop this whole block, allocate the semaphore as directly on the structure (not as a pointer), initialize them in runtime, doing the init statically here waste loads of flash for the static initialization and few bytes of RAM

Semaphores are now initialized at runtime as you suggested. I learned something on this one!

lsd-he360 · 2026-01-22T02:38:43Z

west.yml

Can you please change the commit message header to contain: manifest: hal_ti: <msg>?

This commit was not needed in the new push as the hal_ti has been upstreamed

Ayush1325 · 2026-02-25T12:40:39Z

@d-philpot Any updates? I would like to use mspm0 i2c for some BeagleBoard stuff.

JFMSP · 2026-03-03T15:18:26Z

Hi Zephyr community,

Dylan has had to step down from zephyr development at TI, for the time being I'll be taking back up the reigns for this PR. I've gone ahead and tried to address all comments as best I can before re-pushing.

We also have some i2c testing framework on the TI side now and I have confidence in behavior of merging and timeout features on both target and controller side.

Compliance checks are passing for me locally, but if anything shows up below I'll be quick to fix it

teburd · 2026-03-03T16:02:10Z

Hi Zephyr community,

Dylan has had to step down from zephyr development at TI, for the time being I'll be taking back up the reigns for this PR. I've gone ahead and tried to address all comments as best I can before re-pushing.

We also have some i2c testing framework on the TI side now and I have confidence in behavior of merging and timeout features on both target and controller side.

Compliance checks are passing for me locally, but if anything shows up below I'll be quick to fix it

Can you run some of the in tree tests and post results? The i2c_ram test in particular covers the API well. I do not have mspm0. That would help build confidence quickly for me that the PR is in reasonable shape and I'd look mostly for structural issues then.

JFMSP · 2026-03-03T17:06:42Z

Hi Zephyr community,
Dylan has had to step down from zephyr development at TI, for the time being I'll be taking back up the reigns for this PR. I've gone ahead and tried to address all comments as best I can before re-pushing.
We also have some i2c testing framework on the TI side now and I have confidence in behavior of merging and timeout features on both target and controller side.
Compliance checks are passing for me locally, but if anything shows up below I'll be quick to fix it

Can you run some of the in tree tests and post results? The i2c_ram test in particular covers the API well. I do not have mspm0. That would help build confidence quickly for me that the PR is in reasonable shape and I'd look mostly for structural issues then.

Hi @teburd,

I don't have an I2C Ram chipset on hand locally, but I can elaborate on the testing that we do between two M0's

At 100k, 400k, and 1MHz, we do:

Single byte write and read, target echos
Burst bytes write and read target echos (8 byte and 32 byte)
Repeated start test with write_read
Merging of different messages including read write, read read, and write write
Address NAK handling (controller side)

JFMSP · 2026-03-03T21:02:43Z

Latest push fixed some whitespace fixes based on compliance checks. Got clarity from Discord on the use of 8 tab indents

Ayush1325

I have tested i2c target api on mspm0l1117 running greybus and pocketbeagle 2 running linux with gb-i2c-host driver

fabiobaltieri · 2026-03-09T16:08:17Z

drivers/i2c/i2c_mspm0.c

+static int i2c_mspm0_reset_controller(const struct device *dev)
+{
+	const struct i2c_mspm0_config *config = dev->config;
+	int ret = 0;


doesn't look like this is used? just return 0 at the end

Good point. Addressed in latest push.

fabiobaltieri · 2026-03-09T16:09:30Z

drivers/i2c/i2c_mspm0.c

+	bool additionalMessages = (i + 1 < num_msgs);
+	bool allowMerge = !(msgs[i].flags & I2C_MSG_STOP) && !(msgs[i + 1].flags & I2C_MSG_RESTART);
+	bool sameDir = ((msgs[i].flags & I2C_MSG_READ) == (msgs[i + 1].flags & I2C_MSG_READ));
+	bool merge_next = additionalMessages && allowMerge && sameDir;
+
+	return merge_next;


wrong camelcase, should be additional_messages allow_merge etc... also you can drop the outer parenthesis on the first and third varaiable, merge_next you can just return the value directly

noted. Changed to camel_case to follow style guide. Thanks for catching this!

Includes driver and dts binding changes for I2C support Signed-off-by: Jackson Farley <j-farley@ti.com> Signed-off-by: Dylan Philpot <d-philpot@ti.com>

Adds devicetree entries for different I2C peripherals on MSPM0 devices. Signed-off-by: Dylan Philpot <d-philpot@ti.com>

Added i2c pin information to MSPM0 launchpads Signed-off-by: Dylan Philpot <d-philpot@ti.com> Signed-off-by: Jackson Farley <j-farley@ti.com>

sonarqubecloud · 2026-03-10T17:01:16Z

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added platform: Texas Instruments MSPM0 area: I2C platform: TI SimpleLink Texas Instruments SimpleLink MCU labels Aug 19, 2025

zephyrbot requested review from ssekar15, teburd, vaishnavachath and vanti August 19, 2025 03:22

zephyrbot assigned teburd Aug 19, 2025

pdgendt previously requested changes Aug 19, 2025

View reviewed changes

drivers/i2c/i2c_mspm0.c Outdated Show resolved Hide resolved

d-philpot force-pushed the i2c_dev branch from 72c1da1 to cda6ccf Compare August 19, 2025 14:37

parthitce linked an issue Aug 20, 2025 that may be closed by this pull request

I2C linumiz/zephyr#70

Open

parthitce requested changes Aug 20, 2025

View reviewed changes

teburd requested changes Aug 21, 2025

View reviewed changes

d-philpot force-pushed the i2c_dev branch 3 times, most recently from 1f122c6 to b708dc5 Compare August 27, 2025 18:27

d-philpot requested review from pdgendt and teburd August 27, 2025 19:27

tbursztyka requested changes Sep 9, 2025

View reviewed changes

drivers/i2c/i2c_mspm0.c Outdated Show resolved Hide resolved

drivers/i2c/i2c_mspm0.c Outdated Show resolved Hide resolved

d-philpot force-pushed the i2c_dev branch from b708dc5 to 02e52af Compare September 11, 2025 21:46

zephyrbot added the area: Charger label Sep 11, 2025

zephyrbot requested a review from rriveramcrus September 11, 2025 21:47

github-actions bot added manifest manifest-hal_ti DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Sep 11, 2025

d-philpot force-pushed the i2c_dev branch from 02e52af to 914b39b Compare September 11, 2025 21:59

lsd-he360 reviewed Dec 1, 2025

View reviewed changes

lsd-he360 reviewed Dec 3, 2025

View reviewed changes

lsd-he360 reviewed Dec 4, 2025

View reviewed changes

lsd-he360 reviewed Dec 5, 2025

View reviewed changes

fabiobaltieri reviewed Dec 17, 2025

View reviewed changes

lsd-he360 reviewed Jan 22, 2026

View reviewed changes

Ayush1325 previously approved these changes Mar 9, 2026

View reviewed changes

fabiobaltieri reviewed Mar 9, 2026

View reviewed changes

d-philpot and others added 3 commits March 10, 2026 11:22

drivers: add I2C mspm0 driver

926d4f7

Includes driver and dts binding changes for I2C support Signed-off-by: Jackson Farley <j-farley@ti.com> Signed-off-by: Dylan Philpot <d-philpot@ti.com>

dts: add I2C nodes for MSPM0

635df7a

Adds devicetree entries for different I2C peripherals on MSPM0 devices. Signed-off-by: Dylan Philpot <d-philpot@ti.com>

boards: add I2C information into the MSPM0

4631f91

Added i2c pin information to MSPM0 launchpads Signed-off-by: Dylan Philpot <d-philpot@ti.com> Signed-off-by: Jackson Farley <j-farley@ti.com>

		IF_ENABLED(USES_MERGE_BUF(index), \
		(static uint8_t mspm0_i2c_msg_buf_##index[MERGE_BUF_SIZE(index)];)); \

Conversation

d-philpot commented Aug 19, 2025

Uh oh!

Uh oh!

parthitce left a comment • 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!

teburd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-philpot Aug 22, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-philpot commented Aug 22, 2025

Uh oh!

d-philpot commented Aug 27, 2025

Uh oh!

tbursztyka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lsd-he360 commented Dec 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

d-philpot commented Dec 4, 2025

Uh oh!

lsd-he360 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mshawkyVT commented Dec 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lsd-he360 commented Dec 5, 2025

Uh oh!

d-philpot commented Dec 9, 2025

Uh oh!

lsd-he360 commented Dec 9, 2025

Uh oh!

d-philpot commented Dec 9, 2025

Uh oh!

sonarqubecloud bot commented Dec 9, 2025

Quality Gate passed

Uh oh!

d-philpot commented Dec 16, 2025

Uh oh!

lsd-he360 commented Dec 16, 2025

Uh oh!

Choose a reason for hiding this comment

parthitce left a comment •

edited

Loading

d-philpot Aug 22, 2025 •

edited

Loading

github-actions bot commented Sep 11, 2025 •

edited

Loading

lsd-he360 commented Dec 5, 2025 •

edited

Loading

JFMSP Mar 3, 2026 •

edited

Loading