gemstonedevteam opened a new pull request, #20136:
URL: https://github.com/apache/nuttx/pull/20136
> Opening as draft since this depends on #20116 will mark ready once that
lands.
### Summary
* Adds an I2C master driver for the AM67 I2C instances, following the TI
flow:
a transfer completes on `ARDY` rather than on the data-ready bits alone,
which is what the K3 controller actually signals.
* Bring-up is lazy. The controller is initialised on the first transfer
rather
than in `am67_i2cbus_initialize()`, because the Linux Device Manager
enables
the I2C clocks late and touching the bus during early board init is not
safe
on this part.
* `am67_i2cbus_uninitialize()` clears the initialised flag when the last
reference goes away, so the next transfer brings the hardware up again
rather than talking to a torn-down controller.
* t3-gem-o1 registers WKUP_I2C0 as `/dev/i2c2`; MAIN I2C0 is wired but not
populated on this board.
### Impact
* Is new feature added? **YES** — I2C support for AM67.
* Impact on user? **NO** — new driver, opt-in by Kconfig.
* Impact on build? **NO**.
* Impact on hardware? **YES** — arch/arm/am67 and board t3-gem-o1.
* Impact on documentation? **YES** — provided in this PR (second commit).
* Impact on security? **NO**.
* Impact on compatibility? **NO** — additive.
* Anything else? Depends on PR 3.
### Testing
```
Build Host(s): Pardus GNU/Linux 25 (Debian 13 base), x86_64, host gcc 14
Toolchain: arm-none-eabi-gcc 14.2.1 20241119 (15:14.2.rel1-1)
Target: arm / TI AM67 (J722S) Cortex-R5F, board t3-gem-o1:nsh
nuttx-apps: 5a7ab4200
Loaded on the main-domain R5F by Linux remoteproc; console on UART-MAIN1.
```
Testing logs before change: no I2C support on this arch.
The version string in the logs is from the tested build; the commits were
GPG-signed afterwards, which rewrites hashes. The code is unchanged.
Testing logs after change:
```
make distclean && ./tools/configure.sh t3-gem-o1:nsh && make -j
-> nuttx ELF 534980 bytes, 0 compiler warnings
Console:
nsh> i2c dev -b 2 0x03 0x77
NOTE: Some devices may not appear with this scan.
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh> i2c get -b 2 -a 0x40 -r 0x00
READ Bus: 2 Addr: 40 Subaddr: 00 Value: 5a
nsh>
Test plan result:
console_alive PASS prompt responsive
version PASS NuttX version 0.0.0 218de36161 Sep 10 2026
13:48:24 t3-gem-o1:nsh
procfs PASS procfs readable
tasks PASS 2 task lines
dev_nodes PASS all expected nodes present
i2c_scan PASS found 0x30, 0x40, 0x51, 0x68
i2c_read PASS 0x5a
i2c_repeat PASS 5/5 consistent reads
PASS=8
i2c dev -b 2 0x03 0x77 -> 0x30, 0x40, 0x51, 0x68
i2c get -b 2 -a 0x40 -r 0x00 x5 -> 0x5a each time (lazy re-init verified)
```
RTC read, captured 2026-09-11. The scan shows a device ACKing its address
and the reads above show transfers completing; this shows the bus carrying
data that changes.
```
nsh> i2c get -b 2 -a 0x68 -r 0x00
READ Bus: 2 Addr: 68 Subaddr: 00 Value: 36
nsh> sleep 3
nsh> i2c get -b 2 -a 0x68 -r 0x00
READ Bus: 2 Addr: 68 Subaddr: 00 Value: 39
nsh> sleep 3
nsh> i2c get -b 2 -a 0x68 -r 0x00
READ Bus: 2 Addr: 68 Subaddr: 00 Value: 43
The seconds register advances 36 -> 39 -> 43 across two 3 s waits. The
step 39 -> 43 is a BCD carry rather than 0x3D, which confirms the byte is
BCD and not a raw counter. The board has no backup cell, so the RTC
restarts from zero at power-up and only the tick is meaningful.
```
### PR verification Self-Check
* [x] This PR introduces only one functional change.
* [x] I have updated all required description fields above.
* [x] My PR adheres to Contributing Guidelines and Documentation.
* [ ] My PR is still work in progress (not ready for review).
* [x] My PR is ready for review and can be safely merged into a codebase.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
