On VLV/CHV both pipes A and B have their own backlight control
registers. In order to correctly read out the current hardware state at
init we need to know which pipe is driving the eDP port. Pass that
information down from the eDP init code into the backlight code.

To determine the correct pipe we first look at which pipe is currently
configured in the port control register, if that look invalid we look
at which pipe's PPS is currently controlling the port, and if that
too looks invalid we just assume pipe A.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As per spec, and similar to DDI.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add support for disabling the audio codec on vlv/chv/gen5-7, similar to
hsw/bdw.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-ddi platforms we don't shut down the link when changing link
training parameters. Except when clock recovery fails too hard and we
restart with channel eq training. Which doesn't make a lot of sense
really, since just stopping/restarting the DP port at this point
violates the modeset sequence documented in the Bspec.

So let's tempt fate and try this.

This patch is motivated by a WARN_ON triggered by

commit bc76e320
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue May 20 22:46:50 2014 +0200

    drm/i915: Drop now misleading DDI comment from dp_link_down

References: https://bugs.freedesktop.org/show_bug.cgi?id=85670Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we suspend we turn everything off so the pps should be idle, and we
also (or at least should) disable all power wells which will reset the
power sequencer port assignment. So when we resume all power sequencers
should be in their reset state. However it's at least theoretically
possible that the BIOS would touch the power seuqencer(s), so to be safe
we ought to read out the current port assignment like we do at driver
init time.

To do that we can simply call vlv_initial_power_sequencer_setup() from
the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize().
There's no danger or clobbering the pps delays since we now have those
stored within intel_dp and we don't change them once initialized.

This will make sure that the vdd state gets correctly tracked post-resume
in case the BIOS enabled it.

We need to shuffle things around a bit to get the locking right, and
while at it, make intel_edp_panel_vdd_sanitize() static and move it
around a bit to avoid a forward declaration.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pps timestamp initialization was accidentally lost on vlv/chv in

 commit a4a5d2f8
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Thu Sep 4 14:54:20 2014 +0300

    drm/i915: Track which port is using which pipe's power sequencer

Restore it so that we avoid introducing random delays into the pps operations
during/after driver init time.

Cc: Imre Deak <imre.deak@intel.com>
Reported-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduce functions to enable/disable the audio codec, incorporating the
ELD setup within enable. The disable is initially limited to HSW,
covering exactly what was done previously.

The only functional difference is that ELD valid is no longer set if
there is no connector with ELD, which should be the right thing to do
anyway. Otherwise the sequence remains the same, with warts and all, in
preparation for applying more sanity.

v2: add kernel doc.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The power seqeuencer kick procedure requires the DPLL to be running
in order to complete successfully. In case the DPLL isn't currently
running when we need to kick the power seqeuncer enable it
temporarily. This can happen eg. during ->detect() when the pipe is
not already active.

To avoid needlessly duplicating the DPLL programming re-use the already
existing functions by passing a temporary pipe config to them instead
of having them consult the current pipe config at crtc->config.

v2: Introduce vlv_force_pll_{on,off}() (Daniel)
v3: Rebase due to drm_crtc vs. intel_crtc changes
    Fix a typo in commit msg (checkpatch)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
