Skip to content

[26.04_linux-nvidia-bos] i2c: mediatek: add ACPI/MT8901 support and gpiolib zero-debounce fix - #518

Closed
kmaddaraki wants to merge 2 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
kmaddaraki:i2c-device-clean-stack-bos
Closed

[26.04_linux-nvidia-bos] i2c: mediatek: add ACPI/MT8901 support and gpiolib zero-debounce fix#518
kmaddaraki wants to merge 2 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
kmaddaraki:i2c-device-clean-stack-bos

Conversation

@kmaddaraki

@kmaddaraki kmaddaraki commented Aug 3, 2026

Copy link
Copy Markdown

Two small SAUCE patches to bring up the MediaTek MT8901 I²C host controller under ACPI on 26.04 linux-nvidia-bos.

gpiolib: acpi: route acpi_dev_gpio_irq_wake_get_by() debounce through the warn-only wrapper

Mainline commit e4a77f9 ("gpiolib: acpi: Make set debounce errors non fatal") added the warn-only acpi_gpio_set_debounce_timeout() wrapper and converted two of the three ACPI call sites that program a debounce timeout. The third, in acpi_dev_gpio_irq_wake_get_by(), still returns the raw error: on firmware whose _CRS declares a GpioInt with a DebounceTimeout on an edge-triggered pin, the MediaTek EINT driver rejects set_config(PIN_CONFIG_INPUT_DEBOUNCE) with -EINVAL, the error propagates through acpi_dev_gpio_irq_get(), and i2c_hid_acpi fails probe with HID over i2c has not been provided an Int IRQ — the internal keyboard never enumerates. Convert the remaining call site to the same wrapper so all three ACPI debounce paths behave consistently: the rejection is logged and the IRQ is still delivered. Core gpiolib.c semantics are untouched.

i2c: mediatek: add ACPI/MT8901 support and firmware-managed clocks
Adds ACPI binding to the DT-only i2c-mt65xx driver so the MT8901 I²C controllers enumerate under NVDA0200:

  • New mt8901_compat (v3 register layout, default_parent_rate=124.8 MHz) and an acpi_match_table entry NVDA0200 → mt8901_compat.

  • Switch probe to device_get_match_data() and fwnode-aware device_property_read_*() so DT and ACPI share the same code path.

  • device_set_node(&adap->dev, dev_fwnode(&pdev->dev)) so i2c_acpi_register_devices() walks the child HID nodes and instantiates them.

  • Gate devm_clk_get() for main/dma on has_acpi_companion() — use devm_clk_get_optional() for the ACPI path (firmware keeps those clocks running and does not expose them via the Linux clk framework), and fall back to dev_comp->default_parent_rate in mtk_i2c_set_speed() when no clock handle is available.

DT behaviour is unchanged: both device_get_match_data() and device_property_read_*() fall through to the existing OF helpers for DT-described nodes, and the DT clock path is preserved.

LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-7.0/+bug/2163407

@nirmoy nirmoy added the help wanted Extra attention is needed label Aug 3, 2026
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ✅ All checks passed

Details
Checking 2 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ be4ca719d290 │ [SAUCE] gpiolib: acpi: route acpi_dev_gpio_irq_wake_get_by() deb │ N/A        │ N/A     │ kmaddara                  │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ dfc63029af72 │ [SAUCE] i2c: mediatek: add acpi/mt8901 support and firmware-mana │ N/A        │ N/A     │ zhang, kmaddara           │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

@nirmoy

nirmoy commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

BaseOS Kernel Review

Summary

No issues found across the reviewed commits.

Findings: no problems found

Latest watcher review: open review

Generated test plan: open test plan

Kernel deb build: successful (download debs, 4 files)

Head: be4ca719d290

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

@nvmochs

nvmochs commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

@kmaddaraki

  • What are the upstream plans for these patches?
  • What is the target platform for this? Spark?
    • Related, is there a NVbug associated with these patches?
  • This same PR needs to also be submitted against the 7.0-lts kernel (26.04_linux-nvidia)

Additionally, my review with Codex had one finding:

Medium: drivers/i2c/busses/i2c-mt65xx.c:1390 now defaults missing clock-div to 1 for both ACPI and DT. The comment says this is for ACPI, but DT still uses this same parser, and the binding requires clock-div at Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml:110. Previously a missing or bad DT clock-div failed probe; now it silently probes with different timing. I’d gate the default on has_acpi_companion(i2c->dev) and keep returning the property-read error for DT.

@kmaddaraki

kmaddaraki commented Aug 4, 2026

Copy link
Copy Markdown
Author

@nvmochs
What are the upstream plans for these patches?

Mediatek has plan to upstream these changes and it will happen around Oct 2026

What is the target platform for this? Spark?

Yes target is Spark

Related, is there a NVbug associated with these patches?

6358429

This same PR needs to also be submitted against the 7.0-lts kernel (26.04_linux-nvidia).

#507

@nvmochs

nvmochs commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator

@nvmochs What are the upstream plans for these patches?

Mediatek has plan to upstream these changes and it will happen around Oct 2026

What is the target platform for this? Spark?

