Skip to content

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

Open
kmaddaraki wants to merge 2 commits into
NVIDIA:26.04_linux-nvidiafrom
kmaddaraki:i2c-device-clean-stack
Open

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

Conversation

@kmaddaraki

Copy link
Copy Markdown

Two small SAUCE patches to bring up the MediaTek MT8901 I²C host controller under ACPI on Ubuntu 24.04 nvidia-7.0.

gpiolib: return early in gpio_set_debounce_timeout() for zero debounce
Some GPIO controllers (MediaTek EINT among them) reject set_config(PIN_CONFIG_INPUT_DEBOUNCE, 0) with -EINVAL on edge-triggered lines. When an ACPI _CRS GpioInt/GpioIo declares DebounceTimeout=0, the error propagates through gpiod_get_index() / acpi_dev_gpio_irq_get() and blocks HID-over-I²C from acquiring its interrupt. A debounce timeout of 0 means "no debounce" — nothing to configure — so short-circuit inside gpio_set_debounce_timeout() itself. Fixes all call sites (present and future) without per-site guards.

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.

@nirmoy nirmoy added the help wanted Extra attention is needed label Jul 27, 2026
@nirmoy

nirmoy commented Jul 27, 2026

Copy link
Copy Markdown
Collaborator

BaseOS Kernel Review

Summary

Zero debounce now returns without disabling existing GPIO hardware debounce, while the MediaTek I2C fallback accepts malformed DT and may run the bus at half the requested rate.

Findings: Critical: 0, High: 0, Medium: 2, Low: 0

Latest watcher review: open review

Generated test plan: open test plan

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

Head: 22d6646cc0e9

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

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

Are these patches that you intend to send to the mailing list? If so, I'd suggest doing that first and then referencing the mailing list URL in this PR:

(backported from <lore URL>)

Secondly, I suggest targeting this PR at the following branches instead of 24.04_linux-nvidia-7.0-next:

  • 26.04_linux-nvidia-bos
  • 26.04_linux-nvidia

Canonical helps ensure that the 24.04 kernel source is kept in sync with the 26.04 versions, so no need to target PRs at the 24.04+7.0 branches.

@nvidia-bfigg
nvidia-bfigg force-pushed the 24.04_linux-nvidia-7.0-next branch from dfa0ae4 to a625012 Compare July 27, 2026 15:25
@kmaddaraki
kmaddaraki changed the base branch from 24.04_linux-nvidia-7.0-next to 26.04_linux-nvidia July 28, 2026 04:11
@github-actions

github-actions Bot commented Jul 28, 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 ❌ Errors found

Details
Checking 2 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 22d6646cc0e9 │ [SAUCE] i2c: mediatek: add acpi/mt8901 support and firmware-mana │ N/A        │ N/A     │ zhang, kmaddara           │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ ad27e41c28c4 │ [SAUCE] gpiolib: return early in gpio_set_debounce_timeout() for │ N/A        │ N/A     │ abhsahu, kmaddara         │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

PR metadata:
E: PR targets 26.04_linux-nvidia but body has no https://bugs.launchpad.net/... link

abhsahu and others added 2 commits August 3, 2026 10:54
…or zero debounce

Some GPIO controllers (e.g. MediaTek EINT used in pinctrl-paris) reject
set_config(PIN_CONFIG_INPUT_DEBOUNCE, 0) with -EINVAL when the underlying
interrupt is edge-triggered, even though the argument is 0 (meaning
"no debounce").

ACPI _CRS GpioInt/GpioIo resources that declare DebounceTimeout=0 caused
gpio_set_debounce_timeout() to call into that path, the chip returned
-EINVAL, and the error propagated through gpiod_get_index() and
acpi_dev_gpio_irq_get(), breaking ACPI consumers.

A debounce timeout of 0 means "no debounce" - there is nothing to
configure, so short-circuit the call inside gpio_set_debounce_timeout()
itself and return success without touching the controller. This fixes
all callers (the ACPI core call sites and any future ones) without
having to add the same guard at every call site.

Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Signed-off-by: Kiran Maddaraki <kmaddaraki@nvidia.com>
…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>
@kmaddaraki
kmaddaraki force-pushed the i2c-device-clean-stack branch from 6cb82e7 to 22d6646 Compare August 3, 2026 05:26

@nirmoy nirmoy left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Codex found these two issues.

