https://bugzilla.redhat.com/show_bug.cgi?id=750006Signed-off-by: NAdam Jackson <ajax@redhat.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>

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>

There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The Dell OptiPlex FX170 claims to have LVDS, but doesn't.
Signed-off-by: NPieterjan Camerlynck <pieterjan.camerlynck@gmail.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

I found this while figuring out why gnome-shell would not run on my
Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have
an internal panel, yet it claims it does. Add a quirk to fix this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NKeith Packard <keithp@keithp.com>
cc: stable@kernel.org
Signed-off-by: NKeith Packard <keithp@keithp.com>

If we're using vga switcheroo, the device may be turned off
and poking it can return random state. This provokes an OOPS fixed
separately by 8ff887c847 (drm/i915/dp: Be paranoid in case we disable a
DP before it is attached). Trying to use and respond to events on a
device that has been turned off by the user is in principle a silly thing
to do.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NKeith Packard <keithp@keithp.com>

This is a revert of 428d2e82.

This is broken in the same manner as for VGA: trying to write to an
invalid address on the (currently 7-bit) i2c bus.

One notable failure appears to be for MacBooks. The scary part was that
it gave the appearance of working (i.e. reporting the absence of the
panel) on various all-in-one machines with ghost LVDS panels and not
failing for laptops.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The LVDS connector should default to connected. We tried our best to
verify the claims of the BIOS that the hardware exists during init(),
and then during detect() we then try to verify that the panel is open.
In the event of an unsuccessful query, we should then always report
that the LVDS panel is connected. This was only the case for gen2/3,
later generations leaked the return value from the panel probe instead.
Reported-and-tested-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>

Share the lid detection code for the all panels for consistent behaviour
and a single place to add the eventual quirks for crap hardware.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We had some conversions over to the _PIPE macros, but didn't get
everything.  So hide the per-pipe regs with an _ (still used in a few
places for legacy) and add a few _PIPE based macros, then make sure
everyone uses them.

[update: remove usage of non-existent no-op macro]
[update 2: keep modesetting suspend/resume code, update to new reg names]
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: stylistic cleanups for checkpatch and taste]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

A regression introduced in bee17e5a cleared the dithering bit for native
modes on gen2/3.

Bugzilla: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/711568Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Move code around and invoke iomem annotation in a few more places in
order to silence sparse. Still a few more iomem annotations to go...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Admittedly, trusting ACPI or the BIOS at all to be correct is littered
with numerous examples where it is wrong. Maybe, just maybe, we will
have better luck using the ACPI OpRegion lid status...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NKnut Petersen <knut_petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

... and just any combination of bits & ~PFIT_ENABLE. This way we do not
attempt disable to the panel fitter controller uselessly upon
intel_lvds_disable().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

By tracking the current status of the backlight we can prevent recording
the value of the current backlight when we have disabled it. And so
prevent restoring it to 'off' after an unbalanced sequence of
intel_lvds_disable/enable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Linus Torvalds pointed out that our code was unbalanced when powering on
the panel with respect to the power off sequence in that we were failing
to restore the panel-fitter. The consequence of this would be that
across a simple DPMS off/on for a non-native mode, without an intervening
modeset, the panel fitter would remain disabled and the output would shift
on the panel.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Previously we enabled this for gen4, only to have to revert it due to it
causing a large number of spurious wakeups. Try again hoping that the
hardware has become more sane in the mean time...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and do not just assume to always use pipe B.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... otherwise the panel-fitter may be left enabled with random settings
and cause unintended filtering (i.e. blurring of native modes on external
panels).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942Reported-and-tested-by: NBen Kohler <bkohler@gmail.com>
Tested-by: NCiprian Docan <docan@eden.rutgers.edu>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which sometimes is wide of the mark.
Reported-and-tested-by: NJon Masters <jonathan@jonmasters.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This check only appears to succeed when using GMBUS, so we need to skip
it if we have fallen back to using GPIO bit banging.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

First step, lets have a look at the values for troublesome panels and
see if they may be used to improve our link training.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is now private to the DVO connector, remove it from the main device
private.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Try to validate the panel's connection by writing to address 0xA0.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18072Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we do not wait for the panel to turn off when we need to adjust the
panel-fitting registers we also need to unlock the PLLs as with the
non-pfit update path.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid confusion between i965g meaning broadwater and the gen4+ chipset
families.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We assume that the panel is permenantly connected and that the EDID data
is consistent from boot, so simply cache the whole EDID for the panel.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The SDVO proxy i2c adapter wants to be able to use information stored in
the encoder, so pass that through intel_i2c rather than iterate over all
known encoders every time.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

v2: Julien Cristau pointed out that @nondestructive results in
double-negatives and confusion when trying to interpret the parameter,
so use @force instead. Much easier to type as well. ;-)

And fix the miscompilation of vmgfx reported by Sedat Dilek.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Destructive load-detection is very expensive and due to failings
elsewhere can trigger system wide stalls of up to 600ms. A simple
first step to correcting this is not to invoke such an expensive
and destructive load-detection operation automatically.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29536
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16265Reported-by: NBruno Prémont <bonbons@linux-vserver.org>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

One doesn't need to hold the mode lock in order to duplicate a mode.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Commit 77d07fd9 introduced a regression
where by not waiting for the panel to be turned off, left the panel and
PLL registers locked across the modeset. Thus the panel remaining blank.

As pointed out by Daniel Vetter, when testing LVDS it helps to open the
laptop and look at the actual panel you are purporting to test.

A second issue with the patch was that in order to modify the panel
fitter before gen5, the pipe and the panel must have be completely
powered down. So we wait.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We just assume that it will happen in a timely manner. A variant of this
patch was first written and tested by Arjan van de Van.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>