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

["Du, Bin" <bin.du@amd.com>]

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@kernel.org> 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@amd.com/
>>>>> [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

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