This reverts
commit dff392db
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 6 17:32:41 2013 -0200

    drm/i915: don't touch the VDD when disabling the panel

which didn't take into account

commit 6cb49835
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel

and

commit 35a38556
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Aug 12 22:17:14 2012 +0200

    drm/i915: reorder edp disabling to fix ivb MacBook Air

Unsurprisingly, various MacBooks failed.

Effectively the same has already been done in drm-intel-next-queued.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628Tested-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

| has a higher precedence than ?. Therefore, the calculation doesn't do
at all what you would expect. Thanks to Ken for convincing me that this
was indeed the issue. Send me back to C programmer school, please.

I'm sort of surprised PSR was continuing to work for people. It should
be broken IMO (and it was broken for me, but I had assumed it never
worked).

Regression from:
commit ed8546ac
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Mon Nov 4 22:45:05 2013 -0800

    drm/i915/bdw: Support eDP PSR

Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Reported-by: N"Kumar, Kiran S" <kiran.s.kumar@intel.com>
Cc: stable@vger.kernel.org [v3.13+]
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Retrying indefinitely places too much trust on the aux implementation of
the sink devices.
Reported-by: NDaniel Martin <consume.noise@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: NTheodore Ts'o <tytso@mit.edu>
Tested-by: NSree Harsha Totakura <freedesktop@h.totakura.in>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Give more slack to sink devices before retrying on native aux
defer. AFAICT the 100 us timeout was not based on the DP spec.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org (on Jani's request)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently it's broken in the exact same way as the gmbus irq. For
reference of the full story see

commit c12aba5a
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Mar 19 09:56:57 2013 +0100

    drm/i915: stop using GMBUS IRQs on Gen4 chips

The effect is that we have a storm of unclaimed interrupts on the
legacy irq line. If that one is used by a different device then the
kernel will complain and rather quickly kill the irq source. Which
breaks any device trying to actually use the legacy irq line.

This regression has been introduced

commit 4aeebd74
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 31 09:53:36 2013 +0100

    drm/i915: dp aux irq support for g4x/vlv

Note that disabling MSI works around the issue, but we can't do that
since apparently then the hw will miss interrupts. At least if
relevant comments in i915_irq.c are accurate.

v2: Cross-reference dp aux and gmbus gen4 comments.

v3: Consolidate harder into i915_drv.h as suggested by Chris.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: NJiri Kosina <jkosina@suse.cz>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm we setup the HW panel power sequencer logic both for eDP and DP
ports. On eDP we then go on and start the power on sequence and commence
with link training when it's ready. On DP we don't do the power on
sequencing but do the link training immediately. At this point the DP
PHY block gets stuck, since - supposedly - it is waiting for the power
on sequence to finish. The actual register write that seems to hold off
the PHY is PIPEX_PP_ON_DELAYS[Panel Control Port Select]. Writing here
a non-0 value eventually sets PIPEX_PP_STATUS[Require Asset Status] to
1 and blocks the PHY until the panel power on is ready.

Fix this by not doing any PP sequencing setup for DP ports.

Thanks to Ville Syrjälä, Jesse Barnes and Todd Previte for the help in
tracking this down.

Note that on older gmch platforms (where we have lvds instead of edp)
we've hacked around this by writing the magic ABCD unlock key to PP
registers, which disables the hw sanity checks.

For edp all platforms thus far had the pch split, with the edp port in
the north display complex and the PP registers on the pch the hw
sanity checks (expressed through the "Require Asset Status" bit) was
never functional, hence never a real issue.

This regression has been introduce in

commit bf13e81b
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 6 07:40:05 2013 +0300

    drm/i915: add support for per-pipe power sequencing on vlv
Signed-off-by: NImre Deak <imre.deak@intel.com>
[danvet: Add note about the bigger story here.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add new definitions for hotplug live status bits for VLV2 since they're
in reverse order from the gen4x ones.

Changelog:
- Restored gen4 bit definitions
- Added new definitions for VLV2
- Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct
  bit defintions
- Replaced a lost trailing brace for the added switch()
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951
[danvet: Switch to _VLV postfix instead of prefix and regroupg
comments again so that the g4x warning is right next to those defines.
Also add a _G4X suffix for those special ones. Also cc stable.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.

As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.

v2:
- fix explanation of change impact (Chris)
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.

Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).

Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.

See also the next patch fixing the other half of this issue.

Solution suggested by Ville.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current values seem to be defined in a format that's specific to the
i915, gma500 and radeon drivers. To make this more generally useful, use
the values as defined in the specification.

While at it, prefix the constants with DP_ for improved namespacing.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for panel_power_cycle_delay, not
panel_power_down_delay, because the power down delay was already
respected when we disabled the panel.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo.
Also drop the runtime_pm_put call which now has to go due to different
patch ordering. Also from Paul.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get some messages saying we're touching registers while the HW
is suspended.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are needed when we cat the debugfs and sysfs files.

V2: - Rebase
V3: - Rebase
V4: - Rebase
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When inspecting reports that boot/suspend/resume times are unusual it
would be useful to clearly identify the time we must spend waiting for
the hardware to complete its task. In this case we have a notification
before we start waiting for the panel to change state, but none
afterwards - which would be useful.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sweeping some dead code away.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reduce the eDP detection to just checking if it's port A, or if
the VBT tells us that the port is eDP for the other ports.
Suggested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.

So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051Tested-by: NRobert Hooker <robert.hooker@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now we have this everywhere. Next up would be to wire up the DP
hotplug pin to speed up panel power sequencing for eDP panels ...

I've decided to leave the has_aux_irq logic in the code, it should
come handy for hw bringup.

For testing/fail-safety the dp aux code already has a timeout when
waiting for interrupts to signal completion and screams rather loud if
they don't arrive in time. Given that we need a real piece of hw to
talk to anyway this is probably as good as it gets.

v2: Don't check the dp aux channel bits on i965 machines, they have a
different meaning there. Yay for reusing bits at will! Spotted by
Jani.

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We used to put the local sink and any downstream sinks to power down
mode at disable or dpms off using the DPCD SET_POWER register, until
this was broken by

commit e8cb4558
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 1 13:05:48 2012 +0200

    drm/i915/dp: convert to encoder disable/enable

Fix it.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index.  This should better to gather for upcoming platform.

v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO register define.

v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
DPIO_PHY, and remove unrelated change. (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Broadwell PSR support is a superset of Haswell. With this simple
register base calculation, everything that worked on HSW for eDP PSR
should work on BDW.

Note that Broadwell provides additional PSR support. This is not
addressed at this time.

v2: Make the HAS_PSR include BDW

v3: Use the correct offset (I had incorrectly used one from my faulty
brain) (Art!)

v4: It helps if you git add

v5: Be explicit about not setting min link entry time for BDW. This
should be no functional change over v4 (Jani)
Reviewed-by: NArt Runyan <arthur.j.runyan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They're not the same as the Haswell ones.
Reviewed-by: NArt Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some VLV PHY/PLL DPIO registers have group/lane/channel access.  Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document.  Rename those registers based on the configdb for easy
cross references, and without the need to check the offset in the header
file.

New format is as following.

<platform name>_<DPIO component><optional lane #>_DW<dword # in the
doc>_<optional channel #>

For example,

VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0.
VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0.

Another example is

VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0
VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0.

There is no functional change on this patch.

v2: Rebase based on previous patch change.
v3: There may be configdb different version that document the start DW
differently. Add a comment to clarify.  Fix up some mismatch start DW
for second PLL block. (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info.  So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out the pipe backlight to adjust.

v2: make connector pipe lookup check for NULL crtc (Jani)
    fixup connector check in ASLE code (Jani)
v3: make sure we take the mode config lock around lookups (Daniel)
v4: fix double unlock in panel_get_brightness (Daniel)
v5: push ASLE work into a work queue (Daniel)
v6: separate ASLE work to a prep patch, rebase (Jani)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All the bits in the VBT child device type have some speciifc meaning,
so looking for an exact match isn't always the right thing. On some
VLVs for example the device type for eDP panels is 0x1806.

If we mask out the bits that could concievably change between different
eDP panels, we are left with the set of bits that should still
tell us if the port is eDP or not.

v2: Use the named bits for VBT child device type

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051Tested-by: NRobert Hooker <robert.hooker@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

That explains why I was seeing 2 consecutive "Turning eDP VDD off"
messages.

Regression introduced by:
    commit bf13e81b
    Author: Jani Nikula <jani.nikula@intel.com>
    Date:   Fri Sep 6 07:40:05 2013 +0300
        drm/i915: add support for per-pipe power sequencing on vlv
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now we only print messages when we actually enable VDD and when we
actually disable VDD.

The changes in the last commit triggered a big number of messages
while the driver was being initialized, and I thought we were toggling
things on/off too many times, but that was not really true: we were
just being too verbose.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the eDP output is disabled, then we try to use /dev/i2c-X file to
do i2c transations, we get a WARN from intel_dp_check_edp() saying
we're trying to do AUX communication with the panel off. So this
commit reorganizes the code so we enable the VDD at
intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.

This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
machines that have eDP panels.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.

There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.

The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.

Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.

The bug raised its head since
commit 657445fe
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat May 4 10:09:18 2013 +0200

    Revert "drm/i915: revert eDP bpp clamping code changes"

which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.

Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.

We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950Tested-by: NUlf Winkelvos <ulf@winkelvos.de>
Tested-by: Njkp <jkp@iki.fi>
CC: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So drm was abusing device lifetimes, by having embedded device structures
in the minor and connector it meant that the lifetime of the internal drm
objects (drm_minor and drm_connector) were tied to the lifetime of the device
files in sysfs, so if something kept those files opened the current code
would kfree the objects and things would go downhill from there.

Now in reality there is no need for these lifetimes to be so intertwined,
especailly with hotplugging of devices where we wish to remove the sysfs
and userspace facing pieces before we can unwind the internal objects due
to open userspace files or mmaps, so split the objects out so the struct
device is no longer embedded and do what fbdev does and just allocate
and remove the sysfs inodes separately.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is useful with the follow-up patch that frobs
dev_priv->vbt.edp_bpp, and the value no longer comes directly from
VBT.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Follow-up to
commit 0aec2881
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 27 19:01:01 2013 +0300

    drm/dp: constify DP DPCD helpers
Requested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DP spec allows this, and requires it when full link training is
started with non-minimum voltage swing and/or non-zero pre-emphasis.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If channel equalization succeeds, there's no indication something went
wrong in clock recovery (unless debug is enabled). We should shout about
the failures and fix them instead of hiding them under the carpet.

This has allowed bugs like [1] stay dormant for a long time.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=70117Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

v2: duplicate intel_connector->edid, not uninitialized edid (Dave Airlie).
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>