[Intel-gfx] [PATCH] drm/i915: reset drm state backpointer in crtc_state

[Konduru, Chandra]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, April 08, 2015 1:20 AM
> To: Konduru, Chandra
> Cc: Jani Nikula; intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: reset drm state backpointer in
> crtc_state
> 
> On Tue, Apr 07, 2015 at 06:48:15PM +0000, Konduru, Chandra wrote:
> >
> > > -----Original Message-----
> > > From: Jani Nikula [mailto:jani.nikula at linux.intel.com]
> > > Sent: Tuesday, April 07, 2015 2:02 AM
> > > To: Konduru, Chandra; intel-gfx at lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: reset drm state
> > > backpointer in crtc_state
> > >
> > > On Mon, 06 Apr 2015, Chandra Konduru <chandra.konduru at intel.com>
> wrote:
> > > > At end of intel_crtc_set_config, reset crtc_state's drm_state back
> > > > pointer to null.
> > >
> > > This does not tell me anything that reading the patch already
> > > didn't. Please explain *why* this is needed in the commit message.
> > > What breaks without it? If this fixes a regression, please indicate which
> commit regressed.
> >
> > Once atomic transaction is done, live crtc_state (i.e.,
> > intel_crtc->config) is carrying back pointer to drm_atomic_state which
> > is freed. When a new non-atomic transaction is made (crtc_disable
> > triggered off from set_mode), this stale pointer is carried into that transaction.
> > Depending on timing, this causes issue to scaler feature that I am
> > working if panel fit to be disabled during crtc_disable.
> 
> You shouldn't ever be chasing the state backpointer of a committed state.
> It's ok to clean it up, but chasing that pointer itself is a bug. Why does the scaler
> code look at that pointer?
While setting up scalers, it looks at that pointer to know other scaler users.

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch