On Tue, Apr 07, 2015 at 06:48:15PM +0000, Konduru, Chandra wrote: > > > -----Original Message----- > > From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] > > Sent: Tuesday, April 07, 2015 2:02 AM > > To: Konduru, Chandra; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH] drm/i915: reset drm state backpointer in > > crtc_state > > > > On Mon, 06 Apr 2015, Chandra Konduru <chandra.konduru@xxxxxxxxx> 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 Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
