> -----Original Message----- > From: Daniel Vetter [mailto:[email protected]] On Behalf Of Daniel Vetter > Sent: Wednesday, April 08, 2015 1:20 AM > To: Konduru, Chandra > Cc: Jani Nikula; [email protected] > 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:[email protected]] > > > Sent: Tuesday, April 07, 2015 2:02 AM > > > To: Konduru, Chandra; [email protected] > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: reset drm state > > > backpointer in crtc_state > > > > > > On Mon, 06 Apr 2015, Chandra Konduru <[email protected]> > 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 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