Yes target is Spark

Related, is there a NVbug associated with these patches?

6358429

This same PR needs to also be submitted against the 7.0-lts kernel (26.04_linux-nvidia).

#507

@kmaddaraki Thanks for clarifying.

Please address the codex/claude findings listed here and in PR 507 and then we should be able to get this merged.

@kmaddaraki
kmaddaraki force-pushed the i2c-device-clean-stack-bos branch from 5877724 to cd36a16 Compare August 11, 2026 17:23
@kmaddaraki

Copy link
Copy Markdown
Author

The Codex finding is fixed in v2 — the clock-div default now applies only when an ACPI companion is present; the DT path returns the property-read error as before, so DT behavior is unchanged.

@nvmochs

nvmochs commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

The Codex finding is fixed in v2 — the clock-div default now applies only when an ACPI companion is present; the DT path returns the property-read error as before, so DT behavior is unchanged.

Thanks!

I confirmed this has been fixed along with the other findings from PR 507.

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

Same question I left in #507:

Does the gpiolib commit need to carry a "Fixes" tag?

Fixes: 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings")

housongzhang-maker and others added 2 commits August 12, 2026 11:02
…naged clocks

On MT8901-based platforms the I2C controllers are described through
ACPI (HID NVDA0200) rather than device tree. The upstream i2c-mt65xx
driver is DT-only: no acpi_match_table, no propagation of the ACPI
fwnode to the i2c_adapter device, and clock/timing properties read
through of_property_read_*() helpers that don't operate on ACPI nodes.
Compounding that, on these platforms firmware keeps the controller's
"main" and "dma" clocks running and does not expose them via the
Linux clk framework, so devm_clk_get() returns -ENOENT for both.

Consequently the driver does not bind on ACPI systems: no i2c_adapter
is created, HID-over-I2C never enumerates child devices, and the
internal I2C keyboard stays silent.

Wire up ACPI and accept firmware-managed clocks:

* Add mt8901_compat (v3 register layout, default_parent_rate=124.8 MHz
  as a stand-in for clk_get_rate() when no clock provider is exposed)
  and an acpi_match_table entry NVDA0200 -> mt8901_compat.

* Replace of_device_get_match_data() with device_get_match_data() in
  probe (with a NULL-match check), and switch mtk_i2c_parse_dt() to
  the fwnode-aware device_property_read_*() helpers so DT and ACPI
  share the same probe path.

* Call device_set_node(&adap->dev, dev_fwnode(&pdev->dev)) so the
  ACPI fwnode reaches the i2c_adapter device; without it,
  has_acpi_companion() on the adapter returns 0 and
  i2c_acpi_register_devices() exits early, leaving HID children
  unenumerated.

* Gate devm_clk_get() for "main"/"dma" on has_acpi_companion() - use
  devm_clk_get_optional() in the ACPI branch so absent clocks are
  accepted, and substitute i2c->dev_comp->default_parent_rate when
  mtk_i2c_set_speed() has no clock handle to query.

Signed-off-by: Housong Zhang <housong.zhang@mediatek.com>
Signed-off-by: Kiran Maddaraki <kmaddaraki@nvidia.com>
…ebounce through the warn-only wrapper

Mainline commit e4a77f9 ("gpiolib: acpi: Make set debounce errors
non fatal") introduced acpi_gpio_set_debounce_timeout() and converted
two of the three ACPI call sites that program a debounce timeout to
use it. The wrapper downgrades a set_config(PIN_CONFIG_INPUT_DEBOUNCE)
failure to a dev_warn() so that GPIO controllers which reject that
config (e.g. the MediaTek EINT block used behind pinctrl-paris, which
returns -EINVAL for any debounce request on an edge-triggered pin)
do not fail the whole GpioInt lookup.

The third call site in acpi_dev_gpio_irq_wake_get_by() was not
converted by that commit and still returns the raw -EINVAL from
gpio_set_debounce_timeout(). On ACPI systems whose _CRS declares a
GpioInt with any DebounceTimeout on an edge-triggered pinctrl backend,
that error propagates through acpi_dev_gpio_irq_get() and its
callers, and the affected consumer (e.g. i2c_hid_acpi) fails to
bind - no HID children enumerate.

Route this call site through the same warn-only wrapper so all three
ACPI debounce paths behave consistently.

Fixes: 8dcb7a1 ("gpiolib: acpi: Take into account debounce settings")
Signed-off-by: Kiran Maddaraki <kmaddaraki@nvidia.com>
@kmaddaraki
kmaddaraki force-pushed the i2c-device-clean-stack-bos branch from cd36a16 to be4ca71 Compare August 12, 2026 05:36
@kmaddaraki

Copy link
Copy Markdown
Author

Yes, agreed — added Fixes: 8dcb7a1 ("gpiolib: acpi: Take into account debounce settings")

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

Acked-by: Jamie Nguyen <jamien@nvidia.com>

@nirmoy nirmoy added has_2_acks and removed help wanted Extra attention is needed has_1_ack labels Aug 12, 2026
@clsotog

clsotog commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Acked-by: Carol L Soto <csoto@nvidia.com>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants