aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-10-24drm/hisilicon/hibmc: Use GEM VRAM's prepare_fb() and cleanup_fb() helpersThomas Zimmermann1-10/+4
This patch implements prepare_fb() and cleanup_fb() in hibmc with the GEM VRAM helpers. In the current code, pinning the BO is performed by hibmc_plane_atomic_update(), where the operation does not belong. This patch also fixes a bug where the pinned BO was never unpinned. Pinning multiple BOs would have exhaused the available VRAM and further pin operations would have failed, leaving the display in a corrupt state. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/bochs: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpersThomas Zimmermann1-24/+2
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb() of struct drm_simple_display_pipe_funcs. Switch over bochs. v2: * use helpers for struct drm_simple_display_pipe_funcs Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/vram-helpers: Add helpers for prepare_fb() and cleanup_fb()Thomas Zimmermann1-0/+126
The new helpers pin and unpin a framebuffer's GEM VRAM objects during plane updates. This should be sufficient for most drivers' implementation of prepare_fb() and cleanup_fb(). v2: * provide helpers for struct drm_simple_display_pipe_funcs * rename plane-helper funcs Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/i915/perf: Describe structure members in documentationAnna Karas1-1/+30
Add missing descriptions of i915_perf_stream structure members to documentation. Cc: Umesh Nerlige Ramappa <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Robert Bragg <[email protected]> Signed-off-by: Anna Karas <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/gpu: Add comment for memory barrierBhanusree1-2/+2
-Add comment for memory barrier -Issue found using checkpatch.pl Signed-off-by: Bhanusree <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/mediatek: remove cast to pointers passed to kfreeWambui Karuga1-2/+2
Remove unnecessary casts to pointer types passed to kfree. Issue detected by coccinelle: @@ type t1; expression *e; @@ -kfree((t1 *)e); +kfree(e); Signed-off-by: Wambui Karuga <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/simple-kms: Standardize arguments for callbacksDaniel Vetter4-7/+8
Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <[email protected]> (v1) Cc: Thomas Zimmermann <[email protected]> Cc: Noralf Trønnes <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Emil Velikov <[email protected]> Cc: [email protected] Cc: Linus Walleij <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/i915/gt: Split intel_ring_submissionChris Wilson30-455/+536
Split the legacy submission backend from the common CS ring buffer handling. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/i915: Convert PAT setup to uncore mmioTvrtko Ursulin1-39/+59
One more thing which relied on implicit dev_priv can be covnerted to use the new mmio accessors. Signed-off-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/i915/selftests: Flush any i915_active callback work as wellChris Wilson1-0/+1
Make trebly sure that all possible callbacks and their delayed brethren are complete before asserting that the i915_active should be idle after flushing all barriers. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24drm/i915/selftests: Flush interrupts before disabling taskletsChris Wilson2-2/+2
When setting up the system to perform the atomic reset, we need to serialise with any ongoing interrupt tasklet or else: <0> [472.951428] i915_sel-4442 0d..1 466527056us : __i915_request_submit: rcs0 fence 11659:2, current 0 <0> [472.951554] i915_sel-4442 0d..1 466527059us : __execlists_submission_tasklet: rcs0: queue_priority_hint:-2147483648, submit:yes <0> [472.951681] i915_sel-4442 0d..1 466527061us : trace_ports: rcs0: submit { 11659:2, 0:0 } <0> [472.951805] i915_sel-4442 0.... 466527114us : __igt_atomic_reset_engine: i915_reset_engine(rcs0:active) under hardirq <0> [472.951932] i915_sel-4442 0d... 466527115us : intel_engine_reset: rcs0 flags=11d <0> [472.952056] i915_sel-4442 0d... 466527117us : execlists_reset_prepare: rcs0: depth<-1 <0> [472.952179] i915_sel-4442 0d... 466527119us : intel_engine_stop_cs: rcs0 <0> [472.952305] <idle>-0 1..s1 466527119us : process_csb: rcs0 cs-irq head=3, tail=4 <0> [472.952431] i915_sel-4442 0d... 466527122us : __intel_gt_reset: engine_mask=1 <0> [472.952557] <idle>-0 1..s1 466527124us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 <0> [472.952683] <idle>-0 1..s1 466527130us : trace_ports: rcs0: promote { 11659:2*, 0:0 } <0> [472.952808] i915_sel-4442 0d... 466527131us : execlists_reset: rcs0 <0> [472.952933] i915_sel-4442 0d..1 466527133us : process_csb: rcs0 cs-irq head=3, tail=4 <0> [472.953059] i915_sel-4442 0d..1 466527134us : process_csb: rcs0 csb[4]: status=0x00000001:0x00000000 <0> [472.953185] i915_sel-4442 0d..1 466527136us : trace_ports: rcs0: preempted { 11659:2*, 0:0 } <0> [472.953310] i915_sel-4442 0d..1 466527150us : assert_pending_valid: Nothing pending for promotion! <0> [472.953436] i915_sel-4442 0d..1 466527158us : process_csb: process_csb:1930 GEM_BUG_ON(!assert_pending_valid(execlists, "promote")) We have the same CSB events being seen by process_csb() on two different processors. One being issued by the reset in the test, the other by the interrupt; this scenario is supposed to be prevented by flushing the interrupt tasklet with tasklet_disable() before we enter the atomic reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112069 Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-24dma-buf: stop using the dmabuf->lock so much v2Christian König1-16/+2
The attachment list is now protected by the dma_resv object. Stop holding the dma_buf->lock while calling ->attach/->detach, this allows for concurrent attach/detach operations. v2: cleanup commit message and locking in _debug_show() Signed-off-by: Christian König <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/336790
2019-10-24dma-buf: change DMA-buf locking convention v3Christian König1-17/+101
This patch is a stripped down version of the locking changes necessary to support dynamic DMA-buf handling. It adds a dynamic flag for both importers as well as exporters so that drivers can choose if they want the reservation object locked or unlocked during mapping of attachments. For compatibility between drivers we cache the DMA-buf mapping during attaching an importer as soon as exporter/importer disagree on the dynamic handling. Issues and solutions we considered: - We can't change all existing drivers, and existing improters have strong opinions about which locks they're holding while calling dma_buf_attachment_map/unmap. Exporters also have strong opinions about which locks they can acquire in their ->map/unmap callbacks, levaing no room for change. The solution to avoid this was to move the actual map/unmap out from this call, into the attach/detach callbacks, and cache the mapping. This works because drivers don't call attach/detach from deep within their code callchains (like deep in memory management code called from cs/execbuf ioctl), but directly from the fd2handle implementation. - The caching has some troubles on some soc drivers, which set other modes than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we can't re-create the mapping at _map time due to the above locking fun. We very carefuly step around that by only caching at attach time if the dynamic mode between importer/expoert mismatches. - There's been quite some discussion on dma-buf mappings which need active cache management, which would all break down when caching, plus we don't have explicit flush operations on the attachment side. The solution to this was to shrug and keep the current discrepancy between what the dma-buf docs claim and what implementations do, with the hope that the begin/end_cpu_access hooks are good enough and that all necessary flushing to keep device mappings consistent will be done there. v2: cleanup set_name merge, improve kerneldoc v3: update commit message, kerneldoc and cleanup _debug_show() Signed-off-by: Christian König <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/336788/
2019-10-23drm/i915/gvt: fix dead locking in early workload shadowZhenyu Wang1-2/+0
As early workload scan and shadow happens in execlist mmio handler, which has already taken vgpu_lock. So remove extra lock taking here. Fixes: 952f89f098c7 ("drm/i915/gvt: Wean off struct_mutex") Cc: Chris Wilson <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2019-10-23drm/i915/gt: Replace hangcheck by heartbeatsChris Wilson25-555/+379
Replace sampling the engine state every so often with a periodic heartbeat request to measure the health of an engine. This is coupled with the forced-preemption to allow long running requests to survive so long as they do not block other users. Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Jon Bloomfield <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/gem: Cancel contexts when hangchecking is disabledChris Wilson1-0/+141
Normally, we rely on our hangcheck to prevent persistent batches from hogging the GPU. However, if the user disables hangcheck, this mechanism breaks down. Despite our insistence that this is unsafe, the users are equally insistent that they want to use endless batches and will disable the hangcheck mechanism. We are looking at replacing hangcheck, in the next patch, with a softer mechanism, that sends a pulse down the engine to check if it is well. We can use the same preemptive pulse to flush an active context off the GPU upon context close, preventing resources being lost and unkillable requests remaining on the GPU after process termination. Testcase: igt/gem_ctx_exec/basic-nohangcheck Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: Jon Bloomfield <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/execlists: Cancel banned contexts on schedule-outChris Wilson2-41/+411
On schedule-out (CS completion) of a banned context, scrub the context image so that we do not replay the active payload. The intent is that we skip banned payloads on request submission so that the timeline advancement continues on in the background. However, if we are returning to a preempted request, i915_request_skip() is ineffective and instead we need to patch up the context image so that it continues from the start of the next request. v2: Fixup cancellation so that we only scrub the payload of the active request and do not short-circuit the breadcrumbs (which might cause other contexts to execute out of order). v3: Grammar pass Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/execlists: Force preemptionChris Wilson10-24/+255
If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging unresponsive contexts more frequently (i.e. instead of using an ~10s hangcheck, we now evict at ~100ms). The challenge of lies in picking a timeout that can be reasonably serviced by HW for typical workloads, balancing the existing clients against the needs for responsiveness. Note that coupled with timeslicing, this will lead to rapid GPU "hang" detection with multiple active contexts vying for GPU time. The forced preemption mechanism can be compiled out with ./scripts/config --set-val DRM_I915_PREEMPT_TIMEOUT 0 Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/gt: Try to more gracefully quiesce the system before resetsChris Wilson3-1/+34
If we are doing a normal GPU reset triggered after detecting a long period of stalled work, we can take our time and allow the engines to quiesce. Since we've stopped submission to the engine, and if we wait long enough an innocent context should complete, leaving the engine idle. So by waiting a short amount of time, we should prevent clobbering other users when resetting a stuck context. Suggested-by: Joonas Lahtinen <[email protected]> Suggested-by: Jon Bloomfield <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/guc: Update H2G enable logging action definitionRobert M. Fosha1-1/+1
GuC enable logging H2G action definition changed some time ago from 0xE000 to 0x40. All current GuC FW blobs use this definition, so fix the action definition in driver to match. Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Michal Wajdeczko <[email protected]> Signed-off-by: Robert M. Fosha <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/guc: Enable guc logging on guc log relay writeRobert M. Fosha3-17/+62
Creating and opening the GuC log relay file enables and starts the relay potentially before the caller is ready to consume logs. Change the behavior so that relay starts only on an explicit call to the write function (with a value of '1'). Other values flush the log relay as before. v2: Style changes and fix typos. Add guc_log_relay_stop() function. (Daniele) Cc: Matthew Brost <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Michal Wajdeczko <[email protected]> Signed-off-by: Robert M. Fosha <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915: Add new CNL PCH ID seen on a CML platformImre Deak2-0/+2
Atm we don't detect a PCH with PCI ID 0xA3C1 which showed up now on a CML platform. We don't have the official assignment of the PCH PCI IDs, but this looks like a CNP which was already used on CML platforms. Let's add the new ID->PCH type mapping accordingly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051 Reported-and-tested-by: Cyrus <[email protected]> Cc: Cyrus <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/tegra: Move drm_dp_link helpers to Tegra DRMThierry Reding6-128/+162
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. After all other drivers have been converted not to use these helpers anymore, move these helpers into the last remaining user: Tegra DRM. If at some point these helpers are deemed more widely useful, they can be moved out into the DRM DP helpers again. Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/rockchip: Avoid drm_dp_link helpersThierry Reding3-17/+17
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/msm: edp: Avoid drm_dp_link helpersThierry Reding1-21/+49
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/bridge: tc358767: Use DP nomenclatureThierry Reding1-1/+1
The DP specification uses the term "default framing" instead of "non- enhanced framing". Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/bridge: tc358767: Avoid drm_dp_link helpersThierry Reding1-22/+41
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v3: make link rate unsigned int to avoid overflow Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpersThierry Reding1-17/+39
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v4: use bulk DPCD writes if possible (Daniel Vetter) Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/dp: Add helper to get post-cursor adjustmentsThierry Reding1-0/+10
If the transmitter supports pre-emphasis post cursor2 the sink will request adjustments in a similar way to how it requests adjustments to the voltage swing and pre-emphasis settings. Add a helper to extract these adjustments on a per-lane basis from the DPCD link status. Reviewed-by: Philipp Zabel <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/dp: Do not busy-loop during link trainingThierry Reding1-12/+18
Use microsecond sleeps for the clock recovery and channel equalization delays during link training. The duration of these delays can be from 100 us up to 16 ms. It is rude to busy-loop for that amount of time. While at it, also convert to standard coding style by putting the opening braces in a function definition on a new line. Also switch to using an unsigned int for the AUX read interval to match the data type of the parameters to usleep_range(). v2: use correct multiplier for training delays (Philipp Zabel) v3: clarify data type change in commit message Signed-off-by: Thierry Reding <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/dp: Remove a gratuituous blank lineThierry Reding1-1/+0
It's idiomatic to check the return value of a function call immediately after the function call, without any blank lines in between, to make it more obvious that the two lines belong together. Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23Merge drm/drm-next into drm-misc-nextSean Paul644-15833/+23430
Parroting Daniel's backmerge justification from 2e79e22e092acd55da0b2db066e4826d7d152c41: Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Signed-off-by: Sean Paul <[email protected]>
2019-10-23Revert "drm/omap: add OMAP_BO flags to affect buffer allocation"Sean Paul1-52/+2
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679. This patch does not have an acceptable open source userspace implementation, and as such it does not meet the requirements for adding new UAPI. Discussion is in the Link. Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html Fixes: 23b482252836 ("drm/omap: add OMAP_BO flags to affect buffer allocation") Cc: Tomi Valkeinen <[email protected]> Cc: Jean-Jacques Hiblot <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Acked-by: Tomi Valkeinen <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/dsc: move crtc state dp_dsc_cfg member under dsc as configJani Nikula2-4/+4
DSC isn't DP specific, so remove the dp_ prefix from the crtc state member name. Also moving the member under the dsc sub-struct gives us enough context to allow shortening the name to just config. No functional changes. Cc: Manasi Navare <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/i915/dsc: rename crtc state dsc_params member to dscJani Nikula6-55/+55
Reduce verbosity in code by renaming dsc_params member of crtc state to simply dsc. There is enough context for this to be clear. No functional changes. Cc: Manasi Navare <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23Merge v5.4-rc4 into drm-nextDaniel Vetter307-4301/+2850
Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Some adjacent changes conflicts, plus some clashes in i915 due to cherry-picking and git trying to be helpful and leaving both versions in. Signed-off-by: Daniel Vetter <[email protected]>
2019-10-23drm/i915/selftests: Release ctx->engine_mutex after iterationChris Wilson1-3/+7
A lock once taken must be released again. Fixes: c31c9e82ee8a ("drm/i915/selftests: Teach switch_to_context() to use the context") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-23drm/doc: Drop misleading comment on drm_mode_config_cleanupDaniel Vetter1-2/+0
This is not something we'll fix, because failing to clean up stuff (or doing it in the wrong order) is a driver bug. The offending FIXME goes all the way back to the original modeset merge. We've added a WARN_ON in commit 2b677e8c08eed11e4ebe66a7c334f03e389a19a3 Author: Daniel Vetter <[email protected]> Date: Mon Dec 10 21:16:05 2012 +0100 drm: reference framebuffers which are on the idr including a comment blaming drivers on this. Right thing to do is most likely drm_atomic_helper_shutdown plus making sure that drm_mode_config_cleanup is not called too early (i.e. not in driver unload, but only in the final drm_device release callback). Cc: Mihail Atanassov <[email protected]> Reported-by: Mihail Atanassov <[email protected]> Reviewed-by: Mihail Atanassov <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/selftests: Synchronize checking active status with retirementChris Wilson1-0/+13
If retirement is running on another thread, we may inspect the status of the i915_active before its retirement callback is complete. As we expect it to be running synchronously, we can wait for any callback to complete by acquiring the i915_active.mutex. Signed-off-by: Chris Wilson <[email protected]> Acked-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/selftests: Move uncore fw selftests to operate on intel_gtChris Wilson1-26/+28
Forcewake is the speciality of the GT, so it is natural to run the intel_uncore_forcewake tests over the GT. So pass intel_gt as the parameter to our selftests. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/selftests: Teach switch_to_context() to use the contextChris Wilson1-10/+9
The context details which engines to use, so use the ctx->engines[] to generate the requests to cause the context switch. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915: Teach record_defaults to operate on the intel_gtChris Wilson4-15/+20
Again we wish to operate on the engines, which are owned by the intel_gt. As such it is easier, and much more consistent, to pass the intel_gt parameter. v2: Unexport i915_gem_load_power_context() Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/vc4: Use drm_hdmi_avi_infoframe_bars()Ville Syrjälä1-4/+1
Use the new drm_hdmi_avi_infoframe_bars() helper instead of hand rolling it. Cc: Eric Anholt <[email protected]> Cc: Boris Brezillon <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Boris Brezillon <[email protected]>
2019-10-22drm/edid: Add drm_hdmi_avi_infoframe_bars()Ville Syrjälä1-0/+17
Add a function to fill the AVI infoframe bar information from the standard tv margin properties. Cc: Eric Anholt <[email protected]> Cc: Boris Brezillon <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Boris Brezillon <[email protected]>
2019-10-22drm/i915/gem: Distinguish each object typeChris Wilson12-15/+28
Separate each object class into a separate lock type to avoid lockdep cross-contamination between paths (i.e. userptr!). Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/aml: Allow SPT PCH for all AML devicesJames Ausmus1-1/+2
Even the AML devices that behave like CFLs can be paired with an SPT PCH. Allow this to happen without blowing up dmesg. BSpec: 33665 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112013 Cc: Quanxian Wang <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: James Ausmus <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/mipi_dbi: Use simple right shift instead of double negationAndy Shevchenko1-1/+1
GCC complains about dubious bitwise OR operand: drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y CC [M] drivers/gpu/drm/drm_mipi_dbi.o As long as buffer is consist of byte (u8) values, we may use simple right shift and satisfy compiler. It also reduces amount of operations needed. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Tested-by: Noralf Trønnes <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915: Drop assertion that ce->pin_mutex guards state updatesChris Wilson4-24/+0
The actual conditions are that we know the GPU is not accessing the context, and we hold a pin on the context image to allow CPU access. We used a fake lock on ce->pin_mutex so that we could try and use lockdep to assert that access is serialised, but the various different hardirq/softirq contexts where we need to *fake* holding the pin_mutex are causing more trouble. Still it would be nice if we did have a way to reassure ourselves that the direct update to the context image is serialised with GPU execution. In the meantime, stop lockdep complaining about false irq inversions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111923 Signed-off-by: Chris Wilson <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/selftests: Make the mman object busy everywhereChris Wilson1-14/+14
Loop over all engines, issuing a request for the object on each in order to make sure we leave no stone unturned when creating an active ref. The purpose is to make sure that we can reap a zombie object (one that is only alive due to an active reference on the GPU) no matter where that active reference emanates from. Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-22drm/i915/selftests: Use for_each_uabi_engine in contex selftestsTvrtko Ursulin1-8/+4
Contexts are not testing physical engines so it makes sense to use the uabi iterator. Signed-off-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.