Re: [REGRESSION] AMDISP failure with kernel v7.0-rc2 due to Commit: 02c057ddefef5
From: Du, Bin
Date: Mon Mar 09 2026 - 04:12:27 EST
On 3/9/2026 11:52 AM, Nirujogi, Pratap wrote:
On 3/6/2026 7:45 AM, Mario Limonciello wrote:
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.yes, MFD child devices in this case have the device ID as that of parent (GPU) i.e. LNXVIDEO. Its because when no acpi_match is specified, the MFD child devices are inheriting the parent's ACPI companion device and this is resulting in having the same parent's ACPI device ID.
On 3/6/26 6:01 AM, Rafael J. Wysocki wrote:
On Fri, Mar 6, 2026 at 1:35 AM Mario Limonciello (AMD) (kernel.org)
<superm1@xxxxxxxxxx> wrote:
On 3/5/2026 5:11 PM, Nirujogi, Pratap wrote:
Hi Rafael,
In kernel version 7.0-rc2, the AMDISP device reports the following
errors when created via mfd_add_hotplug_devices.
[ 5.236645] ACPI: video: Video Device [GFX0] (multi-head: yes rom:
no post: no)
[ 5.236744] input: Video Bus as /devices/
pci0000:00/0000:00:08.1/0000:c3:00.0/amd_isp_capture.1.auto/input/ input21
[ 5.236779] acpi device:14: Error installing notify handler
[ 5.236782] acpi device:15: Error installing notify handler
[ 5.236783] acpi device:16: Error installing notify handler
[ 5.236784] acpi device:17: Error installing notify handler
[ 5.236785] acpi device:18: Error installing notify handler
[ 5.236786] acpi device:19: Error installing notify handler
[ 5.236786] acpi device:1a: Error installing notify handler
[ 5.236787] acpi device:1b: Error installing notify handler
[ 5.236788] acpi device:1c: Error installing notify handler
These failures indicate AMDISP device is incorrectly detected as ACPI
Video device while it is not.
The seems like a regression caused by the change that converts the ACPI
video device to a platform device (commit: 02c057ddefef5).
Issue is not observed in 6.19-rc6, and also when this change is reverted
in 7.0-rc2.
I really appreciate your inputs on addressing this issue and helping us
make progress on 7.0 rc2.
Steps followed to reproduce the issue:
1. Apply AMDISP v9 patch series [1] on top of kernel v7.0-rc2
2. Add NULL check for “dev->type” in isp_genpd_add_device() [2] (to
avoid kernel panic found in v7.0-rc2)
3. Build kernel with:
- CONFIG_AMD_ISP_PLATFORM=y
- CONFIG_VIDEO_AMD_ISP4_CAPTURE=m
4. Install kernel on AMDISP supported system (HP ZBook Ultra G1a)
5. Boot system to see the failures
[1] https://lore.kernel.org/all/20260302073020.148277-1- Bin.Du@xxxxxxx/
[2] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/
amdgpu/isp_v4_1_1.c#L132
Thanks,
Pratap
It's a bit weird to see it even probe in this path in the first place.
acpi_video_bus_probe() getting called with the mfd device doesn't seem
right to me.
I wonder if it's because ISP is an MFD device of GPU (and thus LNXVIDEO
ends up matching).
Would a sensible solution be to reject mfd device types in
acpi_video_bus_probe()?
Every platform device with LNXVIDEO in the device ID list will be
matched and so probed.
I'm wondering how those devices get that ID though.
Yeah me too. I was surprised an MFD device got it.
Pratap - can you figure this out before we go too far in this path?
device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent));
https://github.com/torvalds/linux/blob/master/drivers/mfd/mfd-core.c#L91
If they really shouldn't have LNXVIDEO fixing that may be a better solution.AMD ISP related MFD devices are using the same LNXVIDEO device ID even on 6.19-rc4, no issues observed earlier. I can confirm automatic AMD ISP device probe works and also camera works on 7.0-rc2 if I avoid inheriting ACPI companion of the parent (GPU) in the mfd-core.c
// device_set_node(&pdev->dev, acpi_fwnode_handle(adev ?: parent));
https://github.com/torvalds/linux/blob/master/drivers/mfd/mfd-core.c#L91
But why this is an issue on 7.0-rc2 while it works on 6.19-rc4 needs to be root caused.
Possible cause may be.
1. On 6.x (without commit 02c057ddefef5), the ACPI video driver was registered as an acpi_driver (static struct acpi_driver acpi_video_bus) , it lives on the ACPI bus (acpi_bus_type). It only binds to struct acpi_device objects in the ACPI namespace. MFD children of GFX (amd_isp_capture, amd_isp_i2c_designware, amdisp-pinctrl) are platform devices on the platform bus, they are completely invisible to acpi_driver, so there is no chance of the ACPI video driver matching an MFD child.
2. On 7.0 (with commit 02c057ddefef5), the ACPI video driver was converted to a platform_driver (static struct platform_driver acpi_video_bus), it lives on the platform bus. When the kernel registers a new platform device, it checks ALL registered platform drivers to see if any match. The matching logic for acpi_match_table works like this:
- Get the platform device's ACPI companion (ACPI_COMPANION(dev))
- Check if the companion's HID/CID matches any entry in acpi_match_table
- If yes, the driver probes the device
amd_isp_capture, amd_isp_i2c_designware, and amdisp-pinctrl are MFD children of GFX and inherit their parent's ACPI companion, which uses the HID "LNXVIDEO". As a result, all these components will match with the ACPI video driver. Consequently, this issue impacts not only amd_isp_capture but also the upstreamed driver amd_isp_i2c_designware (located in drivers/i2c/busses/i2c-designware-amdisp.c under the I2C_DESIGNWARE_AMDISP config) and amdisp-pinctrl (found in drivers/pinctrl/pinctrl-amdisp.c under the PINCTRL_AMDISP config).
Also, is this really a mainline regression? AMDISP patches are not in
the mainline, no?
The amdgpu half of it is mainline, the other half is still on the lists.
--
Regards,
Bin