Skip to content

Conversation

d-philpot
Copy link
Contributor

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

@pdgendt pdgendt dismissed their stale review August 19, 2025 14:39

comment addressed

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

@parthitce parthitce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@teburd teburd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@d-philpot d-philpot Aug 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking into refactoring transfer to use semaphores

while (!(DL_I2C_getControllerStatus(config->base) & DL_I2C_CONTROLLER_STATUS_IDLE)) {
}

if (data->state == I2C_MSPM0_TIMEOUT) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a configurable SCL low hardware timeout available

reg:
required: true

interrupts:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the interrupts being used?

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem like the driver supports interrupts

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interrupts are used for controller and target logic

@d-philpot
Copy link
Contributor Author

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 d-philpot force-pushed the i2c_dev branch 3 times, most recently from 1f122c6 to b708dc5 Compare August 27, 2025 18:27
@d-philpot d-philpot requested review from teburd and pdgendt August 27, 2025 19:27
@d-philpot
Copy link
Contributor Author

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

Copy link
Contributor

@tbursztyka tbursztyka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

github-actions bot commented Sep 11, 2025

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

Name Old Revision New Revision Diff
hal_ti zephyrproject-rtos/hal_ti@d062844 zephyrproject-rtos/hal_ti#66 zephyrproject-rtos/hal_ti#66/files

DNM label due to: 1 project with PR revision

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

@github-actions github-actions bot added manifest manifest-hal_ti DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Sep 11, 2025
In flight PR changes default pin properties for I2C.

Signed-off-by: Dylan Philpot <[email protected]>
Copy link
Contributor

@tbursztyka tbursztyka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to find some time to dig into the logic details later

@rriveramcrus
Copy link
Contributor

I don't see anything here to review on the charger side of things, so I am going to remove the charger label if no one has any objections.

@d-philpot d-philpot changed the title Add I2C driver support for MSPM0 drivers: add i2c driver support for MSPM0 Sep 24, 2025
@d-philpot
Copy link
Contributor Author

@teburd @tbursztyka @parthitce @ssekar15 ping for review

@teburd
Copy link
Contributor

teburd commented Sep 24, 2025

@d-philpot you need to correct the issues pointed out and push your changed here so we can see them, it doesn't seem you've done that yet

I don't see the comments from @tbursztyka addressed yet, and they are valid

@d-philpot
Copy link
Contributor Author

@d-philpot you need to correct the issues pointed out and push your changed here so we can see them, it doesn't seem you've done that yet

I don't see the comments from @tbursztyka addressed yet, and they are valid

Addressed in latest push

Includes driver and dts binding changes for I2C support

Signed-off-by: Dylan Philpot <[email protected]>
Adds devicetree entries for different I2C peripherals
on MSPM0 devices.

Signed-off-by: Dylan Philpot <[email protected]>
Adds I2C peripheral for launchpad use.

Signed-off-by: Dylan Philpot <[email protected]>
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Charger area: I2C DNM (manifest) This PR should not be merged (controlled by action-manifest) manifest manifest-hal_ti platform: ADI Analog Devices, Inc. platform: Microchip MEC Microchip MEC Platform platform: Microchip SAM Microchip SAM Platform (formerly Atmel SAM) platform: Texas Instruments MSPM0 platform: TI SimpleLink Texas Instruments SimpleLink MCU platform: TI Texas Instruments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

I2C
7 participants