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

[Rafael J. Wysocki]

On Mon, Mar 9, 2026 at 12:58 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> 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.

I guess I know what's going on.

Every device that shares an ACPI companion with the ACPI video bus
device advertises itself as "LNXVIDEO", so udev looks for a module
matching that device ID and since the ACPI video driver is loaded, it
will not attempt to load anything else.

It may be viable to use an auxiliary device for ACPI video bus device
representation, let me have a look at that.