<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/i915, branch v5.11.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.11.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.11.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-05-19T08:30:00+00:00</updated>
<entry>
<title>drm/i915: Fix crash in auto_retire</title>
<updated>2021-05-19T08:30:00+00:00</updated>
<author>
<name>Stéphane Marchesin</name>
<email>marcheu@chromium.org</email>
</author>
<published>2021-04-29T03:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=608441de3976c526b02af4d7063093c8adf351e3'/>
<id>urn:sha1:608441de3976c526b02af4d7063093c8adf351e3</id>
<content type='text'>
commit 402be8a101190969fc7ff122d07e262df86e132b upstream.

The retire logic uses the 2 lower bits of the pointer to the retire
function to store flags. However, the auto_retire function is not
guaranteed to be aligned to a multiple of 4, which causes crashes as
we jump to the wrong address, for example like this:

2021-04-24T18:03:53.804300Z WARNING kernel: [  516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
2021-04-24T18:03:53.804310Z WARNING kernel: [  516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G     U            5.4.105-13595-g3cd84167b2df #1
2021-04-24T18:03:53.804311Z WARNING kernel: [  516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021
2021-04-24T18:03:53.804312Z WARNING kernel: [  516.876911] Workqueue: events_unbound active_work
2021-04-24T18:03:53.804313Z WARNING kernel: [  516.876914] RIP: 0010:auto_retire+0x1/0x20
2021-04-24T18:03:53.804314Z WARNING kernel: [  516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f &lt;1f&gt; 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74
2021-04-24T18:03:53.804319Z WARNING kernel: [  516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286
2021-04-24T18:03:53.804320Z WARNING kernel: [  516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007
2021-04-24T18:03:53.804320Z WARNING kernel: [  516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600
2021-04-24T18:03:53.804321Z WARNING kernel: [  516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff
2021-04-24T18:03:53.804321Z WARNING kernel: [  516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0
2021-04-24T18:03:53.804322Z WARNING kernel: [  516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605
2021-04-24T18:03:53.804323Z WARNING kernel: [  516.876926] FS:  0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000
2021-04-24T18:03:53.804323Z WARNING kernel: [  516.876928] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2021-04-24T18:03:53.804324Z WARNING kernel: [  516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0
2021-04-24T18:03:53.804325Z WARNING kernel: [  516.876930] PKRU: 55555554
2021-04-24T18:03:53.804325Z WARNING kernel: [  516.876931] Call Trace:
2021-04-24T18:03:53.804326Z WARNING kernel: [  516.876935]  __active_retire+0x77/0xcf
2021-04-24T18:03:53.804326Z WARNING kernel: [  516.876939]  process_one_work+0x1da/0x394
2021-04-24T18:03:53.804327Z WARNING kernel: [  516.876941]  worker_thread+0x216/0x375
2021-04-24T18:03:53.804327Z WARNING kernel: [  516.876944]  kthread+0x147/0x156
2021-04-24T18:03:53.804335Z WARNING kernel: [  516.876946]  ? pr_cont_work+0x58/0x58
2021-04-24T18:03:53.804335Z WARNING kernel: [  516.876948]  ? kthread_blkcg+0x2e/0x2e
2021-04-24T18:03:53.804336Z WARNING kernel: [  516.876950]  ret_from_fork+0x1f/0x40
2021-04-24T18:03:53.804336Z WARNING kernel: [  516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring kfifo_buf industrialio cros_ec_sensorhub
2021-04-24T18:03:53.804337Z WARNING kernel: [  516.876972]  cdc_ether usbnet iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev
2021-04-24T18:03:53.804337Z EMERG kernel: [  516.879169] gsmi: Log Shutdown Reason 0x03

This change fixes this by aligning the function.

Signed-off-by: Stéphane Marchesin &lt;marcheu@chromium.org&gt;
Fixes: 229007e02d69 ("drm/i915: Wrap i915_active in a simple kreffed struct")
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210429031021.1218091-1-marcheu@chromium.org
(cherry picked from commit ca419f407b43cc89942ebc297c7a63d94abbcae4)
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/overlay: Fix active retire callback alignment</title>
<updated>2021-05-19T08:29:59+00:00</updated>
<author>
<name>Tvrtko Ursulin</name>
<email>tvrtko.ursulin@intel.com</email>
</author>
<published>2021-04-29T08:35:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b742725518fe5868e7b66c926bbd899924e0be9e'/>
<id>urn:sha1:b742725518fe5868e7b66c926bbd899924e0be9e</id>
<content type='text'>
commit a915fe5e9601c632417ef5261af70788d7d23a8a upstream.

__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.

Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active tracking")
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210429083530.849546-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit d8e44e4dd221ee283ea60a6fb87bca08807aa0ab)
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: Read C0DRB3/C1DRB3 as 16 bits again</title>
<updated>2021-05-19T08:29:59+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2021-04-21T15:33:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85b00ca51f638067151051efc5b1c94a7c2497c7'/>
<id>urn:sha1:85b00ca51f638067151051efc5b1c94a7c2497c7</id>
<content type='text'>
commit 04d019961fd15de92874575536310243a0d4c5c5 upstream.

We've defined C0DRB3/C1DRB3 as 16 bit registers, so access them
as such.

Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences")
Reviewed-by: 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/20210421153401.13847-3-ville.syrjala@linux.intel.com
(cherry picked from commit f765a5b48c667bdada5e49d5e0f23f8c0687b21b)
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/gt: Fix a double free in gen8_preallocate_top_level_pdp</title>
<updated>2021-05-19T08:29:58+00:00</updated>
<author>
<name>Lv Yunlong</name>
<email>lyl2019@mail.ustc.edu.cn</email>
</author>
<published>2021-04-26T12:43:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cd242ee933827b85bdab8516a5988b7a07c0121'/>
<id>urn:sha1:7cd242ee933827b85bdab8516a5988b7a07c0121</id>
<content type='text'>
commit ea995218dddba171fecd05496c69617c5ef3c5b8 upstream.

Our code analyzer reported a double free bug.

In gen8_preallocate_top_level_pdp, pde and pde-&gt;pt.base are allocated
via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde-&gt;pt.base
is freed by i915_gem_object_put() with a reference dropped. Then free_pd
calls free_px() defined in intel_ppgtt.c, which calls i915_gem_object_put()
to put pde-&gt;pt.base again.

As pde-&gt;pt.base is protected by refcount, so the second put will not free
pde-&gt;pt.base actually. But, maybe it is better to remove the first put?

Fixes: 82adf901138cc ("drm/i915/gt: Shrink i915_page_directory's slab bucket")
Signed-off-by: Lv Yunlong &lt;lyl2019@mail.ustc.edu.cn&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210426124340.4238-1-lyl2019@mail.ustc.edu.cn
(cherry picked from commit ac69496fe65cca0611d5917b7d232730ff605bc7)
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: Avoid div-by-zero on gen2</title>
<updated>2021-05-19T08:29:50+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2021-04-21T15:33:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=542bc12f6c565239238bff90d28b38bfe6a5539b'/>
<id>urn:sha1:542bc12f6c565239238bff90d28b38bfe6a5539b</id>
<content type='text'>
commit 4819d16d91145966ce03818a95169df1fd56b299 upstream.

Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size()
can in fact return &lt;4KiB, which leads to div-by-zero here.
Avoid that.

Not sure i915_gem_object_get_tile_row_size() is entirely
sane anyway since it doesn't account for the different tile
layouts on i8xx/i915...

I'm not able to hit this before commit 6846895fde05 ("drm/i915:
Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks
like I also need to run recent version of Mesa. With those in
place xonotic trips on this quite easily on my 85x.

Cc: stable@vger.kernel.org
Reviewed-by: 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/20210421153401.13847-2-ville.syrjala@linux.intel.com
(cherry picked from commit ed52c62d386f764194e0184fdb905d5f24194cae)
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: Fix error code in intel_gvt_init_device()</title>
<updated>2021-05-14T08:50:11+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-04-14T06:01:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ebfa8ac4e1fe3cc800685b39562a5eb80022100'/>
<id>urn:sha1:5ebfa8ac4e1fe3cc800685b39562a5eb80022100</id>
<content type='text'>
[ Upstream commit 329328ec6a87f2c1275f50d979d55513de458409 ]

The intel_gvt_init_vgpu_type_groups() function is only called from
intel_gvt_init_device().  If it fails then the intel_gvt_init_device()
prints the error code and propagates it back again.  That's a bug
because false is zero/success.  The fix is to modify it to return zero
or negative error codes and make everything consistent.

Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt file")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/YHaFQtk/DIVYK1u5@mwanda
Reviewed-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Fix misc new gcc warnings</title>
<updated>2021-05-12T06:37:35+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-04-28T00:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=929a512a314c971e19e7a9024e1f09098186ab83'/>
<id>urn:sha1:929a512a314c971e19e7a9024e1f09098186ab83</id>
<content type='text'>
commit e7c6e405e171fb33990a12ecfd14e6500d9e5cf2 upstream.

It seems like Fedora 34 ends up enabling a few new gcc warnings, notably
"-Wstringop-overread" and "-Warray-parameter".

Both of them cause what seem to be valid warnings in the kernel, where
we have array size mismatches in function arguments (that are no longer
just silently converted to a pointer to element, but actually checked).

This fixes most of the trivial ones, by making the function declaration
match the function definition, and in the case of intel_pm.c, removing
the over-specified array size from the argument declaration.

At least one 'stringop-overread' warning remains in the i915 driver, but
that one doesn't have the same obvious trivial fix, and may or may not
actually be indicative of a bug.

[ It was a mistake to upgrade one of my machines to Fedora 34 while
  being busy with the merge window, but if this is the extent of the
  compiler upgrade problems, things are better than usual    - Linus ]

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Andrey Zhizhikin &lt;andrey.z@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Disable runtime power management during shutdown</title>
<updated>2021-05-07T09:11:23+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2021-01-27T18:19:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7c5727923b5edd8d6f14dd67dba457c2551f645'/>
<id>urn:sha1:a7c5727923b5edd8d6f14dd67dba457c2551f645</id>
<content type='text'>
commit 7962893ecb853aa7c8925ce237ab6c4274cfc1c7 upstream.

At least on some TGL platforms PUNIT wants to access some display HW
registers, but it doesn't handle display power management (disabling DC
states as required) and so this register access will lead to a hang. To
prevent this disable runtime power management for poweroff and reboot.

v2:
- Add code comment clarifying the requirement of display power states.
  (Ville)

Reported-and-tested-by: Khaled Almahallawy &lt;khaled.almahallawy@intel.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Khaled Almahallawy &lt;khaled.almahallawy@intel.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210127181909.128094-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel</title>
<updated>2021-04-21T11:13:24+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2021-03-25T11:48:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c3bf7238c40837f7ad2325ccfdbbf21ea811dc47'/>
<id>urn:sha1:c3bf7238c40837f7ad2325ccfdbbf21ea811dc47</id>
<content type='text'>
commit aee6f25e9c911323aa89a200e1bb160c1613ed3d upstream.

After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.

I've managed to reproduce this without rebooting by doing:
chvt 3; echo 1 &gt; /sys/class/graphics/fb0/blank;\
echo 0 &gt; /sys/class/graphics/fb0/blank

Which rapidly turns the panel off and back on again.

The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
used for panel on/off, since starting with MIPI-sequences version &gt;= 3 the
delays are already included inside the MIPI-sequences.

The problems exposed by the "Shut down displays gracefully on reboot"
change, show that using this helper for the panel_pwr_cycle_delay is
not the right thing to do. This has not been noticed until now because
normally the panel never is cycled off and directly on again in quick
succession.

Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
call to avoid the panel staying black after a quick off + on cycle.

Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com
(cherry picked from commit 2878b29fc25a0dac0e1c6c94177f07c7f94240f0)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Don't zero out the Y plane's watermarks</title>
<updated>2021-04-21T11:13:23+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2021-03-27T00:59:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af49daedef2ae6f756cbc8acb99eede4299e34b2'/>
<id>urn:sha1:af49daedef2ae6f756cbc8acb99eede4299e34b2</id>
<content type='text'>
commit bf52dc49ba0101f648b4c3ea26b812061406b0d4 upstream.

Don't zero out the watermarks for the Y plane since we've already
computed them when computing the UV plane's watermarks (since the
UV plane always appears before ethe Y plane when iterating through
the planes).

This leads to allocating no DDB for the Y plane since .min_ddb_alloc
also gets zeroed. And that of course leads to underruns when scanning
out planar formats.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy &lt;stanislav.lisovskiy@intel.com&gt;
Fixes: dbf71381d733 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20210327005945.4929-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy &lt;stanislav.lisovskiy@intel.com&gt;
(cherry picked from commit f99b805fb9413ff007ca0b6add871737664117dd)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