Comment thread drivers/gpio/gpiolib.c
* touching the hardware.
*/
if (!debounce)
return 0;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Medium: This changes the core API from “zero disables debounce” to “zero is ignored.” If firmware or an earlier request enabled debounce, returning here leaves hardware filtering and desc->debounce_period_us stale, and skips the line-state notification. Please scope the ACPI workaround to the affected call path or make the MediaTek EINT implementation handle zero by disabling debounce.

&i2c->clk_src_div);
if (ret < 0)
return ret;
i2c->clk_src_div = 1; /* ACPI doesn't supply this */

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Low: This fallback also applies to DT and to malformed properties. clock-div is required by i2c-mt65xx.yaml, and the previous DT path returned the read error; silently using 1 changes DT behavior and may calculate the wrong SCL timing. Please default only for an absent ACPI property and preserve the DT/malformed-property error.

@clsotog

clsotog commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

Got the same findings as Nirmoy.

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

@kmaddaraki: Are these going to get sent upstream?

@kmaddaraki

Copy link
Copy Markdown
Author

@kmaddaraki: Are these going to get sent upstream?

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

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

Review: PR 507 — additional notes

The two findings already posted stand (core debounce semantics on
gpiolib.c, the clock-div fallback on i2c-mt65xx.c). The following is
not covered by them.

A four-line fix already exists for the gpiolib problem

e4a77f9c85a5 ("gpiolib: acpi: Make set debounce errors non fatal") is
already in this branch. It added a warn-only wrapper and converted two of
the three gpio_set_debounce_timeout() call sites:

/* drivers/gpio/gpiolib-acpi-core.c */
static void acpi_gpio_set_debounce_timeout(struct gpio_desc *desc,
                                           unsigned int acpi_debounce)
{
        ...
        ret = gpio_set_debounce_timeout(desc, acpi_debounce);
        if (ret)
                gpiod_warn(desc, "Failed to set debounce-timeout %u: %d\n",
                           acpi_debounce, ret);
}

Two consequences.

The commit message is out of date. It says the error "propagated
through gpiod_get_index() and acpi_dev_gpio_irq_get()". The
gpiod_get_index() path — gpiod_find_and_request()
gpiod_fwnode_lookup()gpiod_find_by_fwnode()acpi_find_gpio()
only warns now.

One call site still fails, acpi_dev_gpio_irq_wake_get_by():

ret = gpio_set_debounce_timeout(desc, info.debounce * 10);
if (ret)
        return ret;

Converting that single call to acpi_gpio_set_debounce_timeout() is the
"scope it to the affected call path" fix suggested above, needs no core
change, and finishes what e4a77f9c85a5 started. That commit also records
the upstream position on this failure mode:

But gpio_set_debounce_timeout() failing is a somewhat normal
occurrence, since not all debounce values are supported on all
GPIO/pinctrl chips.

The zero-only guard is incomplete

mtk_eint_set_debounce() rejects the request without inspecting the
requested value at all:

static unsigned int mtk_eint_can_en_debounce(struct mtk_eint *eint,
                                             unsigned int eint_num)
{
        ...
        if (eint->pins[eint_num].debounce && sens != MTK_EINT_EDGE_SENSITIVE)
                return 1;
        else
                return 0;
}

An MT8901 _CRS declaring any non-zero DebounceTimeout on an
edge-triggered EINT would still return -EINVAL and still fail
acpi_dev_gpio_irq_get(). Fixing the call site covers that case; the zero
guard does not.

Nits

  • default_parent_rate = 124800000 has no stated source. With
    clk_src_div falling back to 1, it is the sole input to the ACPI timing
    calculation — a comment naming the source would make it reviewable.
  • i2c->adap.dev.of_node = pdev->dev.of_node; in mtk_i2c_probe() is
    dead; device_set_node() sets of_node from the fwnode a few lines
    later.
  • checkpatch: CHECK: Alignment should match open parenthesis on the
    mtk_i2c_set_speed() call. A local holding the parent rate would read
    better than the nested conditional.

Two corrections to the earlier review

  • desc->debounce_period_us is not left stale by this patch.
    gpio_set_debounce_timeout() never wrote that field on any path; it is
    written only by gpiolib-cdev.c.
  • The skipped gpiod_line_state_notify() is arguably correct now, since no
    configuration changed. Previously it fired even when the call was a
    no-op.

Both changed objects build clean on arm64 defconfig with CONFIG_ACPI=y
and =n.

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

Labels

help wanted Extra attention is needed pending_review_comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants