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
dri-devel@lists.freedesktop.org
-
Imre Deak