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

[Lucas Stach]

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.

Regards,
Lucas

> sincerely
> Josua Mayer
> 
> Am 16.04.21 um 12:41 schrieb Lucas Stach:
> > Hi Josua,
> > 
> > Am Freitag, dem 16.04.2021 um 11:34 +0200 schrieb Ing. Josua Mayer:
> > > Greetings everybody,
> > > 
> > > While testing Debian on the i.MX6 HummingBoard, I came across a problem
> > > where after boot, the /dev/dri/card1 representing the GC2000 does not exist.
> > > 
> > > However at that point issuing
> > > rmmod etnaviv; modprobe etnaviv
> > > succeeds and I can then go on running applications uing GL.
> > > 
> > > So I am very unsure how to debug this. What I have so far is this output
> > > from dmesg [1], which points at some deferred probing timeout behaviour.
> > > I do not know how to trace
> > > (1) whose timeout exceeded
> > > (2) what dependency is being ignored
> > > (3) why after 3 attempts probing apparently gives up
> > > I do know that this problem is shared with the coda driver, which fails
> > > the same way. Hence maybe this is not an etnaviv problem - but hopefully
> > > this message can still reach somebody who understands what is happening
> > > here.
> > 
> > I have no idea how this deferred probe timeout stuff works, but from
> > your logs it seems vddpu gets probed really late (is the anatop
> > regulator driver a module in your config?), which in turn would cause a
> > probe defer of the GPC power domain driver, which is a common
> > dependency between VPU and GPU on the i.MX6. Seems like those etnaviv
> > timeouts happen before the GPC driver had a chance to probe.
> > 
> > Regards,
> > Lucas
> > 
> > 
> > > Yours sincerely
> > > Josua Mayer
> > > 
> > > [1] short dmesg (full dmesg attached):
> > > root at sr-imx6:~# dmesg | grep etna
> > > [    5.969888] etnaviv-gpu 130000.gpu: deferred probe timeout, ignoring
> > > dependency
> > > [    5.985970] etnaviv-gpu: probe of 130000.gpu failed with error -110
> > > [    6.076604] etnaviv-gpu 134000.gpu: deferred probe timeout, ignoring
> > > dependency
> > > [    6.102833] etnaviv-gpu: probe of 134000.gpu failed with error -110
> > > [    6.121231] etnaviv-gpu 2204000.gpu: deferred probe timeout, ignoring
> > > dependency
> > > [    6.150314] etnaviv-gpu: probe of 2204000.gpu failed with error -110
> > > root at sr-imx6:~# rmmod etnaviv
> > > root at sr-imx6:~# modprobe etnaviv
> > > root at sr-imx6:~# dmesg | grep etna
> > > ...
> > > [  166.482349] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops [etnaviv])
> > > [  166.502064] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
> > > [  166.514261] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv])
> > > [  166.520868] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
> > > [  166.527630] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> > > [  166.533879] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> > > [  166.540048] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
> > > [  166.547379] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on
> > > minor 1
> > > _______________________________________________
> > > etnaviv mailing list
> > > etnaviv at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/etnaviv
> > 
> >