summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2018-12-18drm/etnaviv: remove lastctx member from gpu structLucas Stach
It only written and we don't infer any useful information from it anymore. Remove it. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-12-18drm/etnaviv: replace header include with forward declarationLucas Stach
The etnaviv_gpu header only needs to know about the pointer types, so replace by a forward declaration and only include the headers where needed. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-12-18drm/etnaviv: remove unnecessary local irq disableLucas Stach
The only event function that is called from IRQ context is event_free, which is already using atomic bitmap operations, so we can avoid taking the event spinlock in this function completely. As other the other functions still using the event spinlock are all called from normal process context, we can avoid disabling IRQs while holding the spinlock. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-12-18drm/i915: Update crtc scaler settings when update_pipe is setHans de Goede
When the pipe_config's update_pipe flag is set we may need to update the panel fitting settings. On GEN9+ this means we need to update the crtc's scaler settings. This fixes the following WARN_ON, during i915 loading on an Asrock B150M Pro4S/D3 board with an i5-6500 CPU / graphics: [drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled (expected no, found yes) pipe state doesn't match! WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084 With line 12084 being the I915_STATE_WARN call inside the "if (!intel_pipe_config_compare())" block in verify_crtc_state(). On this board with 2 1920x1080 monitors connected over HDMI the GOP initializes both monitors at 1920x1080 and despite no scaling being necessary configures a scaler for one of them. When booting with fastboot=1 on the initial modeset needs_modeset will be false while update_pipe is true. Since we were not calling skl_update_scaler_crtc() in this case we would leave the scaler enabled causing this error. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181217141903.4182-1-hdegoede@redhat.com
2018-12-17drm/i915/huc: Update the HuC version for BXTAnusha Srivatsa
We have an update for HuC for BXT. Load the latest version. v2: Change the subject. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207182840.9292-2-anusha.srivatsa@intel.com
2018-12-17drm/vkms: set preferred depth to 24emersion
Otherwise DRM_CAP_DUMB_PREFERRED_DEPTH is zero. Signed-off-by: Simon Ser <contact@emersion.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/o2SmEP0M6h287Fs5OeL3HtQzTr8uV0PyOhFict_qdxeS7vFvV1Zr8qzRUJh-YnCoJHo13nJgAqqQByzEzTZTqk9R2ExsOszYLj68hQLqBIc=@emersion.fr
2018-12-17drm/ati_pcigart: Fix error code in drm_ati_pcigart_init()Dan Carpenter
The drm_ati_pcigart_init() function was originally suppose to return one on success and zero on failure, but these days it returns a mix of zero, one and -ENOMEM on failure. This patch cleans it up and modifies the caller so now the function returns zero on success and negative error codes on failure. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181217070344.GC12159@kadam
2018-12-17drm: Fix an error pointer dereference()Dan Carpenter
The drm_mode_create_tile_group() is only called from drm_parse_tiled_block() and the caller expects it to return a NULL on error. In other words, this function should match drm_mode_get_tile_group(). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181217065733.GA12159@kadam
2018-12-16drm/i915/dsc: Add Per connector debugfs node for DSC support/enableManasi Navare
DSC can be supported per DP connector. This patch adds a per connector debugfs node to expose DSC support capability by the kernel. The same node can be used from userspace to force DSC enable. force_dsc_en written through this debugfs node is used to force DSC even for lower resolutions. Credits to Ville Syrjala for suggesting the proper locks to be used and to Lyude Paul for explaining how to use them in this context v8: * Add else if (ret) for drm_modeset_lock (Lyude) v7: * Get crtc, crtc_state from connector atomic state and add proper locks and backoff (Ville, Chris Wilson, Lyude) (Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>) * Use %zu for printing size_t variable (Lyude) v6: * Read fec_capable only for non edp (Manasi) v5: * Name it dsc sink support and also add fec support in the same node (Ville) v4: * Add missed connector_status check (Manasi) * Create i915_dsc_support node only for Gen >=10 (manasi) * Access intel_dp->dsc_dpcd only if its not NULL (Manasi) v3: * Combine Force_dsc_en with this patch (Ville) v2: * Use kstrtobool_from_user to avoid explicit error checking (Lyude) * Rebase on drm-tip (Manasi) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181206005407.4698-1-manasi.d.navare@intel.com
2018-12-14drm/amdgpu: WARN once if amdgpu_bo_unpin is called for an unpinned BOMichel Dänzer
It indicates a pin/unpin imbalance bug somewhere. While the bug isn't necessarily in the call chain hitting this, it's at least one part involved. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: enable Vega20 page queue supportEvan Quan
Page queue is supported on Vega20 with SDMA firmware 123 onwards. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: use different irq ring ID for Vega20 page queuesEvan Quan
Vega20 uses ring id 1 for page queues EOP irq while previous ASICs take ring id 3. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: update the vm invalidation engine layout V2Evan Quan
We need new invalidation engine layout due to new SDMA page queues added. V2: fix coding style and add correct return value Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: increase the MAX ring numberEvan Quan
As two more SDMA page queue rings are added on Vega20. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: fix NULL fence handling in amdgpu_cs_fence_to_handle_ioctlChristian König
When the fence is already signaled it is perfectly normal to get a NULL fence here. But since we can't export that we need to use a stub fence. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/dp_mst: Refactor drm_dp_update_payload_part1()Lyude Paul
This: - Adds local variables in the first loop, instead of using array indices everywhere - Adds an early continue to reduce the indent level in the second loop There should be no functional changes here Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Juston Li <juston.li@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181214012604.13746-3-lyude@redhat.com
2018-12-14drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()Lyude Paul
There's no reason we need this, it's just confusing looking. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Juston Li <juston.li@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181214012604.13746-2-lyude@redhat.com
2018-12-14drm/amdgpu/psp: Correct and refine the vmr support. (v2)Emily Deng
Currently driver only psp v11 support vmr. v2: squash in unused variable removal (Alex) Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu/psp_v3_1: Get psp fw version through reading registerEmily Deng
If PSP FW is running already, driver will not load PSP FW again and skip it. So psp fw version is not correct if reading it from FW binary file, need to get right version from register. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: access register without KIQEmily Deng
There is no need to access register such as mmSMC_IND_INDEX_11 and mmSMC_IND_DATA_11, PCIE_INDEX, PCIE_DATA through KIQ because they are VF-copy. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/amdgpu: kfd_pre_reset outside req_full_gpu cause sriov hangwentalou
XGMI hive put kfd_pre_reset into amdgpu_device_lock_adev, but outside req_full_gpu of sriov. It would make sriov hang during reset. Signed-off-by: Wentao Lou <Wentao.Lou@amd.com> Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-14drm/virtio: switch to generic fbdev emulationGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181213134915.24722-1-kraxel@redhat.com
2018-12-14drm/exynos: fimd: Make pixel blend mode configurableChristoph Manszewski
The fimd hardware supports different blend modes. Add pixel blend mode property and make it configurable, by modifying the blend equation. Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019. Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-12-14drm/exynos: fimd: Make plane alpha configurableChristoph Manszewski
The fimd hardware supports variable plane alpha. Currently planes are opaque, make this configurable. Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019. Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-12-13drm/dp_mst: Fix memory leak in drm_dp_mst_topology_mgr_destroy()Lyude Paul
We need to call drm_dp_mst_topology_mgr_set_mst(mgr, false) when destroying the topology manager in order to ensure that the root mstb and all of it's descendents are actually destroyed, and additionally to try to make sure that we leave the hub in a clean state. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181211235026.21758-1-lyude@redhat.com
2018-12-13drm: Rename crtc_idr as object_idr to KMS cleanupsShayenne da Luz Moura
This patch solves this TODO task: drm_mode_config.crtc_idr is misnamed, since it contains all KMS object. Should be renamed to drm_mode_config.object_idr. Signed-off-by: Shayenne da Luz Moura <shayenneluzmoura@gmail.com> [danvet: resolve conflict with addition of privobj_list.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181213212957.vkitkyl5cj2qh7qr@smtp.gmail.com
2018-12-13dma-mapping: bypass indirect calls for dma-directChristoph Hellwig
Avoid expensive indirect calls in the fast path DMA mapping operations by directly calling the dma_direct_* ops if we are using the directly mapped DMA operations. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: Tony Luck <tony.luck@intel.com>
2018-12-14Merge branch 'vmwgfx-fixes-4.20' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-fixes One regression fix for avoiding kernel OOM, one cleanup return fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213122815.10581-1-thellstrom@vmware.com
2018-12-14Merge tag 'vmwgfx-next-2018-12-13' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-next Pull request of 2018-12-13 Two minor fixes for next pull. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213130848.3080-1-thellstrom@vmware.com
2018-12-13drm/i915: Fix Cherryview oops on bootChris Wilson
Do not dereference the LUT blob before checking whether that blob exists. Or else, <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 <6>[ 13.978718] PGD 0 P4D 0 <4>[ 13.978733] Oops: 0000 [#1] PREEMPT SMP PTI <4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted 4.20.0-rc5-CI-CI_DRM_5294+ #1 <4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016 <4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915] <4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75 <4>[ 13.979001] RSP: 0018:ffffc9000026f840 EFLAGS: 00010246 <4>[ 13.979018] RAX: 0000000000000000 RBX: ffff888165500000 RCX: 7885fe6200000000 <4>[ 13.979039] RDX: 0000000000000020 RSI: ffff88816553a008 RDI: ffff888165464a88 <4>[ 13.979060] RBP: ffff888165464a88 R08: 000000000ed0e429 R09: 0000000000000001 <4>[ 13.979080] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000004000 <4>[ 13.979101] R13: 0000000000004000 R14: ffff888165500000 R15: ffff888165464a88 <4>[ 13.979122] FS: 00007fb69c4f3540(0000) GS:ffff88817ba00000(0000) knlGS:0000000000000000 <4>[ 13.979146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 13.979163] CR2: 0000000000000048 CR3: 000000016d7fa000 CR4: 00000000001006f0 <4>[ 13.979184] Call Trace: <4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915] <4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915] <4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915] <4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915] <4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] <4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915] <4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915] <4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915] <4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915] <4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80 <4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0 <4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915] <4>[ 13.980421] pci_device_probe+0xa1/0x130 <4>[ 13.980440] really_probe+0xf3/0x3e0 <4>[ 13.980456] driver_probe_device+0x10a/0x120 <4>[ 13.980474] __driver_attach+0xdb/0x100 <4>[ 13.980489] ? driver_probe_device+0x120/0x120 <4>[ 13.980505] ? driver_probe_device+0x120/0x120 <4>[ 13.980522] bus_for_each_dev+0x74/0xc0 <4>[ 13.980539] bus_add_driver+0x15f/0x250 <4>[ 13.980554] ? 0xffffffffa0348000 <4>[ 13.980568] driver_register+0x56/0xe0 <4>[ 13.980583] ? 0xffffffffa0348000 <4>[ 13.980597] do_one_initcall+0x58/0x2e0 <4>[ 13.980615] ? do_init_module+0x1d/0x1ea <4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80 <4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290 <4>[ 13.980668] do_init_module+0x56/0x1ea <4>[ 13.980685] load_module+0x227a/0x29c0 <4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0 <4>[ 13.980756] do_syscall_64+0x55/0x190 <4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 13.980789] RIP: 0033:0x7fb69c019839 <4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 1f f6 2c 00 f7 d8 64 89 01 48 <4>[ 13.980851] RSP: 002b:00007ffdc112e3a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 <4>[ 13.980875] RAX: ffffffffffffffda RBX: 000055c689fe0b30 RCX: 00007fb69c019839 <4>[ 13.980895] RDX: 0000000000000000 RSI: 000055c689a05d2e RDI: 0000000000000000 <4>[ 13.980916] RBP: 000055c689a05d2e R08: 0000000000000000 R09: 0000000000000000 <4>[ 13.980936] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 <4>[ 13.980957] R13: 000055c689fe0c60 R14: 0000000000040000 R15: 000055c689fe0b30 <4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers <4>[ 13.981027] CR2: 0000000000000048 Fixes: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color management code (v2)") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213161241.3461-1-chris@chris-wilson.co.uk
2018-12-13drm/vmwgfx: Protect from excessive execbuf kernel memory allocations v3Thomas Hellstrom
With the new validation code, a malicious user-space app could potentially submit command streams with enough buffer-object and resource references in them to have the resulting allocated validion nodes and relocations make the kernel run out of GFP_KERNEL memory. Protect from this by having the validation code reserve TTM graphics memory when allocating. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> --- v2: Removed leftover debug printouts
2018-12-13drm/i915/icl: Mind the SFC units when resetting VD or VEBox enginesOscar Mateo
SFC (Scaler & Format Converter) units are shared between VD and VEBoxes. They also happen to have separate reset bits. So, whenever we want to reset one or more of the media engines, we have to make sure the SFCs do not change owner in the process and, if this owner happens to be one of the engines being reset, we need to reset the SFC as well. This happens in 4 steps: 1) Tell the engine that a software reset is going to happen. The engine will then try to force lock the SFC (if currently locked, it will remain so; if currently unlocked, it will ignore this and all new lock requests). 2) Poll the ack bit to make sure the hardware has received the forced lock from the driver. Once this bit is set, it indicates SFC status (lock or unlock) will not change anymore (until we tell the engine it is safe to unlock again). 3) Check the usage bit to see if the SFC has ended up being locked to the engine we want to reset. If this is the case, we have to reset the SFC as well. 4) Unlock all the SFCs once the reset sequence is completed. Obviously, if we are resetting the whole GPU, we don't have to worry about all of this. BSpec: 10989 BSpec: 10990 BSpec: 10954 BSpec: 10955 BSpec: 10956 BSpec: 19212 Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-4-chris@chris-wilson.co.uk
2018-12-13drm/i915/icl: Record the valid VDBoxes with SFC capabilityOscar Mateo
In Gen11, only even numbered "logical" VDBoxes are hooked up to an SFC (Scaler & Format Converter) unit. We will use this information to decide when the SFC units need to be reset. BSpec: 20189 Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-3-chris@chris-wilson.co.uk
2018-12-13drm/i915/selftests: Verify we can perform resets from atomic contextChris Wilson
We currently require that our per-engine reset can be called from any context, even hardirq, and in the future wish to perform the device reset without holding struct_mutex (which requires some lockless shenanigans that demand the lowlevel intel_reset_gpu() be able to be used in atomic context). Test that we meet the current requirements by calling i915_reset_engine() from under various atomic contexts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-2-chris@chris-wilson.co.uk
2018-12-13drm/i915/selftests: Check we can recover a wedged deviceChris Wilson
After declaring a terminally wedged device, we allow ourselves to recover on the next GPU reset (manually triggered), or resume. Check that resetting a wedged device does work. v2: Add rpm (taken explicitly in the subtest in case we remove the outer wakeref) and early warning to i915_reset() for missed wakerefs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
2018-12-12drm/i915: merge gen checks to use rangeLucas De Marchi
Instead of using IS_GEN() for consecutive gen checks, let's pass the range to IS_GEN_RANGE(). By code inspection these were the ranges deemed necessary for spatch: @@ expression e; @@ ( - IS_GEN(e, 3) || IS_GEN(e, 2) + IS_GEN_RANGE(e, 2, 3) | - IS_GEN(e, 3) || IS_GEN(e, 4) + IS_GEN_RANGE(e, 3, 4) | - IS_GEN(e, 5) || IS_GEN(e, 6) + IS_GEN_RANGE(e, 5, 6) | - IS_GEN(e, 6) || IS_GEN(e, 7) + IS_GEN_RANGE(e, 6, 7) | - IS_GEN(e, 7) || IS_GEN(e, 8) + IS_GEN_RANGE(e, 7, 8) | - IS_GEN(e, 8) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 8, 9) | - IS_GEN(e, 10) || IS_GEN(e, 9) + IS_GEN_RANGE(e, 9, 10) | - IS_GEN(e, 9) || IS_GEN(e, 10) + IS_GEN_RANGE(e, 9, 10) ) After conversion, checking we don't have any missing IS_GEN_RANGE() || IS_GEN() was also done. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-3-lucas.demarchi@intel.com
2018-12-12drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-12drm/i915: Rename IS_GEN to IS_GEN_RANGELucas De Marchi
RANGE makes it longer, but clearer. We are also going to add a macro to check an individual gen, so add the _RANGE prefix here. Diff generated with: sed 's/IS_GEN(/IS_GEN_RANGE(/g' drivers/gpu/drm/i915/{*/,}*.{c,h} -i v2: use IS_GEN rather than GT_GEN Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-1-lucas.demarchi@intel.com
2018-12-13Merge tag 'drm-msm-next-2018-12-12' of ↵Dave Airlie
git://people.freedesktop.org/~robclark/linux into drm-next This time around, seeing some love for some older hw: - a2xx gpu support for apq8060 (hp touchpad) and imx5 (headless gpu-only mode) - a2xx gpummu support (a2xx was pre-iommu) - mdp4 display support for apq8060/touchpad For display/dpu: - a big pile of continuing dpu fixes and cleanups On the gpu side of things: - per-submit statistics and traceevents for better profiling - a6xx crashdump support - decouple get_iova() and page pinning.. so we can unpin from physical memory inactive bo's while using softpin to lower cpu overhead - new interface to set debug names on GEM BOs and debugfs output improvements - additional submit flag to indicate buffers that are used to dump (so $debugfs/rd cmdstream dumping is useful with softpin + state-objects) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvVvLPD9_Z4kyfGe98Y--byj6HbxHivEYSgF7Rq7=bFnw@mail.gmail.com
2018-12-13Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-nextDave Airlie
Mostly just initial support for Turing TU104/TU106 chipsets. Support for TU102 is missing as I don't yet have HW, but it should be trivial to add in later in the merge window (in theory). It's a bit of a rough first pass that'll get improved in future releases as a finish figuring out some of the other HW changes, but it's good enough as it stands for modesetting and suspend/resume etc. Acceleration bring-up is incomplete due to NVIDIA not yet having provided FW images for me to use, though command submission and copy engines are functional already. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7KmfcQqZcx+wh_1UKjTovp4PH_5UVMfeyxUu-M9WLZfw@mail.gmail.com
2018-12-13Merge tag 'drm/tegra/for-4.21-rc1' of ↵Dave Airlie
git://anongit.freedesktop.org/tegra/linux into drm-next drm/tegra: Changes for v4.21-rc1 These changes contain a couple of minor fixes for host1x and the Falcon library in Tegra DRM. There are also a couple of missing pieces that finally enable support for host1x, VIC and display on Tegra194. I've also added a patch that enables audio over HDMI using the SOR which has been tested, and works, on both Tegra186 and Tegra194. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207134712.32683-1-thierry.reding@gmail.com
2018-12-13Merge branch 'drm-next-4.21' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next [airlied: make etnaviv build again] amdgpu: - DC trace support - More DC documentation - XGMI hive reset support - Rework IH interaction with KFD - Misc fixes and cleanups - Powerplay updates for newer polaris variants - Add cursor plane update fast path - Enable gpu reset by default on CI parts - Fix config with KFD/HSA not enabled amdkfd: - Limit vram overcommit - dmabuf support - Support for doorbell BOs ttm: - Support for simultaneous submissions to multiple engines scheduler: - Add helpers for hw with preemption support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207233119.16861-1-alexander.deucher@amd.com
2018-12-13Merge branch 'mediatek-drm-fixes-4.20' of ↵Dave Airlie
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Single bridge attachment fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/1544407975.18825.3.camel@mtksdaap41
2018-12-13Merge branch 'linux-4.20' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Three fixes: tegra regression fix display flushing fix mst cleanup fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7WCPzjQZonk+eS1FgEUKirz-4LOrVpMUVMM=D-GjbVpg@mail.gmail.com
2018-12-13Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes Fixes for 4.20: - Stability fixes for new polaris variants (e.g., RX590) - New vega pci ids - Vega20 smu fix - Ctx locking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212203022.3054-1-alexander.deucher@amd.com
2018-12-13Merge tag 'drm-misc-fixes-2018-12-12' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes - rockchip: Revert change causing WARN on shutdown (Brian) Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181212204309.GA150523@art_vandelay
2018-12-13Merge tag 'drm-intel-fixes-2018-12-12-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Two fixes to avoid GPU hangs (on Braswell and Gen3) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212134010.GA18900@jlahtine-desk.ger.corp.intel.com
2018-12-13Merge tag 'drm-intel-fixes-2018-12-07' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix for system crash after GPU hang (Bugzilla #107945) - GVT fix for guest graphics corruption (https://github.com/intel/gvt-linux/issues/61) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181207104352.GA18214@jlahtine-desk.ger.corp.intel.com
2018-12-12drm/amd/display: Add fast path for cursor plane updatesNicholas Kazlauskas
[Why] Legacy cursor plane updates from drm helpers go through the full atomic codepath. A high volume of cursor updates through this slow code path can cause subsequent page-flips to skip vblank intervals since each individual update is slow. This problem is particularly noticeable for the compton compositor. [How] A fast path for cursor plane updates is added by using DRM asynchronous commit support provided by async_check and async_update. These don't do a full state/flip_done dependency stall and they don't block other commit work. However, DC still expects itself to be single-threaded for anything that can issue register writes. Screen corruption or hangs can occur if write sequences overlap. Every call that potentially perform register writes needs to be guarded for asynchronous updates to work. The dc_lock mutex was added for this. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106175 Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-12-12drm/i915: Don't forget to reset blocks when testing lower wm levelsMatt Roper
During DDB allocation, we try to distribute enough blocks for each plane to hit the highest watermark level; if that fails, we retry each lower level (which should require fewer blocks) until we find one that's possible (or until the whole commit is rejected as impossible). We need to reset our running block count when trying each lower level, otherwise all lower levels will fail as well. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d8e8749802 ("drm/i915: Switch to level-based DDB allocation algorithm (v5)") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212191720.3706-1-matthew.d.roper@intel.com
generated by cgit (git 2.34.1) at 2025-09-23 17:15:29 +0000