summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-09-15drm/i915: Nuke pointless variableVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Introduce intel_hpd_hotplug_irqs()Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-12-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Introduce HPD_PORT_TC<n>Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-11-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Move hpd_pin setup to encoder initVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-10-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Split icp_hpd_detection_setup() into ddi vs. tc partsVille Syrjälä
No reason to stuff both DDI and TC port handling into the same function. Split it into two. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-9-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Configure GEN11_{TBT,TC}_HOTPLUG_CTL for ports TC5/6Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-8-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Nuke the redundant TC/TBT HPD bit definesVille Syrjälä
We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke the overlapping defines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Add VBT AUX CH H and IVille Syrjälä
As with everything else VBT can now specify AUX CH H or I. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Add VBT DVO ports H and IVille Syrjälä
VBT has ports H and I since version 217. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-5-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Add AUX_CH_{H,I} power domain handlingVille Syrjälä
AUX CH H/I need their power domains too. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-4-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Add PORT_{H,I} to intel_port_to_power_domain()Ville Syrjälä
We need to go up to PORT_I (aka. TC6) these days. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Add more AUX CHs to the enumVille Syrjälä
We need to go up to AUX_CH_I (aka. AUX CH USBC6) these days. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnectedVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-15drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputsVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200909213824.12390-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Update DRIVER_DATE to 20200914Rodrigo Vivi
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-09-14drm/i915: Update DRIVER_DATE to 20200914Rodrigo Vivi
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-09-14Merge tag 'gvt-next-2020-09-10' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
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 <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910053720.GK28614@zhen-hp.sh.intel.com
2020-09-14drm/i915: Use fb->format->is_yuv for the g4x+ sprite RGB vs. YUV checkVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206201204.31704-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Fix g4x+ sprite dotclock limit for upscalingVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206201204.31704-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Nuke CACHE_MODE_0 save/restoreVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-4-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Nuke MI_ARB_STATE save/restoreVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Nuke the magic FBC_CONTROL save/restoreVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-14drm/i915: Kill unused savePCH_PORT_HOTPLUGVille Syrjälä
We don't save/restore PCH_PORT_HOTPLUG so no point in reseving space for the value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-11Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi
Sync drm-intel-gt-next here so we can have an unified fixes flow. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-09-11drm/i915: Nuke dpio_phy_iosf_port[]Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200907162709.29579-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-09-11drm/i915: move gmbus restore to i915_restore_displayJani Nikula
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-3-jani.nikula@intel.com
2020-09-11drm/i915: move gen4 GCDGMBUS save/restore to display save/restoreJani Nikula
Logically part of the display save/restore. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-2-jani.nikula@intel.com
2020-09-11drm/i915: disable all display features when no displayJani Nikula
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910095227.9466-1-jani.nikula@intel.com
2020-09-10drm/i915: Fix slightly botched merge in __reloc_entry_gpuMaarten Lankhorst
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 <maarten.lankhorst@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dave Airlie <airlied@redhat.com> [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 <joonas.lahtinen@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200910111225.2184193-1-maarten.lankhorst@linux.intel.com
2020-09-10drm/i915/gvt: Init vreg GUC_STATUS to GS_MIA_IN_RESETColin Xu
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 <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200819010900.54598-1-colin.xu@intel.com
2020-09-10drm/i915/gvt: Add F_CMD_ACCESS for some GEN9 SKU WA MMIO accessColin Xu
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 <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200819010801.53411-1-colin.xu@intel.com
2020-09-10drm/i915/gvt: remove F_CMD_ACCESS flag for some registersYan Zhao
some registers cannot be cmd accessible. remove them from the list Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Wang Zhi <zhi.a.wang@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811072720.3525-1-yan.y.zhao@intel.com
2020-09-10drm/i915/gvt: add/modify interfaces for flag F_CMD_ACCESSYan Zhao
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 <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811070233.3387-1-yan.y.zhao@intel.com
2020-09-10drm/i915/gvt: remove flag F_CMD_ACCESSEDYan Zhao
Flag F_CMD_ACCESSED is not used. just remove it. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811063744.3272-1-yan.y.zhao@intel.com
2020-09-10drm/i915/gvt: rename F_IN_CTX flag to F_SR_IN_CTXYan Zhao
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 <zhenyuw@linux.intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200811060944.3039-1-yan.y.zhao@intel.com
2020-09-09Merge tag 'topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1' of ↵Dave Airlie
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 <airlied@redhat.com> From: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/11e59ebdea7ee4f46803a21fe9b21443d2b9c401.camel@redhat.com
2020-09-09Merge tag 'drm-intel-gt-next-2020-09-07' of ↵Dave Airlie
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 <airlied@redhat.com> From: Joonas Lahtinen <jlahtine@jlahtine-mobl.ger.corp.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200907130039.GA27766@jlahtine-mobl.ger.corp.intel.com
2020-09-09Backmerge drm-fixes merge into drm-nextDave Airlie
Commit '6f6a73c8b715d595977774d48450a734297ab21f' from Linus' tree The fixes reverts cause a bit of a conflict pain with intel next, start fixing it up here. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-09-08Merge tag 'amd-drm-next-5.10-2020-09-03' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-next amd-drm-next-5.10-2020-09-03: amdgpu: - RAS fixes - Sienna Cichlid updates - Navy Flounder updates - DCE6 (SI) support in DC - Enable plane rotation - Rework pre-OS vram reservation handling during driver init - Add standard interface to dump GPU metrics table from SMU - Rework tiling and tmz state handling in atomic commits - Pstate fixes - Add voltage and power hwmon interfaces for renoir - SW CTF fixes - S/G display fix for Raven - Print client strings for vmfaults for vega and newer - Manual fan control fixes - Display updates - Reorg power management directory structure - Misc bug fixes - Misc code cleanups amdkfd: - Topology fixes - Add SMI events for thermal throttling and GPU resets radeon: - switch from pci_* to dma_* for dma allocations - PLL fix Scheduler: - Clean up priority levels UAPI: - amdgpu INFO IOCTL query update for TMZ state https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6049 - amdkfd SMI event interface updates https://github.com/RadeonOpenCompute/rocm_smi_lib/tree/therm_thrott From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200903222921.4152-1-alexander.deucher@amd.com
2020-09-08Revert "drm/i915/gem: Delete unused code"Dave Airlie
These commits caused a regression on Lenovo t520 sandybridge machine belonging to reporter. We are reverting them for 5.10 for other reasons, so just do it for 5.9 as well. This reverts commit 7ac2d2536dfa71c275a74813345779b1e7522c91. Reported-by: Harald Arnesen <harald@skogtun.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-09-08Revert "drm/i915/gem: Async GPU relocations only"Dave Airlie
These commits caused a regression on Lenovo t520 sandybridge machine belonging to reporter. We are reverting them for 5.10 for other reasons, so just do it for 5.9 as well. This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47. Reported-by: Harald Arnesen <harald@skogtun.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-09-08Revert "drm/i915: Remove i915_gem_object_get_dirty_page()"Dave Airlie
These commits caused a regression on Lenovo t520 sandybridge machine belonging to reporter. We are reverting them for 5.10 for other reasons, so just do it for 5.9 as well. This reverts commit 763fedd6a216f94c2eb98d2f7ca21be3d3806e69. Reported-by: Harald Arnesen <harald@skogtun.org> Signed-off-by: Dave Airlie <airied@redhat.com>
2020-09-08Merge tag 'drm-msm-fixes-2020-09-04' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes A few fixes for a potential RPTR corruption issue. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGvnr6Nhz2J0sjv2G+j7iceVtaDiJDT8T88uW6jiBfOGKQ@mail.gmail.com
2020-09-08Merge tag 'v5.9-rc4' into drm-nextDave Airlie
Backmerge 5.9-rc4 as there is a nasty qxl conflict that needs to be resolved. Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-09-07drm/i915: Unlock the shared hwsp_gtt object after pinningThomas Hellström
The hwsp_gtt object is used for sub-allocation and could therefore be shared by many contexts causing unnecessary contention during concurrent context pinning. However since we're currently locking it only for pinning, it remains resident until we unpin it, and therefore it's safe to drop the lock early, allowing for concurrent thread access. Signed-off-by: Thomas Hellström <thomas.hellstrom@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-09-07drm/i915: Filter wake_flags passed to default_wake_functionChris Wilson
(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 <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200728152144.1100-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [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 <joonas.lahtinen@linux.intel.com>
2020-09-07drm/i915: Remove i915_request.lock requirement for execution callbacksChris Wilson
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. Previous fix 1d9221e9d395 ("drm/i915: Skip signaling a signaled request") however did not correctly serialize request retirement with the execution callbacks. We were using the i915_request.lock to serialise adding an execution callback with __i915_request_submit. However, if we use an atomic llist_add to serialise multiple waiters and then check to see if the request is already executing, we can remove the irq-spinlock and fix serialization between retirement and execution callbacks in one go. v2: Avoid using the irq_work when outside of the irq-spinlocks, where we can execute the callbacks immediately. v3: Pay close attention to the order of setting ACTIVE on retirement, we need to ensure the request is signaled and breadcrumbs detached before we finish removing the request from the engine. v4: Expanded commit message. Fixes: 1d9221e9d395 ("drm/i915: Skip signaling a signaled request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716142207.13003-2-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Joonas: Rebased and reordered into drm-intel-gt-next branch] [Joonas: Added expanded commit message from Tvrtko and Chris] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-09-07drm/i915: Be wary of data races when reading the active execlistsChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200716142207.13003-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Joonas: Rebased and reordered into drm-intel-gt-next branch] [Joonas: Added expanded commit message from Tvrtko and Chris] Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-09-07drm/i915: Add ww locking to pin_to_display_plane, v2.Maarten Lankhorst
Use ww locking for pin_to_display_plane for all the pinning and locking. With the locking removed from set_cache_level, we need to fix i915_gem_set_caching_ioctl to take the object reservation lock. As this is a single lock, we don't need to use the ww dance. Changes since v1: - Do not use ww locking in i915_gem_set_caching_ioctl (Thomas). Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200819140904.1708856-24-maarten.lankhorst@linux.intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-09-07drm/i915: Add ww locking to vm_fault_gttMaarten Lankhorst
We want to start requiring the reservation_lock instead of obj->mm.lock for pinning objects, take the ww lock inside vm_fault_gtt as a first step towards the legacy lock removal. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200819140904.1708856-23-maarten.lankhorst@linux.intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-15 23:07:57 +0000