linux.git/drivers/gpu/drm/i915, branch v3.9

drm/i915: Fix build failure

2013-03-27T14:05:42+00:00

ERROR: "__build_bug_on_failed" [drivers/gpu/drm/i915/i915.ko] undefined!

Originally reported at http://www.gossamer-threads.com/lists/linux/kernel/1631803
FDO bug #62775

This needs to be backported to both 3.7 and 3.8 stable trees. Doesn't apply straight,
but it's a quick change.

Signed-off-by: Lauri Kasanen 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62775
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter

drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

2013-03-26T21:49:30+00:00

commit f40ebd6bcbbd0d30591f42dc16be52b5086a366b
Author: Patrik Jakobsson 
Date:   Tue Mar 5 14:24:48 2013 +0100

    drm/i915: Turn off hsync and vsync on ADPA when disabling crt

properly disabled the hsync/vsync logic at disable time, but neglected
to re-enable them at enable time.

v2: In the enable hook, restore the connector's expected DPMS level
instead of forcing ON.  Do this by stashing a back pointer to the
connector in the crt (suggested by danvet) since otherwise it's awkward
to look up.

Signed-off-by: Adam Jackson 
Cc: stable@vger.kernel.org
[danvet: Added more verbose commit citation and cc: stable tag. Also,
make it compile. Then self-lart and try to assign the right pointer.]
Signed-off-by: Daniel Vetter

drm/i915: duct-tape locking when eDP init fails

2013-03-26T07:54:50+00:00

Thanks to apple gpu mux fail we detect an eDP output, but can't read
anything over dp aux. In the resulting failure path we then hit a
paranoid WARN about potential locking.

Since the WARN is pretty useful for normal operation just paper over
it in the failure case by grabbing the demanded (but for init/teardown
not really required) lock.

I've checked our driver unload code and we already don't hold the kms
lock when calling drm_mode_config_cleanup. So this won't lead to a new
deadlock when reloading i915.ko.

v2: Make it compile.

Reported-by: Dave Airlie 
Cc: Dave Airlie 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter

Revert "drm/i915: write backlight harder"

2013-03-24T12:23:20+00:00

This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd.

Turns out that cargo-culting breaks systems. Note that we can't revert
further, since

commit 770c12312ad617172b1a65b911d3e6564fc5aca8
Author: Takashi Iwai 
Date:   Sat Aug 11 08:56:42 2012 +0200

    drm/i915: Fix blank panel at reopening lid

fixed a regression in 3.6-rc kernels for which we've never figured out
the exact root cause. But some further inspection of the backlight
code reveals that it's seriously lacking locking. And especially the
asle backlight update is know to get fired (through some smm magic)
when writing specific backlight control registers. So the possibility
of suffering from races is rather real.

Until those races are fixed I don't think it makes sense to try
further hacks. Which sucks a bit, but sometimes that's how it is :(

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Tested-by: Takashi Iwai 
Cc: Jani Nikula 
Cc: Takashi Iwai 
Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too)
Signed-off-by: Daniel Vetter

drm/i915: don't disable the power well yet

2013-03-24T12:22:33+00:00

We're still not 100% ready to disable the power well, so don't disable
it for now. When we disable it we break the audio driver (because some
of the audio registers are on the power well) and machines with eDP on
port D (because it doesn't use TRANSCODER_EDP).

Also, instead of just reverting the code, add a Kernel option to let
us disable it if we want. This will allow us to keep developing and
testing the feature while it's not enabled.

This fixes problems caused by the following commit:
  commit d6dd9eb1d96d2b7345fe4664066c2b7ed86da898
  Author: Daniel Vetter 
  Date:   Tue Jan 29 16:35:20 2013 -0200
       drm/i915: dynamic Haswell display power well support

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Cc: Takashi Iwai 
Cc: Mengdong Lin 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter

Revert "drm/i915: set TRANSCODER_EDP even earlier"

2013-03-24T12:22:32+00:00

This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3.

The reason is that Takashi Iwai reported a regression bisected to this
commit:

http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html

His machine has eDP on port D (usual desktop all-in-on setup), which
intel_dp.c identifies as an eDP panel, but the hsw ddi code
mishandles.

Closer inspection of the code reveals that haswell_crtc_mode_set also
checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
that doesn't make much sense (since there's no edp on the pch), but
what this function _really_ checks is whether that edp connector is on
port A or port D. It's just that on ilk-ivb port D was on the pch ...

