etnaviv fails probe early, but succeeds after rmmod && modprobe

[Ing. Josua Mayer]

Hi John,
Am 17.04.21 um 05:46 schrieb John Stultz:
> On Fri, Apr 16, 2021 at 4:13 AM Lucas Stach <l.stach at pengutronix.de> wrote:
>> Am Freitag, dem 16.04.2021 um 12:57 +0200 schrieb Ing. Josua Mayer:
>>> Hi Lucas,
>>>
>>> anatop_regulator is indeed a module currently,
>>> this is one of the changes introduced in their jump from kernel 5.9 to
>>> 5.10 - and has even landed in buster through backports ...
>>>
>>> I wonder how / where those timeouts are specified.
>>> Regarding the order of module loading there is not much I can do, it is
>>> already the second module inserted by the initramfs.
>>
>> This looks like a kernel bug to me. If no timeout is given on the
>> command line, the status is immediately considered as timed-out after
>> the initcalls are done, as the code doesn't differentiate between "no
>> timeout given" and "timeout expired" at that point.
>>
>> CC'ing John Stultz, who touched that code last.
> 
> Yea, sadly my attempts to try to stretch the default timeouts so this
> wouldn't happen ended up causing problems for the "optional links"
> case, where folks want the driver core to stop deferring and return an
> error for the bits that aren't present. So we had to back out most of
> those changes (so yes, I touched it last, but unfortunately had to to
> put things mostly back the way it was).
 >
Thank you for your comments!
I am sad to hear that adjusting timeouts was not a path of success ...

> Personally, I think the implicit optional link concept in dts was a
> mistake, as I think having some explicit notation would have made
> things work a lot better since the timeout solution does not feel
> ideal for anyone, but I also am (happily) not the expert there, so I
> probably shouldn't judge. :)
> 
> In the end, it seems the fw_devlink logic Saravana is working on is
> really the better solution. I know he's getting closer to being able
> to set it as the default, so you might check that out?
> 
> thanks
> -john
> 

So from all these pointers I finally played with the 
deferred_probe_timeout kernel parameter. Maybe something just needed 
more time? Well ... for some reason passing 20 made it so that etnaviv 
eventually probes successfully!

I am attaching the full dmesg for reference - note that all modules are 
in initramfs only for debugging purposes, this is not the default debian 
split.

Is there really a difference between specifying and not specifying 
deferred_probe_timeout which is described as a debugging feature?

sincerely
Josua Mayer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sr-imx6-etna-probe-timeout20.log
Type: text/x-log
Size: 35969 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20210417/90e90893/attachment-0001.bin>