linux-kernel - Re: [PATCH v13 3/4] drm/atomic-helper: Re-order bridge chain pre-enable and post-disable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251202062911.GA24150@pendragon.ideasonboard.com>
Date: Tue, 2 Dec 2025 15:29:11 +0900
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Vicente Bergas <vicencb@...il.com>
Cc: Aradhya Bhatia <aradhya.bhatia@...ux.dev>, airlied@...il.com,
	alexander.sverdlin@...mens.com, andrzej.hajda@...el.com,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	jernej.skrabec@...il.com, Jonas Karlman <jonas@...boo.se>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	lumag@...nel.org, maarten.lankhorst@...ux.intel.com,
	mripard@...nel.org, neil.armstrong@...aro.org, nm@...com,
	rfoss@...nel.org, simona@...ll.ch, tomi.valkeinen@...asonboard.com,
	tzimmermann@...e.de, vigneshr@...com,
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
	Douglas Anderson <dianders@...omium.org>,
	Damon Ding <damon.ding@...k-chips.com>,
	Sandy Huang <hjc@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>,
	Andy Yan <andy.yan@...k-chips.com>,
	Linux Rockchip Support List <linux-rockchip@...ts.infradead.org>,
	Devarsh Thakkar <devarsht@...com>,
	Linus Walleij <linusw@...nel.org>,
	Marek Vasut <marek.vasut+renesas@...lbox.org>
Subject: Re: [PATCH v13 3/4] drm/atomic-helper: Re-order bridge chain
 pre-enable and post-disable

+Linus, Marek and Tomi.

On Mon, Dec 01, 2025 at 08:34:37PM +0100, Vicente Bergas wrote:
> On Mon, Oct 6, 2025 at 5:30 PM Aradhya Bhatia <aradhya.bhatia@...ux.dev> wrote:
> >
> > +rockchip maintainers
> >
> > Hi Vicente, all,
> 
> Hi everybody,
> please, can some expert on this platform take a look at this bug?

There are similar issues with MCDE and R-Car DU, see
https://lore.kernel.org/all/CAD++jLkNCH=8VmwXh0UJS5QZ9wB-iP2kinytT+__fq0L1PzoZQ@mail.gmail.com/

I think we should revert commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1
and work on a clean solution. It broke too many drivers.

> > I went through the drivers and the affected areas in the gru-kevin
> > chromebook pipeline last week, but nothing has stood out.
> >
> >
> > Pipeline:
> >
> > rockchip,display-subsystem / rk3399-vop (Big/Lite) (CRTC) ->
> > rk3399-edp (Encoder) -> analogix_dp_core (Bridge) ->
> > sharp,lq123p (edp-panel)
> >
> > I am unable to debug this further since I do not have the hardware.
> >
> > I could use some help, especially from folks who understand the hardware
> > requirements better.
> >
> >
> > On 11/09/25 09:01, Aradhya Bhatia wrote:
> > > Hi Vicente,
> > >
> > > Thank you for the bisection and reporting the issue.
> > >
> > > On 10/09/25 16:17, Vicente Bergas wrote:
> > >> Hi,
> > >> this patch causes a regression. It has been reported in
> > >> https://bugzilla.kernel.org/show_bug.cgi?id=220554
> > >>
> > >> It affects the gru/kevin platform (arm64,RK3399) with the Panfrost DRM driver.
> > >
> > > I believe the Panfrost DRM driver may only be for the GPU.
> > >
> > > Based on the dts files in arm64/rockchip/, this is the pipeline of the
> > > gru-kevin setup that I understand.
> > >
> > >       rk3399-vop (Big/Lite) -> rk3399-edp -> sharp,lq123p (edp-panel)
> > >
> > > The setup seems to be using the drm/rockchip drivers for the display
> > > controller and for the bridge.
> > >
> > >>
> > >> When it boots in console mode, the blinking of the cursor keeps the display on.
> > >> If it is turned off via /sys/class/graphics/fbcon/cursor_blink, then
> > >> the display briefly shows each key press presented on screen for less
> > >> than one second and then powers off.
> > >>
> > >> When starting the graphical mode (wayland), if there are no
> > >> applications drawing on the screen, the only way to keep the display
> > >> on is by continuously moving the mouse.
> > >>
> > >
> > > Okay!
> > >
> > > I will have a look through the drivers. In the meanwhile, please do
> > > report back if you find any other observations.

-- 
Regards,

Laurent Pinchart