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>

Found a couple of bare tabs in intel_dp.c
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Make sure the sequence of operations in all three functions makes
sense:

 1) The backlight must be off unless the screen is running
 2) The link must be running to turn the eDP panel on/off
 3) The CPU eDP PLL must be running until everything is off
Signed-off-by: NKeith Packard <keithp@keithp.com>

The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.

No functional changes.
Signed-off-by: NKeith Packard <keithp@keithp.com>