> -----Original Message----- > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel Vetter > Sent: Wednesday, April 08, 2015 1:20 AM > To: Konduru, Chandra > Cc: Jani Nikula; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [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@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? 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 Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
