Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello <mario.limonciello@amd.com>]

On 5/19/26 02:21, Hardik Prakash wrote:
> On Mon, May 18, 2026 at 23:14, Mario Limonciello wrote:
>> I'm still confused though.  Are you saying we're actually racing with
>> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
>> is ready?
>>
>> There is a dynamic debug statement already in amd_gpio_probe() for when
>> it finishes, maybe you can sprinkle a few more around the start of probe
>> and amd_gpio_irq_enable() to confirm?
> 
> Added debug statements and enabled dyndbg at boot. The trace confirms
> the race:
> 
>    0.285415  amd_gpio_probe: start
>    0.285496  amd_gpio_probe: calling irq_init
>    0.285947  GPIO 157 enabled (quirk fires)
>    0.285950  amd_gpio_probe: quirks applied
>    0.285952  amd_gpio_probe: registering gpiochip  <- GPIO chip visible
>    0.287121  amd_gpio_probe: requesting parent IRQ <- probe still running
>    0.290248  AMDI0010:00 dw_i2c_plat_probe: start
>    0.295928  AMDI0010:01 dw_i2c_plat_probe: start
>    0.301454  AMDI0010:02 dw_i2c_plat_probe: start <- races here
>    0.306905  AMDI0010:03 dw_i2c_plat_probe: start
>    2.348157  lost arbitration

You add a debug statement to amd_gpio_irq_enable() too right?  Can you 
please share your debugging messages patch and full log?

I had expected that the interrupt should be enabled before it starts 
getting used.

> 
> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> at 0.301454 while amd_gpio_probe() is still completing. This is why
> device_is_bound() works and initcall promotion does not -- it waits for
> probe completion, not just gpiochip registration.

What is the boot time impact to adding device_is_bound() check?

Bartosz, thoughts?

> 
> Thanks,
> Hardik
> 
> On Mon, 18 May 2026 at 23:14, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 5/18/26 12:22, Hardik Prakash wrote:
>>> On Mon, May 18, 2026 at 19:57, Bartosz Golaszewski wrote:
>>>> If you added wait_for_device_probe() right before requesting the
>>>> interrupt, does it help?
>>>
>>> I'll test this. One concern: wait_for_device_probe() waits for all
>>> pending probes to complete, not just pinctrl-amd. Calling it
>>> unconditionally in dw_i2c_plat_probe() would affect every machine
>>> running i2c-designware, potentially adding boot latency broadly.
>>>
>>> Would it make sense to guard it with the same DMI check, or is the
>>> intention to make this unconditional?
>>
>> Our general aim should be to avoid DMI checks where possible.  If you're
>> finding a timing problem on your system there can very likely be a
>> timing problem on another system from someone not as willing or able to
>> report it.
>>
>> So let's leave DMI hacks for fallback if we really can't figure this out.
>>
>> In an ideal world we would have a _DEP in the ACPI entries, but I don't
>> think I've ever seen that for the GPIO controller.
>>
>> I'm still confused though.  Are you saying we're actually racing with
>> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
>> is ready?
>>
>> There is a dynamic debug statement already in amd_gpio_probe() for when
>> it finishes, maybe you can sprinkle a few more around the start of probe
>> and amd_gpio_irq_enable() to confirm?
>>
>>>
>>> Thanks,
>>> Hardik
>>>
>>> On Mon, 18 May 2026 at 19:58, Andy Shevchenko
>>> <andriy.shevchenko@intel.com> wrote:
>>>>
>>>> On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
>>>>> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
>>>>>> What is blocking the pinctrl driver from probing? Does it return
>>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>>>> core_initcall() so it should work in theory.
>>>>>
>>>>> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
>>>>>> Please try arch_initcall instead.
>>>>>
>>>>> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
>>>>> than any previous boot), but arbitration errors still occur at 2.309s:
>>>>>
>>>>>     subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
>>>>>     arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
>>>>>     patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
>>>>>
>>>>> The driver is not returning -EPROBE_DEFER. The problem is that
>>>>> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
>>>>> even with arch_initcall. Promoting the initcall level gets the driver
>>>>> registered earlier, but probe itself takes time, and i2c_designware
>>>>> catches it mid-probe regardless of registration timing.
>>>>>
>>>>> This is why device_is_bound() works where initcall promotion does not
>>>>> — it waits for probe completion, not just driver registration.
>>>>
>>>> The alternative solution is to have a registered notifier for the device in
>>>> question. But not sure if it will be less-invasive than given solution.
>>>>
>>>>> On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
>>>>>> On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>> On 5/18/26 09:05, Bartosz Golaszewski wrote:
>>>>>>>> On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
>>>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>>>> On 5/18/26 08:40, Hardik Prakash wrote:
>>>>>>>>>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
>>>>>>>>>>> I'd still like to avoid a quirk if we can.
>>>>>>>>>>>
>>>>>>>>>>> I know my proposed patch to try to probe at an earlier stage didn't
>>>>>>>>>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>>>>>>>>>>
>>>>>>>>>>> Maybe fs_initcall()?
>>>>>>>>>>
>>>>>>>>>> Tested. fs_initcall + patch 1 still produces the same arbitration
>>>>>>>>>> errors:
>>>>>>>>>>
>>>>>>>>>>       subsys_initcall + patch 1:   arbitration errors persist
>>>>>>>>>>       fs_initcall + patch 1:       arbitration errors persist
>>>>>>>>>>       patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
>>>>>>>>>>
>>>>>>>>>> The initcall level does not appear to be the determining factor on
>>>>>>>>>> this hardware. i2c_designware is still probing AMDI0010:02 before
>>>>>>>>>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
>>>>>>>>>> The explicit device_is_bound() deferral in patch 2 is the only
>>>>>>>>>> approach that has worked.
>>>>>>>>>
>>>>>>>>> Please try arch_initcall instead.
>>>>>>>>
>>>>>>>> What is blocking the pinctrl driver from probing? Does it return
>>>>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>>>>>> core_initcall() so it should work in theory.
>>>>>>>
>>>>>>> Currently it's module_platform_driver() IE device_initcall().
>>>>>>>
>>>>>>> That's why I think we "should" be able to move it a lot earlier.
>>>>>>
>>>>>> I mean with fs_initcall() change - what's blocking it now?
>>>>
>>>> --
>>>> With Best Regards,
>>>> Andy Shevchenko
>>>>
>>>>
>>