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.lankho...@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

Reply via email to