summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2025-01-22drm/i915/dp_mst: Fix error handling while adding a connectorImre Deak1-8/+9
After an error during adding an MST connector the MST port and the intel_connector object could be leaked, fix this up. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250108151916.491113-2-imre.deak@intel.com
2025-01-22drm/i915/dp: Correct max compressed bpp bounds by using link bppAnkit Nautiyal1-2/+4
While setting the bounds for compressed bpp, we ensure that the compressed bpp is less than the pipe bpp. This causes an issue with the 420 output format, where the effective link bpp (or output bpp) is half that of the pipe bpp. Therefore instead of using pipe bpp, use the output bpp to set the bounds for the compressed bpp. v2: Use identifier output_bpp instead of link_bpp (Imre) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250117050713.152012-1-ankit.k.nautiyal@intel.com
2025-01-22Merge tag 'kthread-for-6.14-rc1' of ↵Linus Torvalds5-8/+8
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks Pull kthread updates from Frederic Weisbecker: "Kthreads affinity follow either of 4 existing different patterns: 1) Per-CPU kthreads must stay affine to a single CPU and never execute relevant code on any other CPU. This is currently handled by smpboot code which takes care of CPU-hotplug operations. Affinity here is a correctness constraint. 2) Some kthreads _have_ to be affine to a specific set of CPUs and can't run anywhere else. The affinity is set through kthread_bind_mask() and the subsystem takes care by itself to handle CPU-hotplug operations. Affinity here is assumed to be a correctness constraint. 3) Per-node kthreads _prefer_ to be affine to a specific NUMA node. This is not a correctness constraint but merely a preference in terms of memory locality. kswapd and kcompactd both fall into this category. The affinity is set manually like for any other task and CPU-hotplug is supposed to be handled by the relevant subsystem so that the task is properly reaffined whenever a given CPU from the node comes up. Also care should be taken so that the node affinity doesn't cross isolated (nohz_full) cpumask boundaries. 4) Similar to the previous point except kthreads have a _preferred_ affinity different than a node. Both RCU boost kthreads and RCU exp kworkers fall into this category as they refer to "RCU nodes" from a distinctly distributed tree. Currently the preferred affinity patterns (3 and 4) have at least 4 identified users, with more or less success when it comes to handle CPU-hotplug operations and CPU isolation. Each of which do it in its own ad-hoc way. This is an infrastructure proposal to handle this with the following API changes: - kthread_create_on_node() automatically affines the created kthread to its target node unless it has been set as per-cpu or bound with kthread_bind[_mask]() before the first wake-up. - kthread_affine_preferred() is a new function that can be called right after kthread_create_on_node() to specify a preferred affinity different than the specified node. When the preferred affinity can't be applied because the possible targets are offline or isolated (nohz_full), the kthread is affine to the housekeeping CPUs (which means to all online CPUs most of the time or only the non-nohz_full CPUs when nohz_full= is set). kswapd, kcompactd, RCU boost kthreads and RCU exp kworkers have been converted, along with a few old drivers. Summary of the changes: - Consolidate a bunch of ad-hoc implementations of kthread_run_on_cpu() - Introduce task_cpu_fallback_mask() that defines the default last resort affinity of a task to become nohz_full aware - Add some correctness check to ensure kthread_bind() is always called before the first kthread wake up. - Default affine kthread to its preferred node. - Convert kswapd / kcompactd and remove their halfway working ad-hoc affinity implementation - Implement kthreads preferred affinity - Unify kthread worker and kthread API's style - Convert RCU kthreads to the new API and remove the ad-hoc affinity implementation" * tag 'kthread-for-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks: kthread: modify kernel-doc function name to match code rcu: Use kthread preferred affinity for RCU exp kworkers treewide: Introduce kthread_run_worker[_on_cpu]() kthread: Unify kthread_create_on_cpu() and kthread_create_worker_on_cpu() automatic format rcu: Use kthread preferred affinity for RCU boost kthread: Implement preferred affinity mm: Create/affine kswapd to its preferred node mm: Create/affine kcompactd to its preferred node kthread: Default affine kthread to its preferred NUMA node kthread: Make sure kthread hasn't started while binding it sched,arm64: Handle CPU isolation on last resort fallback rq selection arm64: Exclude nohz_full CPUs from 32bits el0 support lib: test_objpool: Use kthread_run_on_cpu() kallsyms: Use kthread_run_on_cpu() soc/qman: test: Use kthread_run_on_cpu() arm/bL_switcher: Use kthread_run_on_cpu()
2025-01-22Merge tag 'drm-next-2025-01-17' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds181-4948/+6091
Pull drm updates from Dave Airlie: "There are two external interactions of note, the msm tree pull in some opp tree, hopefully the opp tree arrives from the same git tree however it normally does. There is also a new cgroup controller for device memory, that is used by drm, so is merging through my tree. This will hopefully help open up gpu cgroup usage a bit more and move us forward. There is a new accelerator driver for the AMD XDNA Ryzen AI NPUs. Then the usual xe/amdgpu/i915/msm leaders and lots of changes and refactors across the board: core: - device memory cgroup controller added - Remove driver date from drm_driver - Add drm_printer based hex dumper - drm memory stats docs update - scheduler documentation improvements new driver: - amdxdna - Ryzen AI NPU support connector: - add a mutex to protect ELD - make connector setup two-step panels: - Introduce backlight quirks infrastructure - New panels: KDB KD116N2130B12, Tianma TM070JDHG34-00, - Multi-Inno Technology MI1010Z1T-1CP11 bridge: - ti-sn65dsi83: Add ti,lvds-vod-swing optional properties - Provide default implementation of atomic_check for HDMI bridges - it605: HDCP improvements, MCCS Support xe: - make OA buffer size configurable - GuC capture fixes - add ufence and g2h flushes - restore system memory GGTT mappings - ioctl fixes - SRIOV PF scheduling priority - allow fault injection - lots of improvements/refactors - Enable GuC's WA_DUAL_QUEUE for newer platforms - IRQ related fixes and improvements i915: - More accurate engine busyness metrics with GuC submission - Ensure partial BO segment offset never exceeds allowed max - Flush GuC CT receive tasklet during reset preparation - Some DG2 refactor to fix DG2 bugs when operating with certain CPUs - Fix DG1 power gate sequence - Enabling uncompressed 128b/132b UHBR SST - Handle hdmi connector init failures, and no HDMI/DP cases - More robust engine resets on Haswell and older i915/xe display: - HDCP fixes for Xe3Lpd - New GSC FW ARL-H/ARL-U - support 3 VDSC engines 12 slices - MBUS joining sanitisation - reconcile i915/xe display power mgmt - Xe3Lpd fixes - UHBR rates for Thunderbolt amdgpu: - DRM panic support - track BO memory stats at runtime - Fix max surface handling in DC - Cleaner shader support for gfx10.3 dGPUs - fix drm buddy trim handling - SDMA engine reset updates - Fix doorbell ttm cleanup - RAS updates - ISP updates - SDMA queue reset support - Rework DPM powergating interfaces - Documentation updates and cleanups - DCN 3.5 updates - Use a pm notifier to more gracefully handle VRAM eviction on suspend or hibernate - Add debugfs interfaces for forcing scheduling to specific engine instances - GG 9.5 updates - IH 4.4 updates - Make missing optional firmware less noisy - PSP 13.x updates - SMU 13.x updates - VCN 5.x updates - JPEG 5.x updates - GC 12.x updates - DC FAMS updates amdkfd: - GG 9.5 updates - Logging improvements - Shader debugger fixes - Trap handler cleanup - Cleanup includes - Eviction fence wq fix msm: - MDSS: - properly described UBWC registers - added SM6150 (aka QCS615) support - DPU: - added SM6150 (aka QCS615) support - enabled wide planes if virtual planes are enabled (by using two SSPPs for a single plane) - added CWB hardware blocks support - DSI: - added SM6150 (aka QCS615) support - GPU: - Print GMU core fw version - GMU bandwidth voting for a740 and a750 - Expose uche trap base via uapi - UAPI error reporting rcar-du: - Add r8a779h0 Support ivpu: - Fix qemu crash when using passthrough nouveau: - expose GSP-RM logging buffers via debugfs panfrost: - Add MT8188 Mali-G57 MC3 support rockchip: - Gamma LUT support hisilicon: - new HIBMC support virtio-gpu: - convert to helpers - add prime support for scanout buffers v3d: - Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL vc4: - Add support for BCM2712 vkms: - line-per-line compositing algorithm to improve performance zynqmp: - Add DP audio support mediatek: - dp: Add sdp path reset - dp: Support flexible length of DP calibration data etnaviv: - add fdinfo memory support - add explicit reset handling" * tag 'drm-next-2025-01-17' of https://gitlab.freedesktop.org/drm/kernel: (1070 commits) drm/bridge: fix documentation for the hdmi_audio_prepare() callback doc/cgroup: Fix title underline length drm/doc: Include new drm-compute documentation cgroup/dmem: Fix parameters documentation cgroup/dmem: Select PAGE_COUNTER kernel/cgroup: Remove the unused variable climit drm/display: hdmi: Do not read EDID on disconnected connectors drm/tests: hdmi: Add connector disablement test drm/connector: hdmi: Do atomic check when necessary drm/amd/display: 3.2.316 drm/amd/display: avoid reset DTBCLK at clock init drm/amd/display: improve dpia pre-train drm/amd/display: Apply DML21 Patches drm/amd/display: Use HW lock mgr for PSR1 drm/amd/display: Revised for Replay Pseudo vblank control drm/amd/display: Add a new flag for replay low hz drm/amd/display: Remove unused read_ono_state function from Hwss module drm/amd/display: Do not elevate mem_type change to full update drm/amd/display: Do not wait for PSR disable on vbl enable drm/amd/display: Remove unnecessary eDP power down ...
2025-01-22drm/i915/backlight: Return immediately when scale() finds invalid parametersGuenter Roeck1-2/+3
The scale() functions detects invalid parameters, but continues its calculations anyway. This causes bad results if negative values are used for unsigned operations. Worst case, a division by 0 error will be seen if source_min == source_max. On top of that, after v6.13, the sequence of WARN_ON() followed by clamp() may result in a build error with gcc 13.x. drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale': include/linux/compiler_types.h:542:45: error: call to '__compiletime_assert_415' declared with attribute error: clamp() low limit source_min greater than high limit source_max This happens if the compiler decides to rearrange the code as follows. if (source_min > source_max) { WARN(..); /* Do the clamp() knowing that source_min > source_max */ source_val = clamp(source_val, source_min, source_max); } else { /* Do the clamp knowing that source_min <= source_max */ source_val = clamp(source_val, source_min, source_max); } Fix the problem by evaluating the return values from WARN_ON and returning immediately after a warning. While at it, fix divide by zero error seen if source_min == source_max. Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Suggested-by: David Laight <david.laight.linux@gmail.com> Cc: David Laight <david.laight.linux@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250121145203.2851237-1-linux@roeck-us.net Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-21drm/i915/pmu: Remove i915_pmu_event_event_idx()Lucas De Marchi1-6/+0
perf event already has a default function that returns 0, no need to override with the same thing. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113183329.3138138-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-01-21drm/i915/dsb: Allow DSB to perform commits when VRR is enabledVille Syrjälä1-1/+0
Now that we know how to issue the push with the DSB we can allow the DSB to drive the commits even when VRR is active. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-9-ville.syrjala@linux.intel.com
2025-01-21drm/i915/dsb: Add support for triggering VRR push with DSBVille Syrjälä1-0/+10
We have at least two options for how to do the TRANS_PUSH_SEND + commit completion signalling with the DSB: Option A) 1. trigger TRANS_PUSH_SEND 2. wait for "safe window" 3. signal the interrupt In this cases step 2 should not do anything if we were already between vmin and vmax decision boundaries. Otherwise we'll wait until the next start of the vblank period. Option B) 1. wait for "safe window" 2. trigger TRANS_PUSH_SEND 3. signal the interrupt This option is perhaps a bit less racy, but if we do somehow screw up and the wait is a nop but the push gets deferred until the next frame then we'll end up completing the commit a frame too early. So for now I'm leaning towards option A since losing the race won't have any drastic consequences. To deal with the race we can give the DSB a bit more time to start step 2 before the hardware has started the vblank termination properly. Often times it seems to be fast enough to make it in time even without any extra vblank delay (the push is issued somewhere within a scanline and it latches on the next scanline). v2: Use intel_vrr_possible() to determine if we need some vblank delay (also avoids adding it for DSI which doens't actually program the transcoder registers correctly for it) Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-8-ville.syrjala@linux.intel.com
2025-01-21drm/i915: Allow fastboot to fix up the vblank delayVille Syrjälä1-4/+22
GOP might not agree with our idea of what the vblank delay should be. Reuse the LRR codepaths to fix that up via a fastset. The relevant registers aren't actually double buffered so this is a little bit dodgy. While I've not seen any real issues from frobbing these live, let's limit this to just the fastboot case (by only allowing it when old_crtc_state->inherited==true). Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915: Extract lrr_params_changed()Ville Syrjälä1-2/+9
Pull the "do we actually need a LRR update?" checks into a small helper for clarity. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915: Warn if someone tries to use intel_set_transcoder_timings*() on ↵Ville Syrjälä1-0/+4
DSI outputs intel_set_transcoder_timings*() aren't currently suitable for DSI. Warn if someone accidentally calls them in such cases. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915: Update TRANS_SET_CONTEXT_LATENCY during LRR updatesVille Syrjälä1-0/+4
Update TRANS_SET_CONTEXT_LATENCY in intel_set_transcoder_timings_lrr() as well. While for actual LRR updates this should not change, I want to reuse this code to also sanitize the vblank delay during boot, and in that case we do need to update this. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915: Handle interlaced modes in intel_set_transcoder_timings_lrr()Ville Syrjälä1-2/+6
I want to start using intel_set_transcoder_timings_lrr() also for fixing up the vblank delay during boot. To that end make sure it can cope with interlaced modes as well. Note that we have soft-defeatured interlaced modes on tgl+ so technically this is dead code, but if we ever have the need to bring interlaced support back it seems better to handle this. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915: Keep TRANS_VBLANK.vblank_start==0 on ADL+ even when doing LRR updatesVille Syrjälä1-0/+8
intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0 for clarity on ADL+ (non-DSI) because the hardware no longer uses that value. Do the same in intel_set_transcoder_timings_lrr() to make sure the registers stay consistent even when doing LRR timing updates. Cc: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-01-21drm/i915/psr: Allow changing Panel Replay mode without full modesetJouni Högander2-22/+17
Currently we are forcing full modeset if Panel Replay mode is changed. This is not necessary as long as we are not changing sink PANEL REPLAY ENABLE bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 register. This can be achieved by entering Panel Replay inactive mode (Live Frame mode) when Panel Replay is disabled and keep PANEL REPLAY ENABLE bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 enabled always if panel is just supporting Panel Replay. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-5-jouni.hogander@intel.com
2025-01-21drm/i915/psr: Make intel_psr_enable_sink as local static functionJouni Högander2-4/+2
Intel_psr_enable_sink is not used outside intel_psr.c. Convert it as local static function. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-4-jouni.hogander@intel.com
2025-01-21drm/i915/psr: Enable Panel Replay on sink always when it's supportedJouni Högander1-2/+1
Currently we are configuring Panel Replay on sink when it get's enabled. This means we need to do full modeset when enabling Panel Replay. This is required as DP specification is saying sink Panel Replay needs to be configured before link training. Avoid full modeset by enabling Panel Replay on sink always when it's supported by the sink and the source. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-3-jouni.hogander@intel.com
2025-01-21drm/i915/psr: Add new function for writing sink panel replay enable bitJouni Högander2-0/+8
According to DP/eDP specification only DP_PANEL_REPLAY_ENABLE has to be set prior link training. For this purpose add a new function which sets this bit on sink side if Panel Replay is supported by the sink and the source. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-2-jouni.hogander@intel.com
2025-01-21drm/xe/display: Re-use display vmas when possibleMaarten Lankhorst6-4/+19
i915 has this really nice, infrastructure where everything becomes complicated, GGTT needs eviction, etc.. Lets not do that, and make the dumbest possible interface instead. Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel fb. Link: https://patchwork.freedesktop.org/patch/msgid/20241206182032.196307-1-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Tested-by: Jani Saarinen <jani.saarinen@intel.com>
2025-01-21drm/i915/hdcp: Use correct function to check if encoder is HDMISuraj Kandpal1-1/+1
Use intel_encoder_is_hdmi function which was recently introduced to see if encoder is HDMI or not. --v2 -Add Fixes tag [Jani] Fixes: 6a3691ca4799 ("drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250117041247.1084381-1-suraj.kandpal@intel.com
2025-01-20drm/i915: Carve up skl_get_plane_caps()Ville Syrjälä1-24/+57
Split skl_get_plane_caps() into four variants: skl_plane_caps(), glk_plane_caps(), icl_plane_caps(), tgl_plane_caps(). Makes it easier to figure out what is actually going on there. v2: skl_plane_caps() should return u8 not bool Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241010164617.10280-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Relocate xe AUX hackVille Syrjälä1-5/+10
Move the xe AUX neutering out from skl_get_plane_caps() into the caller so that it'll be easier to refactor skl_get_plane_caps() into a more readable shape. This isn't really hardware specific anyway, and just some kind of bug/misfeature of xe. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-9-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Nuke ADL pre-production Wa_22011186057Ville Syrjälä1-8/+0
Wa_22011186057 (some CCS problem) only affected ADL A-stepping, which I presume is pre-production hw. Drop the dead code. Bspec: 54369 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-8-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Disable scanout VT-d workaround for TGL+Ville Syrjälä1-1/+1
TGL+ should no longer need any VT-d scanout workarounds. Don't apply any. Not 100% sure whether pre-SNB might also suffer from this. The workaround did originate on SNB but who knows if it was just never caught before that. Not that I ever managed to enable VT-d any older hardware. Last time I tried on my ILK it ate the disk! Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-7-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Reuse vlv_primary_min_alignment() for sprites as wellVille Syrjälä3-20/+9
Rename vlv_primary_min_alignment() to vlv_plane_min_alignment() and use it to replace vlv_sprite_min_alignment() since the behaviour is now identical when the plane init doesn't set up any async flips stuff. Technically VLV/CHV sprites do support async flips, so this also makes us a bit more future proof if/when we extend async flip support to more than one plane. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-6-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Use plane->can_async_flip() for alignment exceptionsVille Syrjälä2-39/+37
Async flips often require bigger alignment that sync flips. Currently we have HAS_ASYNC_FLIPS() checks strewn about to inidcate that async flips are generally supported and thus we want more alignment. Switch that over to using intel_plane_can_async_flip() so that we can handle these in a slightly less messy way. Currently we don't have cases where async flips would require different alignment for different modifiers on the same plane. We'll also move the HAS_ASYNC_FLIPS() check to the plane init code so that we can still use that as a quick way to disable the async flips workarounds for testing purposes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-5-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Introduce plane->can_async_flip()Ville Syrjälä6-52/+97
Move the "does this modifier support async flips?" check to be handled by the platform specific plane code instead of having a big mess in common code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-4-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Allow async flips with compression on ICLVille Syrjälä1-1/+20
Apparently ICL can do async flips with CCS. In fact it already seems to work on GLK, but apparently can lead to underruns there so we'll only enable it for ICL. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-3-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-20drm/i915: Allow async flips with render compression on TGL+Ville Syrjälä3-8/+26
Looks like CCS + async flips has been a thing for a while now. Enable this for TGL+ render compression modifiers. Note that we can't update AUX_DIST during async flips we must check to make sure it remains unchanged. We also can't do clear color. Supposedly there was some attempt to make it work, but apparently the issues only got ironed out in MTL. For now we'll not worry about it and refuse async flips with clear color modifiers. Bspec claims that media compression doesn't support async flips. Based on a quick test it does seem to work to some degree, but perhaps it has issues as well. Let's trust the spec here and continue to refuse async flips + media compression. Bspec: 49250,49251,49252,49253 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-2-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2025-01-17drm/i915/uc: Include requested frequency in slow firmware load messagesJohn Harrison2-10/+13
To aid debug of sporadic issues, include the requested frequency in the debug message as well as the actual frequency. That way we know for certain that the clamping is not because the driver forgot to ask. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241221014329.4048408-1-John.C.Harrison@Intel.com
2025-01-17drm/i915/dmc_wl: Track pipe interrupt registersGustavo Sousa1-0/+1
Pipe interrupt registers live in their respective pipes' power wells, which are below PG0. That means that they must also be tracked as registers that are powered-off during dynamic DC states. There are probably more ranges that we need to track down and add to the powered_off_ranges. However, let's make this change only about pipe interrupt registers to fix some vblank timeouts observed due to the DMC wakelock not being taken for those registers. In the future, we might want to replace powered_off_ranges with a new table to represent registers in PG0, which should be probably easier to maintain. Any register not belonging to that table should be considered powered off during dynamic DC states and, as such, requiring the DMC wakelock for access. Bspec: 72519, 71583 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-4-gustavo.sousa@intel.com
2025-01-17drm/i915/display: Wrap IRQ-specific uncore functionsGustavo Sousa1-45/+83
The current display IRQ code calls some IRQ-specific helpers that use intel_uncore_*() MMIO functions instead of the display-specific ones. Wrap those helpers to ensure that the proper display-specific hooks (currently only DMC wakelock handling) are called. v2: - Move functions to intel_display_irq.c instead of having them in intel_de.h. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-3-gustavo.sousa@intel.com
2025-01-17drm/i915/display: Use display MMIO functions in intel_display_irq.cGustavo Sousa1-101/+121
Most of MMIO accesses from intel_display_irq.c are currently done via uncore_*() functions instead of the display-specific ones, namely intel_de_*(). Because of that, DMC wakelock ends up being ignored and some invalid MMIO accesses are performed while display is in dynamic DC states. Thus, update the display IRQ code to use the intel_de_*() MMIO functions. After this change, we are left with some IRQ-specific functions that still use the unwrapped uncore_*() functions (i.e. gen2_irq_init, gen3_irq_reset and gen2_assert_iir_is_zero). We will deal with them in an upcoming change. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-2-gustavo.sousa@intel.com
2025-01-17drm/i915/dsc: Remove old comment about DSC 444 supportAnkit Nautiyal1-1/+0
DSC with YCbCr420 is now supported, so remove the comment mentioning support for only 444 format. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250110044131.3162682-3-ankit.k.nautiyal@intel.com
2025-01-17drm/i915/dsc: Use helper to calculate range_bpg_offsetAnkit Nautiyal1-29/+30
We get range_bpg_offset for different bpps based on linear-interpolation from values given for nearby bpps. Use a helper to get these values. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250110044131.3162682-2-ankit.k.nautiyal@intel.com
2025-01-17drm/i915/hdcp: Fix Repeater authentication during topology changeSuraj Kandpal1-0/+13
When topology changes, before beginning a new HDCP authentication by sending AKE_init message we need to first authenticate only the repeater. Only after repeater authentication failure, it makes sense to start a new HDCP authentication. Even though it made sense to not enable HDCP directly from check_link and schedule it for later, repeater authentication needs to be done immediately. --v2 -Fix comment grammatical errors [Ankit] Fixes: 47ef55a8b784 ("drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217083723.2883317-1-suraj.kandpal@intel.com
2025-01-17drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm valueDnyaneshwar Bhadane3-8/+57
In the C20 algorithm for HDMI TMDS, certain fields have been updated in the BSpec to set values for SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, such as tx_misc and dac_ctrl_range for Xe2LPD, Xe2HPD and MTL/ARL. This patch covers fields that need to be set based on the platform type. Some ARLs SoCs cannot be directly distinguished by their GMD version Id, Specifically to set value of tx_misc, so PCI Host Bridge IDs are used for differentiation. v2: - Relocate defines and Restructure the code(Jani) v3: - Replace conditions with display.platform.<platform> (jani) - Move host bridge check to new function (Jani) v4: - Identify/Replace arrowlake_u as meteorlake_u(Jani) Bspec:74165,74491 Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217201301.3593054-3-dnyaneshwar.bhadane@intel.com
2025-01-17drm/i915/display: Add MTL subplatforms definitionDnyaneshwar Bhadane2-0/+14
Separate MTL-U platform PCI ids in one define macro. Add the MTL U/ARL U as subplatform member in MTL platform description structure to use display.platform.<platform> from intel_display structure instead of IS_<PLATFORM>() in display code path. v2: - Club ARL-u in MTL and identify ARL-u as MTL-u subplatform(Jani) Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217201301.3593054-2-dnyaneshwar.bhadane@intel.com
2025-01-16drm/xe/dp: Enable DP tunnelingImre Deak1-2/+3
Enable the DP tunneling functionality in the xe driver. v2: Keep using IS_ENABLED() for kconfig options. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250114122857.1050090-1-imre.deak@intel.com
2025-01-15drm/i915: Add debug print about hw config table sizeJohn Harrison1-0/+3
Add debug info to help investigate a very rare bug: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13385 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241221011925.3944625-1-John.C.Harrison@Intel.com
2025-01-15drm/i915/vrr: Plumb the DSB into intel_vrr_send_push()Ville Syrjälä3-5/+15
Plumb the DSB down into intel_vrr_send_push() so that we can perform the opration on the DSB. TRANS_PUSH, being a transcoder register, needs non-posted writes to make it through. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-17-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915/vrr: Add extra vblank delay to estimatesVille Syrjälä1-6/+27
On ICL/TGL the VRR hardware injects an extra scanline just after vactive. This essentically behaves the same as an extra line of vblank delay, except it only appears in this one specific spot. Consider our DSB interrupt signalling scheme: 1. arm the update 2. wait for undelayed vblank (or rather safe window with VRR) 3. wait for enough usecs to get past the delayed vblank 4. signal interrupt to indicate that arming has latched If step 2 waits for end of vactive step 3 needs to account for the extra one scanline, or else we risk signalling the interrupt before the delayed vblank has actually elapsed. So include the extra scanline in our vblank delay estimates. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-16-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915/vrr: Fix vmin/vmax/flipline on TGL when using vblank delayVille Syrjälä1-6/+26
Turns out that TGL needs its vmin/vmax/flipline adjusted based on the vblank delay, otherwise the hardware pushes the vtotals further out. Make it so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-15-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915/vrr: Drop the extra vmin adjustment for ADL+Ville Syrjälä1-11/+26
Apparently only ICL/TGL need the annoying vmin adjustment. On ADL+ we can program flipline==vmin and the hardware actually respects that properly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-14-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915/vrr: Introduce intel_vrr_vblank_delay()Ville Syrjälä4-5/+27
Introduce a VRR specific function for determining the current vblank delay. Currently thus will give the same answer as intel_mode_vblank_delay() but that will change later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-13-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915: Extract intel_crtc_active_timings()Ville Syrjälä1-11/+22
Declutter intel_crtc_update_active_timings() a bit by moving the code that determines the timings into a separate function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-12-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915: Consolidate intel_pre_commit_crtc_state()Ville Syrjälä3-35/+45
We have approximately two copies of pre_commit_crtc_state(), one in the DSB code, the other in the vblank evasion code. Combine them into one. The slight difference between the two is that vblank evasion doesn't have a full atomic state (when called from the legacy cursor code), so it gets the old and new crtc state passed in by hand. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-11-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915: Extract intel_mode_vblank_delay()Ville Syrjälä3-4/+8
Extract the code that computes the hardware centric view of the vblank delay into a helper. We'll need a slightly different variant for VRR soon. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-10-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915: Include the scanline offset in the state dumpVille Syrjälä1-0/+4
When looking at raw hardware scanline numbers it's helpful to remember what the offset between the hardware values and our more human readable numbers should be. Include that in the state dump. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-9-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
2025-01-15drm/i915/vrr: Improve VRR state dumpVille Syrjälä1-6/+7
Dump the calculated vmin/vmax vtotal values in addition to the raw vmin/vmax/flipline values. Makes it much easier to see what kind of scanline values we should be expecting from the hardware. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-8-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 04:53:24 +0300