aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2020-09-16drm/i915: Initialise outparam for error return from wait_for_registerChris Wilson1-1/+2
Just in case the caller passes in 0 for both slow&fast timeouts, make sure we initialise the stack value returned. Add an assert so that we don't make the mistake of passing 0 timeouts for the wait. drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'. References: 3f649ab728cd ("treewide: Remove uninitialized_var() usage") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-16drm/i915: Filter wake_flags passed to default_wake_functionChris Wilson1-3/+7
(NOTE: This is the minimal backportable fix, a full fix is being developed at https://patchwork.freedesktop.org/patch/388048/) The flags passed to the wait_entry.func are passed onwards to try_to_wake_up(), which has a very particular interpretation for its wake_flags. In particular, beyond the published WF_SYNC, it has a few internal flags as well. Since we passed the fence->error down the chain via the flags argument, these ended up in the default_wake_function confusing the kernel/sched. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2110 Fixes: ef4688497512 ("drm/i915: Propagate fence errors") Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Cc: <[email protected]> # v5.4+ Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> [Joonas: Rebased and reordered into drm-intel-gt-next branch] [Joonas: Added a note and link about more complete fix] Signed-off-by: Joonas Lahtinen <[email protected]> (cherry picked from commit f4b3c395540aa3d4f5a6275c5bdd83ab89034806) Signed-off-by: Jani Nikula <[email protected]>
2020-09-16drm/i915: Be wary of data races when reading the active execlistsChris Wilson2-6/+34
To implement preempt-to-busy (and so efficient timeslicing and best utilization of the hardware submission ports) we let the GPU run asynchronously in respect to the ELSP submission queue. This created challenges in keeping and accessing the driver state mirroring the asynchronous GPU execution. The latest occurence of this was spotted by KCSAN: [ 1413.563200] BUG: KCSAN: data-race in __await_execution+0x217/0x370 [i915] [ 1413.563221] [ 1413.563236] race at unknown origin, with read to 0xffff88885bb6c478 of 8 bytes by task 9654 on cpu 1: [ 1413.563548] __await_execution+0x217/0x370 [i915] [ 1413.563891] i915_request_await_dma_fence+0x4eb/0x6a0 [i915] [ 1413.564235] i915_request_await_object+0x421/0x490 [i915] [ 1413.564577] i915_gem_do_execbuffer+0x29b7/0x3c40 [i915] [ 1413.564967] i915_gem_execbuffer2_ioctl+0x22f/0x5c0 [i915] [ 1413.564998] drm_ioctl_kernel+0x156/0x1b0 [ 1413.565022] drm_ioctl+0x2ff/0x480 [ 1413.565046] __x64_sys_ioctl+0x87/0xd0 [ 1413.565069] do_syscall_64+0x4d/0x80 [ 1413.565094] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To complicate matters, we have to both avoid the read tearing of *active and avoid any write tearing as perform the pending[] -> inflight[] promotion of the execlists. This is because we cannot rely on the memcpy doing u64 aligned copies on all kernels/platforms and so we opt to open-code it with explicit WRITE_ONCE annotations to satisfy KCSAN. v2: When in doubt, write the same comment again. v3: Expanded commit message. Fixes: b55230e5e800 ("drm/i915: Check for awaits on still currently executing requests") 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] Signed-off-by: Rodrigo Vivi <[email protected]> [Joonas: Rebased and reordered into drm-intel-gt-next branch] [Joonas: Added expanded commit message from Tvrtko and Chris] Signed-off-by: Joonas Lahtinen <[email protected]> (cherry picked from commit b4d9145b0154f8c71dafc2db5fd445f1f3db9426) Signed-off-by: Jani Nikula <[email protected]>
2020-09-16drm/i915/gem: Reduce context termination list iteration guard to RCUChris Wilson1-13/+19
As we now protect the timeline list using RCU, we can drop the timeline->mutex for guarding the list iteration during context close, as we are searching for an inflight request. Any new request will see the context is banned and not be submitted. In doing so, pull the checks for a concurrent submission of the request (notably the i915_request_completed()) under the engine spinlock, to fully serialise with __i915_request_submit()). That is in the case of preempt-to-busy where the request may be completed during the __i915_request_submit(), we need to be careful that we sample the request status after serialising so that we don't miss the request the engine is actually submitting. Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()") References: d22d2d073ef8 ("drm/i915: Protect i915_request_await_start from early waits") # rcu protection of timeline->requests References: https://gitlab.freedesktop.org/drm/intel/-/issues/1622 References: https://gitlab.freedesktop.org/drm/intel/-/issues/2158 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> (cherry picked from commit 736e785f9b28cd9ef2d16a80960a04fd00e64b22) Signed-off-by: Jani Nikula <[email protected]>
2020-09-16drm/i915/gem: Delay tracking the GEM context until it is registeredChris Wilson1-5/+11
Avoid exposing a partially constructed context by deferring the list_add() from the initial construction to the end of registration. Otherwise, if we peek into the list of contexts from inside debugfs, we may see the partially constructed context and chase down some dangling incomplete pointers. Reported-by: CQ Tang <[email protected]> Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace") References: f6e8aa387171 ("drm/i915: Report the number of closed vma held by each context in debugfs") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: CQ Tang <[email protected]> Cc: <[email protected]> # v5.2+ Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Joonas Lahtinen <[email protected]> (cherry picked from commit eb4dedae920a07c485328af3da2202ec5184fb17) Signed-off-by: Jani Nikula <[email protected]>
2020-09-15drm/i915/pll: Centralize PLL_ENABLE register lookupAnusha Srivatsa1-17/+18
We currenty check for platform at multiple parts in the driver to grab the correct PLL. Let us begin to centralize it through a helper function. v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville) v3: Clean up combo_pll_disable() (Rodrigo) v4: s/dev_priv/i915 (Jani) Move static and return type to the same line( Ville, Jani) Suggested-by: Matt Roper <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2020-09-15drm: add constant N value in helper fileChandan Uddaraju1-1/+1
The constant N value (0x8000) is used by i915 DP driver. Define this value in dp helper header file to use in multiple Display Port drivers. Change i915 driver accordingly. Change in v6: Change commit message Signed-off-by: Chandan Uddaraju <[email protected]> Signed-off-by: Vara Reddy <[email protected]> Signed-off-by: Tanmay Shah <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2020-09-15drm/i915: Nuke pointless variableVille Syrjälä1-2/+1
No point in assigning the function return value to a local variable if we're just going to use it the one time. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Introduce intel_hpd_hotplug_irqs()Ville Syrjälä1-27/+23
Introduce intel_hpd_hotplug_irqs() as a partner to intel_hpd_enabled_irqs(). There's no need to care about the encoders which we're not exposing, so we can avoid hardcoding the masks in various places. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Introduce HPD_PORT_TC<n>Ville Syrjälä4-126/+102
Make a clean split between hpd pins for DDI vs. TC. This matches how the actual hardware is split. And with this we move the DDI/PHY->HPD pin mapping into the encoder init instead of having to remap yet again in the interrupt code. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Move hpd_pin setup to encoder initVille Syrjälä3-2/+3
Currently DP/HDMI/DDI encoders init their hpd_pin from the connector init. Let's move it to the encoder init so that we don't need to add platform specific junk to the connector init (which is shared by all g4x+ platforms). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Split icp_hpd_detection_setup() into ddi vs. tc partsVille Syrjälä1-21/+27
No reason to stuff both DDI and TC port handling into the same function. Split it into two. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Configure GEN11_{TBT,TC}_HOTPLUG_CTL for ports TC5/6Ville Syrjälä1-2/+6
gen11_hpd_detection_setup() is missing ports TC5/6. Add them. TODO: Might be nice to only enable the hpd detection logic for ports we actually have. Should be rolled out for all platforms if/when done... Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Nuke the redundant TC/TBT HPD bit definesVille Syrjälä2-34/+22
We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke the overlapping defines. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Add VBT AUX CH H and IVille Syrjälä2-0/+8
As with everything else VBT can now specify AUX CH H or I. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Add VBT DVO ports H and IVille Syrjälä2-2/+8
VBT has ports H and I since version 217. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Add AUX_CH_{H,I} power domain handlingVille Syrjälä1-0/+8
AUX CH H/I need their power domains too. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Add PORT_{H,I} to intel_port_to_power_domain()Ville Syrjälä1-0/+4
We need to go up to PORT_I (aka. TC6) these days. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Add more AUX CHs to the enumVille Syrjälä1-0/+2
We need to go up to AUX_CH_I (aka. AUX CH USBC6) these days. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnectedVille Syrjälä13-9/+44
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED return false we have to be capable of shutting it down cleanly so as to not anger the hw. To that end let's reduce the effect of !INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected. Should prevent anyone from automagically enabling any of them, while still allowing us to cleanly shut them down. v2: Put the check into the right place for CRT Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputsVille Syrjälä5-10/+9
Having a mode where the display hardware is present but we try to pretend it isn't just leads to massive headaches when trying to reason what the fallout might be from skipping some random bits of programming. Let's just neuter INTEL_DISPLAY_ENABLED so that we treat the hardware as fully present, except we just don't register any outputs. That's still rather sketchy if the outputs are already enabled when the driver is loaded. I think the simplest solution would be to probe everything as normal and just return disconnected" from all .detect() hooks. That would avoid anything automagically enabling those outputs, but the driver could then shut things down using the normal codepaths. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() callVille Syrjälä1-7/+0
We update the timestamping constants per-crtc explicitly in intel_crtc_update_active_timings(). Furtermore the helper will use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus let's drop the helper call an rely on what we already have in intel_crtc_update_active_timings(). We can now also drop the hw.adjusted_mode -> uapi.adjusted_mode copy hack that was added to keep the helper from deriving the timestamping constants from the wrong thing. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2020-09-14drm/atomic-helper: Remove the timestamping constant update from ↵Ville Syrjälä1-0/+1
drm_atomic_helper_update_legacy_modeset_state() The timestamping constants have nothing to do with any legacy state so should not be updated from drm_atomic_helper_update_legacy_modeset_state(). Let's make everyone call drm_atomic_helper_calc_timestamping_constants() directly instead of relying on drm_atomic_helper_update_legacy_modeset_state() to call it. @@ expression S; @@ - drm_atomic_helper_calc_timestamping_constants(S); @@ expression D, S; @@ drm_atomic_helper_update_legacy_modeset_state(D, S); + drm_atomic_helper_calc_timestamping_constants(S); v2: Update drm_crtc_vblank_helper_get_vblank_timestamp{,_internal}() docs (Daniel) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2020-09-14drm/i915: Update DRIVER_DATE to 20200914Rodrigo Vivi1-1/+1
Signed-off-by: Rodrigo Vivi <[email protected]>
2020-09-14drm/i915: Update DRIVER_DATE to 20200914Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <[email protected]>
2020-09-14Merge tag 'gvt-next-2020-09-10' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi5-38/+49
drm-intel-next-queued gvt-next-2020-09-10 - Cleanup command access flag (Yan) - New workaround cmd access fix (Colin) - MIA reset state fix (Colin) Signed-off-by: Rodrigo Vivi <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-14Merge v5.9-rc5 into drm-nextDaniel Vetter1-6/+4
Paul needs 1a21e5b930e8 ("drm/ingenic: Fix leak of device_node pointer") and 3b5b005ef7d9 ("drm/ingenic: Fix driver not probing when IPU port is missing") from -fixes to be able to merge further ingenic patches into -next. Signed-off-by: Daniel Vetter <[email protected]>
2020-09-14drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV checkVille Syrjälä1-2/+2
g4x+ sprites have an extra cdclk limitation listed for RGB formats. For some random reason I chose to use cpp>=4 as the check for that. While that does actually work let's deobfuscate it by checking for !is_yuv instead. I suspect is_yuv didn't exist way back when I originally write the code. Also drop the duplicate comment. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Fix g4x+ sprite dotclock limit for upscalingVille Syrjälä1-2/+1
Even if we're not doing downscaling we should account for some of the extra dotclock limitations for g4x+ sprites. In particular we must never exceed the 90% rule, and with RGB that limits actually drops to 80%. So instead of bailing out when upscaling let's clamp the scaling factor appropriately and go through the rest of calculation normally. By luck we already did the full calculations for the 1:1 case. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Nuke CACHE_MODE_0 save/restoreVille Syrjälä2-10/+0
The CACHE_MODE_0 save/restore was added without explanation in commit 1f84e550a870 ("drm/i915 more registers for S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)"). If there are any bits we care about those should be set explicitly during some appropriate init function. Let's assume it's all good and just nuke this magic save/restore. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Nuke MI_ARB_STATE save/restoreVille Syrjälä2-7/+0
Originally added in commit 1f84e550a870 ("drm/i915 more registers for S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)") to fix some underruns. I suspect that was due to the trickle feed settings getting clobbered during suspend. We've been disabling trickle feed explicitly since commit 20f949670f51 ("drm/i915: Disable trickle feed via MI_ARB_STATE for the gen4") so this magic save/restore should no longer be needed. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Nuke the magic FBC_CONTROL save/restoreVille Syrjälä2-9/+0
The FBC_CONTROL save restore is there just to preserve the compression interval setting. Since commit a68ce21ba0c4 ("drm/i915/fbc: Store the fbc1 compression interval in the params") we've been explicitly setting the interval to a specific value, so the sace/restore is now entirely pointless. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-14drm/i915: Kill unused savePCH_PORT_HOTPLUGVille Syrjälä1-1/+0
We don't save/restore PCH_PORT_HOTPLUG so no point in reseving space for the value. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-14drm/i915/gvt: Fix port number for BDW on EDID region setupZhenyu Wang1-1/+5
Current BDW virtual display port is initialized as PORT_B, so need to use same port for VFIO EDID region, otherwise invalid EDID blob pointer is assigned which caused kernel null pointer reference. We might evaluate actual display hotplug for BDW to make this function work as expected, anyway this is always required to be fixed first. Reported-by: Alejandro Sior <[email protected]> Cc: Alejandro Sior <[email protected]> Fixes: 0178f4ce3c3b ("drm/i915/gvt: Enable vfio edid for all GVT supported platform") Reviewed-by: Hang Yuan <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi109-2330/+3855
Sync drm-intel-gt-next here so we can have an unified fixes flow. Signed-off-by: Rodrigo Vivi <[email protected]>
2020-09-11drm/i915: Nuke dpio_phy_iosf_port[]Ville Syrjälä5-23/+14
There's no real reason to stash away the DPIO PHY IOSF sideband port numbers for VLV/CHV. Just compute them at runtime in the sideband code. Gets rid of the oddball intel_init_dpio() function from the high level init flow. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2020-09-11drm/i915: move gmbus restore to i915_restore_displayJani Nikula1-2/+2
Logically part of the display restore. Note: This has been in place since the introduction of gmbus support. The gmbus code also does the resets before transfers. Is this really needed, or a historical accident? Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11drm/i915: move gen4 GCDGMBUS save/restore to display save/restoreJani Nikula1-9/+12
Logically part of the display save/restore. No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11drm/i915: disable all display features when no displayJani Nikula1-0/+8
Disable all display feature flags when there are no pipes i.e. there is no display. This should help with not having to additionally check for HAS_DISPLAY() when a feature flag check would suffice. Also disable modeset and atomic driver features. Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-11Merge tag 'drm-intel-fixes-2020-09-10' of ↵Dave Airlie1-6/+4
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.9-rc5: - Fix regression leading to audio probe failure Signed-off-by: Dave Airlie <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915: Fix slightly botched merge in __reloc_entry_gpuMaarten Lankhorst1-2/+2
This function should be an int, not a bool. Presumably because we had the same 2 reverts in a slightly different way, git got confused. Thanks to Dan for reporting. :) The conflict is between the 3 reverts in drm-fixes: 4993a8a37808 ("Revert "drm/i915: Remove i915_gem_object_get_dirty_page()"") ad5d95e4d538 ("Revert "drm/i915/gem: Async GPU relocations only"") 20561da3a2e1 ("Revert "drm/i915/gem: Delete unused code"") And the slightly different combined revert in drm-intel-gt-next, but with the same goal: 102a0a9051f4 ("Revert "drm/i915/gem: Async GPU relocations only"") In the merge commit 1f4b2aca794f ("Merge tag 'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") things went wrong, but the merge commit view now doesn't show any conflict anymore (as git tends to do when the resolution picks one or the other branch). The need to handle other than just true/false error codes in __reloc_entry_gpu was added in the dma_resv locking changes in c43ce12328df ("drm/i915: Use per object locking in execbuf, v12.") Signed-off-by: Maarten Lankhorst <[email protected]> Reported-by: Dan Carpenter <[email protected]> Cc: Dave Airlie <[email protected]> [danvet: Explain this entire saga a lot better, adding tons of commit references. Also note that this was merged before full intel-gfx-CI results, only after BAT, since the breakage at the BAT run is already severe enough to block all pre-merge testing.] Fixes: 1f4b2aca794f ("Merge tag 'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") Acked-by: Joonas Lahtinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm: i915: fix common struct sg_table related issuesMarek Szyprowski2-12/+6
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. This driver creatively uses sg_table->orig_nents to store the size of the allocated scatterlist and ignores the number of the entries returned by dma_map_sg function. The sg_table->orig_nents is (mis)used to properly free the (over)allocated scatterlist. This patch only introduces the common DMA-mapping wrappers operating directly on the struct sg_table objects to the dmabuf related functions, so the other drivers, which might share buffers with i915 could rely on the properly set nents and orig_nents values. Signed-off-by: Marek Szyprowski <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]>
2020-09-10drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESETColin Xu1-0/+3
Although GVT doesn't support guest GuC, MIA core is still expected to be GS_MIA_IN_RESET after uc HW reset. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915/gvt: Add F_CMD_ACCESS for some GEN9 SKU WA MMIO accessColin Xu1-2/+2
Without F_CMD_ACCESS, guest LRI cmd will fail due to "access to non-render register" when init below WAs: WaDisableDynamicCreditSharing: GAMT_CHKN_BIT_REG WaCompressedResourceSamplerPbeMediaNewHashMode: MMCD_MISC_CTRL So add F_CMD_ACCESS to the two MMIO. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915/gvt: remove F_CMD_ACCESS flag for some registersYan Zhao1-12/+16
some registers cannot be cmd accessible. remove them from the list Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Wang Zhi <[email protected]> Signed-off-by: Yan Zhao <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESSYan Zhao2-3/+18
flag F_CMD_ACCESS represents whether an MMIO is able to be accessed by GPU commands. In this patch, 1. add interface to set this flag 2. rename intel_gvt_mmio_is_cmd_access() to intel_gvt_mmio_is_cmd_accessible() and update its description message. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Yan Zhao <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915/gvt: remove flag F_CMD_ACCESSEDYan Zhao2-16/+0
Flag F_CMD_ACCESSED is not used. just remove it. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Yan Zhao <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-10drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTXYan Zhao3-11/+16
F_IN_CTX is an inaccurate flag name, because people may wrongly think all MMIOs in context image are with this flag. But actually, this flag is only for MMIOs both in GVT's save-restore list and in hardare logical context's image. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Yan Zhao <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-09Merge tag 'topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1' of ↵Dave Airlie3-103/+24
git://anongit.freedesktop.org/drm/drm-misc into drm-next UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau Signed-off-by: Dave Airlie <[email protected]> From: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-09Merge tag 'drm-intel-gt-next-2020-09-07' of ↵Dave Airlie82-2178/+3434
git://anongit.freedesktop.org/drm/drm-intel into drm-next (Same content as drm-intel-gt-next-2020-09-04-3, S-o-b's added) UAPI Changes: (- Potential implicit changes from WW locking refactoring) Cross-subsystem Changes: (- WW locking changes should align the i915 locking more with others) Driver Changes: - MAJOR: Apply WW locking across the driver (Maarten) - Reverts for 5 commits to make applying WW locking faster (Maarten) - Disable preparser around invalidations on Tigerlake for non-RCS engines (Chris) - Add missing dma_fence_put() for error case of syncobj timeline (Chris) - Parse command buffer earlier in eb_relocate(slow) to facilitate backoff (Maarten) - Pin engine before pinning all objects (Maarten) - Rework intel_context pinning to do everything outside of pin_mutex (Maarten) - Avoid tracking GEM context until registered (Cc: stable, Chris) - Provide a fastpath for waiting on vma bindings (Chris) - Fixes to preempt-to-busy mechanism (Chris) - Distinguish the virtual breadcrumbs from the irq breadcrumbs (Chris) - Switch to object allocations for page directories (Chris) - Hold context/request reference while breadcrumbs are active (Chris) - Make sure execbuffer always passes ww state to i915_vma_pin (Maarten) - Code refactoring to facilitate use of WW locking (Maarten) - Locking refactoring to use more granular locking (Maarten, Chris) - Support for multiple pinned timelines per engine (Chris) - Move complication of I915_GEM_THROTTLE to the ioctl from general code (Chris) - Make active tracking/vma page-directory stash work preallocated (Chris) - Avoid flushing submission tasklet too often (Chris) - Reduce context termination list iteration guard to RCU (Chris) - Reductions to locking contention (Chris) - Fixes for issues found by CI (Chris) Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.