<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/i915/intel_fbdev.c, branch v4.17.18</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.18</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.17.18'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-04-25T06:50:35+00:00</updated>
<entry>
<title>drm/i915/fbdev: Enable late fbdev initial configuration</title>
<updated>2018-04-25T06:50:35+00:00</updated>
<author>
<name>José Roberto de Souza</name>
<email>jose.souza@intel.com</email>
</author>
<published>2018-04-18T23:41:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b551f1e0fc50ee4e3cde2dd639cb010dae5b997'/>
<id>urn:sha1:0b551f1e0fc50ee4e3cde2dd639cb010dae5b997</id>
<content type='text'>
If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN).  Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.

So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.

This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.

This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/

Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
  drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: José Roberto de Souza &lt;jose.souza@intel.com&gt;
Tested-by: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Tested-by: frederik &lt;frederik.schwan@linux.com&gt; # 4.15.17
Tested-by: Ian Pilcher &lt;arequipeno@gmail.com&gt;
Acked-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
(cherry picked from commit df9e6521749ab33cde306e8a4350b0ac7889220a)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Only pin the fence for primary planes (and gen2/3)</title>
<updated>2018-02-22T15:41:37+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2018-02-21T18:48:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f7a02ad7d16b24908b9fddbd6176b1c1a2b35058'/>
<id>urn:sha1:f7a02ad7d16b24908b9fddbd6176b1c1a2b35058</id>
<content type='text'>
Currently we pin a fence on every plane doing tiled scanout. The
number of planes we have available is fast apporaching the number
of fences so we really should stop wasting them. Only FBC needs
the fence on gen4+, so let's use fences only for the primary planes
on those platforms.

v2: drop the tiling check from plane_uses_fence() as the obj is
    NULL during initial_plane_config() and we don't rally need the
    check since i915_vma_pin_fence() does the check anyway

Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180221184807.577-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
</content>
</entry>
<entry>
<title>drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning</title>
<updated>2018-02-20T19:03:59+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2018-02-20T13:42:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3c017f15f7ee4c088697d41ee4260986c42a885'/>
<id>urn:sha1:e3c017f15f7ee4c088697d41ee4260986c42a885</id>
<content type='text'>
Use the information about the fence state from the time of pinning to
determine if the fbdev writes are going through a fence. This avoids any
confusion in cases where the fence may appear or disappear unconnected
to the use by fbdev.

Suggested-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-3-chris@chris-wilson.co.uk
</content>
</entry>
<entry>
<title>drm/i915: Move the policy for placement of the GGTT vma into the caller</title>
<updated>2018-02-20T19:03:59+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2018-02-20T13:42:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5935485f8eee356f6bb7b2b1cfb43d69e5c03662'/>
<id>urn:sha1:5935485f8eee356f6bb7b2b1cfb43d69e5c03662</id>
<content type='text'>
Currently we make the unilateral decision inside
i915_gem_object_pin_to_display() where the VMA should resided (inside
the fence and mappable region or above?). This is not our decision to
make as it impacts on how the display engine can use the resulting
scanout object, and it would rather instruct us where to place the VMA so
that it can enable the features it wants. As such, make the pin flags an
argument to i915_gem_object_pin_to_display() and control them from
intel_pin_and_fence_fb_obj()

Whilst taking control of the mapping for ourselves, start tracking how
we use it to avoid trying to free a fence we never claimed:

