According to the gen6 docs, only the DP_A port (on-CPU eDP) still uses
the old IBX bit shift for the link training pattern setup bits.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The obvious counterpart to is_pch_edp().  Convert existing instances of
the idiom to the new routine.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

DPCD 1.1+ adds some automated test infrastructure support.  Add support
for reading the IRQ source and jumping to a test handling routine if
needed.  Subsequent patches will handle particular tests; this patch
just ACKs any requested tests by default.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Read link status first, followed by the full DPCD receiver cap field
rather than just the first 8 bytes.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

These were just working around the math being wrong.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The previous code was confused about units, which is pretty reasonable
given that the units themselves are confusing.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

At the point where we check, we can't do much about the failure, but it
can aid debugging.  Note that the auto-train override bit will be reset
as part of normal mode setting with this patch if a pipe ever does get
stuck, but that's consistent with the workaround for CPT provided by the
hardware team.  This patch helped catch the fact that the pipe wasn't
running in the !composite sync FDI case on my IVB SDV, so has already
shown to be useful.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Well almost anyway.  IVB has 3 planes, pipes, transcoders, and FDI
interfaces, but only 2 pipe PLLs.  So two of the pipes must use the same
pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode
and one other, etc.).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-By: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

If the panel is powered up, there's no need to delay for the 'off'
interval when turning the panel on.
Signed-off-by: NKeith Packard <keithp@keithp.com>

This eliminates a fairly long delay when power sequencing newer
hardware
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respected before trying to turn it back on.
Signed-off-by: NKeith Packard <keithp@keithp.com>

We need to check eDP VDD force and panel on in several places, so
create some simple helper functions to avoid duplicating code.
Signed-off-by: NKeith Packard <keithp@keithp.com>

The return value was unused, so just stop doing that.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.

From the eDP spec, we need the following numbers:

 T1 + T3	Power on to Aux Channel operation (panel_power_up_delay)

		This marks how long it takes the panel to boot up and
		get ready to receive aux channel communications.

 T8		Video signal to backlight on (backlight_on_delay)

		Once a valid video signal is being sent to the device,
		it can take a while before the panel is actuall
		showing useful data. This delay allows the panel
		to get something reasonable up before the backlight
		is turned on.

 T9		Backlight off to video off (backlight_off_delay)

		Turning the backlight off can take a moment, so
		this delay makes sure there is still valid video
		data on the screen.

 T10		Video off to power off (panel_power_down_delay)

		Presumably this delay allows the panel to perform
		an orderly shutdown of the display.

 T11 + T12	Power off to power on (panel_power_cycle_delay)

		So, once you turn the panel off, you have to wait a
		while before you can turn it back on. This delay is
		usually the longest in the entire sequence.

Neither the VBIOS source code nor the hardware documentation has a
clear mapping between the delay values they provide and those required
by the eDP spec. The VBIOS code actually uses two different labels for
the delay values in the five words of the relevant VBT table.

**** MORE LATER ***

Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum of the two
delays, to make sure things work reliably. If there is no VBT data,
then those values will be initialized to zero, so we'll just use the
values as programmed in the hardware. Note that the BIOS just fetches
delays from the VBT table to place in the hardware registers, so we
should get the same values from both places, except for rounding.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

For the backlight delays, the eDP spec says T6 + T8 is the delay from the
end of link training to backlight on and T9 is the delay from
backlight off until video off. The hardware provides a 'backlight on'
delay, which I'm taking to be T6 + T8 while the VBT provides something
called 'T7', which I'm assuming is s

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.
Signed-off-by: NKeith Packard <keithp@keithp.com>

Any call to intel_dp_sink_dpms must ensure that the panel has power so
that the DP_SET_POWER operation will be correctly received. The only
one missing this was in intel_dp_prepare.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DP i2c initialization code does a couple of i2c transactions,
which means that an eDP panel must be powered up.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Talking to the eDP DDC channel requires that the panel be powered
up. Wrap both the EDID and modes fetch code with calls to turn the vdd
power on and back off.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the panel is already off, we'll need to turn VDD on to execute the
(useless) DPMS off code. Yes, it would be better to just not do any of
this, but correctness, and *then* performance.
Signed-off-by: NKeith Packard <keithp@keithp.com>

The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cleans up code dealing with eDP a bit. Remove redundant checks in
callers
Signed-off-by: NKeith Packard <keithp@keithp.com>

Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: NKeith Packard <keithp@keithp.com>

Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.

This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: NKeith Packard <keithp@keithp.com>

We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.

ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:

(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]

(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
    ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver

This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Test scheme: plug in the HDMI/DP monitor, and run

        cat /proc/asound/card0/eld*

to check if the monitor name, HDMI/DP type, etc. show up correctly.

Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.

Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.

CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Various issues involved with the space character were generating
warnings in the checkpatch.pl file. This patch removes most of those
warnings.
Signed-off-by: NAkshay Joshi <me@akshayjoshi.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NSedat Dilek <sedat.dilek@googlemail.com>
Tested-by: NMichel Alexandre Salim <salimma@fedoraproject.org>
Tested-by: NKamal Mostafa <kamal@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit 97cdd710.

Clearing the dpcd data means that if the fetch fails, any previous
data will be lost. On eDP, this is no fun as we only fetch dpcd at
init time, so the memset will destroy that the next time through.

Before initiating a new read or write on the DP AUX channel, wait for
any outstanding activity to complete.  This may happen during normal
retry behavior.  If the wait fails (i.e. after 1ms the AUX channel is
still busy) dump a backtrace to make the caller easier to spot.

v2: use msleep instead, and timeout after 3ms (only ever saw 1 retry
    with msleep in testing)
v3: fix backtrace check to trigger if the 3ms wait times out

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38136.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit 885a5014.

We actually *do* need to track DPMS state so that on hotplug, we don't
retrain the link until DPMS is disabled.

However, that code had avery small bug -- it wouldn't set the
dpms_mode at mode set time, and so link retraining would not actually
occur on monitor hotplug until the monitor had gone through a DPMS
off/DPMS on cycle.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NAndrew Lutomirski <luto@mit.edu>

Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

This uses the common dpcd reading routine, i915_dp_detect_common,
instead of open-coding a call to intel_dp_aux_native_read. Besides
reducing duplicated code, this also gains the read retries which
may be necessary when a cable is first plugged back in and the link
needs to be retrained.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

The docs say the port has to come on in training pattern 1; at this
point, though, ->DP is in normal mode.  The intent here is to wait
until the port is in fact sending data, but that doesn't happen since
we've broken the sequence the hardware expects, and the vblank wait will
time out and kvetch in the log.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The DP spec says training patterns 1 and 2 are to be sent non-scrambled,
and the GPU docs claim that happens (or at least, there's no explicit
scrambling control).  But the sink may be confused if we don't
explicitly tell it what we're doing, so play it safe.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

It's not clear what a sink would do if you wrote zero to this register -
which I guess would mean "I don't support any channel encodings, good
luck" - but let's not find out.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

%hx alone prints 0 as "0", not "00".
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

For parity with radeon and nouveau, and also because I suspect we're
going to need it to get format-conversion dongles right.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>