OMAP GPIO ready too later

OMAP GPIO ready too later

[qianfan]

Hi everyone:

On my board there has a gpio watchdong connected on am3358. And I found 
that the omap gpio device ready too later so it takes about 5 seconds 
when the gpio-wdt is ready.

I had tested on some version of linux, check when the OMAP GPIO is 
ready. Next is the log:

v4.19 [    0.195191] OMAP GPIO hardware version 0.1

v5.4  [    1.168868] OMAP GPIO hardware version 0.1

v5.9  [    4.598052] OMAP GPIO hardware version 0.1

v5.15 [    1.253851] OMAP GPIO hardware version 0.1

I can't find which commit slowdown omap gpio driver. could you please 
give me some advice?

Thanks

Re: OMAP GPIO ready too later

[Tony Lindgren]

Hi,

* qianfan <qianfanguijin@163.com> [220119 08:36]:
> Hi everyone:
> 
> On my board there has a gpio watchdong connected on am3358. And I found that
> the omap gpio device ready too later so it takes about 5 seconds when the
> gpio-wdt is ready.
> 
> I had tested on some version of linux, check when the OMAP GPIO is ready.
> Next is the log:
> 
> v4.19 [    0.195191] OMAP GPIO hardware version 0.1
> 
> v5.4  [    1.168868] OMAP GPIO hardware version 0.1
> 
> v5.9  [    4.598052] OMAP GPIO hardware version 0.1
> 
> v5.15 [    1.253851] OMAP GPIO hardware version 0.1
> 
> I can't find which commit slowdown omap gpio driver. could you please give
> me some advice?

We've moved to probe pretty much everything at normal module_init time
instead of trying to probe everything early. Only clocks and system timers
need to be probed early for the omap variants.

One of the reasons for the device drivers probing later on during the boot
is caused by drivers/bus/ti-sysc.c. As ti-sysc is the parent device on the
interconnect, none of it's child devices probe before it. And there should
not be any need to probe ti-sysc early. The total boot-up time should be
about the same, just the probe order has changed. If there are issues with
the boot-up time in general, then that's a bug.

Maybe you want to configure the watchdog in the bootloader initially until
the Linux device drivers get probed?

Regards,

Tony

Re: OMAP GPIO ready too later

[qianfan]

在 2022/2/3 17:07, Tony Lindgren 写道:
> Hi,
>
> * qianfan <qianfanguijin@163.com> [220119 08:36]:
>> Hi everyone:
>>
>> On my board there has a gpio watchdong connected on am3358. And I found that
>> the omap gpio device ready too later so it takes about 5 seconds when the
>> gpio-wdt is ready.
>>
>> I had tested on some version of linux, check when the OMAP GPIO is ready.
>> Next is the log:
>>
>> v4.19 [    0.195191] OMAP GPIO hardware version 0.1
>>
>> v5.4  [    1.168868] OMAP GPIO hardware version 0.1
>>
>> v5.9  [    4.598052] OMAP GPIO hardware version 0.1
>>
>> v5.15 [    1.253851] OMAP GPIO hardware version 0.1
>>
>> I can't find which commit slowdown omap gpio driver. could you please give
>> me some advice?
> We've moved to probe pretty much everything at normal module_init time
> instead of trying to probe everything early. Only clocks and system timers
> need to be probed early for the omap variants.
>
> One of the reasons for the device drivers probing later on during the boot
> is caused by drivers/bus/ti-sysc.c. As ti-sysc is the parent device on the
> interconnect, none of it's child devices probe before it. And there should
> not be any need to probe ti-sysc early. The total boot-up time should be
> about the same, just the probe order has changed. If there are issues with
> the boot-up time in general, then that's a bug.
>
> Maybe you want to configure the watchdog in the bootloader initially until
> the Linux device drivers get probed?

Yes, the gpio watchdog is alived on bootloader, I want find a good way 
to feed it until linux driver ready.  gpio-wdt.c has an option 
CONFIG_GPIO_WATCHDOG_ARCH_INITCALL which will register gpio-wdt driver 
on arch_innitcall, but this feature doesn't work on am335x platform due 
to the gpio driver ready too later.

>
> Regards,
>
> Tony

Re: OMAP GPIO ready too later

[Tony Lindgren]