&lt;3&gt;[  227.151869] GEM_BUG_ON(vma-&gt;fence-&gt;pin_count &lt;= 0)
&lt;4&gt;[  227.152064] ------------[ cut here ]------------
&lt;2&gt;[  227.152068] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:391!
&lt;4&gt;[  227.152084] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
&lt;0&gt;[  227.152092] Dumping ftrace buffer:
&lt;0&gt;[  227.152099]    (ftrace buffer empty)
&lt;4&gt;[  227.152102] Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me mei prime_numbers
&lt;4&gt;[  227.152131] CPU: 1 PID: 1587 Comm: kworker/u16:49 Tainted: G     U           4.16.0-rc1-gbab67b2f6177-kasan_7+ #1
&lt;4&gt;[  227.152134] Hardware name: Dell Inc. OptiPlex 755                 /0PU052, BIOS A08 02/19/2008
&lt;4&gt;[  227.152236] Workqueue: events_unbound intel_atomic_commit_work [i915]
&lt;4&gt;[  227.152292] RIP: 0010:intel_unpin_fb_vma+0x23a/0x2a0 [i915]
&lt;4&gt;[  227.152295] RSP: 0018:ffff88005aad7b68 EFLAGS: 00010286
&lt;4&gt;[  227.152300] RAX: 0000000000000026 RBX: ffff88005c359580 RCX: 0000000000000000
&lt;4&gt;[  227.152304] RDX: 0000000000000026 RSI: ffffffff8707d840 RDI: ffffed000b55af63
&lt;4&gt;[  227.152307] RBP: ffff880056817e58 R08: 0000000000000001 R09: 0000000000000000
&lt;4&gt;[  227.152311] R10: ffff88005aad7b88 R11: 0000000000000000 R12: ffff8800568184d0
&lt;4&gt;[  227.152314] R13: ffff880065b5ab08 R14: 0000000000000000 R15: dffffc0000000000
&lt;4&gt;[  227.152318] FS:  0000000000000000(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000
&lt;4&gt;[  227.152322] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[  227.152325] CR2: 00007f5fb25550a8 CR3: 0000000068c78000 CR4: 00000000000006e0
&lt;4&gt;[  227.152328] Call Trace:
&lt;4&gt;[  227.152385]  intel_cleanup_plane_fb+0x6b/0xd0 [i915]
&lt;4&gt;[  227.152395]  drm_atomic_helper_cleanup_planes+0x166/0x280
&lt;4&gt;[  227.152452]  intel_atomic_commit_tail+0x159d/0x3380 [i915]
&lt;4&gt;[  227.152463]  ? process_one_work+0x66e/0x1460
&lt;4&gt;[  227.152516]  ? skl_update_crtcs+0x9c0/0x9c0 [i915]
&lt;4&gt;[  227.152523]  ? lock_acquire+0x13d/0x390
&lt;4&gt;[  227.152527]  ? lock_acquire+0x13d/0x390
&lt;4&gt;[  227.152534]  process_one_work+0x71a/0x1460
&lt;4&gt;[  227.152540]  ? __schedule+0x815/0x1e20
&lt;4&gt;[  227.152547]  ? pwq_dec_nr_in_flight+0x2b0/0x2b0
&lt;4&gt;[  227.152553]  ? _raw_spin_lock_irq+0xa/0x40
&lt;4&gt;[  227.152559]  worker_thread+0xdf/0xf60
&lt;4&gt;[  227.152569]  ? process_one_work+0x1460/0x1460
&lt;4&gt;[  227.152573]  kthread+0x2cf/0x3c0
&lt;4&gt;[  227.152578]  ? _kthread_create_on_node+0xa0/0xa0
&lt;4&gt;[  227.152583]  ret_from_fork+0x3a/0x50
&lt;4&gt;[  227.152591] Code: c6 00 11 86 c0 48 c7 c7 e0 bd 85 c0 e8 60 e7 a9 c4 0f ff e9 1f fe ff ff 48 c7 c6 40 10 86 c0 48 c7 c7 e0 ca 85 c0 e8 2b 95 bd c4 &lt;0f&gt; 0b 48 89 ef e8 4c 44 e8 c4 e9 ef fd ff ff e8 42 44 e8 c4 e9
&lt;1&gt;[  227.152720] RIP: intel_unpin_fb_vma+0x23a/0x2a0 [i915] RSP: ffff88005aad7b68

v2: i915_vma_pin_fence() is a no-op if a fence isn't required, so check
vma-&gt;fence as well.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180220134208.24988-2-chris@chris-wilson.co.uk
</content>
</entry>
<entry>
<title>drm/i915: give stolen_usable_size a more suitable home</title>
<updated>2017-12-12T10:30:22+00:00</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2017-12-11T15:18:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b1ace60107e65b915a59b113f2aaeed8587f34fd'/>
<id>urn:sha1:b1ace60107e65b915a59b113f2aaeed8587f34fd</id>
<content type='text'>
Kick it out of i915_ggtt and keep it grouped with dsm and dsm_reserved,
where it makes the most sense.

Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Paulo Zanoni &lt;paulo.r.zanoni@intel.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171211151822.20953-9-matthew.auld@intel.com
</content>
</entry>
<entry>
<title>drm/i915/fbdev: Serialise early hotplug events with async fbdev config</title>
<updated>2017-11-26T12:44:59+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2017-11-25T19:41:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad88d7fc6c032ddfb32b8d496a070ab71de3a64f'/>
<id>urn:sha1:ad88d7fc6c032ddfb32b8d496a070ab71de3a64f</id>
<content type='text'>
As both the hotplug event and fbdev configuration run asynchronously, it
is possible for them to run concurrently. If configuration fails, we were
freeing the fbdev causing a use-after-free in the hotplug event.

&lt;7&gt;[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
&lt;7&gt;[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
&lt;7&gt;[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
&lt;7&gt;[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
&lt;7&gt;[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
&lt;7&gt;[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
&lt;7&gt;[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
&lt;4&gt;[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
&lt;0&gt;[ 3069.977453] ---------------------------------
&lt;4&gt;[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
&lt;4&gt;[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G     U          4.14.0-CI-CI_DRM_3388+ #1
&lt;4&gt;[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
&lt;4&gt;[ 3069.977508] Workqueue: events output_poll_execute
&lt;4&gt;[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
&lt;4&gt;[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
&lt;4&gt;[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
&lt;4&gt;[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
&lt;4&gt;[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
&lt;4&gt;[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
&lt;4&gt;[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
&lt;4&gt;[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
&lt;4&gt;[ 3069.977547] FS:  0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
&lt;4&gt;[ 3069.977551] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
&lt;4&gt;[ 3069.977559] Call Trace:
&lt;4&gt;[ 3069.977565]  ? mark_held_locks+0x64/0x90
&lt;4&gt;[ 3069.977571]  ? _raw_spin_unlock_irq+0x24/0x50
&lt;4&gt;[ 3069.977575]  ? _raw_spin_unlock_irq+0x24/0x50
&lt;4&gt;[ 3069.977579]  ? trace_hardirqs_on_caller+0xde/0x1c0
&lt;4&gt;[ 3069.977583]  ? _raw_spin_unlock_irq+0x2f/0x50
&lt;4&gt;[ 3069.977588]  ? finish_task_switch+0xa5/0x210
&lt;4&gt;[ 3069.977592]  ? lock_acquire+0xaf/0x200
&lt;4&gt;[ 3069.977596]  lock_acquire+0xaf/0x200
&lt;4&gt;[ 3069.977600]  ? __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977604]  _raw_spin_lock+0x2a/0x40
&lt;4&gt;[ 3069.977608]  ? __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977612]  __mutex_lock+0x5e9/0x9b0
&lt;4&gt;[ 3069.977616]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977621]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977625]  drm_fb_helper_hotplug_event.part.19+0x16/0xa0
&lt;4&gt;[ 3069.977630]  output_poll_execute+0x8d/0x180
&lt;4&gt;[ 3069.977635]  process_one_work+0x22e/0x660
&lt;4&gt;[ 3069.977640]  worker_thread+0x48/0x3a0
&lt;4&gt;[ 3069.977644]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
&lt;4&gt;[ 3069.977649]  kthread+0x102/0x140
&lt;4&gt;[ 3069.977653]  ? process_one_work+0x660/0x660
&lt;4&gt;[ 3069.977657]  ? kthread_create_on_node+0x40/0x40
&lt;4&gt;[ 3069.977662]  ret_from_fork+0x27/0x40
&lt;4&gt;[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff &lt;f0&gt; ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
&lt;1&gt;[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
&lt;4&gt;[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---

In order to keep the dev_priv-&gt;ifbdev alive after failure, we have to
avoid the free and leave it empty until we unload the module (which is
less than ideal, but a necessary evil for simplicity). Then we can use
intel_fbdev_sync() to serialise the hotplug event with the configuration.
The serialisation between the two was removed in commit 934458c2c95d
("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
fails")

Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Lukas Wunner &lt;lukas@wunner.de&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
</content>
</entry>
<entry>
<title>drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()</title>
<updated>2017-10-13T14:53:59+00:00</updated>
<author>
<name>Harsha Sharma</name>
<email>harshasharmaiitr@gmail.com</email>
</author>
<published>2017-10-09T12:06:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3ed110386db97e8213151ddc665adedf6cd11df'/>
<id>urn:sha1:c3ed110386db97e8213151ddc665adedf6cd11df</id>
<content type='text'>
Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch

@@
expression ex;
@@

(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)

Signed-off-by: Harsha Sharma &lt;harshasharmaiitr@gmail.com&gt;
[danvet: Drop the drm_dev_put change for now, to make the patch apply
with out a backmerge.]
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20171009120643.11953-1-harshasharmaiitr@gmail.com
</content>
</entry>
<entry>
<title>drm/i915: Wake up the device for the fbdev setup</title>
<updated>2017-09-04T16:30:45+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2017-09-01T19:54:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c63642329610eae216db906a4e22682256981551'/>
<id>urn:sha1:c63642329610eae216db906a4e22682256981551</id>
<content type='text'>
Our fbdev setup requires the device to be awake for access
through the GTT. If one boots without connected displays and
later plugs one in, we won't have any runtime PM references when
the fbdev setup runs. Explicitly grab a runtime PM reference during
the fbdev setup to avoid the following spew:

[   62.518435] RPM wakelock ref not held during HW access
[   62.518459] ------------[ cut here ]------------
[   62.518546] WARNING: CPU: 3 PID: 37 at ../drivers/gpu/drm/i915/intel_drv.h:1800 i915_vma_pin_iomap+0x144/0x150 [i915]
[   62.518585] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole nls_iso8859_1 nls_cp437 vfat fat efi_pstore coretemp hwmon intel_rapl x86_pkg_temp_thermal e1000e efivars ptp pps_core video evdev ip_tables x_tables ipv6 autofs4
[   62.518741] CPU: 3 PID: 37 Comm: kworker/3:1 Not tainted 4.13.0-rc7-skl+ #1077
[   62.518770] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
[   62.518827] Workqueue: events i915_hotplug_work_func [i915]
[   62.518853] task: ffff88046c00dc00 task.stack: ffffc90000184000
[   62.518896] RIP: 0010:i915_vma_pin_iomap+0x144/0x150 [i915]
[   62.518919] RSP: 0018:ffffc90000187cc8 EFLAGS: 00010292
[   62.518942] RAX: 000000000000002a RBX: ffff880460044000 RCX: 0000000000000006
[   62.518969] RDX: 0000000000000006 RSI: ffffffff819c3e6f RDI: ffffffff819f1c0e
[   62.518996] RBP: ffffc90000187cd8 R08: ffff88046c00e4f0 R09: 0000000000000000
[   62.519022] R10: ffff8804669ca800 R11: 0000000000000000 R12: ffff880461d20000
[   62.519049] R13: ffffc90000187d48 R14: ffff880461d20000 R15: ffff880460044000
[   62.519076] FS:  0000000000000000(0000) GS:ffff88047ed80000(0000) knlGS:0000000000000000
[   62.519107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   62.519130] CR2: 000056478ae213f0 CR3: 0000000002c0f000 CR4: 00000000003406e0
[   62.519156] Call Trace:
[   62.519190]  intelfb_create+0x176/0x360 [i915]
[   62.519216]  __drm_fb_helper_initial_config_and_unlock+0x1c7/0x3c0 [drm_kms_helper]
[   62.519251]  drm_fb_helper_hotplug_event.part.18+0xac/0xc0 [drm_kms_helper]
[   62.519282]  drm_fb_helper_hotplug_event+0x1a/0x20 [drm_kms_helper]
[   62.519324]  intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
[   62.519352]  drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
[   62.519395]  i915_hotplug_work_func+0x24e/0x2b0 [i915]
[   62.519420]  process_one_work+0x1d3/0x6d0
[   62.519440]  worker_thread+0x4b/0x400
[   62.519458]  ? schedule+0x4a/0x90
[   62.519475]  ? preempt_count_sub+0x97/0xf0
[   62.519495]  kthread+0x114/0x150
[   62.519511]  ? process_one_work+0x6d0/0x6d0
[   62.519530]  ? kthread_create_on_node+0x40/0x40
[   62.519551]  ret_from_fork+0x27/0x40
[   62.519569] Code: c4 78 e6 e0 0f ff e9 08 ff ff ff 80 3d d5 bc 0c 00 00 0f 85 0b ff ff ff 48 c7 c7 d8 50 32 a0 c6 05 c1 bc 0c 00 01 e8 9d 78 e6 e0 &lt;0f&gt; ff e9 f1 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 0f b6 87 98
[   62.519771] ---[ end trace 5fbe271f991a58ae ]---

Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170901195456.6386-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
</content>
</entry>
<entry>
<title>Merge airlied/drm-next into drm-intel-next-queued</title>
<updated>2017-08-10T16:12:01+00:00</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2017-08-10T16:12:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=148b1e115eae37c9f3705691b4c45aa4cc0fa71d'/>
<id>urn:sha1:148b1e115eae37c9f3705691b4c45aa4cc0fa71d</id>
<content type='text'>
Ben Widawsky/Daniel Stone need the extended modifier support from
drm-misc to be able to merge CCS support for i915.ko

Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
</content>
</entry>
<entry>
<title>drm: i915: remove dead code and pointless local lut storage</title>
<updated>2017-08-04T09:35:56+00:00</updated>
<author>
<name>Peter Rosin</name>
<email>peda@axentia.se</email>
</author>
<published>2017-07-13T16:25:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=749083173510c59d8e79ecc6eabcf1fe62ce4310'/>
<id>urn:sha1:749083173510c59d8e79ecc6eabcf1fe62ce4310</id>
<content type='text'>
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.

Since the fb helpers .gamma_set and .gamma_get are obsolete,
remove the dead code.

Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Peter Rosin &lt;peda@axentia.se&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-10-peda@axentia.se
</content>
</entry>
</feed>
