• D
    drm/crtc-helper: explicit DPMS on after modeset · 25f397a4
    Daniel Vetter 提交于
    Atm the crtc helper implementation of set_config has really
    inconsisten semantics: If just an fb update is good enough, dpms state
    will be left as-is, but if we do a full modeset we force everything to
    dpms on.
    
    This change has already been applied to the i915 modeset code in
    
    commit e3de42b6
    Author: Imre Deak <imre.deak@intel.com>
    Date:   Fri May 3 19:44:07 2013 +0200
    
        drm/i915: force full modeset if the connector is in DPMS OFF mode
    
    which according to Greg KH seems to aim for a new record in most
    Bugzilla: links in a commit message.
    
    The history of this dpms forcing is pretty interesting. This patch
    here is an almost-revert of
    
    commit 811aaa55
    Author: Keith Packard <keithp@keithp.com>
    Date:   Thu Feb 3 16:57:28 2011 -0800
    
        drm: Only set DPMS ON when actually configuring a mode
    
    which fixed the bug of trying to dpms on disabled outputs, but
    introduced the new discrepancy between an fb update only and full
    modesets. The actual introduction of this goes back to
    
    commit bf9dc102
    Author: Keith Packard <keithp@keithp.com>
    Date:   Fri Nov 26 10:45:58 2010 -0800
    
        drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
    
    And if you'd dig around in the i915 driver code there's even more fun
    around forcing dpms on and losing our heads and temper of the
    resulting inconsistencies. Especially the DP re-training code had tons
    of funny stuff in it.
    
    v2: So v1 totally blew up on resume on my radeon system here. After
    much head-scraching I've figured out that the radeon resume functions
    resumes the console system _before_ it actually restores all the
    modeset state. And resuming the console systems means that fbdev doeas
    an immediate ->set_par call.
    
    Now up to this patch that ->set_par did absolutely nothing: All the
    old sw state from pre-suspend was still around (since the modeset
    reset wasn't done yet), which means that the set_config calls done as
    a result of the ->set_par where all treated as no-ops (despite that
    the real hw state was obviously something completely different).
    
    Since v1 of this patch just added a bunch of ->dpms calls if the crtc
    was enabled, those set_config calls suddenly stopped being no-ops. But
    because the hw state wasn't restored the ->dpms callbacks resulted in
    decent amounts of hilarity and eventual full hangs.
    
    Since I can't review all kms drivers for such tricky ordering
    constraints v2 opts for a different approach and forces a full modeset
    if the connector dpms state isnt' DPMS_ON. Since the ->dpms callbacks
    implemented by the modeset helpers update the connector->dpms property
    we have the same effect of ensuring that the pipe is ultimately turned
    on, even if we just end up updating the fb. This is the same approac
    we ended up using in the intel driver.
    
    Note that besides i915.ko only all other drivers eventually call
    drm_helper_connector_dpms with the exception of vmwgfx, which does not
    support dmps at all.
    
    v3: Dave Airlie merged the broken first version of this patch, so
    squash in the revert of
    
    commit 372835a8
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Sat Jun 15 00:13:13 2013 +0200
    
        drm/crtc-helper: explicit DPMS on after modeset
    
    Also fix up the spelling fail a bit in the commit message while at it.
    
    Cc: Dave Airlie <airlied@redhat.com>
    Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67043Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: NDave Airlie <airlied@redhat.com>
    25f397a4
drm_crtc_helper.c 31.5 KB