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? -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
