summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2018-10-17drm/i915: Don't unset intel_connector->mst_portLyude Paul1-11/+6
Currently we set intel_connector->mst_port to NULL to signify that the MST port has been removed from the system so that we can prevent further action on the port such as connector probes, mode probing, etc. However, we're going to need access to intel_connector->mst_port in order to fixup ->best_encoder() so that it can always return the correct encoder for an MST port to prevent legacy DPMS prop changes from failing. This should be safe, so instead keep intel_connector->mst_port always set and instead just check the status of drm_connector->regustered to signify whether or not the connector has disappeared from the system. Changes since v2: - Add a comment to mst_port_gone (Jani Nikula) - Change mst_port_gone to a u8 instead of a bool, per the kernel bot. Apparently bool is discouraged in structs these days Changes since v4: - Don't use mst_port_gone at all! Just check if the connector is registered or not - Daniel Vetter 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-4-lyude@redhat.com (cherry picked from commit 6ed5bb1fbad34382c8cfe9a9bf737e9a43053df5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-10-17drm/i915: Only reset seqno if actually idleChris Wilson1-1/+1
Before we can reset the seqno, we have to be sure the engines are idle. In debugfs/i915_drop_caches_set, we do wait_for_idle but allow ourselves to be interrupted. We should only proceed to reset the seqno then if we were not interrupted, and so also avoid overwriting the error status. References: https://bugs.freedesktop.org/show_bug.cgi?id=108133 Fixes: 6b048706f407 ("drm/i915: Forcibly flush unwanted requests in drop-caches") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004082119.24970-1-chris@chris-wilson.co.uk (cherry picked from commit 88a83f3c2d7a87ce7c9c4171dec8e2fb48070288) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-10-17drm/i915: Use the correct crtc when sanitizing plane mappingVille Syrjälä1-32/+46
When we decide that a plane is attached to the wrong pipe we try to turn off said plane. However we are passing around the crtc we think that the plane is supposed to be using rather than the crtc it is currently using. That doesn't work all that well because we may have to do vblank waits etc. and the other pipe might not even be enabled here. So let's pass the plane's current crtc to intel_plane_disable_noatomic() so that it can its job correctly. To do that semi-cleanly we also have to change the plane readout to record the plane's visibility into the bitmasks of the crtc where the plane is currently enabled rather than to the crtc we want to use for the plane. One caveat here is that our active_planes bitmask will get confused if both planes are enabled on the same pipe. Fortunately we can use plane_mask to reconstruct active_planes sufficiently since plane_mask still has the same meaning (is the plane visible?) during readout. We also have to do the same during the initial plane readout as the second plane could clear the active_planes bit the first plane had already set. v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel) Add Daniel's proposed comment to better document why we do this Drop the redundant intel_set_plane_visible() call Cc: stable@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Cc: Daniel Vetter <daniel@ffwll.ch> Tested-by: Dennis <dennis.nezic@utoronto.ca> Tested-by: Peter Nowee <peter.nowee@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181003145017.4527-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 62358aa4ee86481ce044bef04859820e1bc7c1d9) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-10-17drm/i915: Restore vblank interrupts earlierVille Syrjälä1-10/+13
Plane sanitation needs vblank interrupts (on account of CxSR disable). So let's restore vblank interrupts earlier. v2: Make it actually build v3: Add comment to explain why we need this (Daniel) Cc: stable@vger.kernel.org Cc: Dennis <dennis.nezic@utoronto.ca> Tested-by: Dennis <dennis.nezic@utoronto.ca> Tested-by: Peter Nowee <peter.nowee@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637 Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181003144951.4397-1-ville.syrjala@linux.intel.com (cherry picked from commit 68bc30deac625b8be8d3950b30dc93d09a3645f5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-10-17drm/i915: Check fb stride against plane max strideVille Syrjälä3-0/+37
commit 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") removed the plane max stride check for sprite planes. I was going to add it back when introducing GTT remapping for the display, but after further thought it seems better to re-introduce it separately. So let's add the max stride check back. And let's do it in a nicer form than what we had before and do it for all plane types (easy now that we have the ->max_stride() plane vfunc). Only sprite planes really need this for now since primary planes are capable of scanning out the current max fb size we allow, and cursors have more stringent stride checks elsewhere. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918140243.12207-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> (cherry picked from commit fc3fed5d297b51f9e2c7d4f969c95c0d6e50ca57) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-10-11Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie91-1144/+1652
into drm-next Add a new list.h helper for doing bulk updates. Used by ttm. - Fixes for display underflow on VI APUs at 4K with UVD running - Endian fixes for powerplay on vega - DC fixes for interlaced video - Vega20 powerplay fixes - RV/RV2/PCO powerplay fixes - Fix for spurious ACPI events on HG laptops - Fix a memory leak in DC on driver unload - Fixes for manual fan control mode switching - Suspend/resume robustness fixes - Fix display handling on RV2 - VCN fixes for DPG on PCO - Misc code cleanups and warning fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181011014739.3117-1-alexander.deucher@amd.com
2018-10-11Merge tag 'drm-misc-next-fixes-2018-10-10' of ↵Dave Airlie2-3/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-next - Fix build failure without CONFIG_DRM_FBDEV_EMULATION (Arnd) - Add Maxime to drm-misc maintainer group (Sean) Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sean Paul <sean@poorly.run> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181010203951.GA229456@art_vandelay
2018-10-11Merge branch 'mediatek-drm-next-4.20' of ↵Dave Airlie12-279/+627
https://github.com/ckhu-mediatek/linux.git-tags into drm-next This include hdmi output support for mt2701 and mt7623. Signed-off-by: Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1538616148.28906.1.camel@mtksdaap41
2018-10-11Merge branch 'linux-4.20' of git://github.com/skeggsb/linux into drm-nextDave Airlie17-236/+401
Just initial HDMI 2.0 support, and a bunch of other cleanups. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CABDvA=mgEm9JxP7AX7Sff-AEs7a75M4SqwFHmLPZhJojm4k=OA@mail.gmail.com
2018-10-11drm/nouveau/secboot/acr: fix memory leakGustavo A. R. Silva1-0/+1
In case memory resources for *bl_desc* were allocated, release them before return. Addresses-Coverity-ID: 1472021 ("Resource leak") Fixes: 0d466901552a ("drm/nouveau/secboot/acr: Remove VLA usage") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: take sink support into account for exposing 594mhzIlia Mirkin1-12/+22
Scrambling is required for supporting any mode over 340MHz. If it's not supported, reject any modes that would require it. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: add support for setting scdc parameters for high modesIlia Mirkin1-1/+39
When SCDC is supported, make sure that we configure the GPU and monitor to the same parameters. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: keep track of high-speed state, program into clockIlia Mirkin3-4/+14
The register programmed by the clock method needs to contain a different setting for the link speed as well as special divider settings. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp/gm200-: add scdc parameter setterIlia Mirkin5-0/+39
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: add a way to configure scrambling/tmds for hdmi 2.0Ilia Mirkin3-3/+13
High pixel clocks are required to use a 40 TMDS divider instead of 10, and even low ones may optionally use scrambling depending on device support. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Start using new drm_dev initialization helpersLyude Paul1-72/+101
Per the documentation in drm_get_pci_dev(), this function is deprecated and shouldn't be used anymore. As it turns out, we're going to need to stop using drm_get_pci_dev() anyway in order to allow us to turn off the card before full system shutdowns, otherwise we'll hit race conditions with userspace while trying to tear down the card on shutdown. So, start using drm_dev_get() and drm_dev_put(), and just turn our load/unload callbacks into open coded init/fini() functions. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Fix potential memory leak in nouveau_drm_load()Lyude Paul1-2/+4
We forget to free drm in all instances of failure, and additionally also forget to destroy the master client if the other client fails initialization. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Refactor nvXX_backlight_init()Lyude Paul1-88/+72
There's literally no difference between any of the backlight init functions besides the backlight properties they set and the backlight callbacks that they set, so move all of the duplicated backlight init code out of there and into nouveau_backlight_init(). This gets rid of a lot of copy pasta! Changes since v1: - Some of the pre-refactor callbacks were storing nv_encoder in callback data for the backlight devices that they registered, as opposed to nouveau_drm. This got missed and caused some bugs that didn't originally appear on my setup (NULL kernel derefs) for some reason. So, fix this by finding the nouveau_encoder in nouveau_backlight_init(), and using that as the callback data for all gens instead even if they don't care about the encoder. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jeffery Miller <jmiller@neverware.com> Cc: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Cleanup indenting in nouveau_backlight.cLyude Paul1-6/+7
Still no functional changes. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/Lyude Paul3-4/+4
More consistent with the rest of the codebase, no functional changes here. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Move backlight device into nouveau_connectorLyude Paul6-100/+133
Currently module unloading is broken in nouveau due to a rather annoying race condition resulting from nouveau_backlight.c having gone a bit stale over time: [ 1960.791143] ================================================================== [ 1960.791394] BUG: KASAN: use-after-free in nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791460] Read of size 4 at addr ffff88075accf350 by task zsh/11185 [ 1960.791521] [ 1960.791545] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G O 4.18.0Lyude-Test+ #4 [ 1960.791580] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018 [ 1960.791628] Call Trace: [ 1960.791680] dump_stack+0xa4/0xfd [ 1960.791721] print_address_description+0x71/0x239 [ 1960.791833] ? nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791877] kasan_report.cold.6+0x242/0x2fe [ 1960.791919] __asan_report_load4_noabort+0x19/0x20 [ 1960.792012] nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.792081] nouveau_display_destroy+0x76/0x150 [nouveau] [ 1960.792150] nouveau_drm_device_fini+0xb7/0x190 [nouveau] [ 1960.792265] nouveau_drm_device_remove+0x14b/0x1d0 [nouveau] [ 1960.792347] ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau] [ 1960.792378] ? trace_hardirqs_on_caller+0x38b/0x570 [ 1960.792406] ? trace_hardirqs_on+0xd/0x10 [ 1960.792472] nouveau_drm_remove+0x37/0x50 [nouveau] [ 1960.792502] pci_device_remove+0x112/0x2d0 [ 1960.792530] ? pcibios_free_irq+0x10/0x10 [ 1960.792558] ? kasan_check_write+0x14/0x20 [ 1960.792587] device_release_driver_internal+0x35c/0x650 [ 1960.792617] device_release_driver+0x12/0x20 [ 1960.792643] pci_stop_bus_device+0x172/0x1e0 [ 1960.792671] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 1960.792715] remove_store+0xcb/0xe0 [ 1960.792753] ? sriov_numvfs_store+0x2e0/0x2e0 [ 1960.792779] ? __lock_is_held+0xb5/0x140 [ 1960.792808] ? component_add+0x530/0x530 [ 1960.792834] dev_attr_store+0x3f/0x70 [ 1960.792859] ? sysfs_file_ops+0x11d/0x170 [ 1960.792885] sysfs_kf_write+0x104/0x150 [ 1960.792915] ? sysfs_file_ops+0x170/0x170 [ 1960.792940] kernfs_fop_write+0x24f/0x400 [ 1960.792978] ? __lock_acquire+0x6ea/0x47f0 [ 1960.793021] __vfs_write+0xeb/0x760 [ 1960.793048] ? kernel_read+0x130/0x130 [ 1960.793076] ? __lock_is_held+0xb5/0x140 [ 1960.793107] ? rcu_read_lock_sched_held+0xdd/0x110 [ 1960.793135] ? rcu_sync_lockdep_assert+0x78/0xb0 [ 1960.793162] ? __sb_start_write+0x183/0x220 [ 1960.793189] vfs_write+0x14d/0x4a0 [ 1960.793229] ksys_write+0xd2/0x1b0 [ 1960.793255] ? __ia32_sys_read+0xb0/0xb0 [ 1960.793298] ? fput+0x1d/0x120 [ 1960.793324] ? filp_close+0xf3/0x130 [ 1960.793349] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 1960.793380] __x64_sys_write+0x73/0xb0 [ 1960.793407] do_syscall_64+0xaa/0x400 [ 1960.793433] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.793460] RIP: 0033:0x7f59df433164 [ 1960.793486] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 1960.793541] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1960.793576] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164 [ 1960.793620] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001 [ 1960.793665] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80 [ 1960.793696] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760 [ 1960.793730] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002 [ 1960.793768] [ 1960.793790] Allocated by task 11167: [ 1960.793816] save_stack+0x43/0xd0 [ 1960.793841] kasan_kmalloc+0xc4/0xe0 [ 1960.793880] kasan_slab_alloc+0x11/0x20 [ 1960.793905] kmem_cache_alloc+0xd7/0x270 [ 1960.793944] getname_flags+0xbd/0x520 [ 1960.793969] user_path_at_empty+0x23/0x50 [ 1960.793994] do_faccessat+0x1fc/0x5d0 [ 1960.794018] __x64_sys_access+0x59/0x80 [ 1960.794043] do_syscall_64+0xaa/0x400 [ 1960.794067] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794093] [ 1960.794127] Freed by task 11167: [ 1960.794152] save_stack+0x43/0xd0 [ 1960.794190] __kasan_slab_free+0x139/0x190 [ 1960.794215] kasan_slab_free+0xe/0x10 [ 1960.794239] kmem_cache_free+0xcb/0x2c0 [ 1960.794264] putname+0xad/0xe0 [ 1960.794287] filename_lookup.part.59+0x1f1/0x360 [ 1960.794313] user_path_at_empty+0x3e/0x50 [ 1960.794338] do_faccessat+0x1fc/0x5d0 [ 1960.794362] __x64_sys_access+0x59/0x80 [ 1960.794393] do_syscall_64+0xaa/0x400 [ 1960.794421] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794461] [ 1960.794483] The buggy address belongs to the object at ffff88075acceac0 [ 1960.794483] which belongs to the cache names_cache of size 4096 [ 1960.794540] The buggy address is located 2192 bytes inside of [ 1960.794540] 4096-byte region [ffff88075acceac0, ffff88075accfac0) [ 1960.794581] The buggy address belongs to the page: [ 1960.794609] page:ffffea001d6b3200 count:1 mapcount:0 mapping:ffff880778e4b1c0 index:0x0 compound_mapcount: 0 [ 1960.794651] flags: 0x8000000000008100(slab|head) [ 1960.794679] raw: 8000000000008100 ffffea001d39e808 ffffea001d39ea08 ffff880778e4b1c0 [ 1960.794739] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000 [ 1960.794785] page dumped because: kasan: bad access detected [ 1960.794813] [ 1960.794834] Memory state around the buggy address: [ 1960.794861] ffff88075accf200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794894] ffff88075accf280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794925] >ffff88075accf300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794956] ^ [ 1960.794985] ffff88075accf380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.795017] ffff88075accf400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.795061] ================================================================== [ 1960.795106] Disabling lock debugging due to kernel taint [ 1960.795131] ------------[ cut here ]------------ [ 1960.795148] ida_remove called for id=1802201963 which is not allocated. [ 1960.795193] WARNING: CPU: 7 PID: 11185 at lib/idr.c:521 ida_remove+0x184/0x210 [ 1960.795213] Modules linked in: nouveau(O) mxm_wmi ttm i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm joydev vfat fat intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul iTCO_wdt psmouse wmi_bmof mei_me tpm_tis mei tpm_tis_core tpm i2c_i801 thinkpad_acpi pcc_cpufreq crc32c_intel serio_raw xhci_pci xhci_hcd wmi video i2c_dev i2c_core [ 1960.795305] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G B O 4.18.0Lyude-Test+ #4 [ 1960.795330] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018 [ 1960.795352] RIP: 0010:ida_remove+0x184/0x210 [ 1960.795370] Code: 4c 89 f7 e8 ae c8 00 00 eb 22 41 83 c4 02 4c 89 e8 41 83 fc 3f 0f 86 64 ff ff ff 44 89 fe 48 c7 c7 20 94 1e 83 e8 54 ed 81 fe <0f> 0b 48 b8 00 00 00 00 00 fc ff df 48 01 c3 c7 03 00 00 00 00 c7 [ 1960.795402] RSP: 0018:ffff88074d4df7b8 EFLAGS: 00010082 [ 1960.795421] RAX: 0000000000000000 RBX: 1ffff100e9a9befa RCX: ffffffff81479975 [ 1960.795440] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88077c1de690 [ 1960.795460] RBP: ffff88074d4df878 R08: ffffed00ef83bcd3 R09: ffffed00ef83bcd2 [ 1960.795479] R10: ffffed00ef83bcd2 R11: ffff88077c1de697 R12: 000000000000036b [ 1960.795498] R13: 0000000000000202 R14: ffffffffa0aa7fa0 R15: 000000006b6b6b6b [ 1960.795518] FS: 00007f59e0995b80(0000) GS:ffff88077c1c0000(0000) knlGS:0000000000000000 [ 1960.795553] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1960.795571] CR2: 00007f59e09a2010 CR3: 00000004a1a70005 CR4: 00000000003606e0 [ 1960.795596] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1960.795629] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1960.795649] Call Trace: [ 1960.795667] ? ida_destroy+0x1d0/0x1d0 [ 1960.795686] ? kasan_check_write+0x14/0x20 [ 1960.795704] ? do_raw_spin_lock+0xc2/0x1c0 [ 1960.795724] ida_simple_remove+0x26/0x40 [ 1960.795794] nouveau_backlight_exit+0x9d/0x150 [nouveau] [ 1960.795867] nouveau_display_destroy+0x76/0x150 [nouveau] [ 1960.795930] nouveau_drm_device_fini+0xb7/0x190 [nouveau] [ 1960.795989] nouveau_drm_device_remove+0x14b/0x1d0 [nouveau] [ 1960.796047] ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau] [ 1960.796067] ? trace_hardirqs_on_caller+0x38b/0x570 [ 1960.796089] ? trace_hardirqs_on+0xd/0x10 [ 1960.796146] nouveau_drm_remove+0x37/0x50 [nouveau] [ 1960.796167] pci_device_remove+0x112/0x2d0 [ 1960.796186] ? pcibios_free_irq+0x10/0x10 [ 1960.796218] ? kasan_check_write+0x14/0x20 [ 1960.796237] device_release_driver_internal+0x35c/0x650 [ 1960.796257] device_release_driver+0x12/0x20 [ 1960.796289] pci_stop_bus_device+0x172/0x1e0 [ 1960.796308] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 1960.796328] remove_store+0xcb/0xe0 [ 1960.796345] ? sriov_numvfs_store+0x2e0/0x2e0 [ 1960.796364] ? __lock_is_held+0xb5/0x140 [ 1960.796383] ? component_add+0x530/0x530 [ 1960.796401] dev_attr_store+0x3f/0x70 [ 1960.796419] ? sysfs_file_ops+0x11d/0x170 [ 1960.796436] sysfs_kf_write+0x104/0x150 [ 1960.796454] ? sysfs_file_ops+0x170/0x170 [ 1960.796471] kernfs_fop_write+0x24f/0x400 [ 1960.796488] ? __lock_acquire+0x6ea/0x47f0 [ 1960.796520] __vfs_write+0xeb/0x760 [ 1960.796538] ? kernel_read+0x130/0x130 [ 1960.796556] ? __lock_is_held+0xb5/0x140 [ 1960.796590] ? rcu_read_lock_sched_held+0xdd/0x110 [ 1960.796608] ? rcu_sync_lockdep_assert+0x78/0xb0 [ 1960.796626] ? __sb_start_write+0x183/0x220 [ 1960.796648] vfs_write+0x14d/0x4a0 [ 1960.796666] ksys_write+0xd2/0x1b0 [ 1960.796684] ? __ia32_sys_read+0xb0/0xb0 [ 1960.796701] ? fput+0x1d/0x120 [ 1960.796732] ? filp_close+0xf3/0x130 [ 1960.796749] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 1960.796768] __x64_sys_write+0x73/0xb0 [ 1960.796800] do_syscall_64+0xaa/0x400 [ 1960.796818] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.796836] RIP: 0033:0x7f59df433164 [ 1960.796854] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 1960.796884] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1960.796906] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164 [ 1960.796926] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001 [ 1960.796946] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80 [ 1960.796966] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760 [ 1960.796985] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002 [ 1960.797008] irq event stamp: 509990 [ 1960.797026] hardirqs last enabled at (509989): [<ffffffff8119ff78>] flush_work+0x4b8/0x6d0 [ 1960.797063] hardirqs last disabled at (509990): [<ffffffff8297c395>] _raw_spin_lock_irqsave+0x25/0x60 [ 1960.797085] softirqs last enabled at (509744): [<ffffffff82c005ad>] __do_softirq+0x5ad/0x8c0 [ 1960.797121] softirqs last disabled at (509735): [<ffffffff8115aa15>] irq_exit+0x1a5/0x1e0 [ 1960.797142] ---[ end trace fb1342325f1846b8 ]--- While I haven't actually gone into the details of what's causing this to happen (maybe the kernel removes the backlight device in the device core before we get to it?), it doesn't really matter anyway because the way nouveau handles backlights has long since been deprecated. According to the documentation on the drm_connector->late_register() hook, the ->late_register() hook should be used for adding extra connector-related devices. Vice versa, the ->early_unregister() hook is meant to be used for removing those devices. So: gut nouveau_drm->bl_list and nouveau_drm->backlight, and replace them with per-connector backlight structures. Additionally, move backlight registration/teardown into the ->late_register() and ->early_unregister() hooks so that DRM can give us a chance to remove the backlight before the connector is even removed. This appears to fix the problem once and for all. Changes since v2: - Use NV_INFO_ONCE for printing GMUX information, since otherwise this will end up printing that message for as many times as we have connectors Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Add NV_PRINTK_ONCE and variantsLyude Paul1-0/+8
Since we're about to use this in nouveau_backlight.c. Same thing as DRM_WARN_ONCE, DRM_INFO_ONCE, etc... Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Check backlight IDs are >= 0, not > 0Lyude Paul1-2/+2
Remember, ida IDs start at 0, not 1! Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-10list: introduce list_bulk_move_tail helperChristian König2-20/+28
Move all entries between @first and including @last before @head. This is useful for LRU lists where a whole block of entries should be moved to the end of the list. Used as a band aid in TTM, but better placed in the common list headers. Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: factor out some pptable helpersAlex Deucher4-96/+70
Move copy_array helpers to smu_helper.c and share between vega12 and vega20. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega20_processpptables.cAlex Deucher1-16/+25
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega12_processpptables.cAlex Deucher1-12/+14
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega10_processpptables.cAlex Deucher1-15/+15
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: remove set but not used variable 'header'YueHaibing1-2/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c: In function 'amdgpu_ucode_init_bo': drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:431:39: warning: variable 'header' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: remove set but not used variable 'ring' in psp_v11_0_ring_stopYueHaibing1-3/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/psp_v11_0.c: In function 'psp_v11_0_ring_stop': drivers/gpu/drm/amd/amdgpu/psp_v11_0.c:309:19: warning: variable 'ring' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdkfd: Remove set but not used variable 'preempt_all_queues'YueHaibing1-3/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function 'destroy_queue_cpsch': drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:1366:7: warning: variable 'preempt_all_queues' set but not used [-Wunused-but-set-variable] It never used since introduct in commit 992839ad64f2 ("drm/amdkfd: Add static user-mode queues support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: fix missing break in switch statementsColin Ian King5-0/+10
There are several switch statements that are missing break statements. Add missing breaks to handle any fall-throughs corner cases. Detected by CoverityScan, CID#1457175 ("Missing break in switch") Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Suppress keypresses from ACPI_VIDEO eventsLyude Paul1-5/+12
Currently we return NOTIFY_DONE for any event which we don't think is ours. However, many laptops will send more then just an ATIF event and will also send an ACPI_VIDEO_NOTIFY_PROBE event as well. Since we don't check for this, we return NOTIFY_DONE which causes a keypress for the ACPI event to be propogated to userspace. This is the equivalent of someone pressing the display key on a laptop every time there's a hotplug event. So, check for ACPI_VIDEO_NOTIFY_PROBE events and suppress keypresses from them. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove the direct fw loading support for sdma2.4Rex Zhu1-42/+0
sdma2.4 is only for iceland. For Vi, we don't maintain the direct fw loading. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove wrong fw loading type warningRex Zhu1-2/+0
Remove the warning message: "-1 is not supported on VI" the -1 is the default fw load type, mean auto. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Load fw between hw_init/resume_phase1 and phase2Rex Zhu7-52/+62
Extract the function of fw loading out of powerplay. Do fw loading between hw_init/resuem_phase1 and phase2 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: split ip hw_init into 2 phasesRex Zhu1-13/+53
We need to do some IPs earlier to deal with ordering issues similar to how resume is split into two phases. Will do fw loading via smu/psp between the two phases. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove amdgpu_ucode_fini_boRex Zhu4-26/+1
The variable clean is unnecessary. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Split amdgpu_ucode_init/fini_bo into two functionsRex Zhu3-29/+36
1. one is for create/free bo when init/fini 2. one is for fill the bo before fw loading the ucode bo only need to be created when load driver and free when driver unload. when resume/reset, driver only need to re-fill the bo if the bo is allocated in vram. Suggested by Christian. v2: Return error when bo create failed. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Check late_init status before set cg/pg stateRex Zhu1-2/+2
Fix cg/pg unexpected set in hw init failed case. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Refine function amdgpu_device_ip_late_initRex Zhu1-2/+2
1. only call late_init when hw_init successful, so check status.hw instand of status.valid in late_init. 2. set status.late_initialized true if late_init was not implemented. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Change AI gfx/sdma/smu init sequenceRex Zhu1-4/+4
initialize gfx/sdma before dpm features enabled. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Change SI/CI gfx/sdma/smu init sequenceRex Zhu2-14/+16
initialize gfx/sdma before dpm features enabled. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Limit the max mc address to hole startEmily Deng1-2/+4
For the vram_start is 0 case, the gart range will be from 0x0000FFFF00000000 to 0x0000FFFF1FFFFFFF, which will cause the engine hang. So to avoid the hole, limit the max mc address to AMDGPU_GMC_HOLE_START.:wq Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: fix CPDMA hang in PRT modeTao Zhou1-3/+12
Fix CPDMA hang in PRT mode, set CPF_INT_DMA in reg CP_MECx_F32_INT_DIS for Compute and set DISABLE_GFX_HALT_ON_UTCL1_ERROR in reg CP_DEBUG for GFX Affected ASICs: Vega10 Vega12 Raven Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Tested-by: Yukun.Li <yukun1.li@amd.com> Tested-by: Maciej.Jesionowski <maciej.jesionowski@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: add CP_DEBUG register definition for GC9.0Tao Zhou1-0/+2
Add CP_DEBUG register definition. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amd/display: RV2 DP MST 2nd display within daisy chain not light upHersen Wu1-1/+18
RV2 resource is limit to 3 pipes. Limitation should apply to all HW blocks instead of front pipe. Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amd/display: Fix warning storm on Raven2Roman Li1-2/+41
[Why] Wrong index for pstate debug test register [How] Add correct index value for dcn1_01 in hubbub1_construct() Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10Merge tag 'drm-msm-fixes-2018-10-09' of ↵Dave Airlie2-6/+9
git://people.freedesktop.org/~robclark/linux into drm-next Fix 32-bit arm build. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGt7s20e4aJmnOFM-uZHfYSsicy0E=ssse1D7LTXX4jnWQ@mail.gmail.com
2018-10-10Merge tag 'drm-msm-next-2018-10-07' of ↵Dave Airlie60-3240/+1903
git://people.freedesktop.org/~robclark/linux into drm-next This time mostly further refinement of dpu1+a6xx for sdm845 and beyond.. and hurray for more negative diffstat :-) - Misc cleanups and fixes - GPU preemption optimization - a6xx perf improvements and clock fixes (ie. lets actually not run at minimum clks) - a6xx devfreq/DCVS - Lots of code cleanup across dpu (Bruce, Jeykumar, Sean) - Fixed a few crashes on startup relating to dsi (Sean) - Add cursor support (Sravanthi, Sean) - Properly free mdss irq on destroy (Jordan) - Use correct encoder_type when initializing, fixes crash on boot (Stephen) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsNevCzMiLuNW1EVN6gtP3JZSir6PfnWvnCavSZM+bUFQ@mail.gmail.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-10 12:13:55 +0000