summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* drm/amdgpu/si: fix ASIC testsJean Delvare2019-10-071-3/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ] Comparing adev->family with CHIP constants is not correct. adev->family can only be compared with AMDGPU_FAMILY constants and adev->asic_type is the struct member to compare with CHIP constants. They are separate identification spaces. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Cc: Ken Wang <Qingqing.Wang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: support spdifCharlene Liu2019-10-072-11/+10
| | | | | | | | | | | | | | | | [ Upstream commit b5a41620bb88efb9fb31a4fa5e652e3d5bead7d4 ] [Description] port spdif fix to staging: spdif hardwired to afmt inst 1. spdif func pointer spdif resource allocation (reserve last audio endpoint for spdif only) Signed-off-by: Charlene Liu <charlene.liu@amd.com> Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/nouveau/volt: Fix for some cards having 0 maximum voltageMark Menzynski2019-10-071-0/+2
| | | | | | | | | | | | | | [ Upstream commit a1af2afbd244089560794c260b2d4326a86e39b6 ] Some, mostly Fermi, vbioses appear to have zero max voltage. That causes Nouveau to not parse voltage entries, thus users not being able to set higher clocks. When changing this value Nvidia driver still appeared to ignore it, and I wasn't able to find out why, thus the code is ignoring the value if it is zero. CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Mark Menzynski <mmenzyns@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: reprogram VM config when system resumeLewis Huang2019-10-071-0/+8
| | | | | | | | | | | | | | | | | | | | [ Upstream commit e5382701c3520b3ed66169a6e4aa6ce5df8c56e0 ] [Why] The vm config will be clear to 0 when system enter S4. It will cause hubbub didn't know how to fetch data when system resume. The flip always pending because earliest_inuse_address and request_address are different. [How] Reprogram VM config when system resume Signed-off-by: Lewis Huang <Lewis.Huang@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Eric Yang <eric.yang2@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: fix issue where 252-255 values are clippedAnthony Koo2019-10-071-1/+2
| | | | | | | | | | | | | | | | | | | [ Upstream commit 1cbcfc975164f397b449efb17f59d81a703090db ] [Why] When endpoint is at the boundary of a region, such as at 2^0=1 we find that the last segment has a sharp slope and some points are clipped at the top. [How] If end point is 1, which is exactly at the 2^0 region boundary, we need to program an additional region beyond this point. Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gpu: drm: radeon: Fix a possible null-pointer dereference in ↵Jia-Ju Bai2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | radeon_connector_set_property() [ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ] In radeon_connector_set_property(), there is an if statement on line 743 to check whether connector->encoder is NULL: if (connector->encoder) When connector->encoder is NULL, it is used on line 755: if (connector->encoder->crtc) Thus, a possible null-pointer dereference may occur. To fix this bug, connector->encoder is checked before being used. This bug is found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/radeon: Fix EEH during kexecKyleMahlkuch2019-10-071-0/+8
| | | | | | | | | | | | [ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ] During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. Signed-off-by: KyleMahlkuch <kmahlkuc@linux.vnet.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/rockchip: Check for fast link training before enabling psrSean Paul2019-10-071-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ad309284a52be47c8b3126c9376358bf381861bc ] Once we start shutting off the link during PSR, we're going to want fast training to work. If the display doesn't support fast training, don't enable psr. Changes in v2: - None Changes in v3: - None Changes in v4: - None Changes in v5: - None Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-3-sean@poorly.run Link to v2: https://patchwork.freedesktop.org/patch/msgid/20190326204509.96515-2-sean@poorly.run Link to v3: https://patchwork.freedesktop.org/patch/msgid/20190502194956.218441-9-sean@poorly.run Link to v4: https://patchwork.freedesktop.org/patch/msgid/20190508160920.144739-8-sean@poorly.run Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-8-sean@poorly.run Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/panel: check failure cases in the probe funcNavid Emamdoost2019-10-071-0/+13
| | | | | | | | | | | | | | | | | | [ Upstream commit afd6d4f5a52c16e1483328ac074abb1cde92c29f ] The following function calls may fail and return NULL, so the null check is added. of_graph_get_next_endpoint of_graph_get_remote_port_parent of_graph_get_remote_port Update: Thanks to Sam Ravnborg, for suggession on the use of goto to avoid leaking endpoint. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190724195534.9303-1-navid.emamdoost@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/stm: attach gem fence to atomic stateAhmad Fatoum2019-10-071-0/+2
| | | | | | | | | | | | | | | | [ Upstream commit 8fabc9c3109a71b3577959a05408153ae69ccd8d ] To properly synchronize with other devices the fence from the GEM object backing the framebuffer needs to be attached to the atomic state, so the commit work can wait on fence signaling. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190712084228.8338-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/panel: simple: fix AUO g185han01 horizontal blankingLucas Stach2019-10-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f8c6bfc612b56f02e1b8fae699dff12738aaf889 ] The horizontal blanking periods are too short, as the values are specified for a single LVDS channel. Since this panel is dual LVDS they need to be doubled. With this change the panel reaches its nominal vrefresh rate of 60Fps, instead of the 64Fps with the current wrong blanking. Philipp Zabel added: The datasheet specifies 960 active clocks + 40/128/160 clocks blanking on each of the two LVDS channels (min/typical/max), so doubled this is now correct. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1562764060.23869.12.camel@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/bridge: tc358767: Increase AUX transfer length limitAndrey Smirnov2019-10-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ] According to the datasheet tc358767 can transfer up to 16 bytes via its AUX channel, so the artificial limit of 8 appears to be too low. However only up to 15-bytes seem to be actually supported and trying to use 16-byte transfers results in transfers failing sporadically (with bogus status in case of I2C transfers), so limit it to 15. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew.smirnov@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: Restore backlight brightness after system resumeKai-Heng Feng2019-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | commit bb264220d9316f6bd7c1fd84b8da398c93912931 upstream. Laptops with AMD APU doesn't restore display backlight brightness after system resume. This issue started when DC was introduced. Let's use BL_CORE_SUSPENDRESUME so the backlight core calls update_status callback after system resume to restore the backlight level. Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495 (Raven Ridge). Cc: <stable@vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amd/powerplay/smu7: enforce minimal VBITimeout (v2)Ahzo2019-10-051-0/+5
| | | | | | | | | | | | | | [ Upstream commit f659bb6dae58c113805f92822e4c16ddd3156b79 ] This fixes screen corruption/flickering on 75 Hz displays. v2: make print statement debug only (Alex) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102646 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Ahzo <Ahzo@tutanota.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/nouveau/disp/nv50-: fix center/aspect-corrected scalingIlia Mirkin2019-10-011-4/+24
| | | | | | | | | | | | | | [ Upstream commit 533f4752407543f488a9118d817b8c504352b6fb ] Previously center scaling would get scaling applied to it (when it was only supposed to center the image), and aspect-corrected scaling did not always correctly pick whether to reduce width or height for a particular combination of inputs/outputs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm: Flush output polling on shutdownChris Wilson2019-10-011-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3b295cb1a411d9c82bbfaa66bc17a8508716ed07 ] We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000 <4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c <4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600 <4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0 <4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0 <4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000 <4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 <4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7 <4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948 <4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160 <4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000 <4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000 <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [<ffffffff819aad2c>] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [<ffffffff819aab9d>] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [<ffffffff810b6379>] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.890655] Workqueue: events output_poll_execute <4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0 <4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8 <4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202 <4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000 <4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff <4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 <4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8 <4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007 <4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000 <4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0 <4> [341.890752] Call Trace: <4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0 <4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30 <4> [341.890774] output_poll_execute+0x9d/0x1a0 <4> [341.890782] process_one_work+0x245/0x610 <4> [341.890790] worker_thread+0x37/0x380 <4> [341.890796] ? process_one_work+0x610/0x610 <4> [341.890802] kthread+0x119/0x130 <4> [341.890808] ? kthread_park+0x80/0x80 <4> [341.890815] ret_from_fork+0x3a/0x50 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
* Revert "drm/amd/powerplay: Enable/Disable NBPSTATE on On/OFF of UVD"Shirish S2019-10-011-4/+1
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 00fedbe629bfc0a51c07b6e665265ce31d8b6f3c ] This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8. Reason for revert: This patch sends msg PPSMC_MSG_DisableLowMemoryPstate(0x002e) in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008). This leads to SMU failing to service the request as it is dependent on UVD to be powered ON, since it accesses UVD registers. This msg should ideally be sent only when the UVD is about to decode a 4k video. Signed-off-by: Shirish S <shirish.s@amd.com> Signed-off-by: suresh guttula <suresh.guttula@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to ↵Nick Desaulniers2019-10-012-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | undefined SW FP routines [ Upstream commit 0f0727d971f6fdf8f1077180d495ddb9928f0c8b ] arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn on SSE2 to support emitting double precision floating point instructions rather than calls to non-existent (usually available from gcc_s or compiler_rt) floating point helper routines for Clang. This was originally landed in: commit 10117450735c ("drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines") but reverted in: commit 193392ed9f69 ("Revert "drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines"") due to bugreports from GCC builds. Add guards to only do so for Clang. Link: https://bugs.freedesktop.org/show_bug.cgi?id=109487 Link: https://github.com/ClangBuiltLinux/linux/issues/327 Suggested-by: Sedat Dilek <sedat.dilek@gmail.com> Suggested-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/mediatek: mtk_drm_drv.c: Add of_node_put() before gotoNishka Dasgupta2019-09-191-1/+4
| | | | | | | | | | | | | | | | | commit 165d42c012be69900f0e2f8545626cb9e7d4a832 upstream. Each iteration of for_each_child_of_node puts the previous node, but in the case of a goto from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the goto in two places. Issue found with Coccinelle. Fixes: 119f5173628a (drm/mediatek: Add DRM Driver for Mediatek SoC MT8173) Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm: panel-orientation-quirks: Add extra quirk table entry for GPD MicroPCHans de Goede2019-09-191-0/+12
| | | | | | | | | | | | | | | commit dae1ccee012ea7514af8e4a88429844157aca7dc upstream. Newer GPD MicroPC BIOS versions have proper DMI strings, add an extra quirk table entry for these new strings. This is good news, as this means that we no longer have to update the BIOS dates list with every BIOS update. Fixes: 652b8b086538("drm: panel-orientation-quirks: Add quirk for GPD MicroPC") Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190624154014.8557-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/meson: Add support for XBGR8888 & ABGR8888 formatsNeil Armstrong2019-09-191-0/+16
| | | | | | | | | | | | | commit 5ffff4415f9eeae834960226770963e2947e17eb upstream. Add missing XBGR8888 & ABGR8888 formats variants from the primary plane. Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429075238.7884-1-narmstrong@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectorsLyude Paul2019-09-162-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 34ca26a98ad67edd6e4870fe2d4aa047d41a51dd ] It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com (cherry picked from commit b5d29843d8ef86d4cde4742e095b81b7fd41e688) Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHVVille Syrjälä2019-09-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a8f196a0fa6391a436f63f360a1fb57031fdf26c ] On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by: Stefan Gottwald <gottwald@igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190717114536.22937-1-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit bffb31f73b29a60ef693842d8744950c2819851d) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/panel: Add support for Armadeus ST0700 AdaptSébastien Szymanski2019-09-161-0/+29
| | | | | | | | | | | | | | | [ Upstream commit c479450f61c7f1f248c9a54aedacd2a6ca521ff8 ] This patch adds support for the Armadeus ST0700 Adapt. It comes with a Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so that it can be connected on the TFT header of Armadeus Dev boards. Cc: stable@vger.kernel.org # v4.19 Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190507152713.27494-1-sebastien.szymanski@armadeus.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdgpu/{uvd,vcn}: fetch ring's read_ptr after allocShirish S2019-09-163-3/+12
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 517b91f4cde3043d77b2178548473e8545ef07cb ] [What] readptr read always returns zero, since most likely these blocks are either power or clock gated. [How] fetch rptr after amdgpu_ring_alloc() which informs the power management code that the block is about to be used and hence the gating is turned off. Signed-off-by: Louis Li <Ching-shih.Li@amd.com> Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)Louis Li2019-09-161-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d ] [What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by: Louis Li <Ching-shih.Li@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdkfd: Add missing Polaris10 IDKent Russell2019-09-161-0/+1
| | | | | | | | | | | | [ Upstream commit 0a5a9c276c335870a1cecc4f02b76d6d6f663c8b ] This was added to amdgpu but was missed in amdkfd Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.rg Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Sanity check mmap length against object sizeChris Wilson2019-09-161-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 000c4f90e3f0194eef218ff2c6a8fd8ca1de4313 ] We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong. Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access. Reported-by: Antonio Argenziano <antonio.argenziano@intel.com> Testcase: igt/gem_mmap/bad-size Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk (cherry picked from commit 794a11cb67201ad1bb61af510bb8460280feb3f3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC setJoonas Lahtinen2019-09-161-2/+10
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ebfb6977801da521d8d5d752d373a187e2a2b9b3 ] Add err goto label and use it when VMA can't be established or changes underneath. v2: - Dropping Fixes: as it's indeed impossible to race an object to the error address. (Chris) v3: - Use IS_ERR_VALUE (Chris) Reported-by: Adam Zabrocki <adamza@microsoft.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Adam Zabrocki <adamza@microsoft.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-2-joonas.lahtinen@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm: add __user attribute to ptr_to_compat()Ben Dooks2019-09-161-3/+3
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit e552f0851070fe4975d610a99910be4e9bf5d7bd ] The ptr_to_compat() call takes a "void __user *", so cast the compat drm calls that use it to avoid the following warnings from sparse: drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/drm_ioc32.c:188:39: expected void [noderef] <asn:1>*uptr drivers/gpu/drm/drm_ioc32.c:188:39: got void *[addressable] [assigned] handle drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/drm_ioc32.c:529:41: expected void [noderef] <asn:1>*uptr drivers/gpu/drm/drm_ioc32.c:529:41: got void *[addressable] [assigned] handle Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190301120046.26961-1-ben.dooks@codethink.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/nouveau: Don't WARN_ON VCPI allocation failuresLyude Paul2019-09-161-1/+2
| | | | | | | | | | | | | | | | | | [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915/ilk: Fix warning when reading emon_status with no outputJosé Roberto de Souza2019-09-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cab870b7fdf3c4be747d88de5248b28db7d4055e ] When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs. [22.756480] ------------[ cut here ]------------ [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282 [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006 [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57 [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000 [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001 [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188 [22.756651] FS: 00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000 [22.756653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008 [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020 [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0 [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000 [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/vblank: Allow dynamic per-crtc max_vblank_countVille Syrjälä2019-09-161-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit ed20151a7699bb2c77eba3610199789a126940c4 ] On i965gm we need to adjust max_vblank_count dynamically depending on whether the TV encoder is used or not. To that end add a per-crtc max_vblank_count that takes precedence over its device wide counterpart. The driver can now call drm_crtc_set_max_vblank_count() to configure the per-crtc value before calling drm_vblank_on(). Also looks like there was some discussion about exynos needing similar treatment. v2: Drop the extra max_vblank_count!=0 check for the WARN(last!=current), will take care of it in i915 code (Daniel) WARN_ON(!inmodeset) (Daniel) WARN_ON(dev->max_vblank_count) Pimp up the docs (Daniel) Cc: stable@vger.kernel.org Cc: Inki Dae <inki.dae@samsung.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127182004.28885-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Cleanup gt powerstate from gemChris Wilson2019-09-162-4/+3
| | | | | | | | | | | | [ Upstream commit 30b710840e4b9c9699d3d4b33fb19ad8880d4614 ] Since the gt powerstate is allocated by i915_gem_init, clean it from i915_gem_fini for symmetry and to correct the imbalance on error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180812223642.24865-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Restore sane defaults for KMS on GEM error loadChris Wilson2019-09-161-1/+10
| | | | | | | | | | | | | | | | | [ Upstream commit 7ed43df720c007d60bee6d81da07bcdc7e4a55ae ] If we fail during GEM initialisation, we scrub the HW state by performing a device level GPU resuet. However, we want to leave the system in a usable state (with functioning KMS but no GEM) so after scrubbing the HW state, we need to restore some sane defaults and re-enable the low-level common parts of the GPU (such as the GMCH). v2: Restore GTT entries. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180726085033.4044-2-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/dm: Understand why attaching path/tile properties are neededLyude Paul2019-09-161-3/+0
| | | | | | | | | | | | [ Upstream commit 04ac4b0ed412f65230b456fcd9aa07e13befff89 ] Path property is used for userspace to know what MST connector goes to what actual DRM DisplayPort connector, the tiling property is for tiling configurations. Not sure what else there is to figure out. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/pp: Fix truncated clock value when set watermarkRex Zhu2019-09-161-16/+16
| | | | | | | | | | | | | | | [ Upstream commit 4d454e9ffdb1ef5a51ebc147b5389c96048db683 ] the clk value should be tranferred to MHz first and then transfer to uint16. otherwise, the clock value will be truncated. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reported-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* powerplay: Respect units on max dcfclk watermarkDavid Francis2019-09-161-1/+1
| | | | | | | | | | | | | | | | [ Upstream commit f191415b24a3ad3fa22088af7cd7fc328a2f469f ] In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/atomic_helper: Disallow new modesets on unregistered connectorsLyude Paul2019-09-161-1/+20
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4d80273976bf880c4bed9359b8f2d45663140c86 ] With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915/gen9+: Fix initial readout for Y tiled framebuffersImre Deak2019-09-161-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 914a4fd8cd28016038ce749a818a836124a8d270 ] If BIOS configured a Y tiled FB we failed to set up the backing object tiling accordingly, leading to a lack of GT fence installed and a garbled console. The problem was bisected to commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2") but it just revealed a pre-existing issue. Kudos to Ville who suspected a missing fence looking at the corruption on the screen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: <ronald@innovation.ch> Cc: <stable@vger.kernel.org> Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: <ronald@innovation.ch> Tested-by: <ronald@innovation.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.deak@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Rename PLANE_CTL_DECOMPRESSION_ENABLEDhinakaran Pandiyan2019-09-162-5/+5
| | | | | | | | | | | | | | [ Upstream commit 53867b46fa8443713b3aee520d6ca558b222d829 ] Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822015053.1420-2-dhinakaran.pandiyan@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Fix intel_dp_mst_best_encoder()Lyude Paul2019-09-161-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c ] Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Changes since v1: - Remove mst atomic helper, since this got replaced with a much simpler solution Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdgpu: Update gc_9_0 golden settings.Feifei Xu2019-09-161-0/+1
| | | | | | | | | | | | [ Upstream commit c55045adf7210d246a016c961916f078ed31a951 ] Add mmDB_DEBUG3 settings. Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amdgpu/gfx9: Update gfx9 golden settings.Feifei Xu2019-09-161-1/+1
| | | | | | | | | | | | | [ Upstream commit 54d682d9a5b357eb711994fa94ef1bc44d7ce9d9 ] Update the goldensettings for vega20. Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Re-apply "Perform link quality check, unconditionally during long ↵Jan-Marek Glogowski2019-09-161-0/+16
| | | | | | | | | | | | | | | | | | | | | | | pulse" [ Upstream commit 3cf71bc9904d7ee4a25a822c5dcb54c7804ea388 ] This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147bb939 ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/vmwgfx: Fix double free in vmw_recv_msg()Dan Carpenter2019-09-161-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream. We recently added a kfree() after the end of the loop: if (retries == RETRIES) { kfree(reply); return -EINVAL; } There are two problems. First the test is wrong and because retries equals RETRIES if we succeed on the last iteration through the loop. Second if we fail on the last iteration through the loop then the kfree is a double free. When you're reading this code, please note the break statement at the end of the while loop. This patch changes the loop so that if it's not successful then "reply" is NULL and we can test for that afterward. Cc: <stable@vger.kernel.org> Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/mediatek: set DMA max segment sizeAlexandre Courbot2019-09-102-2/+35
| | | | | | | | | | | | | [ Upstream commit 070955558e820b9a89c570b91b1f21762f62b288 ] This driver requires imported PRIME buffers to appear contiguously in its IO address space. Make sure this is the case by setting the maximum DMA segment size to a more suitable value than the default 64KB. Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/mediatek: use correct device to import PRIME buffersAlexandre Courbot2019-09-101-1/+13
| | | | | | | | | | | | | [ Upstream commit 4c6f3196e6ea111c456c6086dc3f57d4706b0b2d ] PRIME buffers should be imported using the DMA device. To this end, use a custom import function that mimics drm_gem_prime_import_dev(), but passes the correct device. Fixes: 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()Lyude Paul2019-09-061-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 32f0a982650b123bdab36865617d3e03ebcacf3b upstream. Currently, we don't call dma_set_max_seg_size() for i915 because we intentionally do not limit the segment length that the device supports. However, this results in a warning being emitted if we try to map anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG enabled: [ 7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer than device claims to support [len=98304] [max=65536] [ 7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220 debug_dma_map_sg+0x20f/0x340 This was originally brought up on https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus there was it wasn't really useful to set a limit (and that dma-debug isn't really all that useful for i915 in the first place). Unfortunately though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for various distro kernels. Since a WARN_ON() will disable automatic problem reporting (and cause any CI with said option enabled to start complaining), we really should just fix the problem. Note that as me and Chris Wilson discussed, the other solution for this would be to make DMA-API not make such assumptions when a driver hasn't explicitly set a maximum segment size. But, taking a look at the commit which originally introduced this behavior, commit 78c47830a5cb ("dma-debug: check scatterlist segments"), there is an explicit mention of this assumption and how it applies to devices with no segment size: Conversely, devices which are less limited than the rather conservative defaults, or indeed have no limitations at all (e.g. GPUs with their own internal MMU), should be encouraged to set appropriate dma_parms, as they may get more efficient DMA mapping performance out of it. So unless there's any concerns (I'm open to discussion!), let's just follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit to silence any warnings. Changes since v3: * Drop patch for enabling CONFIG_DMA_API_DEBUG_SG in CI. It looks like just turning it on causes the kernel to spit out bogus WARN_ONs() during some igt tests which would otherwise require teaching igt to disable the various DMA-API debugging options causing this. This is too much work to be worth it, since DMA-API debugging is useless for us. So, we'll just settle with this single patch to squelch WARN_ONs() during driver load for users that have CONFIG_DMA_API_DEBUG_SG turned on for some reason. * Move dma_set_max_seg_size() call into i915_driver_hw_probe() - Chris Wilson Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.18+ Link: https://patchwork.freedesktop.org/patch/msgid/20190823205251.14298-1-lyude@redhat.com (cherry picked from commit acd674af95d3f627062007429b9c195c6b32361d) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guestXiong Zhang2019-09-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0a3dfbb5cd9033752639ef33e319c2f2863c713a upstream. The following call trace may exist in linux guest dmesg when guest i915 driver is unloaded. [ 90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space: range [0x0 - 0x0] 0 KiB. [ 90.776621] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0 [ 90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm] [ 90.776718] PGD 800000012c7d0067 P4D 800000012c7d0067 PUD 138e4c067 PMD 0 [ 90.777091] task: ffff9adab60f2f00 task.stack: ffffaf39c0fe0000 [ 90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm] [ 90.777573] Call Trace: [ 90.777653] intel_vgt_deballoon+0x4c/0x60 [i915] [ 90.777729] i915_ggtt_cleanup_hw+0x121/0x190 [i915] [ 90.777792] i915_driver_unload+0x145/0x180 [i915] [ 90.777856] i915_pci_remove+0x15/0x20 [i915] [ 90.777890] pci_device_remove+0x3b/0xc0 [ 90.777916] device_release_driver_internal+0x157/0x220 [ 90.777945] driver_detach+0x39/0x70 [ 90.777967] bus_remove_driver+0x51/0xd0 [ 90.777990] pci_unregister_driver+0x23/0x90 [ 90.778019] SyS_delete_module+0x1da/0x240 [ 90.778045] entry_SYSCALL_64_fastpath+0x24/0x87 [ 90.778072] RIP: 0033:0x7f34312af067 [ 90.778092] RSP: 002b:00007ffdea3da0d8 EFLAGS: 00000206 [ 90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP: ffffaf39c0fe3dc0 [ 90.778344] ---[ end trace f4b1bc8305fc59dd ]--- Four drm_mm_node are used to reserve guest ggtt space, but some of them may be skipped and not initialised due to space constraints in intel_vgt_balloon(). If drm_mm_remove_node() is called with uninitialized drm_mm_node, the above call trace occurs. This patch check drm_mm_node's validity before calling drm_mm_remove_node(). Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size under gvt environment") Cc: stable@vger.kernel.org Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1566279978-9659-1-git-send-email-xiong.y.zhang@intel.com (cherry picked from commit 4776f3529d6b1e47f02904ad1d264d25ea22b27b) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-08 08:21:06 +0000