* qianfan <qianfanguijin@163.com> [220212 02:18]:
> 
> 在 2022/2/3 17:07, Tony Lindgren 写道:
> > Hi,
> > 
> > * qianfan <qianfanguijin@163.com> [220119 08:36]:
> > > Hi everyone:
> > > 
> > > On my board there has a gpio watchdong connected on am3358. And I found that
> > > the omap gpio device ready too later so it takes about 5 seconds when the
> > > gpio-wdt is ready.
> > > 
> > > I had tested on some version of linux, check when the OMAP GPIO is ready.
> > > Next is the log:
> > > 
> > > v4.19 [    0.195191] OMAP GPIO hardware version 0.1
> > > 
> > > v5.4  [    1.168868] OMAP GPIO hardware version 0.1
> > > 
> > > v5.9  [    4.598052] OMAP GPIO hardware version 0.1
> > > 
> > > v5.15 [    1.253851] OMAP GPIO hardware version 0.1
> > > 
> > > I can't find which commit slowdown omap gpio driver. could you please give
> > > me some advice?
> > We've moved to probe pretty much everything at normal module_init time
> > instead of trying to probe everything early. Only clocks and system timers
> > need to be probed early for the omap variants.
> > 
> > One of the reasons for the device drivers probing later on during the boot
> > is caused by drivers/bus/ti-sysc.c. As ti-sysc is the parent device on the
> > interconnect, none of it's child devices probe before it. And there should
> > not be any need to probe ti-sysc early. The total boot-up time should be
> > about the same, just the probe order has changed. If there are issues with
> > the boot-up time in general, then that's a bug.
> > 
> > Maybe you want to configure the watchdog in the bootloader initially until
> > the Linux device drivers get probed?
> 
> Yes, the gpio watchdog is alived on bootloader, I want find a good way to
> feed it until linux driver ready.  gpio-wdt.c has an option
> CONFIG_GPIO_WATCHDOG_ARCH_INITCALL which will register gpio-wdt driver on
> arch_innitcall, but this feature doesn't work on am335x platform due to the
> gpio driver ready too later.

Well seems like the boottime of 1.25 seconds to having the gpio probed should
be way longer than your bootloader configured watchdog timeout :) What do you
have the bootloader set the watchdog timeout?

Regards,

Tony

Re: OMAP GPIO ready too later

[qianfan]

在 2022/2/14 15:50, Tony Lindgren 写道:
> * qianfan <qianfanguijin@163.com> [220212 02:18]:
>> 在 2022/2/3 17:07, Tony Lindgren 写道:
>>> Hi,
>>>
>>> * qianfan <qianfanguijin@163.com> [220119 08:36]:
>>>> Hi everyone:
>>>>
>>>> On my board there has a gpio watchdong connected on am3358. And I found that
>>>> the omap gpio device ready too later so it takes about 5 seconds when the
>>>> gpio-wdt is ready.
>>>>
>>>> I had tested on some version of linux, check when the OMAP GPIO is ready.
>>>> Next is the log:
>>>>
>>>> v4.19 [    0.195191] OMAP GPIO hardware version 0.1
>>>>
>>>> v5.4  [    1.168868] OMAP GPIO hardware version 0.1
>>>>
>>>> v5.9  [    4.598052] OMAP GPIO hardware version 0.1
>>>>
>>>> v5.15 [    1.253851] OMAP GPIO hardware version 0.1
>>>>
>>>> I can't find which commit slowdown omap gpio driver. could you please give
>>>> me some advice?
>>> We've moved to probe pretty much everything at normal module_init time
>>> instead of trying to probe everything early. Only clocks and system timers
>>> need to be probed early for the omap variants.
>>>
>>> One of the reasons for the device drivers probing later on during the boot
>>> is caused by drivers/bus/ti-sysc.c. As ti-sysc is the parent device on the
>>> interconnect, none of it's child devices probe before it. And there should
>>> not be any need to probe ti-sysc early. The total boot-up time should be
>>> about the same, just the probe order has changed. If there are issues with
>>> the boot-up time in general, then that's a bug.
>>>
>>> Maybe you want to configure the watchdog in the bootloader initially until
>>> the Linux device drivers get probed?
>> Yes, the gpio watchdog is alived on bootloader, I want find a good way to
>> feed it until linux driver ready.  gpio-wdt.c has an option
>> CONFIG_GPIO_WATCHDOG_ARCH_INITCALL which will register gpio-wdt driver on
>> arch_innitcall, but this feature doesn't work on am335x platform due to the
>> gpio driver ready too later.
> Well seems like the boottime of 1.25 seconds to having the gpio probed should
> be way longer than your bootloader configured watchdog timeout :) What do you
> have the bootloader set the watchdog timeout?
I had sniffer the gpio data by using logic analysis, when the linux 
gpio-wdt driver toggle watchdog pin, it passed about 5 seconds after the 
u-boot done. And the gpio watchdog's deadline is 1.6s.
>
> Regards,
>
> Tony

Re: OMAP GPIO ready too later

[Tony Lindgren]

* qianfan <qianfanguijin@163.com> [220216 04:05]:
> 在 2022/2/14 15:50, Tony Lindgren 写道:
> > Well seems like the boottime of 1.25 seconds to having the gpio probed should
> > be way longer than your bootloader configured watchdog timeout :) What do you
> > have the bootloader set the watchdog timeout?
> I had sniffer the gpio data by using logic analysis, when the linux gpio-wdt
> driver toggle watchdog pin, it passed about 5 seconds after the u-boot done.
> And the gpio watchdog's deadline is 1.6s.

Well on my beaglebone black looks like gpios are initialized around 1.7s,
but pinctrl is initialized around 0.25s. You could create some driver that
in it's init sets the related gpio pin to PIN_OUTPUT_PULLUP | SAFE_MODE
to kick the gpio watchdog, and then exits releasing the pinmux so the
gpio based driver can take over. Or maybe your gpio watchdog driver could
do pin configuration in init, then do what it currently does in probe.

Of course booting things faster would be the best solution, but that can
easily get delayed with kernel updates with deferred probe for example.

Regards,

Tony