[danvet: Appease checkpatch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDP ports need the power seqeuncer whenever the port is active. Warn if
we accidentally steal the power sequener from an active eDP port. This
should not happen unless there's a bug somewhere else, but it's best to
scream loudly if it happens to help with debugging.

Note that this only checks for active pipes and not for enabled pipes
which are turned off with dpms. Which means we might run the risk that
the pps might get stolen and we can't reacquire one when enabling the
pipe again with dpms on. But on current platforms that's impossible
since we only support two edp ports with just two panel power
sequencers. So a more elaborate scheme which reserves the pps even
when the pipe is inactive isn't required.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Summarize my discussion with Ville about dpms on/off issues.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should never enable the panel power twice. That would indicate a bug
somewhere else as we would need to enable the port twice without
disabling it in between. Also print the port name.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Print the port name in the VDD/PPS debugs messages.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In case we fumble something and end up picking an already used power
seqeuencer in vlv_power_sequencer_pipe() at least try to steal it
gracefully. In theory this should never happen though.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no power sequencer on pipe C on VLV/CHV so scream a bit if we
try to steal one from pipes other than A and B.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV gets confused if two power sequencers have the same port selected.
It would seem the port doesn't start up properly in the is case and
vlv_wait_port_ready() will fail as will the link training. Clearing the
port select in the PP_ON_DELAYS register fixes this problem.

CHV doesn't seem to need this, but it doesn't seem to hurt either so
let's just do it for both to keep the code between the platforms as
uniform as possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If there's no power sequencer assigned to the port currently we can't
very well have vdd or panel power enabled either. If we would try to
check that from the pps registers we'd need to pick a power seqeuncer
and kick it. So let's skip the register read and the kick.

Note that there's still a bit an issue about correctly recovering pps
state from resume if the bios is nasty: With this check we'll always
assume that the pps is off. But that's better done in a follow-up
patch and it shouldn't be too harmful - at most we waste time enabling
the pps if it's on already.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Add note about resume issues Imre spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we pick a new power sequencer for the port but we're not doing a
full modeset, the power sequencer may have locked on to another port (or
no port). So kick it a bit to make sure it controls the port we want.

Again just like when we attempt to actually enable the DP port, we
must first write the port register with the approriate value except
the enable bit, and then we must enable the port to make the power
sequencer happy. In this case since we don't want the port actually
enabled we just toggle it on and immediately back off. Going forward
the power sequencer will keep working on that specific port until again
moved to another port.

v2: Refine the kick procedure
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done before any AUX transactions are attempted.

After extensive experimentation I've determined that it's sufficient
to first write the port register with the correct values except the
port must remain disabled, then we can do a second write to enable the
port, after which the power sequencer is operational and allows the port
to start up properly.

Contrary to my earlier theories we don't need to enable the port with
the idle pattern, so let's just use training pattern 1 as that's what
other platforms use here.

v2: Refine the kick procedure
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no point in checking if the data lanes came out of reset after
link training. If the data lanes aren't ready link training will fail
anyway.
Suggested-by: NTodd Previte <tprevite@gmail.com>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just grab the pps_mutex once and do all the pps panel startup operations
while holding the mutex instead of grabbing the mutex separately for
each individual step.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We'll be needing to the call the power seqeuencer functions while
already holding pps_mutex, so split the locking out to small wrapper
functions.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since we read the current power seqeuncer delays from the registers
(as well as looking at the vbt and spec values) we may end up
corrupting delays we already initialized when we switch to another
pipe and the power seqeuncer there has different values currently
in the registers.

So make sure we only initialize the delays once even if
intel_dp_init_panel_power_sequencer() gets called multiple times.

There was some discussion in the review about when exactly we need to
unlock the pps. Quoting Bspec:

"If this bit is not a zero, it activates the register write protect
 and writes to those registers will be ignored unless the write
 protect key value is set in the panel sequencing control register."
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Add Bspec quote per review discussion between Imre and
Ville.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The power seqeuncer delays are fixed for a given panel, so we can keep
them around once computed.

Not that on VLV/CHV we still re-compute them every time we initialize
the power seqeuncer registers, but that will change soon enough.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

want_panel_vdd is a bool so it can't cope with interleaving on/off calls
from multiple threads. If we want to make that possible we'd need to
convert want_panel_vdd into a proper ref count. But an easier fix is to
remove the high level vdd on/off calls from detect/hpd code paths and
just rely on the delayed vdd off to avoid needless vdd on<->off ping
pong.

After this change only the encoder enable/disable paths use the high
level functions, which is fine since both the on and off low level edp
vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in
between and so want_panel_vdd can't change in between.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only ports B and C have the power sequencer and backlight controls,
so complain if we ever try to register an eDP connector on some other
port.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Everything else can be derived from that. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Clear the override bits to make sure the hardware manages
the TX FIFO reset master on its own.

v2: Squash with the earlier attempt at forcing the override bits
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The register can house two different swing marging/deemph settings at
once. However only one gets used based on some other bits. Make sure we
set those bits correctly to make the hardware use the settings we
provided.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Even though it's unliky, we should check each aux transaction not just
the first one. Also

commit ce31d9f4
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Mon Sep 29 18:29:52 2014 -0400

    drm/i915: preserve other DP_TEST_SINK bits.

added a new aux transaction before the one which was checked. Fix
this.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Inspired by Ville constifying the send buffer for pach_aux.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
and use the defines from dp_dp_helper.h to populate the message
contents.

v2: Use sizeof() for message size (Jani)
    Use a generic loop to write EDP_PSR_AUX_DATA registers

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- fini goes with init, so call it intel_power_domains_fini. While
  at it shovel some of the fini code that leaked out of it back in.

- give power_enabled functions the verb _is_ to make the meaning clearer.
  Also use a __ prefix instead of _unlocked to really discourage users.

- rename runtime_pm_init/fini to enable/disable since that's what they do.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sink crc was implemented based on dp 1.1 spec that had all TEST_SINK bits
reserved reading all 0s. But when reviewing my latest changes on sink crc
Todd warned me that on new specs we have other valid bits on this reg that we
might want to preserve.

Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.

So let's give up to 6 vblank wait time. However we now check for
TEST_CRC_COUNT that shows when panel finished to calculate CRC and
has it ready.

v2: Jani pointed out attempts decrements was wrong and should never reach
the error condition. And Daniel pointed out that EIO is more appropriated than
EGAIN. Also I realized that I have to read test_crc_count after setting
test_sink

v3: Rebase and adding error message

Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's make sure PSR is propperly disabled before to re-enabled it.

According to Spec, after disabled PSR CTL, the Idle state might occur
up to 24ms, that is one full frame time (1/refresh rate),
plus SRD exit training time (max of 6ms),
plus SRD aux channel handshake (max of 1.5ms).

So if something went wrong PSR will be disabled until next full
enable/disable setup.

v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode. However
on low frequency modes this can take longer. So let's use 50ms for safeness.

v3: Move wait out of psr.lock critical area.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The panel has to be reconfigured only when it really loose the power.
The traditional enable/disable sequence already take care of this so we can
minimize the time spend on every re-enable.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Skylake doesn't use the pre-charge field now, but, instead, we need to
specify the total number of SYNC pulses for the SYNC phase (pre-charge +
SYNC pattern pules). Let's use the default value (32) for that.

v3: increase DP AUX TX timeout as 400us is not to be used on SKL
    apparently (Jesse).
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to provide a vfunc that will make the code in intel_dp_aux_ch()
loop once to start the AUX transaction. The return value (clock divider)
is unused on SKL, so just return 1.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So we can apply the old aux_ctl = dp_ctl + 0x10 rule again.
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They are similar to Haswell.

v2: Rebased on top of drm-intel-nightly
v3: Rebased on top of Sonika's DP train defines renaming
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't need to setup everything else if it doesn't match all conditions.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>