<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu/drm, branch v3.15.5</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/i915: fix display power sw state reporting</title>
<updated>2014-07-09T18:21:32+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2014-06-02T11:21:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4979d8bd0bb4eb958549f8721cc34001987b5424'/>
<id>4979d8bd0bb4eb958549f8721cc34001987b5424</id>
<content type='text'>
commit b8c000d9bf23e7c1155ef421f595d1cbc25262da upstream.

Atm, we refcount both power domains and power wells and
intel_display_power_enabled_sw() returns the power domain refcount. What
the callers are really interested in though is the sw state of the
underlying power wells. Due to this we will report incorrectly that a
given power domain is off if its power wells were enabled via another
power domain, for example POWER_DOMAIN_INIT which enables all power
wells.

As a fix return instead the state based on the refcount of all power
wells included in the passed in power domain.

References: https://bugs.freedesktop.org/show_bug.cgi?id=79505
References: https://bugs.freedesktop.org/show_bug.cgi?id=79038
Reported-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b8c000d9bf23e7c1155ef421f595d1cbc25262da upstream.

Atm, we refcount both power domains and power wells and
intel_display_power_enabled_sw() returns the power domain refcount. What
the callers are really interested in though is the sw state of the
underlying power wells. Due to this we will report incorrectly that a
given power domain is off if its power wells were enabled via another
power domain, for example POWER_DOMAIN_INIT which enables all power
wells.

As a fix return instead the state based on the refcount of all power
wells included in the passed in power domain.

References: https://bugs.freedesktop.org/show_bug.cgi?id=79505
References: https://bugs.freedesktop.org/show_bug.cgi?id=79038
Reported-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i2c: tda998x: move drm_i2c_encoder_destroy call</title>
<updated>2014-07-09T18:21:27+00:00</updated>
<author>
<name>Guido Martínez</name>
<email>guido@vanguardiasur.com.ar</email>
</author>
<published>2014-06-17T14:17:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f6f7bbbf4b08d6f96821029e13ef91f7c3689b57'/>
<id>f6f7bbbf4b08d6f96821029e13ef91f7c3689b57</id>
<content type='text'>
commit 2e48cecb55435e10c93c6aface1a1c7ef32f4e71 upstream.

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.

Signed-off-by: Guido Martínez &lt;guido@vanguardiasur.com.ar&gt;
Signed-off-by: Ezequiel García &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2e48cecb55435e10c93c6aface1a1c7ef32f4e71 upstream.

Currently tda998x_encoder_destroy() calls cec_write() and reg_clear(),
as part of the release procedure. Such calls need to access the I2C bus
and therefore, we need to call them before drm_i2c_encoder_destroy()
which unregisters the I2C device.

This commit moves the latter so it's done afterwards.

Signed-off-by: Guido Martínez &lt;guido@vanguardiasur.com.ar&gt;
Signed-off-by: Ezequiel García &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix incorrect write to read-only register v2:</title>
<updated>2014-07-09T18:21:27+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2014-07-02T13:47:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=509a64038ca3f5c07c6ea3e448d49bf5c32f4f4f'/>
<id>509a64038ca3f5c07c6ea3e448d49bf5c32f4f4f</id>
<content type='text'>
commit 4e578080ed3262ed2c3985868539bc66218d25c0 upstream.

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: Christopher Friedt &lt;chrisfriedt@gmail.com&gt;
Tested-by: Christopher Friedt &lt;chrisfriedt@gmail.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4e578080ed3262ed2c3985868539bc66218d25c0 upstream.

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: Christopher Friedt &lt;chrisfriedt@gmail.com&gt;
Tested-by: Christopher Friedt &lt;chrisfriedt@gmail.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: provide interface for audio driver to query cdclk</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2014-07-04T02:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8143820319a5e7d617c122c70b58e1fdbd1b2c6e'/>
<id>8143820319a5e7d617c122c70b58e1fdbd1b2c6e</id>
<content type='text'>
commit c149dcb5c60bfea8871f16dfcc0690255eeb825f upstream.

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Mengdong Lin &lt;mengdong.lin@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c149dcb5c60bfea8871f16dfcc0690255eeb825f upstream.

For Haswell and Broadwell, if the display power well has been disabled,
the display audio controller divider values EM4 M VALUE and EM5 N VALUE
will have been lost. The CDCLK frequency is required for reprogramming them
to generate 24MHz HD-A link BCLK. So provide a private interface for the
audio driver to query CDCLK.

This is a stopgap solution until a more generic interface between audio
and display drivers has been implemented.

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Damien Lespiau &lt;damien.lespiau@intel.com&gt;
Signed-off-by: Mengdong Lin &lt;mengdong.lin@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm: fix NULL pointer access by wrong ioctl</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Zhaowei Yuan</name>
<email>zhaowei.yuan@samsung.com</email>
</author>
<published>2014-06-18T06:33:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6fe5d7d9b99de2b295cfc81b91c5abd279b9be2e'/>
<id>6fe5d7d9b99de2b295cfc81b91c5abd279b9be2e</id>
<content type='text'>
commit 1539fb9bd405ee32282ea0a38404f9e008ac5b7a upstream.

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.

Signed-off-by: Zhaowei Yuan &lt;zhaowei.yuan@samsung.com&gt;
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1539fb9bd405ee32282ea0a38404f9e008ac5b7a upstream.

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.

Signed-off-by: Zhaowei Yuan &lt;zhaowei.yuan@samsung.com&gt;
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i95: Initialize active ring-&gt;pid to -1</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2014-06-10T11:09:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=598b7efff633ac2f7bdd9013d9134c7fb19021ed'/>
<id>598b7efff633ac2f7bdd9013d9134c7fb19021ed</id>
<content type='text'>
commit eee73b46261325eb140d899b5371f49b02d88f63 upstream.

Otherwise we print out spurious processes on unused rings in the error
state.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eee73b46261325eb140d899b5371f49b02d88f63 upstream.

Otherwise we print out spurious processes on unused rings in the error
state.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: default to having backlight if VBT not available</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2014-06-17T12:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=510655b978c0ac33a399c4797c440564663731c7'/>
<id>510655b978c0ac33a399c4797c440564663731c7</id>
<content type='text'>
commit 56c4b63aaf4c2cd91966b2a5e69e5367bea60bbe upstream.

Apparently there are Apple laptops with magic smoke for a VBIOS, which
we fail to find and use. Default to having and setting up backlight in
this case.

This fixes a regression introduced by
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Wed Apr 9 11:31:37 2014 +0300

    drm/i915: do not setup backlight if not available according to VBT

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77831
Reported-and-tested-by: Matteo Cypriani &lt;mcy@lm7.fr&gt;
Reviewed-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 56c4b63aaf4c2cd91966b2a5e69e5367bea60bbe upstream.

Apparently there are Apple laptops with magic smoke for a VBIOS, which
we fail to find and use. Default to having and setting up backlight in
this case.

This fixes a regression introduced by
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Wed Apr 9 11:31:37 2014 +0300

    drm/i915: do not setup backlight if not available according to VBT

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77831
Reported-and-tested-by: Matteo Cypriani &lt;mcy@lm7.fr&gt;
Reviewed-by: Imre Deak &lt;imre.deak@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: Hold the table lock whilst walking the file's idr and counting the objects in debugfs</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2014-06-17T08:56:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4036523a5fff5a13856b7574856eb5df78ae9df1'/>
<id>4036523a5fff5a13856b7574856eb5df78ae9df1</id>
<content type='text'>
commit 5b5ffff0d25060ab0e21fa0f6cd16428e87bf1ea upstream.

Fixes an issue whereby we may race with the table updates (before the
core takes the struct_mutex) and so risk dereferencing a stale pointer in
the iterator for /debugfs/.../i915_gem_objects. For example,

[ 1524.757545] BUG: unable to handle kernel paging request at f53af748
[ 1524.757572] IP: [&lt;c1406982&gt;] per_file_stats+0x12/0x100
[ 1524.757599] *pdpt = 0000000001b13001 *pde = 00000000379fb067 *pte = 80000000353af060
[ 1524.757621] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 1524.757637] Modules linked in: ctr ccm arc4 ath9k ath9k_common ath9k_hw ath snd_hda_codec_conexant mac80211 snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec bnep snd_hwdep rfcomm snd_pcm gpio_ich dell_wmi sparse_keymap snd_seq_midi hid_multitouch uvcvideo snd_seq_midi_event dell_laptop snd_rawmidi dcdbas snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core usbhid videodev snd_seq_device coretemp snd_timer hid joydev kvm_intel cfg80211 ath3k kvm btusb bluetooth serio_raw snd microcode soundcore lpc_ich wmi mac_hid parport_pc ppdev lp parport psmouse ahci libahci
[ 1524.757825] CPU: 3 PID: 1911 Comm: intel-gpu-overl Tainted: G        W  OE 3.15.0-rc3+ #96
[ 1524.757840] Hardware name: Dell Inc. Inspiron 1090/Inspiron 1090, BIOS A06 08/23/2011
[ 1524.757855] task: f52f36c0 ti: f4cbc000 task.ti: f4cbc000
[ 1524.757869] EIP: 0060:[&lt;c1406982&gt;] EFLAGS: 00210202 CPU: 3
[ 1524.757884] EIP is at per_file_stats+0x12/0x100
[ 1524.757896] EAX: 0000002d EBX: 00000000 ECX: f4cbdefc EDX: f53af700
[ 1524.757909] ESI: c1406970 EDI: f53af700 EBP: f4cbde6c ESP: f4cbde5c
[ 1524.757922]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 1524.757934] CR0: 80050033 CR2: f53af748 CR3: 356af000 CR4: 000007f0
[ 1524.757945] Stack:
[ 1524.757957]  f4cbdefc 00000000 c1406970 f53af700 f4cbdea8 c12e5f15 f4cbdefc c1406970
[ 1524.757993]  0000ffff f4cbde90 0000002d f5dc5cd0 e4e80438 c1181d59 f4cbded8 f4d89900
[ 1524.758027]  f5631b40 e5131074 c1903f37 f4cbdf28 c14068e6 f52648a0 c1927748 c1903f37
[ 1524.758062] Call Trace:
[ 1524.758084]  [&lt;c1406970&gt;] ? i915_gem_object_info+0x510/0x510
[ 1524.758106]  [&lt;c12e5f15&gt;] idr_for_each+0xa5/0x100
[ 1524.758126]  [&lt;c1406970&gt;] ? i915_gem_object_info+0x510/0x510
[ 1524.758148]  [&lt;c1181d59&gt;] ? seq_vprintf+0x29/0x50
[ 1524.758168]  [&lt;c14068e6&gt;] i915_gem_object_info+0x486/0x510
[ 1524.758189]  [&lt;c11823a6&gt;] seq_read+0xd6/0x380
[ 1524.758208]  [&lt;c116d11d&gt;] ? final_putname+0x1d/0x40
[ 1524.758227]  [&lt;c11822d0&gt;] ? seq_hlist_next_percpu+0x90/0x90
[ 1524.758246]  [&lt;c1163e52&gt;] vfs_read+0x82/0x150
[ 1524.758265]  [&lt;c11645d6&gt;] SyS_read+0x46/0x90
[ 1524.758285]  [&lt;c16b8d8c&gt;] sysenter_do_call+0x12/0x22
[ 1524.758298] Code: f5 8f 2a 00 83 c4 6c 31 c0 5b 5e 5f 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 04 3e 8d 74 26 00 83 41 04 01 &lt;8b&gt; 42 48 01 41 08 8b 42 4c 89 d7 85 c0 75 07 8b 42 60 85 c0 74
[ 1524.758461] EIP: [&lt;c1406982&gt;] per_file_stats+0x12/0x100 SS:ESP 0068:f4cbde5c
[ 1524.758485] CR2: 00000000f53af748

Reported-by: Sam Jansen &lt;sam.jansen@starleaf.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Sam Jansen &lt;sam.jansen@starleaf.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5b5ffff0d25060ab0e21fa0f6cd16428e87bf1ea upstream.

Fixes an issue whereby we may race with the table updates (before the
core takes the struct_mutex) and so risk dereferencing a stale pointer in
the iterator for /debugfs/.../i915_gem_objects. For example,

[ 1524.757545] BUG: unable to handle kernel paging request at f53af748
[ 1524.757572] IP: [&lt;c1406982&gt;] per_file_stats+0x12/0x100
[ 1524.757599] *pdpt = 0000000001b13001 *pde = 00000000379fb067 *pte = 80000000353af060
[ 1524.757621] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 1524.757637] Modules linked in: ctr ccm arc4 ath9k ath9k_common ath9k_hw ath snd_hda_codec_conexant mac80211 snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec bnep snd_hwdep rfcomm snd_pcm gpio_ich dell_wmi sparse_keymap snd_seq_midi hid_multitouch uvcvideo snd_seq_midi_event dell_laptop snd_rawmidi dcdbas snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core usbhid videodev snd_seq_device coretemp snd_timer hid joydev kvm_intel cfg80211 ath3k kvm btusb bluetooth serio_raw snd microcode soundcore lpc_ich wmi mac_hid parport_pc ppdev lp parport psmouse ahci libahci
[ 1524.757825] CPU: 3 PID: 1911 Comm: intel-gpu-overl Tainted: G        W  OE 3.15.0-rc3+ #96
[ 1524.757840] Hardware name: Dell Inc. Inspiron 1090/Inspiron 1090, BIOS A06 08/23/2011
[ 1524.757855] task: f52f36c0 ti: f4cbc000 task.ti: f4cbc000
[ 1524.757869] EIP: 0060:[&lt;c1406982&gt;] EFLAGS: 00210202 CPU: 3
[ 1524.757884] EIP is at per_file_stats+0x12/0x100
[ 1524.757896] EAX: 0000002d EBX: 00000000 ECX: f4cbdefc EDX: f53af700
[ 1524.757909] ESI: c1406970 EDI: f53af700 EBP: f4cbde6c ESP: f4cbde5c
[ 1524.757922]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 1524.757934] CR0: 80050033 CR2: f53af748 CR3: 356af000 CR4: 000007f0
[ 1524.757945] Stack:
[ 1524.757957]  f4cbdefc 00000000 c1406970 f53af700 f4cbdea8 c12e5f15 f4cbdefc c1406970
[ 1524.757993]  0000ffff f4cbde90 0000002d f5dc5cd0 e4e80438 c1181d59 f4cbded8 f4d89900
[ 1524.758027]  f5631b40 e5131074 c1903f37 f4cbdf28 c14068e6 f52648a0 c1927748 c1903f37
[ 1524.758062] Call Trace:
[ 1524.758084]  [&lt;c1406970&gt;] ? i915_gem_object_info+0x510/0x510
[ 1524.758106]  [&lt;c12e5f15&gt;] idr_for_each+0xa5/0x100
[ 1524.758126]  [&lt;c1406970&gt;] ? i915_gem_object_info+0x510/0x510
[ 1524.758148]  [&lt;c1181d59&gt;] ? seq_vprintf+0x29/0x50
[ 1524.758168]  [&lt;c14068e6&gt;] i915_gem_object_info+0x486/0x510
[ 1524.758189]  [&lt;c11823a6&gt;] seq_read+0xd6/0x380
[ 1524.758208]  [&lt;c116d11d&gt;] ? final_putname+0x1d/0x40
[ 1524.758227]  [&lt;c11822d0&gt;] ? seq_hlist_next_percpu+0x90/0x90
[ 1524.758246]  [&lt;c1163e52&gt;] vfs_read+0x82/0x150
[ 1524.758265]  [&lt;c11645d6&gt;] SyS_read+0x46/0x90
[ 1524.758285]  [&lt;c16b8d8c&gt;] sysenter_do_call+0x12/0x22
[ 1524.758298] Code: f5 8f 2a 00 83 c4 6c 31 c0 5b 5e 5f 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 04 3e 8d 74 26 00 83 41 04 01 &lt;8b&gt; 42 48 01 41 08 8b 42 4c 89 d7 85 c0 75 07 8b 42 60 85 c0 74
[ 1524.758461] EIP: [&lt;c1406982&gt;] per_file_stats+0x12/0x100 SS:ESP 0068:f4cbde5c
[ 1524.758485] CR2: 00000000f53af748

Reported-by: Sam Jansen &lt;sam.jansen@starleaf.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Sam Jansen &lt;sam.jansen@starleaf.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915, HD-audio: Don't continue probing when nomodeset is given</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2014-06-13T13:14:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ab2a211c3d3d2f871f79f0a48c73b8df653219ea'/>
<id>ab2a211c3d3d2f871f79f0a48c73b8df653219ea</id>
<content type='text'>
commit 74b0c2d75fb4cc89173944e6d8f9eb47aca0c343 upstream.

When a machine is booted with nomodeset option, i915 driver skips the
whole initialization.  Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.

In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 74b0c2d75fb4cc89173944e6d8f9eb47aca0c343 upstream.

When a machine is booted with nomodeset option, i915 driver skips the
whole initialization.  Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.

In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/i915: set backlight duty cycle after backlight enable for gen4</title>
<updated>2014-07-09T18:21:26+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2014-06-09T15:24:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b6dec4194aa9571de67c0d0677f398a9e858663b'/>
<id>b6dec4194aa9571de67c0d0677f398a9e858663b</id>
<content type='text'>
commit 2e7eeeb59a92d09144fdb7d2dc1af77a10a7945b upstream.

For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.

This fixes a regression introduced by
commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Thu Nov 14 12:13:41 2013 +0200

    drm/i915: do full backlight setup at enable time

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791
Reported-and-tested-by: mcy@lm7.fr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423
Reported-and-tested-by: Marc Milgram &lt;mmilgram@redhat.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2e7eeeb59a92d09144fdb7d2dc1af77a10a7945b upstream.

For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.

This fixes a regression introduced by
commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
Author: Jani Nikula &lt;jani.nikula@intel.com&gt;
Date:   Thu Nov 14 12:13:41 2013 +0200

    drm/i915: do full backlight setup at enable time

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791
Reported-and-tested-by: mcy@lm7.fr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423
Reported-and-tested-by: Marc Milgram &lt;mmilgram@redhat.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
