drm/radeon: work around KMS modeset limitations in PLL allocation (v2)
authorAlex Deucher <alexander.deucher@amd.com>
Mon, 17 Sep 2012 21:34:45 +0000 (17:34 -0400)
committerAlex Deucher <alexander.deucher@amd.com>
Thu, 27 Sep 2012 14:22:40 +0000 (10:22 -0400)
commit57b35e29cf4e45eb163631c4ece10dbc259ddf30
treeadd8d0761eb25bd74bb0ee1e94fd77f93f77e8e0
parent9642ac0e645198b62f99279704e829a286f58d96
drm/radeon: work around KMS modeset limitations in PLL allocation (v2)

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: Alex Deucher <alexander.deucher@amd.com>
drivers/gpu/drm/radeon/atombios_crtc.c
drivers/gpu/drm/radeon/radeon_mode.h