CC Saravana
On Tue, Dec 17, 2024 at 2:29 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Mon, Dec 16, 2024 at 2:33 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen
> > <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
> > > From: Tomi Valkeinen <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx>
> > >
> > > Add support for the mini DP output on the Gray Hawk board.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx>
> > > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx>
> > > Tested-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> >
> > Thanks for your patch, which is now commit b1000645dc29701f
> > ("arm64: dts: renesas: gray-hawk-single: Add DisplayPort support")
> > in renesas-devel/renesas-dts-for-v6.14.
> >
> > Apparently this patch breaks s2idle on Gray Hawk Single when "[PATCH
> > v3 06/10] drm/rcar-du: dsi: Add r8a779h0 support" is not present, or
> > when CONFIG_DRM_RCAR_USE_MIPI_DSI is not enabled. If the DSI driver
> > is not available, the ti_sn65dsi86.bridge part fails to probe with
> > -EPROBE_DEFER and "failed to attach dsi host". Still, the sn65dsi86
> > driver must do something critical, as resuming from s2idle now hangs.
> > I haven't identified yet where exactly it hangs.
> >
> > As a result, s2idle is broken in current renesas-devel, which only
> > has the DTS changes. Perhaps I should drop the DTS until the issue
> > is resolved?
> >
> > However, I suspect White Hawk has the same issue (if
> > CONFIG_DRM_RCAR_USE_MIPI_DSI=n), but I cannot verify as my local White
> > Hawk is currently not available for kernel testing.
>
> Confirmed on White Hawk by Tomi and me.
>
> When the hang occurs, magic sysrq no longer works. However, the system
> still prints "nfs server not responding" once in a while, so I added
> calls to various sysrq print functions to rpc_check_timeout().
> This revealed that the system is blocked on wait_for_completion()
> in dpm_wait_for_superior(), called from device_resume_noirq().
> Printing the actual device and parent gives:
>
> platform fed80000.dsi-encoder: PM: device_resume_noirq
> platform fed80000.dsi-encoder: PM: dpm_wait_for_superior: parent fed80000.dsi-encoder
So it's waiting for itself, i.e. deadlock :-(
When the DSI driver is available:
rcar-mipi-dsi fed80000.dsi-encoder: PM: device_resume_noirq:627
rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:280
rcar-mipi-dsi fed80000.dsi-encoder: PM: dpm_wait_for_superior:296:
parent fed80000.dsi-encoder
still waiting for itself, but it does continue!
Note that the fed80000.dsi-encoder block is now bound, and
"rcar-mipi-dsi" is printed instead of "platform".
fw_devlink issue?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
