| Message ID | 1375180592-16514-1-git-send-email-imre.deak@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote: > Userspace can pass a mode with an unspecified vsync/hsync polarity > setting. All encoders in the Intel driver take this to mean a negative > polarity setting. The HW readout/state checker code on the other hand > needs these flags to be explicitly set, otherwise the state checker will > WARN about the mismatch. > > Get rid of the WARN by making the polarity setting explicit in the > adjusted mode flags based on the requested mode flags. This will keep > the existing behavior otherwise. > > Note that we could guess from the other timing parameters whether the > user wanted a VESA or other standard mode and set the polarity > accordingly. This is what the NV driver does > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very > exact and would change the existing behavior of the Intel driver. Right, don't guess. If the user wanted the standard mode, then the flags would have been taken from the standard modeline. > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 You can add a tested-by here for qa. > Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
On Tue, 2013-07-30 at 11:57 +0100, Chris Wilson wrote: > On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote: > > Userspace can pass a mode with an unspecified vsync/hsync polarity > > setting. All encoders in the Intel driver take this to mean a negative > > polarity setting. The HW readout/state checker code on the other hand > > needs these flags to be explicitly set, otherwise the state checker will > > WARN about the mismatch. > > > > Get rid of the WARN by making the polarity setting explicit in the > > adjusted mode flags based on the requested mode flags. This will keep > > the existing behavior otherwise. > > > > Note that we could guess from the other timing parameters whether the > > user wanted a VESA or other standard mode and set the polarity > > accordingly. This is what the NV driver does > > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very > > exact and would change the existing behavior of the Intel driver. > > Right, don't guess. If the user wanted the standard mode, then the flags > would have been taken from the standard modeline. > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 > > You can add a tested-by here for qa. Tested-by: Cancan Feng <cancan.feng@intel.com> > > Signed-off-by: Imre Deak <imre.deak@intel.com> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> CC'ing people who might be interested. After some discussion with Ville, we could refine this further at the drm core level by enforcing the Intel behavior - defaulting to negative polarity and also checking/sanitizing the PHSYNC/PVSYNC flags. PHSYNC/PVSYNC isn't used by the Intel driver so we could still go with the above patch for now and follow-up with a drm core fix. We should probably also reject modes at drm core level where both positive and negative flags are set, again in a separate follow-up patch. --Imre
On Tue, 2013-07-30 at 15:43 +0300, Imre Deak wrote: > On Tue, 2013-07-30 at 11:57 +0100, Chris Wilson wrote: > > On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote: > > > Userspace can pass a mode with an unspecified vsync/hsync polarity > > > setting. All encoders in the Intel driver take this to mean a negative > > > polarity setting. The HW readout/state checker code on the other hand > > > needs these flags to be explicitly set, otherwise the state checker will > > > WARN about the mismatch. > > > > > > Get rid of the WARN by making the polarity setting explicit in the > > > adjusted mode flags based on the requested mode flags. This will keep > > > the existing behavior otherwise. > > > > > > Note that we could guess from the other timing parameters whether the > > > user wanted a VESA or other standard mode and set the polarity > > > accordingly. This is what the NV driver does > > > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very > > > exact and would change the existing behavior of the Intel driver. > > > > Right, don't guess. If the user wanted the standard mode, then the flags > > would have been taken from the standard modeline. > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 > > > > You can add a tested-by here for qa. > > Tested-by: Cancan Feng <cancan.feng@intel.com> > > > > Signed-off-by: Imre Deak <imre.deak@intel.com> > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > > CC'ing people who might be interested. > > After some discussion with Ville, we could refine this further at the > drm core level by enforcing the Intel behavior - defaulting to negative > polarity and also checking/sanitizing the PHSYNC/PVSYNC flags. > PHSYNC/PVSYNC isn't used by the Intel driver so we could still go with Sorry, I meant PCSYNC/NCSYNC above. --Imre > the above patch for now and follow-up with a drm core fix. > > We should probably also reject modes at drm core level where both > positive and negative flags are set, again in a separate follow-up > patch. > > --Imre
On Tue, Jul 30, 2013 at 11:57:06AM +0100, Chris Wilson wrote: > On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote: > > Userspace can pass a mode with an unspecified vsync/hsync polarity > > setting. All encoders in the Intel driver take this to mean a negative > > polarity setting. The HW readout/state checker code on the other hand > > needs these flags to be explicitly set, otherwise the state checker will > > WARN about the mismatch. > > > > Get rid of the WARN by making the polarity setting explicit in the > > adjusted mode flags based on the requested mode flags. This will keep > > the existing behavior otherwise. > > > > Note that we could guess from the other timing parameters whether the > > user wanted a VESA or other standard mode and set the polarity > > accordingly. This is what the NV driver does > > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very > > exact and would change the existing behavior of the Intel driver. > > Right, don't guess. If the user wanted the standard mode, then the flags > would have been taken from the standard modeline. > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 > > You can add a tested-by here for qa. > > > Signed-off-by: Imre Deak <imre.deak@intel.com> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Queued for -next, thanks for the patch. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index baaefd7..98f0fa6 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8058,6 +8058,19 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, (enum transcoder) to_intel_crtc(crtc)->pipe; pipe_config->shared_dpll = DPLL_ID_PRIVATE; + /* + * Sanitize sync polarity flags based on requested ones. If neither + * positive or negative polarity is requested, treat this as meaning + * negative polarity. + */ + if (!(pipe_config->adjusted_mode.flags & + (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC))) + pipe_config->adjusted_mode.flags |= DRM_MODE_FLAG_NHSYNC; + + if (!(pipe_config->adjusted_mode.flags & + (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC))) + pipe_config->adjusted_mode.flags |= DRM_MODE_FLAG_NVSYNC; + /* Compute a starting value for pipe_config->pipe_bpp taking the source * plane pixel format and any sink constraints into account. Returns the * source plane bpp so that dithering can be selected on mismatches
Userspace can pass a mode with an unspecified vsync/hsync polarity setting. All encoders in the Intel driver take this to mean a negative polarity setting. The HW readout/state checker code on the other hand needs these flags to be explicitly set, otherwise the state checker will WARN about the mismatch. Get rid of the WARN by making the polarity setting explicit in the adjusted mode flags based on the requested mode flags. This will keep the existing behavior otherwise. Note that we could guess from the other timing parameters whether the user wanted a VESA or other standard mode and set the polarity accordingly. This is what the NV driver does (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very exact and would change the existing behavior of the Intel driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442 Signed-off-by: Imre Deak <imre.deak@intel.com> --- drivers/gpu/drm/i915/intel_display.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)