JorgeGzm opened a new pull request, #20017:
URL: https://github.com/apache/nuttx/pull/20017
## Summary
The M5Stack Tab5 ships in two hardware variants and the board in tree
supports only the newer one. This adds the older one.
| Variant | Panel | Touch controller |
|---------------|-----------------|-------------------|
| Earlier units | ILI9881C | GT911 (I2C 0x14) |
| Later units | ST7121 / ST7123 | ST7123 (I2C 0x55) |
The panel and the touch controller always come as a pair, so scanning I2C0
identifies the board: a GT911 on 0x14 means an earlier unit, and therefore
an ILI9881C panel. This is the same criterion the Espressif BSP uses.
On an earlier unit today the panel stays lit but black, and the touch
bring-up fails with `failed to register ST7123: -5`.
Two commits, because the touch also needs two fixes in the shared GT9XX
driver, neither of them specific to this board:
- **`input/gt9xx`**. The register write used `I2C_M_NOSTART`, which not
every controller can honour; on ESP32-P4 every write returned
`-ETIMEDOUT`, so the buffer status clear never reached the controller.
And `read()` returned a zero point sample instead of `-EAGAIN` when there
was no contact, which makes the LVGL touchscreen driver loop on
`continue_reading` and stop refreshing the display.
- **`boards/esp32p4-tab5`**. Adds the ILI9881C panel and the GT911 as new
options. The init table comes from the Espressif BSP (Apache-2.0,
credited in the file header); its timings differ from the ST7123 ones, so
they became per panel. The GT911 units have a pull-up to 3V3 on the touch
interrupt line that stops the controller from scanning, so the line is
driven low and no interrupt is used, as the BSP also does.
The commit messages carry the details.
## Impact
No change for the later units: the defaults still select the ST7121 panel
and the ST7123 touch controller, and no defconfig in tree changed. Owners
of an earlier unit select `ESP32P4_TAB5_LCD_ILI9881C` and
`ESP32P4_TAB5_TOUCH_GT911`.
`drivers/input/gt9xx.c` is shared with `pinephone`. The write change puts
identical bytes on the wire. The read change only affects a non blocking
reader with no contact pending; a blocking reader, such as
`apps/examples/touchscreen`, is unaffected. `pinephone:lvgl` builds clean,
but I have no PinePhone to test on and would welcome confirmation.
Switching either choice changes which source is compiled, so an existing
tree needs `make clean` when moving between variants.
## Testing
Host Linux x86_64, riscv-none-elf-gcc 14.2.0, on a Tab5 earlier unit
(ESP32-P4 rev v1.0).
Identifying the board with `esp32p4-tab5:nsh` (0x14 present, 0x55 absent):
```
nsh> i2c dev -b 0 0x03 0x77
0 1 2 3 4 5 6 7 8 9 a b c d e f
10: 10 -- -- -- 14 -- -- -- -- -- -- -- -- -- -- --
30: -- -- 32 -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 41 -- 43 44 -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
```
`esp32p4-tab5:lvgl_term` with both options selected, on that hardware:
```
ILI9881C panel init...
ili9881c: panel ID 98 81 5c
/dev/fb0 ready 720x1280 RGB565 @ 0x48000040
/dev/fb0 registered (ILI9881C)
gt911: product "911" (39 31 31 00) fw 1060
GT911 touchscreen controller initialized!
```
`98 81` is the Ilitek signature, `911` the GT911 product ID, both read from
the chips. The LVGL terminal renders and responds to touch: 589 contacts
over a 45 s window with `CONFIG_DEBUG_INPUT_INFO`, coordinates inside
720x1280. Before the read fix the same instrumentation counted 7498 touch
reads against 1 display refresh in 15 s.
Builds clean: `esp32p4-tab5:lvgl_demo` (defaults), `esp32p4-tab5:lvgl_term`
with ILI9881C plus GT911, the same with ST7123 plus ST7123, and
`pinephone:lvgl`.
`tools/checkpatch.sh -f` passes on every file touched. The one error it
reports in `drivers/input/gt9xx.c` is a missing blank line in `gt9xx_poll()`
already present at 1401179f85. `tools/refresh.sh --silent` was run on the
three defconfigs in tree that mention the affected symbols
(`esp32p4-tab5:lvgl_demo`, `esp32p4-tab5:lvgl_term`, `pinephone:lvgl`);
none changed.
--
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]
