summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2023-01-31drm/i915/lvds: s/dev_priv/i915/Ville Syrjälä
Do the customary s/dev_priv/i915/ rename and aliasing 'dev' pointer removal. Though various register definitions still depend on the magic 'dev_priv' variable so not a 100% conversion. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Fix whitespaceVille Syrjälä
Replace some stray spaces with tabs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Extract intel_lvds_regs.hVille Syrjälä
Extract the integrated LVDS port register definitions into their own header file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Use REG_BIT() & co.Ville Syrjälä
Use REG_BIT() & co. for the LVDS port register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Use intel_de_rmw()Ville Syrjälä
Replace the hand rolled rmw stuff with intel_de_rmw(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Split long linesVille Syrjälä
Split some overly long lines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915: Implement workaround for CDCLK PLL disable/enableStanislav Lisovskiy
It was reported that we might get a hung and loss of register access in some cases when CDCLK PLL is disabled and then enabled, while squashing is enabled. As a workaround it was proposed by HW team that SW should disable squashing when CDCLK PLL is being reenabled. v2: - Added WA number comment(Rodrigo Vivi) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130135836.12738-1-stanislav.lisovskiy@intel.com
2023-01-31drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock > 340MHzAnkit Nautiyal
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate is capped to 340MHz via VBT. In such cases scrambling might be supported by the platform and an HDMI2.0 sink for lower TMDS rates, but not supported by the retimer, causing blankouts. So avoid enabling scrambling, if the TMDS clock is capped to <= 340MHz. v2: Added comment, documenting the rationale to check for TMDS clock, before going for scrambling. (Arun) v3: Fixed the function name to check if source supports scrambling. (Jani) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221222040851.3029514-1-ankit.k.nautiyal@intel.com
2023-01-30drm/nouveau/acr/gm20b: regression fixesBen Skeggs
Missed some Tegra-specific quirks when reworking ACR to support Ampere. Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130223715.1831509-3-bskeggs@redhat.com
2023-01-30drm/nouveau/fb/tu102-: fix register used to determine scrub statusBen Skeggs
Turing apparently needs to use the same register we use on Ampere. Not executing the scrubber ucode when required would result in large areas of VRAM being inaccessible to the driver. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130223715.1831509-2-bskeggs@redhat.com
2023-01-30drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETEDBen Skeggs
Starting from Turing, the driver is no longer responsible for initiating DEVINIT when required as the GPU started loading a FW image from ROM and executing DEVINIT itself after power-on. However - we apparently still need to wait for it to complete. This should correct some issues with runpm on some systems, where we get control of the HW before it's been fully reinitialised after resume from suspend. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130223715.1831509-1-bskeggs@redhat.com
2023-01-30drm/i915/adlp: Fix typo for reference clockChaitanya Kumar Borah
Fix typo for reference clock from 24400 to 24000. Bspec: 55409 Fixes: 626426ff9ce4 ("drm/i915/adl_p: Add cdclk support for ADL-P") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230112094131.550252-1-chaitanya.kumar.borah@intel.com (cherry picked from commit 2b6f7e39ccae065abfbe3b6e562ec95ccad09f1e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915: Fix potential bit_17 double-freeRob Clark
A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. Signed-off-by: Rob Clark <robdclark@chromium.org> Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Cc: <stable@vger.kernel.org> # v5.5+ [tursulin: Correct fixes tag and added cc stable.] Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127200550.3531984-1-robdclark@gmail.com (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915: Fix up locking around dumping requests listsJohn Harrison
The debugfs dump of requests was confused about what state requires the execlist lock versus the GuC lock. There was also a bunch of duplicated messy code between it and the error capture code. So refactor the hung request search into a re-usable function. And reduce the span of the execlist state lock to only the execlist specific code paths. In order to do that, also move the report of hold count (which is an execlist only concept) from the top level dump function to the lower level execlist specific function. Also, move the execlist specific code into the execlist source file. v2: Rename some functions and move to more appropriate files (Daniele). v3: Rename new execlist dump function (Daniele) Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-4-John.C.Harrison@Intel.com (cherry picked from commit a4be3dca53172d9d2091e4b474fb795c81ed3d6c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915: Fix request ref counting during error capture & debugfs dumpJohn Harrison
When GuC support was added to error capture, the reference counting around the request object was broken. Fix it up. The context based search manages the spinlocking around the search internally. So it needs to grab the reference count internally as well. The execlist only request based search relies on external locking, so it needs an external reference count but within the spinlock not outside it. The only other caller of the context based search is the code for dumping engine state to debugfs. That code wasn't previously getting an explicit reference at all as it does everything while holding the execlist specific spinlock. So, that needs updaing as well as that spinlock doesn't help when using GuC submission. Rather than trying to conditionally get/put depending on submission model, just change it to always do the get/put. v2: Explicitly document adding an extra blank line in some dense code (Andy Shevchenko). Fix multiple potential null pointer derefs in case of no request found (some spotted by Tvrtko, but there was more!). Also fix a leaked request in case of !started and another in __guc_reset_context now that intel_context_find_active_request is actually reference counting the returned request. v3: Add a _get suffix to intel_context_find_active_request now that it grabs a reference (Daniele). v4: Split the intel_guc_find_hung_context change to a separate patch and rename intel_context_find_active_request_get to intel_context_get_active_request (Tvrtko). v5: s/locking/reference counting/ in commit message (Tvrtko) Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-3-John.C.Harrison@Intel.com (cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915/guc: Fix locking when searching for a hung requestJohn Harrison
intel_guc_find_hung_context() was not acquiring the correct spinlock before searching the request list. So fix that up. While at it, add some extra whitespace padding for readability. Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-2-John.C.Harrison@Intel.com (cherry picked from commit d1c3717501bcf56536e8b8c1bdaf5cd5357f6bb2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915: Avoid potential vm use-after-freeRob Clark
Adding the vm to the vm_xa table makes it visible to userspace, which could try to race with us to close the vm. So we need to take our extra reference before putting it in the table. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm") Cc: <stable@vger.kernel.org> # v5.16+ Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230119173321.2825472-1-robdclark@gmail.com (cherry picked from commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-01-30drm/i915/dg1: Drop final use of IS_DG1_GRAPHICS_STEPMatt Roper
All production DG1 hardware has graphics stepping B0; there is no such thing as C0. As such, we can simplify IS_DG1_GRAPHICS_STEP(uncore->i915, STEP_A0, STEP_C0) to just match DG1 in general. Bspec: 44463 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-4-matthew.d.roper@intel.com
2023-01-30drm/i915/dg1: Drop support for pre-production steppingsMatt Roper
Several post-DG1 platforms have been brought up now, so we're well past the point where we usually drop the workarounds that are only applicable to internal/pre-production hardware. Production DG1 hardware always has a B0 stepping for both display and GT. Bspec: 44463 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-3-matthew.d.roper@intel.com
2023-01-30drm/i915/tgl: Drop support for pre-production steppingsMatt Roper
Several post-TGL platforms have been brought up now, so we're well past the point where we usually drop the workarounds that are only applicable to internal/pre-production hardware. Production TGL hardware always has display stepping C0 or later and GT stepping B0 or later (this is true for both the original TGL and the U/Y subplatform). Bspec 44455 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-2-matthew.d.roper@intel.com
2023-01-30vfio-mdev: add back CONFIG_VFIO dependencyArnd Bergmann
CONFIG_VFIO_MDEV cannot be selected when VFIO itself is disabled, otherwise we get a link failure: WARNING: unmet direct dependencies detected for VFIO_MDEV Depends on [n]: VFIO [=n] Selected by [y]: - SAMPLE_VFIO_MDEV_MTTY [=y] && SAMPLES [=y] - SAMPLE_VFIO_MDEV_MDPY [=y] && SAMPLES [=y] - SAMPLE_VFIO_MDEV_MBOCHS [=y] && SAMPLES [=y] /home/arnd/cross/arm64/gcc-13.0.1-nolibc/x86_64-linux/bin/x86_64-linux-ld: samples/vfio-mdev/mdpy.o: in function `mdpy_remove': mdpy.c:(.text+0x1e1): undefined reference to `vfio_unregister_group_dev' /home/arnd/cross/arm64/gcc-13.0.1-nolibc/x86_64-linux/bin/x86_64-linux-ld: samples/vfio-mdev/mdpy.o: in function `mdpy_probe': mdpy.c:(.text+0x149e): undefined reference to `_vfio_alloc_device' Fixes: 8bf8c5ee1f38 ("vfio-mdev: turn VFIO_MDEV into a selectable symbol") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230126211211.1762319-1-arnd@kernel.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-01-30drm/i915: implement async_flip mode per plane trackingAndrzej Hajda
Current implementation of async flip w/a relies on assumption that previous atomic commit contains valid information if async_flip is still enabled on the plane. It is incorrect. If previous commit did not modify the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE errors can be observed: i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set v2: update async_flip_planes in more reliable places (Ville) v3: reset async_flip_planes and do_async_flip in more scenarios (Ville) v4: move all resets to plane loops (Ville) Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127153003.2225111-1-andrzej.hajda@intel.com
2023-01-30drm/i915/psr: Split sel fetch plane configuration into arm and noarmJouni Högander
SEL_FETCH_CTL registers are armed immediately when plane is disabled. SEL_FETCH_* instances of plane configuration are used when doing selective update and normal plane register instances for full updates. Currently all SEL_FETCH_* registers are written as a part of noarm plane configuration. If noarm and arm plane configuration are not happening within same vblank we may end up having plane as a part of selective update before it's PLANE_SURF register is written. Fix this by splitting plane selective fetch configuration into arm and noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm version. v3: - add arm suffix into intel_psr2_disable_plane_sel_fetch v2: - drop color_plane parameter from arm part - dev_priv -> i915 in arm part Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130080651.3796929-1-jouni.hogander@intel.com
2023-01-30drm/shmem: Cleanup drm_gem_shmem_create_with_handle()Rob Clark
Once we create the handle, the handle owns the reference. Currently nothing was doing anything with the shmem ptr after the handle was created, but let's change drm_gem_shmem_create_with_handle() to not return the pointer, so-as to not encourage problematic use of this function in the future. As a bonus, it makes the code a bit cleaner. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123154831.3191821-1-robdclark@gmail.com
2023-01-30drm/i915/display/dsi: use intel_de_rmw if possibleAndrzej Hajda
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219130844.2914001-1-andrzej.hajda@intel.com
2023-01-30drm/i915/display/vlv: use intel_de_rmw if possibleAndrzej Hajda
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219092428.2515430-2-andrzej.hajda@intel.com
2023-01-30drm/i915/display/vlv: fix pixel overlap register updateAndrzej Hajda
To update properly bits in the register the mask should be used to clear old value and then the result should be or-ed with new value, for such updates there is separate helper intel_de_rmw. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219092428.2515430-1-andrzej.hajda@intel.com
2023-01-30drm/i915/display/fdi: use intel_de_rmw if possibleAndrzej Hajda
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221215125610.1161729-1-andrzej.hajda@intel.com
2023-01-30drm/i915/adlp: Fix typo for reference clockChaitanya Kumar Borah
Fix typo for reference clock from 24400 to 24000. Bspec: 55409 Fixes: 626426ff9ce4 ("drm/i915/adl_p: Add cdclk support for ADL-P") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230112094131.550252-1-chaitanya.kumar.borah@intel.com
2023-01-30drm/i915: Fix potential bit_17 double-freeRob Clark
A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. Signed-off-by: Rob Clark <robdclark@chromium.org> Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Cc: <stable@vger.kernel.org> # v5.5+ [tursulin: Correct fixes tag and added cc stable.] Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127200550.3531984-1-robdclark@gmail.com
2023-01-30Merge tag 'amd-drm-next-6.3-2023-01-27' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.3-2023-01-27: amdgpu: - GC11 fixes - SMU13 fixes - Freesync fixes - DP MST fixes - DP MST code rework and cleanup - AV1 fixes for VCN4 - DCN 3.2.x fixes - PSR fixes - DML optimizations - DC link code rework Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127225917.2419162-1-alexander.deucher@amd.com
2023-01-30Merge tag 'drm/tegra/for-6.3-rc1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/tegra into drm-next drm/tegra: Changes for v6.3-rc1 This set of changes includes a rework of the custom syncpoint interrupt code to take better advantage of existing DRM/KMS infrastructure. There's also various bits of cleanup and fixes included. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127170119.495943-1-thierry.reding@gmail.com
2023-01-30Merge tag 'drm-next-20230127' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next Renesas R-Car DU fixes and improvements Signed-off-by: Dave Airlie <airlied@redhat.com> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/Y9QCw3SkHm6k1bwJ@pendragon.ideasonboard.com
2023-01-30Merge tag 'drm-intel-next-2023-01-27' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull #2 v6.3: Features and functionality: - Enable HF-EEODB by switching HDMI, DP and LVDS to use struct drm_edid (Jani) - Start using unversioned DMC firmware paths for new platforms (Gustavo) Refactoring and cleanups: - ELD refactor: Stop using hardware buffer, precompute ELD, and wire up ELD in the state checker (Ville) - Use generics for debugfs device parameters (Jani) - DSB refactoring and fixes (Ville) - Header refactoring, add new intel_display_limits.h (Jani) - Split out GMCH code to a new file (Jani) - Split out vblank code to a new file (Jani) - i915_drv.h and struct drm_i915_private cleanups (Jani) - Simplify FBC and DRRS debug attributes (Deepak R Varma) - Remove some single-use macros (Rodrigo) Fixes: - Fix scaler limits for display versions 12 and 13 (Luca) - Fix plane source size check for zero height (Drew Davenport) - Implement PSR2 selective fetch workaround (Jouni) - Expand a PSR workaound to more platforms and pipes (Jouni) - Expand an HDMI infoframe workaround to all MTL steppings (Jouni) - Enable PIPEDMC whenever its corresponding pipe is enabled (Imre) Merges: - Backmerge drm-next (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87tu0c44gv.fsf@intel.com
2023-01-29drm/mediatek: Remove unused GEM DMA header includeRob Clark
No longer needed since the removal of dependency on DMA helper. Signed-off-by: Rob Clark <robdclark@chromium.org> Reported-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20230127165409.3512501-1-robdclark@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2023-01-27amdgpu: fix build on non-DCN platforms.Dave Airlie
This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-01-27Merge tag 'drm-fixes-2023-01-27' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Fairly small this week as well, i915 has a memory leak fix and some minor changes, and amdgpu has some MST fixes, and some other minor ones: drm: - DP MST kref fix - fb_helper: check return value i915: - Fix BSC default context for Meteor Lake - Fix selftest-scheduler's modify_type - memory leak fix amdgpu: - GC11.x fixes - SMU13.0.0 fix - Freesync video fix - DP MST fixes - build fix" * tag 'drm-fixes-2023-01-27' of git://anongit.freedesktop.org/drm/drm: amdgpu: fix build on non-DCN platforms. drm/amd/display: Fix timing not changning when freesync video is enabled drm/display/dp_mst: Correct the kref of port. drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD drm/amdgpu/display/mst: limit payload to be updated one by one drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments drm/amdgpu: declare firmware for new MES 11.0.4 drm/amdgpu: enable imu firmware for GC 11.0.4 drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0 drm/amdgpu: remove unconditional trap enable on add gfx11 queues drm/fb-helper: Use a per-driver FB deferred I/O handler drm/fb-helper: Check fb_deferred_io_init() return value drm/i915/selftest: fix intel_selftest_modify_policy argument types drm/i915/mtl: Fix bcs default context drm/i915: Fix a memory leak with reused mmap_offset drm/drm_vma_manager: Add drm_vma_node_allow_once()
2023-01-27drm/i915/guc: Rename GuC register state capture node to be more obviousJohn Harrison
The GuC specific register state entry in the error capture object was just called 'capture'. Although the companion 'node' entry was called 'guc_capture_node'. Rename the base entry to be 'guc_capture' instead so that it is a) more consistent and b) more obvious what it is. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-9-John.C.Harrison@Intel.com
2023-01-27drm/i915/guc: Add a debug print on GuC triggered resetJohn Harrison
For understanding bug reports, it can be useful to have an explicit dmesg print when a reset notification is received from GuC. As opposed to simply inferring that this happened from other messages. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-8-John.C.Harrison@Intel.com
2023-01-27drm/i915/guc: Look for a guilty context when an engine reset failsJohn Harrison
Engine resets are supposed to never fail. But in the case when one does (due to unknown reasons that normally come down to a missing w/a), it is useful to get as much information out of the system as possible. Given that the GuC intentionally dies on such a situation, it is not possible to get a guilty context notification back. So do a manual search instead. Given that GuC is dead, this is safe because GuC won't be changing the engine state asynchronously. v2: Change comment to be less alarming (Tvrtko) Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-7-John.C.Harrison@Intel.com
2023-01-27drm/i915: Allow error capture of a pending requestJohn Harrison
A hang situation has been observed where the only requests on the context were either completed or not yet started according to the breaadcrumbs. However, the register state claimed a batch was (maybe) in progress. So, allow capture of the pending request on the grounds that this might be better than nothing. v2: Reword 'not started' warning message (Tvrtko) Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-6-John.C.Harrison@Intel.com
2023-01-27drm/i915: Allow error capture without a requestJohn Harrison
There was a report of error captures occurring without any hung context being indicated despite the capture being initiated by a 'hung context notification' from GuC. The problem was not reproducible. However, it is possible to happen if the context in question has no active requests. For example, if the hang was in the context switch itself then the breadcrumb write would have occurred and the KMD would see an idle context. In the interests of attempting to provide as much information as possible about a hang, it seems wise to include the engine info regardless of whether a request was found or not. As opposed to just prentending there was no hang at all. So update the error capture code to always record engine information if a context is given. Which means updating record_context() to take a context instead of a request (which it only ever used to find the context anyway). And split the request agnostic parts of intel_engine_coredump_add_request() out into a seaprate function. v2: Remove a duplicate 'if' statement (Umesh) and fix a put of a null pointer. v3: Tidy up request locking code flow (Tvrtko) v4: Pull in improved info message from next patch and fix up potential leak of GuC register state (Daniele) Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> (v2) Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-5-John.C.Harrison@Intel.com
2023-01-27drm/i915: Fix up locking around dumping requests listsJohn Harrison
The debugfs dump of requests was confused about what state requires the execlist lock versus the GuC lock. There was also a bunch of duplicated messy code between it and the error capture code. So refactor the hung request search into a re-usable function. And reduce the span of the execlist state lock to only the execlist specific code paths. In order to do that, also move the report of hold count (which is an execlist only concept) from the top level dump function to the lower level execlist specific function. Also, move the execlist specific code into the execlist source file. v2: Rename some functions and move to more appropriate files (Daniele). v3: Rename new execlist dump function (Daniele) Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-4-John.C.Harrison@Intel.com
2023-01-27drm/i915: Fix request ref counting during error capture & debugfs dumpJohn Harrison
When GuC support was added to error capture, the reference counting around the request object was broken. Fix it up. The context based search manages the spinlocking around the search internally. So it needs to grab the reference count internally as well. The execlist only request based search relies on external locking, so it needs an external reference count but within the spinlock not outside it. The only other caller of the context based search is the code for dumping engine state to debugfs. That code wasn't previously getting an explicit reference at all as it does everything while holding the execlist specific spinlock. So, that needs updaing as well as that spinlock doesn't help when using GuC submission. Rather than trying to conditionally get/put depending on submission model, just change it to always do the get/put. v2: Explicitly document adding an extra blank line in some dense code (Andy Shevchenko). Fix multiple potential null pointer derefs in case of no request found (some spotted by Tvrtko, but there was more!). Also fix a leaked request in case of !started and another in __guc_reset_context now that intel_context_find_active_request is actually reference counting the returned request. v3: Add a _get suffix to intel_context_find_active_request now that it grabs a reference (Daniele). v4: Split the intel_guc_find_hung_context change to a separate patch and rename intel_context_find_active_request_get to intel_context_get_active_request (Tvrtko). v5: s/locking/reference counting/ in commit message (Tvrtko) Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-3-John.C.Harrison@Intel.com
2023-01-27drm/i915/guc: Fix locking when searching for a hung requestJohn Harrison
intel_guc_find_hung_context() was not acquiring the correct spinlock before searching the request list. So fix that up. While at it, add some extra whitespace padding for readability. Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with GuC") Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Michael Cheng <michael.cheng@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-2-John.C.Harrison@Intel.com
2023-01-27drm/i915/pxp: Pxp hw init should be in resume_completeAlan Previn
During suspend flow, i915 currently achors' on the pm_suspend_prepare callback as the location where we quiesce the entire GPU and perform all necessary cleanup in order to go into suspend. PXP is also called during this time to perform the arbitration session teardown (with the assurance no additional GEM IOCTLs will come after that could restart the session). However, if other devices or drivers fail their suspend_prepare, the system will not go into suspend and i915 will be expected to resume operation. In this case, we need to re-initialize the PXP hardware and this really should be done within the pm_resume_complete callback which is the correct opposing function in the resume sequence to match pm_suspend_prepare of the suspend sequence. Because this callback is the last thing at the end of resuming we expect little to no impact to the rest of the i915 resume sequence with this change. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-7-alan.previn.teres.alexis@intel.com
2023-01-27drm/i915/pxp: Trigger the global teardown for before suspendingAlan Previn
A driver bug was recently discovered where the security firmware was receiving internal HW signals indicating that session key expirations had occurred. Architecturally, the firmware was expecting a response from the GuC to acknowledge the event with the firmware side. However the OS was in a suspended state and GuC had been reset. Internal specifications actually required the driver to ensure that all active sessions be properly cleaned up in such cases where the system is suspended and the GuC potentially unable to respond. This patch adds the global teardown code in i915's suspend_prepare code path. v2 : Split __pxp_global_teardown_locked helper into two variants for teardown-with-restart vs teardown-for-suspend/shutdown. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Juston Li <justonli@chromium.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-6-alan.previn.teres.alexis@intel.com
2023-01-27drm/i915/pxp: Invalidate all PXP fw sessions during teardownAlan Previn
A gap was recently discovered where if an application did not invalidate all of the stream keys (intentionally or not), and the driver did a full PXP global teardown on the GT subsystem, we find that future session creation would fail on the security firmware's side of the equation. i915 is the entity that needs ensure the sessions' state across both iGT and security firmware are at a known clean point when performing a full global teardown. Architecturally speaking, i915 should inspect all active sessions and submit the invalidate-stream-key PXP command to the security firmware for each of them. However, for the upstream i915 driver we only support the arbitration session that can be created so that will be the only session we will cleanup. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Juston Li <justonli@chromium.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-5-alan.previn.teres.alexis@intel.com
2023-01-27drm/i915/pxp: add device link between i915 and mei_pxpAlexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier to ensure proper ordering of power flows. V2: condition on absence of heci_pxp to filter out DG Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-3-alan.previn.teres.alexis@intel.com
2023-01-27i915/gvt: Replace one-element array with flexible-array memberPaulo Miguel Almeida
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct gvt_firmware_header and refactor the rest of the code accordingly. Additionally, previous implementation was allocating 8 bytes more than required to represent firmware_header + cfg_space data + mmio data. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. To make reviewing this patch easier, I'm pasting before/after struct sizes. pahole -C gvt_firmware_header before/drivers/gpu/drm/i915/gvt/firmware.o struct gvt_firmware_header { u64 magic; /* 0 8 */ u32 crc32; /* 8 4 */ u32 version; /* 12 4 */ u64 cfg_space_size; /* 16 8 */ u64 cfg_space_offset; /* 24 8 */ u64 mmio_size; /* 32 8 */ u64 mmio_offset; /* 40 8 */ unsigned char data[1]; /* 48 1 */ /* size: 56, cachelines: 1, members: 8 */ /* padding: 7 */ /* last cacheline: 56 bytes */ }; pahole -C gvt_firmware_header after/drivers/gpu/drm/i915/gvt/firmware.o struct gvt_firmware_header { u64 magic; /* 0 8 */ u32 crc32; /* 8 4 */ u32 version; /* 12 4 */ u64 cfg_space_size; /* 16 8 */ u64 cfg_space_offset; /* 24 8 */ u64 mmio_size; /* 32 8 */ u64 mmio_offset; /* 40 8 */ unsigned char data[]; /* 48 0 */ /* size: 48, cachelines: 1, members: 8 */ /* last cacheline: 48 bytes */ }; As you can see the additional byte of the fake-flexible array (data[1]) forced the compiler to pad the struct but those bytes aren't actually used as first & last bytes (of both cfg_space and mmio) are controlled by the <>_size and <>_offset members present in the gvt_firmware_header struct. Link: https://github.com/KSPP/linux/issues/79 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/Y6Eu2604cqtryP4g@mail.google.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-23 19:27:08 +0000