Re: [REGRESSION] AMDISP failure with kernel v7.0-rc2 due to Commit: 02c057ddefef5

[Rafael J. Wysocki]

On Mon, Mar 9, 2026 at 9:11 AM Du, Bin <bin.du@xxxxxxx> wrote:
>
>
>
> 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.
> >>
> >>
> >> 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?
> >>
> > 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.
> >
> > 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

It does, but then the probe fails.  This is the problem that has been
reported to start with.

> 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).

Why is inheriting the parent's ACPI node regarded as a good idea?