Re: [PATCH v2 13/20] drm/i915: Always reset in intel_crtc_restore_mode

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jul 07, 2015 at 12:48:36PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 12:17 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:24AM +0200, Maarten Lankhorst wrote:
> >> And get rid of things that are no longer true. This function is only
> >> used for forcing a modeset when encoder properties are changed.
> >>
> >> All the existing state is fine in this case, only setting mode_changed
> >> will force a full recalculation here, and take all the state needed.
> >>
> >> The previous commit will prevent unneeded modesets anyway.
> >>
> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 58 ++++++++++--------------------------
> >>  1 file changed, 16 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >> index 16373309dcae..f7b1fc28142c 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -13260,63 +13260,37 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
> >>  {
> >>  	struct drm_device *dev = crtc->dev;
> >>  	struct drm_atomic_state *state;
> >> -	struct intel_encoder *encoder;
> >> -	struct intel_connector *connector;
> >> -	struct drm_connector_state *connector_state;
> >> -	struct intel_crtc_state *crtc_state;
> >> +	struct drm_crtc_state *crtc_state;
> >>  	int ret;
> >>  
> >>  	state = drm_atomic_state_alloc(dev);
> >>  	if (!state) {
> >> -		DRM_DEBUG_KMS("[CRTC:%d] mode restore failed, out of memory",
> >> +		DRM_DEBUG_KMS("[CRTC:%d] crtc restore failed, out of memory",
> >>  			      crtc->base.id);
> >>  		return;
> >>  	}
> >>  
> >> -	state->acquire_ctx = dev->mode_config.acquire_ctx;
> >> -
> >> -	/* The force restore path in the HW readout code relies on the staged
> >> -	 * config still keeping the user requested config while the actual
> >> -	 * state has been overwritten by the configuration read from HW. We
> >> -	 * need to copy the staged config to the atomic state, otherwise the
> >> -	 * mode set will just reapply the state the HW is already in. */
> >> -	for_each_intel_encoder(dev, encoder) {
> >> -		if (encoder->base.crtc != crtc)
> >> -			continue;
> >> +	state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> >>  
> >> -		for_each_intel_connector(dev, connector) {
> >> -			if (connector->base.state->best_encoder !=
> >> -			    &encoder->base)
> >> -				continue;
> >> -
> >> -			connector_state = drm_atomic_get_connector_state(state, &connector->base);
> >> -			if (IS_ERR(connector_state)) {
> >> -				DRM_DEBUG_KMS("Failed to add [CONNECTOR:%d:%s] to state: %ld\n",
> >> -					      connector->base.base.id,
> >> -					      connector->base.name,
> >> -					      PTR_ERR(connector_state));
> >> -				continue;
> >> -			}
> >> +retry:
> >> +	crtc_state = drm_atomic_get_crtc_state(state, crtc);
> >> +	ret = PTR_ERR_OR_ZERO(crtc_state);
> >> +	if (!ret) {
> >> +		if (!crtc_state->active)
> >> +			goto out;
> >>  
> >> -			connector_state->crtc = crtc;
> >> -		}
> >> +		crtc_state->mode_changed = true;
> >> +		ret = intel_set_mode(state);
> > I think here (instead of the hw state readout/restore code) we must do a
> > full compute config of the pipe state - most of the connector properties
> > need that to get reflected. Should be easy to test by changing the panel
> > upscaling property. Hence I think we should be able to run a full-blown
> > drm_atomic_commit here.
> Which is what this code does?
> Together with the previous commit at least, without it it just performs a full modeset and recalculation.

Oh I had a confusion about what intel_set_mode does, I thought it only
does the commit side of things and doesn't do all the compute_config
stuff. I guess this is something to clean up once we have it all landed,
but I'd have expected that a drm_atomic_commit(state) would exactly do
what we want to do here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx