<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu/drm/i915/intel_display.c, branch linux-3.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.8.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-3.8.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2013-05-11T20:54:03Z</updated>
<entry>
<title>drm/i915: Fixup Oops in the pipe config computation</title>
<updated>2013-05-11T20:54:03Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2013-04-12T16:48:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9f75bb3137659e678ccdfe353f73adb0d7f6cb68'/>
<id>urn:sha1:9f75bb3137659e678ccdfe353f73adb0d7f6cb68</id>
<content type='text'>
commit b6c5164d7bf624f3e1b750787ddb983150c5117c upstream.

Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.

So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully set up by intel_crtc_set_config) and
then goes through the modeset sequence for any crtc which needs
updating.

Now the issue is that the actual interface with the remaining code
still only works on one crtc, and so we only pass in one fb and one
mode. In intel_set_mode we also only compute one intel_crtc_config
(which should be the one for the crtc we're doing a modeset on).

The reason for that mismatch is twofold:
- We want to eventually do all modeset as global state changes, so
it's just infrastructure prep.
- But even the old semantics can change more than one crtc when you
e.g. move a connector from crtc A to crtc B, then both crtc A and B
need to be updated. Usually that means one pipe is disabled and the
other enabled. This is also the reason why the hack doesn't touch the
disable_pipes mask.

Now hilarity ensued in our kms config restore paths when we actually
try to do a modeset on all crtcs: If the first crtc should be off and
the second should be on, then the call on the first crtc will notice
that the 2nd one should be switched on and so tries to compute the
pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
after all) it only results in tears.

This case is ridiculously easy to hit on gen2/3 where the lvds output
is restricted to pipe B. Note that before the pipe_config bpp rework
gen2/3 didn't care really about the fb-&gt;depth, so this is a regression
brought to light with

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

But apparently Ajax also managed to blow up pch platforms, probably
with some randomized configs, and pch platforms trip up over the lack
of an fb even in the old code. So this actually goes back to the first
introduction of the new modeset restore code in

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Fri Nov 23 18:16:34 2012 +0100

    drm/i915: force restore on lid open

Fix this mess by now by justing shunting all the cool new global
modeset logic in intel_modeset_affected_pipes.

v2: Improve commit message and clean up all the comments in
intel_modeset_affected_pipes - since the introduction of the modeset
restore code they've been a bit outdated.

Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725
References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html
Tested-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: ensure single initialization and cleanup of backlight device</title>
<updated>2013-05-11T20:54:02Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2013-04-12T12:18:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=99367f6b937fd2cd0148c933b76ce7b4883d6501'/>
<id>urn:sha1:99367f6b937fd2cd0148c933b76ce7b4883d6501</id>
<content type='text'>
commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.

Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Tested-by: Peter Verthez &lt;peter.verthez@skynet.be&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: add quirk to invert brightness on Packard Bell NCL20</title>
<updated>2013-04-12T16:52:12Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2013-01-22T10:50:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=060c519a9fd1467f6958f98520a9a9aea1aee373'/>
<id>urn:sha1:060c519a9fd1467f6958f98520a9a9aea1aee373</id>
<content type='text'>
commit 5559ecadad5a73b27f863e92f4b4f369501dce6f upstream.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
Reported-by: Alan Zimmerman &lt;alan.zimm@gmail.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: add quirk to invert brightness on eMachines e725</title>
<updated>2013-04-12T16:52:11Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2013-01-22T10:50:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=979913cd288da7c284f4a3f08e5d7092511788da'/>
<id>urn:sha1:979913cd288da7c284f4a3f08e5d7092511788da</id>
<content type='text'>
commit 01e3a8feb40e54b962a20fa7eb595c5efef5e109 upstream.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
[Note: There are more than one broken setups in the bug. This fixes one.]
Reported-by: Martins &lt;andrissr@inbox.lv&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: add quirk to invert brightness on eMachines G725</title>
<updated>2013-04-12T16:52:11Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2013-01-22T10:50:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=52024312c30b6c58be6bb6ea638972fc95b23db4'/>
<id>urn:sha1:52024312c30b6c58be6bb6ea638972fc95b23db4</id>
<content type='text'>
commit 1ffff60320879830e469e26062c18f75236822ba upstream.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
Reported-by: Roland Gruber &lt;post@rolandgruber.de&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Don't clobber crtc-&gt;fb when queue_flip fails</title>
<updated>2013-04-05T16:26:15Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2013-02-22T14:53:38Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6c7db2bac62fc0b01ac35981144b05e355cbdb3e'/>
<id>urn:sha1:6c7db2bac62fc0b01ac35981144b05e355cbdb3e</id>
<content type='text'>
commit 4a35f83b2b7c6aae3fc0d1c4554fdc99dc33ad07 upstream.