So that explains why this seemingly innocent change killed eDP on port
D. Furthermore it looks like everything else accidentally works, since
we've never enabled eDP on port D support for hsw intentionally (e.g.
we still register the HDMI output for port D in that case).

But in retrospective I also don't like that this leaks highly platform
specific details into common code, and the reason is that the drm
vblank layer sucks. So instead I think we should:
- move the cpu_transcoder into the dynamic pipe_config tracking (once
  that's merged).
- fix up the drm vblank layer to finally deal with kms crtc objects
  instead of int pipes.

v2: Pimp commit message with the better diagnosis as discussed with
Paulo on irc.

Cc: Paulo Zanoni 
Cc: Takashi Iwai 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter

drm/i915: stop using GMBUS IRQs on Gen4 chips

2013-03-19T23:03:16+00:00

Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.

It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.

Typically this results in the spurious interrupt source getting
disabled:

[    9.636345] irq 16: nobody cared (try booting with the "irqpoll" option)
[    9.637915] Pid: 4157, comm: ifup Tainted: GF            3.9.0-rc2-00341-g0863702 #422
[    9.639484] Call Trace:
[    9.640731]    [] __report_bad_irq+0x1d/0xc7
[    9.640731]  [] note_interrupt+0x15b/0x1e8
[    9.640731]  [] handle_irq_event_percpu+0x1bf/0x214
[    9.640731]  [] handle_irq_event+0x3c/0x5c
[    9.640731]  [] handle_fasteoi_irq+0x7a/0xb0
[    9.640731]  [] handle_irq+0x1a/0x24
[    9.640731]  [] do_IRQ+0x48/0xaf
[    9.640731]  [] common_interrupt+0x6a/0x6a
[    9.640731]    [] ? system_call_fastpath+0x16/0x1b
[    9.640731] handlers:
[    9.640731] [] usb_hcd_irq [usbcore]
[    9.640731] [] yenta_interrupt [yenta_socket]
[    9.640731] Disabling IRQ #16

The really curious thing is now that irq 16 is _not_ the interrupt for
the i915 driver when using MSI, but it _is_ the interrupt when not
using MSI. So by all indications it seems like gmbus is able to
generate a legacy (shared) interrupt in MSI mode on some
configurations. I've tried to reproduce this and the differentiating
thing seems to be that on unaffected systems no other device uses irq
16 (which seems to be the non-MSI intel gfx interrupt on all gm45).

I have no idea how that even can happen.

To avoid tempting this elephant into a rage, just disable gmbus
interrupt support on gen 4.

v2: Improve the commit message with exact details of what's going on.
Also add a comment in the code to warn against this particular
elephant in the room.

v3: Move the comment explaing how gen4 blows up next to the definition
of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris
Wilson.

Signed-off-by: Jiri Kosina  (v1)
Acked-by: Chris Wilson 
References: https://lkml.org/lkml/2013/3/8/325
Signed-off-by: Daniel Vetter

drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()

2013-03-18T10:25:36+00:00

The eDP output on HP Z1 is still broken when X is started even after
fixing the infinite link-train loop.  The regression was introduced in
3.6 kernel for cleaning up the mode clock handling code in intel_dp.c
by the commit [71244653: drm/i915: adjusted_mode->clock in the dp
mode_fix].

In the past, the clock of the reference mode was modified in
intel_dp_mode_fixup() in the case of eDP fixed clock, and this clock was
used for calculating in intel_dp_set_m_n().  This override was removed,
thus the wrong mode clock is used for the calculation, resulting in a
psychedelic smoking output in the end.

This patch corrects the clock to be used in the place.

v1->v2: Use intel_edp_target_clock() for checking eDP fixed clock
instead of open code as in ironlake_set_m_n().

Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Daniel Vetter

Revert "drm/i915: try to train DP even harder"

2013-03-17T21:57:46+00:00

This reverts commit 0d71068835e2610576d369d6d4cbf90e0f802a71.

Not only that the commit introduces a bogus check (voltage_tries == 5
will never meet at the inserted code path), it brings the i915 driver
into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP.

At least reverting this commit recovers the framebuffer (but X is
still broken by other reasons...)

Cc: 
Signed-off-by: Takashi Iwai 
Signed-off-by: Daniel Vetter

drm/i915: bounds check execbuffer relocation count

2013-03-13T20:31:03+00:00

It is possible to wrap the counter used to allocate the buffer for
relocation copies. This could lead to heap writing overflows.

CVE-2013-0913

v3: collapse test, improve comment
v2: move check into validate_exec_list

Signed-off-by: Kees Cook 
Reported-by: Pinkie Pie
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter