<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/i915, branch v4.11.5</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.11.5</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.11.5'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-06-14T13:07:51+00:00</updated>
<entry>
<title>drm/i915/vbt: split out defaults that are set when there is no VBT</title>
<updated>2017-06-14T13:07:51+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-03-10T13:27:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6b183d1b84764e81dcb64f6b41151e79db23679c'/>
<id>urn:sha1:6b183d1b84764e81dcb64f6b41151e79db23679c</id>
<content type='text'>
commit bb1d132935c2f87cd261eb559759fe49d5e5dc43 upstream.

The main thing are the DDI ports. If there's a VBT that says there are
no outputs, we should trust that, and not have semi-random
defaults. Unfortunately, the defaults have resulted in some Chromebooks
without VBT to rely on this behaviour, so we split out the defaults for
the missing VBT case.

Reviewed-by: Manasi Navare &lt;manasi.d.navare@intel.com&gt;
Cc: Manasi Navare &lt;manasi.d.navare@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/95c26079ff640d43f53b944f17e9fc356b36daec.1489152288.git.jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/vbt: don't propagate errors from intel_bios_init()</title>
<updated>2017-06-14T13:07:51+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-03-10T13:27:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07f0aa40fcc708afb7cd7351149b4adda3177e18'/>
<id>urn:sha1:07f0aa40fcc708afb7cd7351149b4adda3177e18</id>
<content type='text'>
commit 665788572c6410b7efadc2e3009c5d830b6d8ef9 upstream.

We don't use the error return for anything other than reporting and
logging that there is no VBT. We can pull the logging in the function,
and remove the error status return. Moreover, if we needed the
information for something later on, we'd probably be better off storing
the bit in dev_priv, and using it where it's needed, instead of using
the error return.

While at it, improve the comments.

Cc: Manasi Navare &lt;manasi.d.navare@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/438ebbb0d5f0d321c625065b9cc78532a1dab24f.1489152288.git.jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Fix runtime PM for LPE audio</title>
<updated>2017-06-14T13:07:50+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2017-04-27T16:02:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa8a1ce79271d38cadba5c43b025d44b67c14b9c'/>
<id>urn:sha1:fa8a1ce79271d38cadba5c43b025d44b67c14b9c</id>
<content type='text'>
commit 668e3b014afb66ab29e134bca7c258527273ac75 upstream.

Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.

Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.

So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.

The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.

Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.

Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.

Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai &lt;tiwai@suse.de&gt;
(cherry picked from commit 183c00350ccda86781f6695840e6c5f5b22efbd1)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915/gvt: Disable access to stolen memory as a guest</title>
<updated>2017-05-25T13:46:30+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2016-11-09T10:39:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7705859189a225120e7b26cd475ccb770917893'/>
<id>urn:sha1:b7705859189a225120e7b26cd475ccb770917893</id>
<content type='text'>
commit 04a68a35ce6d7b54749989f943993020f48fed62 upstream.

Explicitly disable stolen memory when running as a guest in a virtual
machine, since the memory is not mediated between clients and reserved
entirely for the host. The actual size should be reported as zero, but
like every other quirk we want to tell the user what is happening.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20161109103905.17860-1-chris@chris-wilson.co.uk
Reviewed-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Don't call synchronize_rcu_expedited under struct_mutex</title>
<updated>2017-04-11T10:25:18+00:00</updated>
<author>
<name>Joonas Lahtinen</name>
<email>joonas.lahtinen@linux.intel.com</email>
</author>
<published>2017-04-07T10:49:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c053b5a506d3afc038c485a86e3d461f6c7fb207'/>
<id>urn:sha1:c053b5a506d3afc038c485a86e3d461f6c7fb207</id>
<content type='text'>
Only call synchronize_rcu_expedited after unlocking struct_mutex to
avoid deadlock because the workqueues depend on struct_mutex.

&gt;From original patch by Andrea:

synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
wait on the struct_mutex to be released. So we cannot wait for a
quiescent state using those rcu primitives while holding the
struct_mutex or it creates a circular lock dependency resulting in
kernel hangs (which is reproducible but goes undetected by lockdep).

kswapd0         D    0   700      2 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300
? wake_up_bit+0x20/0x20
? rcu_stall_kick_kthreads.part.54+0xc0/0xc0
? rcu_exp_wait_wake+0x530/0x530
? i915_gem_shrink+0x34b/0x4b0
? i915_gem_shrinker_scan+0x7c/0x90
? i915_gem_shrinker_scan+0x7c/0x90
? shrink_slab.part.61.constprop.72+0x1c1/0x3a0
? shrink_zone+0x154/0x160
? kswapd+0x40a/0x720
? kthread+0xf4/0x130
? try_to_free_pages+0x450/0x450
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30
plasmashell     D    0  4657   4614 0x00000000
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? i915_gem_close_object+0x26/0xc0
? i915_gem_close_object+0x26/0xc0
? drm_gem_object_release_handle+0x48/0x90
? drm_gem_handle_delete+0x50/0x80
? drm_ioctl+0x1fa/0x420
? drm_gem_handle_create+0x40/0x40
? pipe_write+0x391/0x410
? __vfs_write+0xc6/0x120
? do_vfs_ioctl+0x8b/0x5d0
? SyS_ioctl+0x3b/0x70
? entry_SYSCALL_64_fastpath+0x13/0x94
kworker/0:0     D    0 29186      2 0x00000000
Workqueue: events __i915_gem_free_work
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? del_timer_sync+0x44/0x50
? update_curr+0x57/0x110
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_work+0x2d/0x40
? process_one_work+0x13a/0x3b0
? worker_thread+0x4a/0x460
? kthread+0xf4/0x130
? process_one_work+0x3b0/0x3b0
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30

Fixes: 3d3d18f086cd ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
Reported-by: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
(cherry picked from commit 8f612d055183545070ca1009ac2eb1f2e044cc20)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Suspend GuC prior to GPU Reset during GEM suspend</title>
<updated>2017-04-11T10:25:12+00:00</updated>
<author>
<name>Sagar Arun Kamble</name>
<email>sagar.a.kamble@intel.com</email>
</author>
<published>2017-04-05T10:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63987bfebd8869e00b34e2bdd12e59d71909bec0'/>
<id>urn:sha1:63987bfebd8869e00b34e2bdd12e59d71909bec0</id>
<content type='text'>
i915 is currently doing a full GPU reset at the end of
i915_gem_suspend() followed by GuC suspend in i915_drm_suspend(). This
GPU reset clobbers the GuC, causing the suspend request to then fail,
leaving the GuC in an undefined state. We need to tell the GuC to
suspend before we do the direct intel_gpu_reset().

v2: Commit message update. (Chris, Daniele)

Fixes: 1c777c5d1dcd ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
Cc: Jeff McGee &lt;jeff.mcgee@intel.com&gt;
Cc: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Cc: Mika Kuoppala &lt;mika.kuoppala@intel.com&gt;
Signed-off-by: Sagar Arun Kamble &lt;sagar.a.kamble@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1491387710-20553-1-git-send-email-sagar.a.kamble@intel.com
Reviewed-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Acked-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
(cherry picked from commit fd08923384385400101c71ac0d21d37d6b23b00d)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'gvt-fixes-2017-04-07' of https://github.com/01org/gvt-linux into drm-intel-fixes</title>
<updated>2017-04-11T09:51:47+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-04-11T09:51:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e5199a37f7ed0effc74d3aaeedd6ce3f816a91d1'/>
<id>urn:sha1:e5199a37f7ed0effc74d3aaeedd6ce3f816a91d1</id>
<content type='text'>
gvt-fixes-2017-04-07

- execlist csb initial read ptr fix (Min)

Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20170407084240.4d2ig5ja2umcnsq3@zhen-hp.sh.intel.com
</content>
</entry>
<entry>
<title>drm/i915/gvt: set the correct default value of CTX STATUS PTR</title>
<updated>2017-04-06T03:08:04+00:00</updated>
<author>
<name>Min He</name>
<email>min.he@intel.com</email>
</author>
<published>2017-04-06T03:01:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a34f83639490a5cc11a9d5c1b3773d4b6eb69a9e'/>
<id>urn:sha1:a34f83639490a5cc11a9d5c1b3773d4b6eb69a9e</id>
<content type='text'>
Fix wrong initial csb read pointer value. This fixes the random
engine timeout issue in guest when guest boots up.

Fixes: 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization")
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Min He &lt;min.he@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'gvt-fixes-2017-04-01' of https://github.com/01org/gvt-linux into drm-intel-fixes</title>
<updated>2017-04-03T15:18:34+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-04-03T15:14:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf082a4a264d5e0bb79f0055be02d255438836a4'/>
<id>urn:sha1:cf082a4a264d5e0bb79f0055be02d255438836a4</id>
<content type='text'>
gvt-fixes-2017-04-01

- Fix cfg space in failsafe (Changbin)
- Fix a race for irq inject with vgpu release (Zhi)
- Fix golden state firmware load (Zhi)

Link: http://patchwork.freedesktop.org/patch/msgid/20170401080650.6cvqon7nsbziwnyc@zhen-hp.sh.intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state</title>
<updated>2017-04-01T05:13:27+00:00</updated>
<author>
<name>Zhi Wang</name>
<email>zhi.a.wang@intel.com</email>
</author>
<published>2017-03-31T16:00:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa4ce4493c88dc324911152d1ccd25469366dba3'/>
<id>urn:sha1:aa4ce4493c88dc324911152d1ccd25469366dba3</id>
<content type='text'>
Firmware loading interface for GVT-g golden HW state has been broken
before. This patch fixes GVT-g firmware loading interface. A user should
apply this patch if he wants to load GVT-g golden HW state from firmware
interface.

Fixes: 579cea5 ("drm/i915/gvt: golden virtual HW state management")
Cc: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Zhi Wang &lt;zhi.a.wang@intel.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
</content>
</entry>
</feed>
