• A
    drm/radeon: work around KMS modeset limitations in PLL allocation (v2) · 57b35e29
    Alex Deucher 提交于
    Since the current KMS API sets the mode independantly on
    each crtc, we may end up with resource conflicts.  The PLL
    allocation is one of those cases.  In the following example
    we have 3 crtcs in use driving 2 DVI connectors and 1 DP
    connector.  On the initial kernel modeset for fbdev, the
    display topology ends up as follows:
    
    crtc0 -> DP-0
    crtc1 -> DVI-0
    crtc2 -> DVI-1
    
    Because this is the first modeset, all of the PLLs are
    available as none have been assigned.  So we end up with
    the following:
    
    crtc0 uses DCPLL
    crtc1 uses PPLL2
    crtc2 uses PPLL1
    
    When X starts, it assigns a different topology:
    
    crtc0 -> DVI-0
    crtc1 -> DP-0
    crtc2 -> DVI-1
    
    However, since the KMS API is per crtc, we set the mode on each
    crtc independantly.  When it comes time to set the mode on crtc0,
    the topology for crtc1 and crtc2 are still intact.  crtc1 and
    crtc2 are already assigned PPLL2 and PPLL1 so when it comes time
    to set the mode on crtc0, crtc1 and crtc2 have not been torn down
    yet, so there appears to be no PLLs available.  In reality, we
    are reconfiguring the entire display topology, however, since
    each crtc is handled independantly, we don't know that in the
    driver at each crtc mode set time.
    
    This patch checks to see if the same connector is being driven by
    another crtc, and if so, uses the PLL already associated with it.
    
    v2: store connector in the radeon crtc struct, simplify checking.
    Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
    57b35e29
atombios_crtc.c 61.0 KB