aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-11-11drm/xen: Implement mmap as GEM object functionThomas Zimmermann3-87/+44
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The respective xen functions are being removed. The file_operations structure fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-3-tzimmermann@suse.de
2021-11-11drm/i915/dsi: transmit brightness command in HS stateWilliam Tseng1-0/+4
In Video Mode, if DSI transcoder is set to transmit packets in LP Escape mode, screen flickering would be obseved when brightness commands are continuously and quickly transmitted to a panel. The problem may be resolved by changing the mode to transmit packets from Low Power to HS. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: William Tseng <william.tseng@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110010217.26759-1-william.tseng@intel.com
2021-11-11drm/i915/dp: For PCON TMDS mode set only the relavant bits in config DPCDAnkit Nautiyal1-1/+23
Currently we reset the whole PCON linkConfig DPCD to set the TMDS mode. This also resets the Source control bit and HDMI link enable bit and goes to autonomous mode of operation, which is seen to spoil the PCONs internal state. This patch avoids resetting the PCON link config register and sets only the source control bit, with FRL Enable bit set to 0 (TMDS mode) in the configuration DPCD. It then enables the HDMI Link Enable bit. v2: Removed the redundant resetting of the bits as the buffer is already initialized to 0. (Uma) Updated comments and commit message. v3: Rebase Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110072947.171659-3-ankit.k.nautiyal@intel.com
2021-11-11drm/i915/dp: Optimize the FRL configuration for HDMI2.1 PCONAnkit Nautiyal1-14/+23
Currently the HDMI2.1 PCON's frl link config DPCD registers are reset and configured even if they are already configured. Also the HDMI Link Mode does not settle to FRL MODE immediately after HDMI Link Status is active. This patch: -Checks if the PCON is already configured for FRL. -Include HDMI Link Mode in wait for loop along with HDMI Link status DPCD. v2: Rebase Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110072947.171659-2-ankit.k.nautiyal@intel.com
2021-11-11drm/etnaviv: use dma_resv_describeChristian König1-19/+7
Instead of dumping the fence info manually. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-4-christian.koenig@amd.com
2021-11-11drm/msm: use the new dma_resv_describeChristian König1-19/+1
Instead of hand rolling pretty much the same code. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-3-christian.koenig@amd.com
2021-11-11drm/ttm: Put BO in its memory manager's lru listxinhui pan1-0/+2
After we move BO to a new memory region, we should put it to the new memory manager's lru list regardless we unlock the resv or not. Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-1-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-11-11drm/ttm: Double check mem_type of BO while evictionxinhui pan1-1/+2
BO might sit in a wrong lru list as there is a small period of memory moving and lru list updating. Lets skip eviction if we hit such mismatch. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-2-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-11-11drm/i915/ttm: Fix illegal addition to shrinker listThomas Hellström1-10/+21
There's a small window of opportunity during which the adjust_lru() function can be called with a GEM refcount of zero from the TTM eviction code. This results in a kernel BUG(). Ensure that we don't attempt to modify the GEM shrinker lists unless we have a GEM refcount. Fixes: ebd4a8ec7799 ("drm/i915/ttm: move shrinker management into adjust_lru") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110085527.1033475-1-thomas.hellstrom@linux.intel.com
2021-11-10drm/i915: split general MMIO setup from per-GT uncore initDaniele Ceraolo Spurio3-15/+13
In coming patches we'll be doing the actual tile initialization between these two uncore init phases. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029032817.3747750-3-matthew.d.roper@intel.com
2021-11-10drm/i915: rework some irq functions to take intel_gt as argumentPaulo Zanoni1-11/+15
We'll be adding multi-tile support soon; on multi-tile platforms interrupts are per-tile and every tile has the full set of interrupt registers. In this commit we start passing intel_gt instead of dev_priv for the functions that are related to Xe_HP irq handling. Right now we're still passing tile 0 everywhere, but in later patches we'll start actually passing the correct tile. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-authored-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029032817.3747750-2-matthew.d.roper@intel.com
2021-11-11Merge tag 'amd-drm-fixes-5.16-2021-11-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie32-79/+205
amd-drm-fixes-5.16-2021-11-10: amdgpu: - Don't allow partial copy from user for DC debugfs - SRIOV fixes - GFX9 CSB pin count fix - Various IP version check fixes - DP 2.0 fixes - Limit DCN1 MPO fix to DCN1 amdkfd: - SVM fixes - Reset fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110222536.7527-1-alexander.deucher@amd.com
2021-11-11Merge tag 'drm-misc-next-fixes-2021-11-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-nextDave Airlie12-189/+21
Removed the TTM Huge Page functionnality to address a crash, a timeout fix for udl, CONFIG_FB dependency improvements, a fix for a circular locking depency in imx, a NULL pointer dereference fix for virtio, and a naming collision fix for drm/locking. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211110082114.vfpkpnecwdfg27lk@gilmour
2021-11-10drm/amdgpu: add missed support for UVD IP_VERSION(3, 0, 64)Guchun Chen3-0/+3
Fixes: 96b8dd4423e74d ("drm/amdgpu/amdgpu_vcn: convert to IP version checking") Signed-off-by: Flora Cui <flora.cui@amd.com> Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-10drm/amdgpu: drop jpeg IP initialization in SRIOV caseGuchun Chen1-1/+2
Fixes: b05b9c591f9ed6 ("drm/amdgpu: clean up set IP function") Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-10drm/amd/display: reject both non-zero src_x and src_y only for DCN1xShirish S1-9/+11
[Why] Video plane gets rejected for non-zero src_y and src_x on DCN2.x. [How] Limit the rejection till DCN1.x and verified MPO, by dragging video playback beyond display's left (0, 0) co-ordinates. Fixes: d89f6048bdcb ("drm/amd/display: Reject non-zero src_y and src_x for video planes") Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-10drm/tidss: Make use of the helper macro SET_RUNTIME_PM_OPS()Cai Huoqing1-9/+2
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little more concise. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907033526.1612-1-caihuoqing@baidu.com
2021-11-10drm/omap: increase DSS5 max tv pclk to 192MHzTomi Valkeinen1-1/+1
DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To support DRA76's wide screen HDMI feature, we need to increase this maximum rate. Testing shows that the PLL seems to work fine even with ~240MHz clocks, and even the HDMI output at that clock is stable enough for monitors to show a picture. This holds true for all DRA7 and AM5 SoCs (and probably also for OMAP5). However, the highest we can go without big refactoring to the clocking code is 192MHz, as that is the DSS func clock we get from the PRCM. So, increase the max HDMI pixel clock to 192MHz for now, to allow some more 2k+ modes to work. This patch never had a clear confirmation from HW people, but this change stayed on production trees for multiple years without any report on an eventual breakage. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012133939.2145462-1-narmstrong@baylibre.com
2021-11-10drm/omap: Make use of the helper function devm_platform_ioremap_resourcexxx()Cai Huoqing9-34/+11
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135707.4676-1-caihuoqing@baidu.com
2021-11-10drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()Cai Huoqing4-8/+4
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little clearer, a little more concise. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210828084811.104-1-caihuoqing@baidu.com
2021-11-10drm/omapdrm: Convert to SPDX identifierCai Huoqing6-62/+6
use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210822072323.408-1-caihuoqing@baidu.com
2021-11-10Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"Vandita Kulkarni1-8/+2
This reverts commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"). The Bspec was updated recently with the pll ungate sequence similar to that of icl dsi enable sequence. Hence reverting. Bspec: 49187 Fixes: 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com
2021-11-10drm/i915/selftests: Use clear_and_wake_up_bit() for the per-engine reset bitlocksThomas Hellström2-9/+13
Some selftests assume that nothing will attempt to grab these bitlocks while they are held by the selftests. With GuC, for example, that is not true because the hanging workloads may cause the GuC code to attempt to grab them for a global reset, and that may cause it to end up sleeping on the bit never waking up. Regardless whether that will be the final solution for GuC, use clear_and_wake_up_bit() pending a more thorough investigation on how this should be handled moving forward. To be clear this needs to be a temporary solution. If we can't find an in-kernel locking primitive to use here, we should at the very least add lockdep annotation to these bitlocks with a thorough explanation as to why we need to use bits. v3: - Use GEM_BUG_ON(test_and_set_bit()) rather than set_bit() to verify the assumption that nothing is holding the reset locks when we attempt to grab them. (Chris Wilson) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105150146.834052-1-thomas.hellstrom@linux.intel.com
2021-11-10drm/i915/gem: Fix gem_madvise for ttm+shmem objectsThomas Hellström1-1/+2
Gem-TTM objects that are backed by shmem might have populated page-vectors without having the GEM pages set. Those objects aren't moved to the correct shrinker / purge list by gem_madvise. For such objects, identified by having the _SELF_MANAGED_SHRINK_LIST set, make sure they end up on the correct list. v2: - Revert a change that made swapped-out objects inaccessible for truncating. (Matthew Auld) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108123637.929617-1-thomas.hellstrom@linux.intel.com
2021-11-10Merge tag 'drm-intel-next-fixes-2021-11-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie13-111/+148
Couple Reverts, build fix, couple virtualization fixes, blank screen and other display rates fixes, and more. Four patches targeting stable in here. Display Fixes: - DP rates related fixes (Imre, Jani) - A Revert on disaling dual eDP that was causing state readout problems (Jani) - put the cdclk vtables in const data (Jani) - Fix DVO port type for moder platforms (Ville) - Fix blankscreen by turning DP++ TMDS output buffers on encoder->shutdown (Ville) - CCS FBs related fixes (Imre) GT fixes: - Fix recursive lock in GuC submission (Matt Brost) - Revert guc_id from i915_request tracepoint (Joonas) - Build fix around dmabuf (Matt Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YYsBif3HMi8GjLoU@intel.com
2021-11-09drm/i915/guc: Refcount context during error captureJohn Harrison1-0/+14
When i915 receives a context reset notification from GuC, it triggers an error capture before resetting any outstanding requsts of that context. Unfortunately, the error capture is not a time bound operation. In certain situations it can take a long time, particularly when multiple large LMEM buffers must be read back and eoncoded. If this delay is longer than other timeouts (heartbeat, test recovery, etc.) then a full GT reset can be triggered in the middle. That can result in the context being reset by GuC actually being destroyed before the error capture completes and the GuC submission code resumes. Thus, the GuC side can start dereferencing stale pointers and Bad Things ensue. So add a refcount get of the context during the entire reset operation. That way, the context can't be destroyed part way through no matter what other resets or user interactions occur. v2: (Matthew Brost) - Update patch to work with async error capture v3: (Matthew Brost) - Drop async capture support as that hasn't landed yet Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108164054.23588-1-matthew.brost@intel.com
2021-11-09drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()Dan Carpenter1-7/+5
The "ret" variable is checked on the previous line so we know it's zero. No need to check again. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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/20211109114850.GB16587@kili
2021-11-10drm/i915: Call intel_update_active_dpll() for both bigjoiner pipesVille Syrjälä1-1/+7
Currently we're only calling intel_update_active_dpll() for the bigjoiner master pipe but not for the slave. With TC ports this leads to the two pipes end up trying to use different PLLs (TC vs. TBT). What's worse we're enabling the PLL that didn't get intel_update_active_dpll() called on it at the spot where we need the clocks turned on. So we turn on the wrong PLL and the DDI is now trying to source its clock from the other PLL which is still disabled. Naturally that doesn't end so well and the DDI fails to start up. The state checker also gets a bit unhappy (which is a good thing) when it notices that one of the pipes was using the wrong PLL. Let's fix this by remembering to call intel_update_active_dpll() for both pipes. That should get the correct PLL turned on when we need it, and the state checker should also be happy. Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4434 Fixes: e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105212156.5697-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-11-10drm/i915: Use unlocked register accesses for LUT loadsVille Syrjälä2-66/+66
We have to bash in a lot of registers to load the higher precision LUT modes. The locking overhead is significant, especially as we have to get this done as quickly as possible during vblank. So let's switch to unlocked accesses for these. Fortunately the LUT registers are mostly spread around such that two pipes do not have any registers on the same cacheline. So as long as commits on the same pipe are serialized (which they are) we should get away with this without angering the hardware. The only exceptions are the PREC_PIPEGCMAX registers on ilk/snb which we don't use atm as they are only used in the 12bit gamma mode. If/when we add support for that we may need to remember to still serialize those registers, though I'm not sure ilk/snb are actually affected by the same cacheline issue. I think ivb/hsw at least were, but they use a different set of registers for the precision LUT. I have a test case which is updating the LUTs on two pipes from a single atomic commit. Running that in a loop for a minute I get the following worst case with the locks in place: intel_crtc_vblank_work_start: pipe B, frame=10037, scanline=1081 intel_crtc_vblank_work_start: pipe A, frame=12274, scanline=769 intel_crtc_vblank_work_end: pipe A, frame=12274, scanline=58 intel_crtc_vblank_work_end: pipe B, frame=10037, scanline=74 And here's the worst case with the locks removed: intel_crtc_vblank_work_start: pipe B, frame=5869, scanline=1081 intel_crtc_vblank_work_start: pipe A, frame=7616, scanline=769 intel_crtc_vblank_work_end: pipe B, frame=5869, scanline=1096 intel_crtc_vblank_work_end: pipe A, frame=7616, scanline=777 The test was done on a snb using the 10bit 1024 entry LUT mode. The vtotals for the two displays are 793 and 1125. So we can see that with the locks ripped out the LUT updates are pretty nicely confined within the vblank, whereas with the locks in place we're routinely blasting past the vblank end which causes visual artifacts near the top of the screen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-11-10drm/i915: Use vblank workers for gamma updatesVille Syrjälä5-10/+129
The pipe gamma registers are single buffered so they should only be updated during the vblank to avoid screen tearing. In fact they really should only be updated between start of vblank and frame start because that is the only time the pipe is guaranteed to be empty. Already at frame start the pipe begins to fill up with data for the next frame. Unfortunately frame start happens ~1 scanline after the start of vblank which in practice doesn't always leave us enough time to finish the gamma update in time (gamma LUTs can be several KiB of data we have to bash into the registers). However we must try our best and so we'll add a vblank work for each pipe from where we can do the gamma update. Additionally we could consider pushing frame start forward to the max of ~4 scanlines after start of vblank. But not sure that's exactly a validated configuration. As it stands the ~100 first pixels tend to make it through with the old gamma values. Even though the vblank worker is running on a high prority thread we still have to contend with C-states. If the CPU happens be in a deep C-state when the vblank interrupt arrives even the irq handler gets delayed massively (I've observed dozens of scanlines worth of latency). To avoid that problem we'll use the qos mechanism to keep the CPU awake while the vblank work is scheduled. With all this hooked up we can finally enjoy near atomic gamma updates. It even works across several pipes from the same atomic commit which previously was a total fail because we did the gamma updates for each pipe serially after waiting for all pipes to have latched the double buffered registers. In the future the DSB should take over this responsibility which will hopefully avoid some of these issues. Kudos to Lyude for finishing the actual vblank workers. Works like the proverbial train toilet. v2: Add missing intel_atomic_state fwd declaration v3: Clean up properly when not scheduling the worker v4: Clean up the rest and add tracepoints v5: s/intel_wait_for_vblank_works/intel_wait_for_vblank_workers/ (Jani,Uma) CC: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-11-10drm/i915: Do vrr push before sampling the frame counterVille Syrjälä1-3/+3
Do the vrr push before we sample the frame counter to know when the commit has been latched. Doing these in the wrong order could lead us to complete the flip before it has actually happened. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-11-09drm/amd/display: Add callbacks for DMUB HPD IRQ notificationsNicholas Kazlauskas1-2/+15
[Why] We need HPD IRQ notifications (RX, short pulse) to properly handle DP MST for DPIA connections. [How] A null pointer exception currently occurs when these are received so add a check to validate that we have a handler installed for the notification. Extend the HPD handler to also handle HPD IRQ (RX) since the logic is the same. Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling") Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Jude Shih <shenshih@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amd/display: Don't lock connection_mutex for DMUB HPDNicholas Kazlauskas1-4/+0
[Why] Per DRM spec we only need to hold that lock when touching connector->state - which we do not do in that handler. Taking this locking introduces unnecessary dependencies with other threads which is bad for performance and opens up the potential for a deadlock since there are multiple locks being held at once. [How] Remove the connection_mutex lock/unlock routine and just iterate over the drm connectors normally. The iter helpers implicitly lock the connection list so this is safe to do. DC link access also does not need to be guarded since the link table is static at creation - we don't dynamically add or remove links, just streams. Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling") Reviewed-by: Jude Shih <shenshih@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amd/display: Add comment where CONFIG_DRM_AMD_DC_DCN macro endsAnson Jacob3-7/+9
Trivial patch which adds a comment for macro endif's in amdgpu_dm.c Reviewed-by: Ariel Bernstein <Eric.Bernstein@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Anson Jacob <Anson.Jacob@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amdkfd: Fix retry fault drain race conditionsFelix Kuehling2-5/+20
The check for whether to drain retry faults must be under the mmap write lock to serialize with munmap notifier callbacks. We were also missing checks on child ranges. To fix that, simplify the logic by using a flag rather than checking on each prange. That also allows draining less freqeuntly when many ranges are unmapped at once. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Tested-by: Philip Yang <Philip.Yang@amd.com> Tested-by: Alex Sierra <Alex.Sierra@amd.com> Reviewed-by: Philip Yang <Philip.Yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amdkfd: lower the VAs base offset to 8KBAlex Sierra1-1/+1
The low 16MB of virtual address space are currently reserved for kernel mode allocations mapped into user virtual address space. This causes conflicts with HMM/SVM mappings at low virtual addresses. We tried to move those kernel mode allocations to the upper half of the 64-bit virtual address space for GFX9, which is naturally reserved for kernel use. However, TBA (trap handler code) has problems to access addresses in the high virtual space. We have decided to set this to 8KB of the lower address space as a temporary fix, while investigate TBA address problem. It is very unlikely for user space to map memory at this low region. Signed-off-by: Alex Sierra <alex.sierra@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amd/display: fix exit from amdgpu_dm_atomic_check() abruptlyShirish S1-1/+1
make action upon failure in "drm_atomic_add_affected_connectors()" consistent with the rest of failures in amdgpu_dm_atomic_check(). Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amd/amdgpu: fix the kfd pre_reset sequence in sriovshaoyunl1-4/+1
The KFD pre_reset should be called before reset been executed, it will hold the lock to prevent other rocm process to sent the packlage to hiq during host execute the real reset on the HW Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/amdgpu: fix uvd crash on Polaris12 during driver unloadingEvan Quan1-11/+13
There was a change(below) target for such issue: d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload") But the fix for VI ASICs was missing there. This is a supplement for that. Fixes: d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload") Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-11-09drm/i915/resets: Don't set / test for per-engine reset bits with GuC submissionMatthew Brost1-10/+17
Don't set, test for, or clear per-engine reset bits with GuC submission as the GuC owns the per engine resets not the i915. Setting, testing for, and clearing these bits is causing issues with the hangcheck selftest. Rather than change to test to not use these bits, rip the use of these bits out from the reset code. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211028224224.32693-1-matthew.brost@intel.com
2021-11-09Merge branch 'akpm' (patches from Andrew)Linus Torvalds4-27/+8
Merge more updates from Andrew Morton: "87 patches. Subsystems affected by this patch series: mm (pagecache and hugetlb), procfs, misc, MAINTAINERS, lib, checkpatch, binfmt, kallsyms, ramfs, init, codafs, nilfs2, hfs, crash_dump, signals, seq_file, fork, sysvfs, kcov, gdb, resource, selftests, and ipc" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (87 commits) ipc/ipc_sysctl.c: remove fallback for !CONFIG_PROC_SYSCTL ipc: check checkpoint_restore_ns_capable() to modify C/R proc files selftests/kselftest/runner/run_one(): allow running non-executable files virtio-mem: disallow mapping virtio-mem memory via /dev/mem kernel/resource: disallow access to exclusive system RAM regions kernel/resource: clean up and optimize iomem_is_exclusive() scripts/gdb: handle split debug for vmlinux kcov: replace local_irq_save() with a local_lock_t kcov: avoid enable+disable interrupts if !in_task() kcov: allocate per-CPU memory on the relevant node Documentation/kcov: define `ip' in the example Documentation/kcov: include types.h in the example sysv: use BUILD_BUG_ON instead of runtime check kernel/fork.c: unshare(): use swap() to make code cleaner seq_file: fix passing wrong private data seq_file: move seq_escape() to a header signal: remove duplicate include in signal.h crash_dump: remove duplicate include in crash_dump.h crash_dump: fix boolreturn.cocci warning hfs/hfsplus: use WARN_ON for sanity check ...
2021-11-09lib, stackdepot: add helper to print stack entries into bufferImran Khan4-27/+8
To print stack entries into a buffer, users of stackdepot, first get a list of stack entries using stack_depot_fetch and then print this list into a buffer using stack_trace_snprint. Provide a helper in stackdepot for this purpose. Also change above mentioned users to use this helper. [imran.f.khan@oracle.com: fix build error] Link: https://lkml.kernel.org/r/20210915175321.3472770-4-imran.f.khan@oracle.com [imran.f.khan@oracle.com: export stack_depot_snprint() to modules] Link: https://lkml.kernel.org/r/20210916133535.3592491-4-imran.f.khan@oracle.com Link: https://lkml.kernel.org/r/20210915014806.3206938-4-imran.f.khan@oracle.com Signed-off-by: Imran Khan <imran.f.khan@oracle.com> Suggested-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Jani Nikula <jani.nikula@intel.com> [i915] Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-11-09drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding NULL pagesImre Deak2-1/+11
So far the remapped view size in GTT/DPT was padded to the next aligned offset unnecessarily after the last color plane with an unaligned size. Remove the unnecessary padding. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Fixes: 3d1adc3d64cf ("drm/i915/adlp: Add support for remapping CCS FBs") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-3-imre.deak@intel.com (cherry picked from commit 6b6636e17649d75b4d0cc55d3dff9e44511a442a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-09drm/i915/fb: Fix rounding error in subsampled plane size calculationImre Deak1-2/+2
For NV12 FBs with odd main surface tile-row height the CCS surface height was incorrectly calculated 1 less than the actual value. Fix this by rounding up the result of divison. For consistency do the same for the CCS surface width calculation. Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-2-imre.deak@intel.com (cherry picked from commit 2ee5ef9c934ad26376c9282171e731e6c0339815) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-09drm/i915/hdmi: Turn DP++ TMDS output buffers back on in encoder->shutdown()Ville Syrjälä4-2/+17
Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater TMDS output buffers back on after a reboot. This leads to a black screen after reboot if we turned the TMDS output buffers off prior to reboot. And if i915 decides to do a fastboot the black screen will persist even after i915 takes over. Apparently this has been a problem ever since commit b2ccb822d376 ("drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed") if one rebooted while the display was turned off. And things became worse with commit fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") since now we always turn the display off before a reboot. This was reported on a RKL, but I confirmed the same behaviour on my SNB as well. So looks pretty universal. Let's fix this by explicitly turning the TMDS output buffers back on in the encoder->shutdown() hook. Note that this gets called after irqs have been disabled, so the i2c communication with the DP dual mode adapter has to be performed via polling (which the gmbus code is perfectly happy to do for us). We also need a bit of care in handling DDI encoders which may or may not be set up for HDMI output. Specifically ddc_pin will not be populated for a DP only DDI encoder, in which case we don't want to call intel_gmbus_get_adapter(). We can handle that by simply doing the dual mode adapter type check before calling intel_gmbus_get_adapter(). Cc: <stable@vger.kernel.org> # v5.11+ Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4371 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029191802.18448-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 49c55f7b035b87371a6d3c53d9af9f92ddc962db) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-11-09drm/locking: fix __stack_depot_* name conflictStephen Rothwell1-7/+7
Commit cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") added functions named __stack_depot_* in drm which conflict with stack depot. Rename to __drm_stack_depot_*. v2 by Jani: - Also rename __stack_depot_print References: https://lore.kernel.org/r/20211015202648.258445ef@canb.auug.org.au Fixes: cd06ab2fd48f ("drm/locking: add backtrace for locking contended locks without backoff") Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018085113.27033-1-jani.nikula@intel.com (cherry picked from commit c4f08d7246a520da5f2b1068f635da0678485e33)
2021-11-09drm/i915/dsi: disable lpdt if it is not enabledWilliam Tseng1-0/+2
Avoid setting LP_DATA_TRANSFER when enable_lpdt is false Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: William Tseng <william.tseng@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211109034125.11291-1-william.tseng@intel.com
2021-11-08drm/i915: Fix Memory BW formulae for ADL-PRadhakrishna Sripada1-1/+1
The earlier update to BW formulae broke ADL-P. Include display 13 to use TGL path for BW parameters. Fixes: c64a9a7c05be ("drm/i915: Update memory bandwidth formulae") Cc: Matt Roper <matthew.d.roper@intel.com> Reported-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211106003714.17894-1-radhakrishna.sripada@intel.com
2021-11-08drm/virtio: Fix NULL dereference error in virtio_gpu_pollVivek Kasireddy1-1/+2
When virgl is not enabled, vfpriv pointer would not be allocated. Therefore, check for a valid value before dereferencing. Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> Link: http://patchwork.freedesktop.org/patch/msgid/20211104214249.1802789-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-11-06drm/lima: fix warning when CONFIG_DEBUG_SG=y & CONFIG_DMA_API_DEBUG=yQiang Yu1-0/+1
Otherwise get following warning: DMA-API: lima 1c40000.gpu: mapping sg segment longer than device claims to support [len=4149248] [max=65536] See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5496 Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reported-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211031041604.187216-1-yuq825@gmail.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.