Also add some macros to make the pipe computation a bit easier.

v2: I've mixed up the CPT and !CPT PORT_TO_PIPE macro variants ...
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new infrastructure we're doing this when enabling/disabling
the entire display pipe.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Together with the static helper functions drm_crtc_prepare_encoders
and drm_encoder_disable (which will be simplified in the next patch,
but for now are 1:1 copies). Again, no changes beside new names for
these functions.

Also call our new set_mode instead of the crtc helper one now in all
the places we've done so far.

v2: Call the function just intel_set_mode to better differentia it
from intel_crtc_mode_set which really only does the ->mode_set step of
the entire modeset sequence on one crtc. Whereas this function does
the global change.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DP is the first encoder which isn't simple. As

commit d240f20f
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Aug 13 15:43:26 2010 -0700

    drm/i915: make sure eDP PLL is enabled at the right time

discovered, we need to enable the eDP PLL for the cpu port _before_ we
enable the pipes and planes. After a few more commits the current
solution is to enable the PLL in the dp mode_set function (because
this is the only encoder callback the crtc helper code calls before it
calls the crtc's commit function).

Now I suspect that we actually should enable/disable the entire cpu
eDP port before/after planes, but thanks to how the crtc helper code
assumes that you can disable an encoder without disabling it's crtc
right away, this won't work.

The result is that the current prepare/commit hooks don't touch the
eDP PLL, but instead it get's frobbed in dp_mode_set and in the dp
dpms function. Hence we need to keep things (at least for now)
bug-for-bug compatible by using our own special dp dpms function and
keep everything else more-or-less as-is (just using our own
infrastrucutre now).

This mess can only be cleaned up once we control the entire modeset
sequence and can move things around freely.

v2: Squash unsupported dpms modes to OFF at the beginning of the DP
dpms function.

v3: Need to set the dpms state to off in dp_disable, otherwise this
breaks the newly added WARNs ...

v4: Rebased against edp panel off sequence changes in 3.6-rc2
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in

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

But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.

Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.

For reference the old bug, which hopefully doesn't get broken by this:

https://bugzilla.kernel.org/show_bug.cgi?id=43163

In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.

v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.

v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671Tested-by: NRoberto Romer <sildurin@gmail.com>
Tested-by: NDaniel Wagner <wagi@monom.org>
Tested-by: NKeith Packard <keithp@keithp.com>
Cc: stable@vger.kernel.org
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed for Haswell, but already has its uses here.

This patch started as a small patch written patch by Shobhit Kumar,
but it has changed so much that none of its original lines remain.

Credits-to: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have some common code that we always run before calling
intel_dp_set_link_train. This common code sets the correct training
patterns to the DP variable. If we add more calls to
intel_dp_set_link_train, we'll also have to duplicate this common
code. So instead of repeating this code whenever we call
intel_dp_set_link_train, we move the code to inside the function: now
we check which training pattern we're going to set and then we set the
DP register according to it.

One of the side-effects of this change is that now we never forget to
mask the training pattern bits before changing them. It looks like
this was working before because we were first masking the bits, then
writing 00, 01 and then 11.

This patch also enables us to use the intel_dp_set_link_train function
when disabling link training: in this case we need to avoid writing
the DP_TRAINING_LANE*_SET AUX commands.

As a bonus, the big intel_dp_{start,complete}_link_train functions
will get smaller and a little bit easier to read.

Version 2 changes:
 - Rewrite commit message.
 - Also clear the training pattern bits before changing them.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Intel hw only has one MUX for encoders, so outputs are either not
cloneable or all in the same group of cloneable outputs. This neatly
simplifies the code and allows us to ditch some ugly if cascades in
the dp and hdmi init code (well, we need these if cascades for other
stuff still, but that can be taken care of in follow-up patches).

Note that this changes two things:
- dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is
  gen3+, so no problem. Note that the old code had a bug and didn't
  allow cloning crt with dvo (but only the other way round).
- sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't
  work, but the only reason I've found is that you can't use the
  panel-fitter (used for lvds upscaling) with anything else. But we
  don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is
  a) rather confusing b) mostly as a guideline to implementors (i.e.
  explicitly stating what is already implicit from the spec, without
  always going into the details of why). So I think we can ignore this
  - worst case we'll get a bug report from a user with with sdvo-lvds
  and sdvo-tmds and have to add that special case back in.

Because sdvo lvds is a bit special explain in comments why sdvo LVDS
outputs can be cloned, but native LVDS and eDP can't be cloned - we
use the panel fitter for the later, but not for sdvo.

Note that this also uncoditionally initializes the panel_vdd work used
by eDP. Trying to be clever doesn't buy us anything (but strange bugs)
and this way we can kill the is_edp check.

v2: Incorporate review from Paulo
- Add in a missing space.
- Pimp comment message to address his concerns.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the DP structure to shared location so that it can be used from
within the ddi module.

Changes from Paulo:
- Move less code to intel_drv.h
- Remove #include statement
- Replace a tab with a space in train_set
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While debugging Haswell link train failures I observed that we never
try the maximum voltage configuration more than once consecutively. We
start the training, the monitor keeps telling us to increase the
voltage, then when we reach the maximum we just go back to the start
(because of the "memset" above "voltage_tries = 0"). When we reach
this point, we keep alternating between the maximum and the minimum
voltages until we give up.

The DP spec suggests that we should try the same voltage 5 times
before giving up. This patch makes us try the maximum voltage at
least 5 times before going back to the minimum voltages.

This patch does not fix any particular bug I'm aware of.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

We already have this pattern at quite a few places, and moving part of
the modeset helper stuff into the driver will add more.

v2: Don't clobber the crtc struct name with the macro parameter ...

v3: Convert two more places noticed by Paulo Zanoni.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead.  This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: peter@colberg.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They aren't going anywhere, and probing on DDC can cause the panel to
blank briefly, so read them up front and cache them for later queries.

v2: fix potential NULL derefs in intel_dp_get_edid_modes and
    intel_dp_get_edid (Jani)
    copy full EDID length, including extension blocks (Takashi)
    free EDID on teardown (Takashi)
v3: malloc a new EDID buffer that's big enough for the memcpy (Chris)
v4: change handling of NULL EDIDs, just preserve the NULL behavior
    across detects and mode list fetches rather than trying to re-fetch
    the EDID (Chris)
v5: be glad that Chris is around to remind me to hit C-x C-s before
    committing.

References: https://bugs.freedesktop.org/show_bug.cgi?id=46856Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 092945e1.

This commit prevents a DP screen from properly training the link.
Oddly enough it works, once the machine has been warm-booted with an
older kernel.

According to DP docs this _should_ have been the right precharge time.
Also, the commit that originally introduces this was just general snb
DP enabling and didn't mention any specific reason for this special
value. Whatever, trust the reporter that this makes things worse and
let's just revert it.

v2: Less spelling fail.

Cc: Adam Jackson <ajax@redhat.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reported-by: N"Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl>
Buglink: https://lkml.org/lkml/2012/6/14/301
Cc: stable@vger.kernel.org (only for 3.4)
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The new oui probe has been missing these.

This issue has been introduce in

commit 0d198328
Author: Adam Jackson <ajax@redhat.com>
Date:   Mon May 14 16:05:47 2012 -0400

    drm/i915/dp: Probe branch/sink OUIs

v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels
as suggested by Chris Wilson.

v3: Fix up the error path fail - I suck.

Cc: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695Tested-by: NYang Guang <guang.a.yang@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should only frob adjusted_mode. This is in preparation of
a massive patch by Laurent Pinchart to make the mode argument
const.

After the previous two prep patches the only thing left is to clean up
things a bit. I've opted to pass in an adjust_mode param to
dp_adjust_dithering because that way we can be sure to avoid
duplicating this logic between mode_valid and mode_fixup - which was
the cause behind a dp link bw calculation bug in the past.

Also mark the mode argument of pch_panel_fitting const.

v2: Split up the mode->clock => adjusted_mode->clock change,
as suggested by Chris Wilson.
Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... instead of changing mode->clock, which we should leave as-is.

After the previous patch we only touch that if it's a panel, and then
adjusted mode->clock equals adjusted_mode->clock. Outside of
intel_dp.c we only use ajusted_mode->clock in the mode_set functions.

Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.

As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).

Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.

Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock,
and that stays the same after this patch (still equals the selected dp
link clock). intel_display.c also needs the actual dotclock (as
target_clock), but that has been fixed up in the previous patch.

v2: Adjust the debug message to also use adjusted_mode->clock.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... instead of abusing mode->clock by storing it in there - we
shouldn't touch that one at all. This patch is the first prep step to
constify the mode argument of the intel_dp_mode_fixup function.

The next patch will stop us from modifying mode->clock.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of checking for !CPT, check for IBX to make it clearer that
this is a IBX-specific workaround. No functional change because we
smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled
on the haswell LPT PCH yet.

See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30 for
details of this workaround.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are ultra-low-res modes used to upscale SDTV content and we
don't know how to support these on dp on intel hw:
- It's unclear whether we can send avi infoframes over dp ports.
- And the pixel repeat setting that work for hdmi/sdvo explicitly
  don't work for dp.

So don't bother and just reject these modes. These modes have been
introduced in

commit 54ac76f8
Author: Christian Schmidt <schmidt@digadd.de>
Date:   Mon Dec 19 14:53:16 2011 +0000

    drm/edid: support CEA video modes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729Tested-by: NYuang Guang <guang.a.yang@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have one bug report from a validation team that we get the eDP
