linux-kernel - Re: [PATCH 1/2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

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] [day] [month] [year] [list]

Date:   Tue, 17 Jul 2018 09:54:03 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     "stefan@...er.ch" <stefan@...er.ch>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "marex@...x.de" <marex@...x.de>
CC:     "A.s. Dong" <aisheng.dong@....com>,
        dl-linux-imx <linux-imx@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Laurentiu Palcu <laurentiu.palcu@....com>,
        Robert Chiras <robert.chiras@....com>,
        Marco Antonio Franchi <marco.franchi@....com>,
        Fabio Estevam <fabio.estevam@....com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Mirela Rabulea <mirela.rabulea@....com>
Subject: Re: [PATCH 1/2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

On Fri, 2018-07-13 at 12:57 +0200, Stefan Agner wrote:
> On 05.06.2018 19:11, Leonard Crestez wrote:
> > Adding imx6sl/sx lcdif nodes in a power domain currently does work, it
> > results in black/corrupted screens or hangs. While the driver does
> > enable runtime pm it does not deal correctly with the block being
> > unpowered.
> > 
> > Fix by adding pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
> > 
> > The mxsfb_plane_atomic_update function can get called before
> > mxsfb_pipe_enable while the block is not powered. When this happens the
> > write to LCDIF_NEXT_BUF is lost causing random corrupted pixels on
> > unblank.
> > 
> > Fix this by splitting the writing of gem->paddr to nextbuf into a
> > mxsfb_update_hw_next_buf functiona and also calling it from
> > mxsfb_crtc_mode_set_nofb.
> > 
> > Also add fields to mxsfb_drv to keep track of enabled/suspended states.

> > +static void mxsfb_update_hw_next_buf(struct mxsfb_drm_private *mxsfb)
> > +{
> > +	struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
> > +	struct drm_gem_cma_object *gem;
> > +
> > +	if (!fb)
> > +		return;
> > +
> > +	gem = drm_fb_cma_get_gem_obj(fb, 0);
> > +	if (!gem)
> > +		return;
> > +
> > +	writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
> > +}
> > +
> >  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
> >  {
> >  	struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
> >  	const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
> >  	u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
> > @@ -268,35 +283,41 @@ static void mxsfb_crtc_mode_set_nofb(struct
> > mxsfb_drm_private *mxsfb)
> >  	       mxsfb->base + LCDC_VDCTRL3);
> >  
> >  	writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
> >  	       mxsfb->base + LCDC_VDCTRL4);
> >  
> > +	mxsfb_update_hw_next_buf(mxsfb);
> >  	mxsfb_disable_axi_clk(mxsfb);
> >  }
> >  
> >  void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
> >  {
> > +	if (mxsfb->enabled)
> > +		return;
> > +
> >  	mxsfb_crtc_mode_set_nofb(mxsfb);
> >  	mxsfb_enable_controller(mxsfb);
> > +
> > +	mxsfb->enabled = true;
> 
> Is this state keeping really necessary?

Sort of. The code is indeed a bit complicated, there are 3 possible
states: "disabled", "enabled", "enabled but suspended"

When the device resumes it should enable the controller only if it was
enabled before (not if screen is blanked). After some digging I found
that suspend/resume could be better implemented using
drm_mode_config_helper_suspend/resume. This should automatically
remember the crtc state "properly" without keeping state in the driver.

One notable issue is that the lcdif block is only powered while the
crtc is enabled but mxsfb_plane_atomic_update can be called outside
that. So we need to check if the CRTC is enabled inside
mxsfb_plane_atomic_update and avoid writing to hardware. Instead the HW
write for next is delayed for the next mxsfb_crtc_mode_set_nofb.

Does this make sense? Being unable to update the plane if the crtc is
not enabled seems like it would be a common limitation of simple
display controllers.

Writing the FB paddr from mxsfb_crtc_mode_set_nofb feels wrong and I'm
not sure it behaves correctly: when the display is resumed it seems to
output an initial frame of incorrect data. It's possible the enable
sequence needs to be adjusted.