Sharing PPLLs seems to cause problems on some boards.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=45334Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Since we aren't using it when the crtc is disabled, turn it off
to save power.  The GRPH block is the part of the display
controller that controls the primary graphics plane (size,
address, etc.).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Required for checking vblank time for mclk changes.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Only Bonaire has PPLL0.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

v2: make PPLL0 is available for non-DP on CI
v3: rebase changes, update documentation
v4: fix kabini
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some new fields and DESKTOP_HEIGHT register moved.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

bool in_mode_set from struct radeon_crtc is not used anymore.
Signed-off-by: NNiels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Monitors seem to prefer it.  Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=37696Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Only enable it when we disable the display rather than
at DPMS time since enabling it requires a full modeset
to restore the display state.  Fixes blank screens in
certain cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fixes flickering with some high res montiors.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org

This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.

agd5f: drop unnecessary crtc id check, cc stable in case
we miss 3.7.

This fixes the root cause that was worked around by commits:
drm/radeon: allocate PPLLs from low to high
drm/radeon/dce3: switch back to old pll allocation order for discrete
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The order shouldn't matter, but this seems to cause regressions for
certain specific cases.  This should fix it for now.  We probably
need to investigate a proper fix in the next development cycle.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Andy Furniss <andyqos@ukfsn.org>

The order shouldn't matter, but there have been problems
reported on certain older asics.  This behaves more
like the original code before the PPLL allocation
rework.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc:  Markus Trippelsdorf <markus@trippelsdorf.de>

This allows us to bail if we can't support the requested
setup from a PPLL perspective.  Prevents broken setups
from being attempted.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

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>

Compare the adjusted clock as well as the crtc mode
clock.  This handles cases where the driver adjusts
the clock for specific special cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This saves lots of lookups later.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need the calculate the pixel clock before allocating a PPLL
in order to insure the clocks really match.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If several non-DP displays use the same pixel clock
we can use the same PPLL for all of them.  If all
relevant displays have the same pixel clock, this
allows the driver to:
- use fewer PPLLs which saves power
- support more than two non-DP displays on DCE4+

The current drm modesetting infrastructure doesn't
really provide a good framework for validating combinations
that work or won't work, so it's possible you could go from
a working configuration to a non-working one by changing the
mode a one of the displays.  However, there this is better
than what was there before.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If possible, use a single PPLL for multiple DP displays
on DCE3.x.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.
v4: - same as v3, but re-apply to drm-next as the corner
      cases are fixed properly in subsequent patches.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

MiscInfo field should be programmed with the crtc id
rather than the pll id.  However, at this point the
two are the same for chips with this version of the table.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 985f61f7.

This commit fixed certain cases, but ended up regressing others
due to limitations in the current KMS API.  A proper fix is too
invasive for 3.6.  Push it back to 3.7.
Reported-by: NAndres Freund <andres@anarazel.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Power gating is per crtc pair, but the powergating registers
should be called individually.  The hw handles power up/down
properly.  The pair is powered up if either crtc in the pair
is powered up and the pair is not powered down until both
crtcs in the pair are powered down.  This simplifies
programming and should save additional power as the previous
code never actually power gated the crtc pair.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Some plls are shared for DP.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

When checking if a pll is in use.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If spread spectrum is enabled and in use for a given pll we
should not turn it off as it will lead to turning off display
for crtc that use the pll (this behavior was observed on chelsea
edp).
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.

Noticed by kallisti5 on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to make sure the crtc is gated on before modesetting.
Explicitly gate the crtc on in prepare() and set a flag
so that the dpms functions don't gate it off during
mode set.

Noticed by sylware on IRC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The passed mode must not be modified by the operation, make it const.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Need to actually set the SS parameters rather than just 0.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

- Use the correct union for getting the tiling info
- Properly init the PIPE_CONFIG field for SI
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Makes Nutmeg DP to VGA bridges work for me.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=42490

Noticed by Jerome Glisse (after weeks of debugging).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Seems to be more stable on certain monitors.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=48880Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Improve handling of bpc (bits per color) in radeon.
In most cases we want 8 except for HDMI, DP, LVDS, and eDP.

v2: handle DP better.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Tested-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Using the bpc (bits per color) specified by the monitor
can cause problems in some cases.  Until we get a better
handle on how to deal with those cases, just use a bpc of 8.
Reported-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>