panel sequencing still somewhat wrong: We need to enable VDD while
switching off the panel and backlight. Unfortunately that reporter
seems to have fallen off the earth :(

For another reporter this actually fixes a black panel issue because
without this the backlight/panel gets confused and doesn't light up
again.

v2: I've forgotten to remove the vdd_off call in panel_off which is
now bogus. This essentially reverts

commit 17038de5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Apr 16 22:43:42 2012 +0100

    drm/i915/dp: Flush any outstanding work to turn the VDD off

v3: the current panel_off code forces off the vdd power, too. Which is
bogus and resulted in some funny warnings later on when we've tried to
do aux channel communications with just the vdd forced on. Fix this,
too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163Tested-by: NVincent Frentzel <zcecc22@gmail.com>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The status bits corresponding to the interrupt enable bits are the
"live" hotplug status bits, and reflect the current status of the port
(high for a detected connection, low for a disconnect). The actual bits
corresponding to the interrupt source are elsewhere. The actual event is
then determined by a combination of the interrupt flag and the current
live status (if the interrupt is active, but the current status is not,
then we have detected a disconnect.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.

So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.

v2: add num_pch_pll field to dev_priv (Daniel)
    don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
    put register offsets in pll struct (Chris)

v3: Decouple enable/disable of PLLs from get/put.
v4: Track temporary PLL disabling during modeset
v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni)
v6: Avoid mishandling allocation failure by embedding the small array of
    PLLs into the device struct

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+)
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pretty useful to debug our DP bandwidth woes.

v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.

v3: Also print out the input parameters so that diagnosing failures to
find a valid dp link configuration is possible.

v4: s/Display port/DP/ to shorten the output.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we may kick off a delayed workqueue task to switch of the VDD lines, we
need to complete that task prior to turning off the panel (which itself
depends upon VDD being off).

v2: Don't cancel the outstanding work as this may trigger a deadlock
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If these regs don't have valid values, the panel won't come up, and may
even cause a system hang.  So do a basic sanity check when an eDP panel
is detected.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44305Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.

Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).

The likely culprit for this regression is

commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
Author: Keith Packard <keithp@keithp.com>
Date:   Wed Jan 25 08:16:25 2012 -0800

    drm/i915: Force explicit bpp selection for intel_dp_link_required

v2: Fix indentation and tune down the too bold claim that this should
fix the world. Both noticed by Chris Wilson.

v3: Try to really git add things.
Reported-and-tested-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
Cc: stable@kernel.org
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While fixing up a merge conflict with drm-next I've noticed that we
use the same audio drm connector property also for dp and sdvo
outputs.

So put the new enum to some good use and convert these paths, too. The
HDMI_AUDIO_ prefix is a bit a misnomer. But at least for sdvo it makes
sense (and you can also connect a hdmi monitor with a dp->hdmi cable),
so I've decided to stick with it.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.

intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.

* intel_dp_mode_valid is called to list supported modes; in this case,
  the current crtc values cannot be relevant as the modes in question
  may never be selected. Thus, using intel_crtc->bpp is never right.

* intel_dp_mode_fixup is called during mode setting, but it is run
  well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
  so using intel_crtc-bpp in this path can only ever get a stale
  value.

Cc: Lubos Kolouch <lubos.kolouch@gmail.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881Tested-by: NDave Airlie <airlied@redhat.com>
Tested-by: camalot@picnicpark.org (Dell Latitude 6510)
Tested-by: NRoland Dreier <roland@digitalvampire.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This is paranoid, but I am entirely willing to believe the hardware
could come up with a condition where I get a status with both the 'done'
and 'receive error' bits set.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The default in the Sandybridge docs is 5, as on Ironlake, and I have no
reason to believe 3 would work any better.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Matches the advice in the Sandybridge documentation.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On DP monitor hot remove, clear DP_AUDIO_OUTPUT_ENABLE accordingly,
so that the audio driver will receive hot plug events and take action
to refresh its device state and ELD contents.

Note that the DP_AUDIO_OUTPUT_ENABLE bit may be enabled or disabled
only when the link training is complete and set to "Normal".

Tested OK for both hot plug/remove and DPMS on/off.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Some active adaptors (VGA usually) only have two lanes at 2.7GHz.
That's a maximum pixel clock of 144MHz at 8bpc, but 192MHz at 6bpc.

Fixes Asus UX31 panel being black at startup due to no valid modes since
dc22ee6f.

v2: Rebased to current code, resulting in the fix applying to EDP panels as
    well.  Also changed from spatio-temporal to just spatial dithering on
    pre-ironlake, to be conssitent (and less visual flicker)
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NEric Anholt <eric@anholt.net>
Tested-by: NDirk Hohndel <hohndel@infradead.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The Ivybridge eDP control register looks like a cross between a
Cougarpoint PCH DP control register and a Sandybridge eDP control
register.

Where things trivially match, share the code. Where there are any
tricky bits, just split things out into two obviously separate code paths.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NFang Xun <xunx.fang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41991

The BIOS VBT value for an eDP panel has been shown to be incorrect on
one machine, and we haven't found any machines where the DPCD value
was wrong, so we'll use the DPCD value everywhere.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Limit the link training setting command to the lanes needed for the
current mode. It seems vaguely possible that a monitor will try to
train the other lanes and fail in some way, so this seems like the
safer plan.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>