Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 7f4c6284 authored by Ville Syrjälä's avatar Ville Syrjälä Committed by Daniel Vetter
Browse files

drm/i915: Assign hwmode after encoder state readout 



The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.

Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled

v2: Steal Maarten's idea to move crtc->mode etc. assignment too

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428


Reviewed-by: default avatarPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
parent 237ed86c

drivers/gpu/drm/i915/intel_display.c

+30 −27
Original line number Diff line number Diff line
@@ -15121,33 +15121,6 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev) 
		crtc->base.state->active = crtc->active;

		crtc->base.enabled = crtc->active;



		memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));

		if (crtc->base.state->active) {

			intel_mode_from_pipe_config(&crtc->base.mode, crtc->config);

			intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);

			WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, &crtc->base.mode));



			/*

			 * The initial mode needs to be set in order to keep

			 * the atomic core happy. It wants a valid mode if the

			 * crtc's enabled, so we do the above call.

			 *

			 * At this point some state updated by the connectors

			 * in their ->detect() callback has not run yet, so

			 * no recalculation can be done yet.

			 *

			 * Even if we could do a recalculation and modeset

			 * right now it would cause a double modeset if

			 * fbdev or userspace chooses a different initial mode.

			 *

			 * If that happens, someone indicated they wanted a

			 * mode change, which means it's safe to do a full

			 * recalculation.

			 */

			crtc->base.state->mode.private_flags = I915_MODE_FLAG_INHERITED;

		}



		crtc->base.hwmode = crtc->config->base.adjusted_mode;

		readout_plane_state(crtc, to_intel_crtc_state(crtc->base.state));



		DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
@@ -15207,6 +15180,36 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev) 
			      connector->base.name,

			      connector->base.encoder ? "enabled" : "disabled");

	}



	for_each_intel_crtc(dev, crtc) {

		crtc->base.hwmode = crtc->config->base.adjusted_mode;



		memset(&crtc->base.mode, 0, sizeof(crtc->base.mode));

		if (crtc->base.state->active) {

			intel_mode_from_pipe_config(&crtc->base.mode, crtc->config);

			intel_mode_from_pipe_config(&crtc->base.state->adjusted_mode, crtc->config);

			WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, &crtc->base.mode));



			/*

			 * The initial mode needs to be set in order to keep

			 * the atomic core happy. It wants a valid mode if the

			 * crtc's enabled, so we do the above call.

			 *

			 * At this point some state updated by the connectors

			 * in their ->detect() callback has not run yet, so

			 * no recalculation can be done yet.

			 *

			 * Even if we could do a recalculation and modeset

			 * right now it would cause a double modeset if

			 * fbdev or userspace chooses a different initial mode.

			 *

			 * If that happens, someone indicated they wanted a

			 * mode change, which means it's safe to do a full

			 * recalculation.

			 */

			crtc->base.state->mode.private_flags = I915_MODE_FLAG_INHERITED;

		}

	}

}



/* Scan out the current hw modeset state,