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/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
>>
>>