aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-03-07drm/nouveau/secboot: support for loading LS PMU firmwareAlexandre Courbot3-1/+121
Allow secboot to load a LS PMU firmware. LS PMU is one instance of firmwares based on the message queue mechanism, which is also used for other firmwares like SEC, so name its source file accordingly. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/pmu: add msgqueue memberAlexandre Courbot2-0/+3
NVIDIA-provided PMU firmware is controlled by a msgqueue. Add a member to the PMU structure as well as the required cleanup code if this feature is used. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: support for gm20b msgqueueAlexandre Courbot4-0/+329
Add support for the msgqueue firmware used to process PMU commands for gm20b. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: add msgqueue interfaceAlexandre Courbot4-0/+796
A message queue firmware implements a specific protocol allowing the host to send "commands" to a falcon, and the falcon to reply using "messages". This patch implements the common part of this protocol and defines the interface that the host can use. Due to the way the firmware is developped internally at NVIDIA (where kernel driver and firmware evolve in lockstep), firmwares taken at different points in time can have frustratingly subtle differences that must be taken into account. This code is architectured to make implementing such differences as easy as possible. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: add LS firmware post-run hooksAlexandre Courbot2-0/+13
Add the ability for LS firmwares to declare a post-run hook that is invoked right after the HS firmware is executed. This allows them to e.g. write some initialization data into the falcon's DMEM. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: abstract fixup_hs_desc functionAlexandre Courbot3-3/+9
As different firmare versions use different HS descriptor formats, we need to abstract this part as well. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: make specialized ls_ucode_img struct privateAlexandre Courbot2-96/+90
This structure does not need to be shared anymore. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: store ucode offset in base image structureAlexandre Courbot3-9/+9
This allows the bootloader descriptor generation code to not rely on specialized ls_ucode_img structures, making it reusable in other instances. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: fix usage of hsf_load_headerAlexandre Courbot3-13/+30
Offsets were not properly computed. This went unnoticed because we are only using one app for now. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: prevent address trimmingAlexandre Courbot1-2/+2
Using 32-bit integers would trim the WPR address if it is allocated above 4GB. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: fix WPR region alignmentAlexandre Courbot1-2/+2
A WPR region smaller than 256K will result in secure boot failure. Adjust the minimal size. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: fix WPR address to be 64-bitAlexandre Courbot2-3/+3
The WPR address parameter of the ls_write_wpr hook was defined as a u32, which will very likely overflow on boards with more than 4GB VRAM. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: make sure requested falcons are supportedAlexandre Courbot1-0/+7
Check at contruction time that we have support for all the LS firmwares asked by the caller. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: remove unused hookAlexandre Courbot2-29/+0
Remove a leftover that became obsolete with the falcon interface. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: fix IMEM port accessAlexandre Courbot1-5/+6
All IMEM registers are duplicated per port. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: fix port offset for DMEM registerAlexandre Courbot1-9/+10
DMEM registers are replicated with a stride of 8 bytes. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: protect against concurrent DMEM accessesAlexandre Courbot2-0/+10
The falcon library may be used concurrently, especially after the introduction of the msgqueue interface. Make it safe to use it that way. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/falcon: add missing context binding memory targetAlexandre Courbot1-0/+1
This is not used currently, but is added for the sake of completeness. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/pmu: make sure the reset hook exists before running itAlexandre Courbot1-1/+2
Some PMU implementations (in particular the ones managed by secure boot) may not have a reset() hook. Make sure we don't crash in that case. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/secboot: make nvkm_secboot_falcon_name visibleAlexandre Courbot2-2/+2
Make nvkm_secboot_falcon_name publicly visible as other subdevs will need to use it for debug messages. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm/nouveau/priv: punt messages to debug levelBen Skeggs2-6/+6
Ideally we'd be able to keep these at a more obvious error level, as they're a good indication of us doing something wrong. However, NVIDIA's FECS/GPCCS firmware touches registers that trigger priv ring faults, and we can't do anything to fix that ourselves due to the need for them to be signed by NVIDIA. This issue was reported a while back, but hasn't been fixed, so, for now we will hide the messages to prevent spamming Optimus users with messages whenever the NVIDIA GPU is powered off and on again. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-07drm: virtio: use kmem_cacheGerd Hoffmann2-50/+11
Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1488377348-5006-1-git-send-email-kraxel@redhat.com
2017-03-07qxl: fix qxl_conn_get_modesGerd Hoffmann1-10/+12
Call qxl_add_monitors_config_modes() unconditionally. Do all sanity checks in that function. Fix sanity checks. monitors_config is the current monitor configuration, whereas client_monitors_config is the configuration requested by the spice client. So when filling the mode list, based on the spice client request, we need to look at client_monitors_config->count not monitors_config->count. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-5-git-send-email-kraxel@redhat.com
2017-03-07qxl: read monitors config at bootGerd Hoffmann1-0/+5
Try to read the client monitors config at driver load time, even without explicit notification. So in case that info was filled before the driver loaded and we've missed the notifications because of that the settings will still be used. With that place we now have to take care to properly handle a empty client monitors config, so we don't trip over an uninitialized client monitors config. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-4-git-send-email-kraxel@redhat.com
2017-03-07qxl: limit monitor config read retriesGerd Hoffmann1-8/+12
When reading the monitor config fails, don't retry forever. If it fails ten times in a row just give up to avoid the driver hangs. Also add a small delay after each attempt, so the host has a chance to complete a partial update. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-3-git-send-email-kraxel@redhat.com
2017-03-07qxl: drop mode_info.modes & related code.Gerd Hoffmann2-24/+0
very old qxl hardware revisions (predating qxl ksm support by a few years) supported a fixed list of video modes only. The list is still provided by the virtual hardware, for backward compatibility reasons. The qxl kms driver never ever looks at it, except for dumping it to the kernel log at load time in case debug logging is enabled. Drop that pointless code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488363154-6889-2-git-send-email-kraxel@redhat.com
2017-03-07drm: qxl: Don't alloc fbdev if emulation is not supportedGabriel Krisman Bertazi1-1/+8
If fbdev emulation is disabled, the QXL shutdown path will try to clean a framebuffer that wasn't initialized, hitting the Oops below. The problem is that even when FBDEV_EMULATION is disabled we allocate the qfbdev strutucture, but we don't initialize it. The fix is to stop allocating the memory, since it won't be used. This allows the existing verification in the cleanup hook to do it's job preventing the oops. Now that we don't allocate the unused fbdev structure, we need to be careful when dereferencing it in the PM suspend hook. [ 24.284684] BUG: unable to handle kernel NULL pointer dereference at 00000000000002e0 [ 24.285627] IP: mutex_lock+0x18/0x30 [ 24.286049] PGD 78cdf067 [ 24.286050] PUD 7940f067 [ 24.286344] PMD 0 [ 24.286649] [ 24.287072] Oops: 0002 [#1] SMP [ 24.287422] Modules linked in: qxl [ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97 [ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 24.289681] task: ffff88007c4c0000 task.stack: ffffc90001b58000 [ 24.290354] RIP: 0010:mutex_lock+0x18/0x30 [ 24.290812] RSP: 0018:ffffc90001b5bcb0 EFLAGS: 00010246 [ 24.291401] RAX: 0000000000000000 RBX: 00000000000002e0 RCX: 0000000000000000 [ 24.292209] RDX: ffff88007c4c0000 RSI: 0000000000000001 RDI: 00000000000002e0 [ 24.292987] RBP: ffffc90001b5bcb8 R08: fffffffffffffffe R09: 0000000000000001 [ 24.293797] R10: ffff880078d80b80 R11: 0000000000011400 R12: 0000000000000000 [ 24.294601] R13: 00000000000002e0 R14: ffffffffa0009c28 R15: 0000000000000060 [ 24.295439] FS: 00007f30e3acbb40(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000 [ 24.296364] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.296997] CR2: 00000000000002e0 CR3: 0000000078c7b000 CR4: 00000000000006f0 [ 24.297813] Call Trace: [ 24.298097] drm_framebuffer_cleanup+0x1f/0x70 [ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl] [ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl] [ 24.299562] qxl_pci_remove+0x22/0x50 [qxl] [ 24.300025] pci_device_remove+0x34/0xb0 [ 24.300507] device_release_driver_internal+0x150/0x200 [ 24.301082] device_release_driver+0xd/0x10 [ 24.301587] unbind_store+0x108/0x150 [ 24.301993] drv_attr_store+0x20/0x30 [ 24.302402] sysfs_kf_write+0x32/0x40 [ 24.302827] kernfs_fop_write+0x108/0x190 [ 24.303269] __vfs_write+0x23/0x120 [ 24.303678] ? security_file_permission+0x36/0xb0 [ 24.304193] ? rw_verify_area+0x49/0xb0 [ 24.304636] vfs_write+0xb0/0x190 [ 24.305004] SyS_write+0x41/0xa0 [ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 24.305887] RIP: 0033:0x7f30e31d9620 [ 24.306285] RSP: 002b:00007ffc54b47e68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 24.307128] RAX: ffffffffffffffda RBX: 00007f30e3497600 RCX: 00007f30e31d9620 [ 24.307928] RDX: 000000000000000d RSI: 0000000000da2008 RDI: 0000000000000001 [ 24.308727] RBP: 000000000070bc60 R08: 00007f30e3498760 R09: 00007f30e3acbb40 [ 24.309504] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000001 [ 24.310295] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc54b47f34 [ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e> 48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3 [ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: ffffc90001b5bcb0 [ 24.313811] CR2: 00000000000002e0 [ 24.314208] ---[ end trace 29669c1593cae14b ]--- Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170227203330.18542-1-krisman@collabora.co.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2017-03-07Merge tag 'drm-misc-next-2017-03-06' of git://anongit.freedesktop.org/git/drm-misc into drm-nextDave Airlie179-4026/+2947
First slice of drm-misc-next for 4.12: Core/subsystem-wide: - link status core patch from Manasi, for signalling link train fail to userspace. I also had the i915 patch in here, but that had a small buglet in our CI, so reverted. - more debugfs_remove removal from Noralf, almost there now (Noralf said he'll try to follow up with the stragglers). - drm todo moved into kerneldoc, for better visibility (see Documentation/gpu/todo.rst), lots of starter tasks in there. - devm_ of helpers + use it in sti (from Ben Gaignard, acked by Rob Herring) - extended framebuffer fbdev support (for fbdev flipping), and vblank wait ioctl fbdev support (Maxime Ripard) - misc small things all over, as usual - add vblank callbacks to drm_crtc_funcs, plus make lots of good use of this to simplify drivers (Shawn Guo) - new atomic iterator macros to unconfuse old vs. new state Small drivers: - vc4 improvements from Eric - vc4 kerneldocs (Eric)! - tons of improvements for dw-mipi-dsi in rockchip from John Keeping and Chris Zhong. - MAINTAINERS entries for drivers managed in drm-misc. It's not yet official, still an experiment, but definitely not complete fail and better to avoid confusion. We kinda screwed that up with drm-misc a bit when we started committers last year. - qxl atomic conversion (Gabriel Krisman) - bunch of virtual driver polish (qxl, virgl, ...) - misc tiny patches all over This is the first time we've done the same merge-window blackout for drm-misc as we've done for drm-intel for ages, hence why we have a _lot_ of stuff queued already. But it's still only half of drm-intel (room to grow!), and the drivers in drm-misc experiment seems to work at least insofar as that you also get lots of driver updates here alredy. * tag 'drm-misc-next-2017-03-06' of git://anongit.freedesktop.org/git/drm-misc: (141 commits) drm/vc4: Fix OOPSes from trying to cache a partially constructed BO. drm/vc4: Fulfill user BO creation requests from the kernel BO cache. Revert "drm/i915: Implement Link Rate fallback on Link training failure" drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC drm: Update drm_fbdev_cma_init documentation drm/rockchip/dsi: add dw-mipi power domain support drm/rockchip/dsi: fix insufficient bandwidth of some panel dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: remove mode_valid function drm/rockchip/dsi: dw-mipi: correct the coding style drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip: dw-mipi-dsi: add reset control drm/rockchip: dw-mipi-dsi: support non-burst modes drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded drm/rockchip: vop: test for P{H,V}SYNC drm/rockchip: dw-mipi-dsi: use positive check for N{H, V}SYNC drm/rockchip: dw-mipi-dsi: use specific poll helper drm/rockchip: dw-mipi-dsi: improve PLL configuration drm/rockchip: dw-mipi-dsi: properly configure PHY timing ...
2017-03-06drm/rockchip: Fix link error when CONFIG_DRM_ANALOGIX_DP undefinedSean Paul1-0/+10
Fixes the following link error when CONFIG_DRM_ANALOGIX_DP is not defined: ERROR: "analogix_dp_start_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined! ERROR: "analogix_dp_stop_crc" [drivers/gpu/drm/rockchip/rockchipdrm.ko] undefined! Fixes: 3190e58dafaf ("drm/rockchip: Implement CRC debugfs API") Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2017-03-06drm/rockchip: Implement CRC debugfs APITomeu Vizoso1-0/+41
Implement the .set_crc_source() callback and call the DP helpers accordingly to start and stop CRC capture. This is only done if this CRTC is currently using the eDP connector. v3: Remove superfluous check on rockchip_crtc_state->output_type v6: Remove superfluous variable Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Mark Yao <mark.yao@rock-chips.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-5-tomeu.vizoso@collabora.com
2017-03-06drm/bridge: analogix_dp: add helpers for capture of frame CRCsTomeu Vizoso1-0/+22
Add two simple functions that just take the drm_dp_aux from our struct and calls the corresponding DP helpers with it. v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul) Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-4-tomeu.vizoso@collabora.com
2017-03-06drm/dp: add helpers for capture of frame CRCsTomeu Vizoso1-0/+126
Adds helpers for starting and stopping capture of frame CRCs through the DPCD. When capture is on, a worker waits for vblanks and retrieves the frame CRC to put it in the queue on the CRTC that is using the eDP connector, so it's passed to userspace. v2: Reuse drm_crtc_wait_one_vblank Update locking, as drm_crtc_add_crc_entry now takes the lock v3: Don't call wake_up_interruptible directly, that's now done in drm_crtc_add_crc_entry. v4: Style fixes (Sean Paul) Reworked retry of CRC reads (Sean Paul) Flush worker after stopping CRC generationa (Sean Paul) v5: Move back to make the retry explicitly once v6: Set and use the drm_crtc backpointer (Sean Paul) Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170303133936.14964-3-tomeu.vizoso@collabora.com
2017-03-06drm/i915: Take rpm wakelock for releasing the fence on unbindChris Wilson1-3/+8
Unbind the vma may happen at any time, outside of the normal GT wakeref. As such it relies on having a wakeref of its own. However, we can forgo clearing the register whilst the device is asleep and just mark it as unused - so that when we do wake up the device, we will clear the unused fence register (see i915_gem_restore_fences). [22423.944631] WARNING: CPU: 3 PID: 26178 at drivers/gpu/drm/i915/intel_drv.h:1739 i915_vma_put_fence+0xf3/0x100 [i915] [22423.946053] RPM wakelock ref not held during HW access [22423.946056] Modules linked in: vgem(E) i915(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) intel_gtt(E) i2c_algo_bit(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) evdev(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) sysimgblt(E) fb_sys_fops(E) prime_numbers(E) drm(E) efivars(E) mei_me(E) lpc_ich(E) mei(E) mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) thermal(E) fan(E) i2c_designware_platform(E) i2c_designware_core(E) [22423.946438] CPU: 2 PID: 26178 Comm: gem_concurrent_ Tainted: G E 4.10.0+ #101 [22423.946513] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2 [22423.946600] Call Trace: [22423.946641] dump_stack+0x68/0x9f [22423.946703] __warn+0x107/0x130 [22423.946763] warn_slowpath_fmt+0xa8/0xe0 [22423.946825] ? __warn+0x130/0x130 [22423.946868] ? free_hot_cold_page_list+0x53/0x70 [22423.946942] ? mark_lock+0xcc/0x7f0 [22423.946997] ? __lock_is_held+0x84/0x100 [22423.947115] ? i915_vma_put_fence+0x64/0x100 [i915] [22423.947224] i915_vma_put_fence+0xf3/0x100 [i915] [22423.947335] i915_vma_unbind+0x4da/0x560 [i915] [22423.947387] ? rb_erase+0x812/0x8a0 [22423.947439] ? kfree+0xa2/0xd0 [22423.947562] i915_vma_close+0x159/0x180 [i915] [22423.947674] intel_ring_free+0x31/0x50 [i915] [22423.947776] i915_gem_context_free+0x1ff/0x3d0 [i915] [22423.947887] context_close+0x106/0x110 [i915] [22423.947989] context_idr_cleanup+0xc/0x10 [i915] [22423.948041] idr_for_each+0x14d/0x1d0 [22423.948158] ? context_close+0x110/0x110 [i915] [22423.948206] ? get_from_free_list+0x70/0x70 [22423.948261] ? __lock_is_held+0x84/0x100 [22423.948325] ? __mutex_unlock_slowpath+0xd4/0x400 [22423.948448] i915_gem_context_close+0x4b/0x90 [i915] [22423.948544] i915_driver_preclose+0x28/0x50 [i915] [22423.948620] drm_release+0x175/0x690 [drm] [22423.948681] ? fcntl_setlk+0x5e0/0x5e0 [22423.948746] __fput+0x17d/0x300 [22423.948807] ____fput+0x9/0x10 [22423.948859] task_work_run+0xa7/0xe0 [22423.948924] do_exit+0x4d2/0x13e0 [22423.948986] ? mm_update_next_owner+0x320/0x320 [22423.949051] ? __do_page_fault+0x209/0x5c0 [22423.949110] ? mark_held_locks+0x23/0xc0 [22423.949166] ? entry_SYSCALL_64_fastpath+0x5/0xb1 [22423.949232] do_group_exit+0x93/0x160 [22423.949289] SyS_exit_group+0x18/0x20 [22423.949350] entry_SYSCALL_64_fastpath+0x1c/0xb1 [22423.949403] RIP: 0033:0x7f9cc2e154c8 [22423.949484] RSP: 002b:00007ffd7e81b448 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [22423.949557] RAX: ffffffffffffffda RBX: ffffffff810ef1f0 RCX: 00007f9cc2e154c8 [22423.949617] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [22423.949677] RBP: ffff880367e9ff98 R08: 00000000000000e7 R09: ffffffffffffff88 [22423.949741] R10: 00007f9cc1d5c000 R11: 0000000000000246 R12: 00007f9cc30f6c30 [22423.949798] R13: 0000000000000000 R14: 00007f9cc30f6c20 R15: 0000000000000003 [22423.949868] ? trace_hardirqs_off_caller+0xc0/0x110 v2: Move the rpm check down a layer so that we still perform the vma/fence update required for the deferred mmio write on resume. v3: Don't touch i915_gem_object_set_cache_level() and leave the rpm to the low level routines (such as i915_vma_put_fence). v4: vma may be null in fence_write, so extract drm_i915_private from fence->i915 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170306092916.11623-3-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2017-03-06drm/i915: Wake up all waiters before idlingChris Wilson1-7/+15
When we idle, we wakeup the first waiter (checking to see if it missed an earlier wakeup) and disarm the breadcrumbs. However, we now assert that there are no waiter when the interrupt is disabled, triggering an assert if there were multiple waiters when we idled. [ 420.842275] invalid opcode: 0000 [#1] PREEMPT SMP [ 420.842285] Modules linked in: vgem snd_hda_codec_realtek x86_pkg_temp_thermal snd_hda_codec_generic intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep mei_me snd_hda_core mei snd_pcm lpc_ich i915 r8169 mii prime_numbers [ 420.842357] CPU: 4 PID: 8714 Comm: kms_pipe_crc_ba Tainted: G U W 4.10.0-CI-CI_DRM_2280+ #1 [ 420.842377] Hardware name: Hewlett-Packard HP Pro 3500 Series/2ABF, BIOS 8.11 10/24/2012 [ 420.842395] task: ffff880117ddce40 task.stack: ffffc90001114000 [ 420.842439] RIP: 0010:__intel_engine_remove_wait+0x1f4/0x200 [i915] [ 420.842454] RSP: 0018:ffffc90001117b18 EFLAGS: 00010046 [ 420.842467] RAX: 0000000000000000 RBX: ffff88010c25c2a8 RCX: 0000000000000001 [ 420.842481] RDX: 0000000000000001 RSI: 00000000ffffffff RDI: ffffc90001117c50 [ 420.842495] RBP: ffffc90001117b58 R08: 0000000011e52352 R09: c4d16acc00000000 [ 420.842511] R10: ffffffff82789eb0 R11: ffff880117ddce40 R12: ffffc90001117c50 [ 420.842525] R13: ffffc90001117c50 R14: 0000000000000078 R15: 0000000000000000 [ 420.842540] FS: 00007fe47dda0a40(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000 [ 420.842559] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 420.842571] CR2: 00007fd6c0a2cec4 CR3: 000000010a5e5000 CR4: 00000000001406e0 [ 420.842586] Call Trace: [ 420.842595] ? do_raw_spin_lock+0xad/0xb0 [ 420.842635] intel_engine_remove_wait.part.3+0x26/0x40 [i915] [ 420.842678] intel_engine_remove_wait+0xe/0x20 [i915] [ 420.842721] i915_wait_request+0x4f0/0x8c0 [i915] [ 420.842736] ? wake_up_q+0x70/0x70 [ 420.842747] ? wake_up_q+0x70/0x70 [ 420.842787] i915_gem_object_wait_fence+0x7d/0x1a0 [i915] [ 420.842829] i915_gem_object_wait+0x30d/0x520 [i915] [ 420.842842] ? __this_cpu_preempt_check+0x13/0x20 [ 420.842884] i915_gem_wait_ioctl+0x12e/0x2e0 [i915] [ 420.842924] ? i915_gem_wait_ioctl+0x22/0x2e0 [i915] [ 420.842939] drm_ioctl+0x200/0x450 [ 420.842976] ? i915_gem_set_wedged+0x90/0x90 [i915] [ 420.842993] do_vfs_ioctl+0x90/0x6e0 [ 420.843003] ? entry_SYSCALL_64_fastpath+0x5/0xb1 [ 420.843017] ? __this_cpu_preempt_check+0x13/0x20 [ 420.843030] ? trace_hardirqs_on_caller+0xe7/0x200 [ 420.843042] SyS_ioctl+0x3c/0x70 [ 420.843054] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 420.843065] RIP: 0033:0x7fe47c4b9357 [ 420.843075] RSP: 002b:00007ffc3c0633c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 420.843094] RAX: ffffffffffffffda RBX: ffffffff81482393 RCX: 00007fe47c4b9357 [ 420.843109] RDX: 00007ffc3c063400 RSI: 00000000c010646c RDI: 0000000000000004 [ 420.843123] RBP: ffffc90001117f88 R08: 0000000000000008 R09: 0000000000000000 [ 420.843137] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 420.843151] R13: 0000000000000004 R14: 00000000c010646c R15: 0000000000000000 [ 420.843168] ? __this_cpu_preempt_check+0x13/0x20 [ 420.843180] Code: 81 48 c7 c1 40 6a 16 a0 48 c7 c2 47 29 15 a0 be 17 01 00 00 48 c7 c7 10 6a 16 a0 e8 c7 ea fe e0 e9 5d ff ff ff 0f 0b 0f 0b 0f 0b <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 e8 67 41 7e e1 [ 420.843325] RIP: __intel_engine_remove_wait+0x1f4/0x200 [i915] RSP: ffffc90001117b18 Fixes: b66255f0f779 ("drm/i915: Refactor wakeup of the next breadcrumb waiter") Fixes: 67b807a89230 ("drm/i915: Delay disabling the user interrupt for breadcrumbs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170306092916.11623-2-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2017-03-06drm/i915: Complain if we take too long under vblank evasion.Maarten Lankhorst1-2/+10
Instead of only complaining when we actually miss a vblank, always complain if we take longer than 100 us. This will make it easier to find cases where we potentially miss vblanks. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488292128-14540-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Add commit message.]
2017-03-06drm/i915: Move updating color management to before vblank evasionMaarten Lankhorst1-5/+7
This cannot be done reliably during vblank evasasion since the color management registers are not double buffered. The original commit that moved it always during vblank evasion was wrong, so revert it to before vblank evasion again. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank evasion.") Cc: stable@vger.kernel.org # v4.7+ Link: http://patchwork.freedesktop.org/patch/msgid/1488292128-14540-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-03-06drm/i915/glk: Remove MODULE_FIRMWARE() tag from Geminilake's DMCAnder Conselvan de Oliveira1-1/+0
Geminilake's DMC is not yet available in the linux-firmware repository. To prevent userspace tools such as mkinitramfs to complain about missing firmware, remove the MODULE_FIRMWARE() tag for now. Fixes: dbb28b5c3d3c ("drm/i915/DMC/GLK: Load DMC on GLK") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: <drm-intel-fixes@lists.freedesktop.org> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170306085651.14008-1-ander.conselvan.de.oliveira@intel.com
2017-03-06drm/blend: Use new atomic iterator macros.Maarten Lankhorst1-11/+11
There are new iterator macros that annotate whether the new or old state should be used. This is better than using a state that depends on whether it's called before or after swap. For clarity, also rename the variables from $obj_state to (old,new)_$obj_state as well. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-6-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-03-06drm/atomic: Convert get_existing_state callers to get_old/new_state, v4.Maarten Lankhorst4-30/+30
This is a straightforward conversion that converts all the users of get_existing_state in atomic core to use get_old_state or get_new_state Changes since v1: - Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state. Changes since v2: - Use the correct state in disable_outputs() Changes since v3: - Rebase for link status training. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/df91a9f9-005e-bcbd-1f74-03c38e1e21dd@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-03-06drm/atomic: Make drm_atomic_plane_disabling easier to understand.Maarten Lankhorst2-4/+5
This function becomes a lot simpler when having passed both the old and new state to it. Looking at all callers, it seems that old_plane_state is never NULL so the check can be dropped. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487256430-7625-3-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-03-06drm/atomic: Fix atomic helpers to use the new iterator macros, v3.Maarten Lankhorst1-216/+230
There are new iterator macros that annotate whether the new or old state should be used. This is better than using a state that depends on whether it's called before or after swap. For clarity, also rename the variables from $obj_state to (old,new)_$obj_state as well. Changes since v1: - Use old/new_*_state for variable names as much as possible. (pinchartl) - Expand commit message. Changes since v2: - Rebase on top of link training patches. - free -> cleanup (pinchartl) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/aafa0d4d-474d-441f-3685-fa6c042ef37e@linux.intel.com Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-03-06drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration spaceChangbin Du1-3/+51
Per PCI specification, Configuration Register has different types (RO, RW, RW1C, Rsvd). For RO Register bits are read-only and cannot be altered by software. For RW1C Register bits indicate status when read. A Set bit indicates a status event which is Cleared by writing a 1b. Writing a 0b to RW1C bits has no effect. Reserved Register is for future implementations, and they are read-only and must return zero when read. Current vGPU configuration write emulation just copy the value as it is. So we haven't emulated RO, RW1C and Rsvd Registers correctly. This patch is following the Spec to correct emulation logic. We add a function vgpu_cfg_mem_write to wrap the access to vGPU configuration memory. The write function uses a RW Register bitmap to avoid RO bits be overwritten, and emulate RW1C behavior for the particular status Register. v2: new = src[i] --> new = src[i] & mask (zhenyu) Signed-off-by: Changbin Du <changbin.du@intel.com> Cc: Xiaoguang Chen <xiaoguang.chen@intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Cc: Min He <min.he@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-03-06drm/i915/gvt: handle workload lifecycle properlyChuanxiao Dong1-16/+33
Currently i915 has a request replay mechanism which can make sure the request can be replayed after a GPU reset. With this mechanism, gvt should wait until the GVT request seqno passed before complete the current workload. So that there should be a context switch interrupt come before gvt free the workload. In this way, workload lifecylce matches with the i915 request lifecycle. The workload can only be freed after the request is completed. v2: use gvt_dbg_sched instead of gvt_err to print when wait again Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-03-06drm/i915: Update DRIVER_DATE to 20170306Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-03-06drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058Tomeu Vizoso1-0/+3
Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all 1.1. When a sink that supports deep color is connected to the output, the receiver will send EDIDs that advertise this capability, even if it isn't possible with HDMI versions earlier than 1.3. Currently the kernel is assuming that deep color is possible and the sink displays an error. This quirk will make sure that deep color isn't used with this particular receiver. Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"") Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com Cc: stable@vger.kernel.org Cc: Matt Horan <matt@matthoran.com> Tested-by: Matt Horan <matt@matthoran.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-03-05drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible stringLaurent Pinchart1-0/+1
The THC63LVDM83D is a transparent LVDS encoder. Unlike dumb LVDS encoders it can be controlled through a few pins (power down, LVDS swing, clock edge selection) and requires power supplies. However, on several boards where the device is used neither the control pins nor the power supply are controllable. To avoid developing a separate device-specific driver add a "thine,thc63lvdm83d" compatible entry to the lvds-encoder driver. This will allow supporting many THC63LVDM83D-based boards easily, while allowing future development of an thc63lvdm83d driver when needed without breaking backward compatibility. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-5-laurent.pinchart+renesas@ideasonboard.com
2017-03-05drm: bridge: vga-dac: Add adi,adv7123 compatible stringLaurent Pinchart1-0/+1
The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be controlled through a power save pin, and requires a power supply. However, on most boards where the device is used neither the power save signal nor the power supply are controllable. To avoid developing a separate device-specific driver add an "adi,adv7123" compatible entry to the dumb-vga-dac driver. This will allow supporting most ADV7123-based boards easily, while allowing future development of an adv7123 driver when needed without breaking backward compatibility. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-4-laurent.pinchart+renesas@ideasonboard.com
2017-03-05drm: bridge: Add LVDS encoder driverLaurent Pinchart3-0/+219
The LVDS encoder driver is a DRM bridge driver that supports the parallel to LVDS encoders that don't require any configuration. The driver thus doesn't interact with the device, but creates an LVDS connector for the panel and exposes its size and timing based on information retrieved from DT. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/20170302104728.7150-3-laurent.pinchart+renesas@ideasonboard.com
2017-03-05drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)Peter Senna Tschudin3-0/+440
The video processing pipeline on the second output on the GE B850v3: Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output Each bridge has a dedicated flash containing firmware for supporting the custom design. The result is that in this design neither the STDP4028 nor the STDP2690 behave as the stock bridges would. The compatible strings include the suffix "-ge-b850v3-fw" to make it clear that the driver is for the bridges with the firmware which is specific for the GE B850v3. The driver is powerless to control the video processing pipeline, as the two bridges behaves as a single one. The driver is only needed for telling the host about EDID / HPD, and for giving the host powers to ack interrupts. This driver adds one i2c_device for each bridge, but only one drm_bridge. This design allows the creation of a functional connector that is capable of reading EDID from the STDP2690 while handling interrupts on the STDP4028. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Martyn Welch <martyn.welch@collabora.co.uk> Cc: Martin Donnelly <martin.donnelly@ge.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Herring <robh@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: David Airlie <airlied@linux.ie> Cc: Thierry Reding <treding@nvidia.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: Enric Balletbo <enric.balletbo@collabora.com> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/ad92919f2eaff2623a551aac94cf11ef948ff9ee.1488555615.git.peter.senna@collabora.com
2017-03-03drm/i915: Don't use enums for hardware engine idMichal Wajdeczko3-18/+24
Generally we are using macros for any hardware identifiers as these may change between Gens. Do the same with hardware engine ids. v2: move hw engine defs to i915_reg.h (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170301202615.118632-1-michal.wajdeczko@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.