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>

Just assume that it will turn off...
Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Currently we have a exact mapping of a connector onto an encoder for its
whole lifetime. Make this an explicit property of the structure and so
simplify the code.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Why iterate all the crtcs to find the pipe, when we already know which
crtc is attached to which pipe?
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

[Patch is slightly larger than is strictly necessary to fixup
surrounding checkpatch.pl errors.]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

It seems to be possible to program a new mode without disabling the panel
if the panel fitter setup doesn't change. Add support for that.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There were two instances of code to control the panel backlight and
neither handled the complete set of device variations.

Fixes:

  Bug 29716 - [GM965] Regression: Backlight resets to minimum when changing resolution
  https://bugs.freedesktop.org/show_bug.cgi?id=29716

And a bug on one of my PineView boxes which overflowed the backlight
value.

Incorporates part of a similar patch by Matthew Garrett that exposes a
native Intel backlight controller.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
addin-offset. With the check in place, the panel was declared absent.

v2: Only trust BIOS writers that have graduated to writing OpRegions.
(We are all doomed.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Cc: Adam Jackson <ajax@redhat.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>

Jesse's feedback from using the wait_for() macro was that the msleep
argument was that it was superfluous and made the macro more difficult
to use and to read. As the actually amount of time to sleep is not
critical, the crucial part is to sleep and let the processor schedule
something else whilst we wait for the event, replace the argument with a
hardcoded value.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

This reverts commit 0f3ee801.

Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle
systems due to i915 interrupts. So restrict the LVDS to pipe B once more,
whilst the issue is properly diagnosed.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307Reported-and-tested-by: NEnrico Bandiello <enban@postal.uv.es>
Poked-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@kernel.org

Add a new macro, wait_for, to simplify the act of waiting on a register
to change state. wait_for() takes three arguments, the condition to
inspect on every loop, the maximum amount of time to wait and whether to
yield the cpu for a length of time after each check.

v2: Upgrade failure messages to DRM_ERROR on the suggestion of
Eric Anholt. We do not expect to hit these conditions as they reflect
programming errors, so if we do we want to be notified.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Subclass intel_encoder to reduce the pointer dance through
intel_encoder->dev_priv.

10 files changed, 896 insertions(+), 997 deletions(-)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Move the common routines into separate functions to not only increase
readability, but also throwaway surplus code.

In doing so, we review the calculation of the aspect preserving scaling
and avoid the use of fixed-point until we need to calculate the accurate
scale factor.

v2: Improve comments as suggested by Jesse.

1 files changed, 105 insertions(+), 194 deletions(-)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We already checked just a couple of lines above that we have found a
fixed_panel_mode for the LVDS, so remove the surplus check.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

On some machines (currently only the Toshiba Tecra A11 is known), the GPU
locks up when modeset is forced on LID open. This patch adds a new DMI
blacklist and omits modesetting for all matches.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15550Signed-off-by: NThomas Bächler <thomas@archlinux.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

On some machines (currently only the Toshiba Tecra A11 is known), the GPU
locks up when modeset is forced on LID open. This patch adds a new DMI
blacklist and omits modesetting for all matches.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15550Signed-off-by: NThomas Bächler <thomas@archlinux.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We did this a long time ago in the DDX driver, but now this fix belongs
in the kernel.

Preserving the aspect ratio is a nicer default.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=18033.
Tested-by: NJosh Triplett <josh@freedesktop.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The gen4 docs say it works, so why not.  Tested on Ironlake.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This was brought over from UMS, and used for a while until we decided
that drm_helper_resume_force_mode was easier and more reliable, since
it didn't require duplicating all the code deleted here.  We just
forgot to delete all that junk for a while.

This trys to shut up complains about invalid LVDS EDID during
mode probe, but uses fixed panel mode directly for panels with
broken EDID.

https://bugs.freedesktop.org/show_bug.cgi?id=23099
https://bugs.freedesktop.org/show_bug.cgi?id=26395Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This one replaces original param for intel_ddc_get_modes() with
DRM connector and i2c bus adapter instead. With explicit params,
we won't require that a single driver structure must hold connector
and DDC bus reference, which ease the conversion to splitted encoder/
connector model.

It also clears up for some cases that we would steal other DDC bus
for mode probe, like VGA analog DDC probe for DVI-I. Also it fixed
a bug in old DVI-I probe handling, that failed to restore origin
analog GPIO port.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

BugLink: http://bugs.launchpad.net/ubuntu/bugs/544671

This system claims to have a LVDS but has not.
Signed-off-by: NStephane Graber <stgraber@ubuntu.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
CC: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

The intel_output naming is inherited from the UMS code, which had a
structure of screen -> CRTC -> output.  The DRM code has an additional
notion of encoder/connector, so the structure is screen -> CRTC ->
encoder -> connector.  This is a useful structure for SDVO encoders
which can support multiple connectors (each of which requires
different programming in the one encoder and could be connected to
different CRTCs), or for DVI-I, where multiple encoders feed into the
connector for whether it's used for digital or analog.  Most of our
code is encoder-related, so transition it to talking about encoders
before we start trying to distinguish connectors.

This patch is produced by sed s/intel_output/intel_encoder/ over the
driver.
Signed-off-by: NEric Anholt <eric@anholt.net>

I've been getting more and more quirk reports about this.  It seems
clear at this point that other OSes are not using this for determining
whether the integrated panel should be turned on, and it is not
reliable for doing so.  Better to light up an unintended panel than to
not light up the only usable output on the system.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

It would be good to disable the LVDS port when we shut down the panel
to save power.  We haven't done so until now because we had trouble
getting the right LVDS parameters from the BIOS.  I think we're past
that now, so enabling and disabling the port should be safe, though it
would probably be made cleaner with some additional changes to the
display code, where we also bang on the LVDS reg to set the pairing
correctly etc.

Seems to save a bit of power (up to 300mW in my basic wattsup
meter testing).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

I think this is pretty much correct.  Not really tested.
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

These old machines more often than not lie about their lid state.  So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.

Fixes kernel bug #15248
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Wrong Lid state reported.
Need to blacklist this machine for LVDS detection.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_lid_open() could take up to 10ms on my computer.  Some component is
calling the drm GETCONNECTOR ioctl many times in a row.  This results in
flickering (for example, when starting a video).  Fix it by assuming an
always connected lid status.
Signed-off-by: NThomas Meyer <thomas@m3y3r.de>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reported-by: NPhilipp Kohlbecher <xt28@gmx.de>
Signed-off-by: NEric Anholt <eric@anholt.net>

Many platform support this feature, and it can provide significant
power savings when the reduced refresh rate is low.  However, on some
platforms a secondary (reduced) timing is provided but not actually
supported by the hardware.  This results in undesirable flicker at
runtime.

So disable the feature by default, but allow users to opt-in to the
reduced clock behavior with a new module parameter, lvds_downclock,
that can be set to 1 to enable the feature.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is
closed and we can't use it reliabily for LVDS detection. So add the two boxes
into the quirk list.

http://bugzilla.kernel.org/show_bug.cgi?id=14957
http://bugzilla.kernel.org/show_bug.cgi?id=14554Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
close/reopen the LID. And I also reproduce this issue on another laptop.
After some tests and debug, it seems that it is related with that the
LVDS status is not updated in time in course of suspend/resume.

Now the LID state is used to check whether the LVDS is connected or
disconnected. And when the LID is closed, it means that the LVDS is
disconnected. When it is reopened, it means that the LVDS is connected.
At the same time on some distributions the LID event is also used to put
the system into suspend state. When the LID is closed, the system will enter
the suspend state. When the LID is reopened, the system will be resumed.

In such case when the LID is closed, user-space script will receive the LID
notification event and  detect the LVDS as disconnected. Then the system will
enter the suspended state. When the LID is reopened, the system will be
resumed. As the LVDS status is not updated in course of resume, it will cause
that the LVDS connector is marked as unused and disabled. After the resume is
finished,user-space script will try to configure the display mode for LVDS.
But unfortunately as the LVDS status is not updated in time and it is still
marked as disconnected, the LVDS and its corresponding CRTC will be disabled
again in the function of drm_helper_disable_unused_functions after changing
mode for LVDS.

So we had better check and update the status of LVDS connector after receiving
the LID notication event. Then after the system is resumed from suspended
state, we can set the display mode for LVDS correctly.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reported-by: NDirk Hohndel <hohndel@infradead.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
CC: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

The MALATA PC-81005 laptop always reports that the LID status is closed and we
can't use it reliabily for LVDS detection. So add this box into the quirk list.

https://bugs.freedesktop.org/show_bug.cgi?id=25523Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Review-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NHector <hector1987@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Checking for the presence of a lid in order to validate whether or not
an LVDS display exists fails on some development platforms that implement
a lid device but allow the LVDS to be disabled. The VBT is correctly
updated, but Linux assumes that an LVDS is still present and lies to
userspace. Remove the lid check and trust the VBT.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>