Restore crtc-&gt;fb to the old framebuffer if queue_flip fails.

While at it, kill the pointless intel_fb temp variable.

v2: Update crtc-&gt;fb before queue_flip and restore it back
    after a failure.

Backported for 3.8-stable. Restored an atomic_sub removed
in 3.9 ca9c46.

Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Reported-and-Tested-by: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Lingzhu Xiang &lt;lxiang@redhat.com&gt;
Reviewed-by: CAI Qian &lt;caiqian@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Handle untiled planes when computing their offsets</title>
<updated>2013-02-28T13:38:37Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2013-02-21T20:04:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5414a74ee10725f6a28f5e2c49559e854ddad47b'/>
<id>urn:sha1:5414a74ee10725f6a28f5e2c49559e854ddad47b</id>
<content type='text'>
commit bc752862170c135d6c09fb22d79eeb451023568e upstream.

We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.

However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advance in whole tiles (instead of the
linear increment expected), leaving the CRTC misaligned with its
contents.

Fixes regression from commit c2c75131244507c93f812862fdbd4f3a37139401
Author: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Date:   Thu Jul 5 12:17:30 2012 +0200

    drm/i915: adjust framebuffer base address on gen4+

v2: Adjust relative x-coordinate after linear alignment (vsyrjala)
v3: Repaint with pokadots (vsyrjala)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: inverted brightness quirk for Acer Aspire 4736Z</title>
<updated>2013-02-28T13:38:37Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2013-02-15T17:35:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80927f571d384c0d5a98dfc11ca26af734054b7b'/>
<id>urn:sha1:80927f571d384c0d5a98dfc11ca26af734054b7b</id>
<content type='text'>
commit ac4199e0f047546aa40172785e26c82b54bbe811 upstream.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Tested-by: Jani Monoses &lt;jani@ubuntu.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Set i9xx sdvo clock limits according to specifications</title>
<updated>2013-02-28T13:38:36Z</updated>
<author>
<name>Patrik Jakobsson</name>
<email>patrik.r.jakobsson@gmail.com</email>
</author>
<published>2013-02-13T21:20:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8cf59fe0c1dd0d07a38ecf28736b015a92eb6808'/>
<id>urn:sha1:8cf59fe0c1dd0d07a38ecf28736b015a92eb6808</id>
<content type='text'>
commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream.

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.

Signed-off-by: Patrik Jakobsson &lt;patrik.r.jakobsson@gmail.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: disable shared panel fitter for pipe</title>
<updated>2013-02-28T13:38:36Z</updated>
<author>
<name>Mika Kuoppala</name>
<email>mika.kuoppala@linux.intel.com</email>
</author>
<published>2013-02-08T14:35:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80dda7b532285f32b6fdb23ebf29de7c035b2bae'/>
<id>urn:sha1:80dda7b532285f32b6fdb23ebf29de7c035b2bae</id>
<content type='text'>
commit 24a1f16de97c4cf0029d9acd04be06db32208726 upstream.

If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.

Based on work by Chris Wilson &lt;chris@chris-wilson.co.uk&gt;

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Tested-by: Andreas Sturmlechner &lt;andreas.sturmlechner@gmail.com&gt;
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
