[26.04_linux-nvidia] pinctrl: mediatek: MT8901 ACPI wake-event EINT support and bus-hold bias - #564
[26.04_linux-nvidia] pinctrl: mediatek: MT8901 ACPI wake-event EINT support and bus-hold bias#564kmaddaraki wants to merge 2 commits into
Conversation
BaseOS Kernel ReviewWarning
|
PR Validation ReportPatchscan ✅ No Missing FixesAll cherry-picked commits checked — no missing upstream fixes found. PR Lint ❌ Errors foundDetailsChecking 2 commits... Cherry-pick digest: ┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐ │ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 1f8500beee46 │ [SAUCE] pinctrl: mediatek: add bus-hold bias and program-by-gpio │ N/A │ N/A │ paralika, kmaddara │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ 761ead28432d │ [SAUCE] pinctrl: mt8901: enable acpi wake-event eint support │ N/A │ N/A │ pant, kmaddara │ └──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘ Lint: all checks passed. PR metadata: E: PR targets 26.04_linux-nvidia but body has no https://bugs.launchpad.net/... link |
|
I got this finding with Codex: |
b5ac609 to
f8c1047
Compare
b94410f to
896cc0c
Compare
On MT8901-based ACPI platforms some EINT wake sources belong to pins that are owned by firmware and have no Linux consumer driver. Two things are missing for such a pin to wake the SoC from system sleep. First, the EINT block only forwards a wake event to the SPM when the pin's bit in the EINT event mask is cleared. Nothing in the driver programs that register, so the event never reaches the SPM. Second, the ACPI GPIO interrupts declared in the controller's _AEI are never requested after the pinctrl driver probes. Without that request there is no IRQ consumer for the pin, so nothing calls enable_irq_wake() on it, its bit in wake_mask stays clear, and mtk_eint_do_suspend() masks the interrupt for the duration of suspend. The SPM cannot see the event from a masked EINT. Add a wake-event pin list to mtk_eint so the SoC driver can declare the pins whose event mask must be cleared, and clear it on init and on resume so the setting survives suspend/resume. Declare EINT 20 for MT8901. Call acpi_gpiochip_request_interrupts() once the GPIO chip has been added so gpiolib-acpi requests the _AEI interrupts and, for the wake-capable ones, calls enable_irq_wake(). That sets the pin's bit in wake_mask through the normal irq_set_wake path, so the EINT stays unmasked across suspend without any driver touching wake_mask directly. Signed-off-by: Ankit Pant <ankit.pant@mediatek.com> Signed-off-by: Kiran Maddaraki <kmaddaraki@nvidia.com>
896cc0c to
b3cc94e
Compare
|
Thanks Carol, confirmed. The generic parser passes argument 0 for |
|
Updated head addresses the BaseOS review:
|
…IO helper The MediaTek pinctrl bias code only knows pull-up and pull-down. The pad "bus keeper" mode, with both PU and PD enabled, cannot be requested or read back, yet the MT8901 SoundWire pads need it: the ACPI _CRS for the SoundWire controller carries PinFunction() vendor encodings that ask for bus-keeper on the data lines, and without it codec enumeration fails unless the pad registers are written by hand. Add MTK_BUS_HOLD as a third pull mode in the PU/PD bias path and wire PIN_CONFIG_BIAS_BUS_HOLD through the pinctrl-paris get/set handlers. The generic bias-bus-hold property carries no argument, so the set handler always requests MTK_ENABLE for it. The RSEL and R1R0 bias paths cannot express bus-hold and reject it explicitly. The bias getters report PU=1, PD=1 back as MTK_BUS_HOLD. Register every mtk_pinctrl instance in a global list at probe and export mtk_pinctrl_program_bias_by_gpio() through <linux/soc/mediatek/mtk-pinctrl.h>, so a client driver that parses PinFunction() vendor encodings from its own _CRS can apply pad bias by absolute SoC GPIO number without going through pinctrl states. The instance is unregistered via a devm action so it leaves the list before devm frees it. MediaTek pin numbers are zero-based per controller, so the helper refuses with -EINVAL if more than one registered controller could own the requested pin instead of programming whichever probed first. Every supported platform registers a single pinctrl instance, so this cannot trigger today. Signed-off-by: shubham.paralikar <shubham.paralikar@mediatek.com> Signed-off-by: Kiran Maddaraki <kmaddaraki@nvidia.com>
b3cc94e to
1f8500b
Compare
|
On the remaining Medium, the helper returning -EINVAL when more than one controller could own a pin: This cannot happen on any platform this driver supports. MediaTek describes all pads of an SoC under a single pinctrl device, and MT8901 exposes exactly one (NVDA9221). The upstream MediaTek device trees follow the same shape: mt8186, mt8188, mt8192 and mt8195 each have one pinctrl node with several register banks inside it, never two nodes. So the instance list always has one entry and the helper is unambiguous. The guard exists so that a hypothetical future two-controller platform fails loudly instead of programming whichever controller probed first, which was the original High. |
|
Thanks for the changes. I got another finding let me know: |
|
I independently reached the same gpiochip lifetime finding Carol reported on In addition to Carol's finding, I have a few non-blocking comments:
|
4 participants
Two SAUCE patches for the MediaTek MT8901 pinctrl driver under ACPI, ported from the FastOS kernel.
pinctrl: mt8901: Enable ACPI wake-event EINT support
On MT8901 ACPI platforms some EINT wake sources belong to pins that are owned by firmware and have no Linux consumer driver, so nothing calls enable_irq_wake() for them and the platform cannot be woken from system sleep through those pins. The ACPI GPIO interrupts declared for the controller (_AEI) are also never requested after the pinctrl driver probes, so the ACPI event handlers for those pins do not run. Add a wake-event pin list to mtk_eint that the SoC driver populates, program it on init and resume, force wake_mask for the declared pins so the state survives suspend/resume without a consumer driver, declare the MT8901 event pins in the SoC data, and call acpi_gpiochip_request_interrupts() once the GPIO chip has been added.
pinctrl: mediatek: Add bus-hold bias and program-by-GPIO helper
The MediaTek bias code only knows pull-up and pull-down. The pad bus-keeper mode (PU and PD both enabled) cannot be requested or read back, yet the MT8901 SoundWire pads need it: the SoundWire controller's _CRS carries PinFunction() vendor encodings asking for bus-keeper on the data lines, and without it codec enumeration fails unless the pad registers are written by hand. Add MTK_BUS_HOLD as a third pull mode in the PU/PD path, wire PIN_CONFIG_BIAS_BUS_HOLD through pinctrl-paris get/set, and reject it on the RSEL and R1R0 paths that cannot express it. Register each mtk_pinctrl instance at probe and export mtk_pinctrl_program_bias_by_gpio() through <linux/soc/mediatek/mtk-pinctrl.h> so a client driver can apply pad bias by absolute SoC GPIO number. Nothing in this tree calls the helper yet; the SoundWire manager that consumes it will follow in a separate PR.
Existing DT and pull-up/pull-down behaviour is unchanged.