summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-12-02drm/i915/display: convert power domain code internally to struct intel_displayJani Nikula
Going forward, struct intel_display is the main device data structure for display. Convert intel_display_power.c internally first, leaving external interfaces for follow-up. v2: Rebase, checkpatch fixes Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d3284b30b53dd2fec786775ccb8992939360d774.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert power wells to struct intel_displayJani Nikula
Going forward, struct intel_display is the main device data structure for display. Switch the power well code over to it. v2: Fix parenthesis alignment Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b8c0ff5502a5df55ec7a160d90257c6f2befc0b6.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert for_each_power_domain_well() to struct intel_displayJani Nikula
Start converting display power domain code to struct intel_display. Start off with for_each_power_domain_well() and the reverse variant. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d21752baef1cab52ac3bec4f4e1f09f9acd6c1bf.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/display: convert for_each_power_well() to struct intel_displayJani Nikula
Start converting power well code to struct intel_display. Start off with for_each_power_well() and the reverse variant. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/30c3e44cdb9557a195b2e086bf169da8d8497c6b.1732808222.git.jani.nikula@intel.com
2024-12-02drm/i915/hdcp: Remove log for HDMI HDCP LIC checkSuraj Kandpal
We don't need to shout out loud if there is a Link Integrity Failure. This does not mean HDCP has failed, it is expected and taken into account in the HDCP Spec. The real failure happens when we are not able to reauthenticate and get HDCP running again for which we already have the right logging. --v2 -Remove the log altogether [Ankit] --v3 -Remove useless display variable 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/20241202060410.1872121-1-suraj.kandpal@intel.com
2024-12-01Get rid of 'remove_new' relic from platform driver structLinus Torvalds
The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-30drm/xe/display: Flush DMC wakelock release work on runtime suspendGustavo Sousa
We currently are not calling display runtime suspend functions when D3cold is not allowed. Because of that, we end up not disabling dynamic DC states (and do not go to DC9). With dynamic DC states enabled, we will also have DMC wakelock enabled. Since we use a delayed work to release the DMC wakelock, the work might get executed a little too late (after the PCI device has been put to D3hot) and we get a timeout warning ("DMC wakelock release timed out") because the MMIO for releasing the wakelock will be invalid after that point. To fix that, make sure we flush the release work at the end of xe_display_pm_runtime_suspend_late(). We can do that unconditionally because, if there is no pending work, that turns into a no-op. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-4-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-30drm/xe/display: Extract xe_display_pm_runtime_suspend_late()Gustavo Sousa
The current behavior for the runtime suspend case is that xe_display_pm_suspend_late() is only called when D3cold is allowed. Let's incorporate that behavior into a function specific to runtime PM and call it xe_display_pm_runtime_suspend_late(). With that, we keep stuff a bit more self-contained and allow having a place for adding more "late display runtime suspend"-related logic that isn't dependent on the "D3cold allowed" state. v2: - Fix typo in that caused xe_display_pm_runtime_suspend_late() to call itself instead of xe_display_pm_suspend_late(). - Add the empty version of xe_display_pm_runtime_suspend_late() for the !CONFIG_DRM_XE_DISPLAY case. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-3-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-30drm/i915/dmc_wl: Extract intel_dmc_wl_flush_release_work()Gustavo Sousa
We will need to flush the release work from outside in an upcoming change. Let's put that into a public interface and call it intel_dmc_wl_flush_release_work(). Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129164010.29887-2-gustavo.sousa@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-11-29Merge tag 'drm-next-2024-11-29' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Merge window fixes, mostly amdgpu and xe, with a few other minor ones, all looks fairly normal, i915: - hdcp: Fix when the first read and write are retried xe: - Wake up waiters after wait condition set to true - Mark the preempt fence workqueue as reclaim - Update xe2 graphics name string - Fix a couple of guc submit races - Fix pat index usage in migrate - Ensure non-cached migrate pagetable bo mappings - Take a PM ref in the delayed snapshot capture worker amdgpu: - SMU 13.0.6 fixes - XGMI fixes - SMU 13.0.7 fixes - Misc code cleanups - Plane refcount fixes - DCN 4.0.1 fixes - DC power fixes - DTO fixes - NBIO 7.11 fixes - SMU 14.0.x fixes - Reset fixes - Enable DC on LoongArch - Sysfs hotplug warning fix - Misc small fixes - VCN 4.0.3 fix - Slab usage fix - Jpeg delayed work fix amdkfd: - wptr handling fixes radeon: - Use ttm_bo_move_null() - Constify struct pci_device_id - Fix spurious hotplug - HPD fix rockchip - fix 32-bit build" * tag 'drm-next-2024-11-29' of https://gitlab.freedesktop.org/drm/kernel: (48 commits) drm/xe: Take PM ref in delayed snapshot capture worker drm/xe/migrate: use XE_BO_FLAG_PAGETABLE drm/xe/migrate: fix pat index usage drm/xe/guc_submit: fix race around suspend_pending drm/xe/guc_submit: fix race around pending_disable drm/xe: Update xe2_graphics name string drm/rockchip: avoid 64-bit division Revert "drm/radeon: Delay Connector detecting when HPD singals is unstable" drm/amdgpu/jpeg: cancel the jpeg worker drm/amdgpu: fix usage slab after free drm/amdgpu/vcn: reset fw_shared when VCPU buffers corrupted on vcn v4.0.3 drm/amdgpu: Fix sysfs warning when hotplugging drm/amdgpu: Add sysfs interface for vcn reset mask drm/amdgpu/gmc7: fix wait_for_idle callers drm/amd/pm: Remove arcturus min power limit drm/amd/pm: skip setting the power source on smu v14.0.2/3 drm/amd/pm: disable pcie speed switching on Intel platform for smu v14.0.2/3 drm/amdkfd: Use the correct wptr size drm/xe: Mark preempt fence workqueue as reclaim drm/xe/ufence: Wake up waiters after setting ufence->signalled ...
2024-11-29Merge tag 'driver-core-6.13-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is a small set of driver core changes for 6.13-rc1. Nothing major for this merge cycle, except for the two simple merge conflicts are here just to make life interesting. Included in here are: - sysfs core changes and preparations for more sysfs api cleanups that can come through all driver trees after -rc1 is out - fw_devlink fixes based on many reports and debugging sessions - list_for_each_reverse() removal, no one was using it! - last-minute seq_printf() format string bug found and fixed in many drivers all at once. - minor bugfixes and changes full details in the shortlog" * tag 'driver-core-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (35 commits) Fix a potential abuse of seq_printf() format string in drivers cpu: Remove spurious NULL in attribute_group definition s390/con3215: Remove spurious NULL in attribute_group definition perf: arm-ni: Remove spurious NULL in attribute_group definition driver core: Constify bin_attribute definitions sysfs: attribute_group: allow registration of const bin_attribute firmware_loader: Fix possible resource leak in fw_log_firmware_info() drivers: core: fw_devlink: Fix excess parameter description in docstring driver core: class: Correct WARN() message in APIs class_(for_each|find)_device() cacheinfo: Use of_property_present() for non-boolean properties cdx: Fix cdx_mmap_resource() after constifying attr in ->mmap() drivers: core: fw_devlink: Make the error message a bit more useful phy: tegra: xusb: Set fwnode for xusb port devices drm: display: Set fwnode for aux bus devices driver core: fw_devlink: Stop trying to optimize cycle detection logic driver core: Constify attribute arguments of binary attributes sysfs: bin_attribute: add const read/write callback variants sysfs: implement all BIN_ATTR_* macros in terms of __BIN_ATTR() sysfs: treewide: constify attribute callback of bin_attribute::llseek() sysfs: treewide: constify attribute callback of bin_attribute::mmap() ...
2024-11-29drm/i915/dp: use seq buf for printing ratesJani Nikula
Hand rolling the buffer overflow handling with snprintf() is a bit tedious. The seq_buf interface is made for this. Switch to it. Use struct intel_display while at it. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127131838.3268735-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-11-29drm/hibmc: Drop dependency on ARM64Thomas Zimmermann
There exists x86-based hardware with HiSilicon BMC chipsets. This driver works well on these systems. Drop the dependency on ARM64. Tested on RH1288 V3. v2: - s/Aarch86/ARM64 (Sui) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://patchwork.freedesktop.org/patch/msgid/20241127133732.470414-1-tzimmermann@suse.de
2024-11-28drm/rockchip: vop2: fix rk3588 dp+dsi maxclk verificationHeiko Stuebner
The clock is in Hz while the value checked against is in kHz, so actual frequencies will never be able to be below to max value. Fix this by specifying the max-value in Hz too. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Acked-by: Andy Yan <andyshrk@163.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241115151131.416830-1-heiko@sntech.de
2024-11-29Merge tag 'drm-xe-next-fixes-2024-11-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Update xe2 graphics name string (Matt Roper) - Fix a couple of guc submit races (Matt Auld) - Fix pat index usage in migrate (Matt Auld) - Ensure non-cached migrate pagetable bo mappings (Matt Auld) - Take a PM ref in the delayed snapshot capture worker (Matt Brost) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z0iOjKwEGVo_DmgY@fedora
2024-11-29Merge tag 'drm-misc-next-fixes-2024-11-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next A single buildfix for 32-bits rockchip compilation. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1f91eeaa-d3e4-4eca-9375-24c467f6976d@linux.intel.com
2024-11-28drm/i915/pps: Eliminate pointless get_delay() macroVille Syrjälä
Now that we have pps_units_to_msecs(), get_delay() looks rather pointless. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Extract pps_units_to_msecs()Ville Syrjälä
Add pps_units_to_msecs() as the counterpart to msecs_pps_units_to(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Extract msecs_to_pps_units()Ville Syrjälä
Replace all the hand rolled *10 stuff with something a bit more descriptive (msecs_to_pps_units()). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Spell out the eDP spec power sequencing delays a bit more clearlyVille Syrjälä
We determine the "spec" eDP power sequencing delays by referencing some max values from the eDP spec. Write out each number from the spec explicitly instead of precomputing the final number (that's the job of the computer). Makes it a bit easier to see what the supposed spec defined numbers actually are. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/lvds: Use struct intel_pps_delays for LVDS power sequencingVille Syrjälä
Reuse struct intel_pps_delays for the LVDS power sequencing delays instead of hand rolling it all. Perhaps in the future we could reuse some of the same PPS code for both LVDS and eDP (assuming we can decouple the PPS code from intel_dp...). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Rename intel_pps_delay membersVille Syrjälä
Stop using the semi-random eDP spec T1,T3,... names for the power sequencing delays, and instead call them by their human readable names. Much easier to keep track what delay goes where when you don't have to constantly cross reference against the eDP spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Decouple pps delays from VBT struct definitionVille Syrjälä
We currently lack a proper struct definition for the VBT power squencing delays, and instead we use the same struct definition (in intel_bios.h) for both the VBT layout and our driver side state. Decouple those two things by moving the current struct into intel_vbt_defs.h and adding a new one for the driver's use. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/pps: Store the power cycle delay without the +1Ville Syrjälä
The code initializing the power sequencing delays is a bit hard to follow. One confusing thing is that we keep doing the +/-1 adjustment for the hardware register value in several places. Simplify this a bit by doing the adjustment only when reading or writing the actual register. This also matches how the LVDS code does things. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241106215859.25446-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-11-28drm/i915/dsb: Nuke the MMIO->indexed register write logicVille Syrjälä
We've determined that indexed DSB writes are only faster than MMIO writes when writing the same register ~5 or more times. That seems very unlikely to happen in any other case than when using indexed LUT registers. Simplify the code by removing the MMIO->indexed write conversion logic and just emit the instruction as an indexed write from the get go. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-4-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28drm/i915/color: Stop using non-posted DSB writes for legacy LUTVille Syrjälä
DSB LUT register writes vs. palette anti-collision logic appear to interact in interesting ways: - posted DSB writes simply vanish into thin air while anti-collision is active - non-posted DSB writes actually get blocked by the anti-collision logic, but unfortunately this ends up hogging the bus for long enough that unrelated parallel CPU MMIO accesses start to disappear instead Even though we are updating the LUT during vblank we aren't immune to the anti-collision logic because it kicks in briefly for pipe prefill (initiated at frame start). The safe time window for performing the LUT update is thus between the undelayed vblank and frame start. Turns out that with low enough CDCLK frequency (DSB execution speed depends on CDCLK) we can exceed that. As we are currently using non-posted writes for the legacy LUT updates, in which case we can hit the far more severe failure mode. The problem is exacerbated by the fact that non-posted writes are much slower than posted writes (~4x it seems). To mititage the problem let's switch to using posted DSB writes for legacy LUT updates (which will involve using the double write approach to avoid other problems with DSB vs. legacy LUT writes). Despite writing each register twice this will in fact make the legacy LUT update faster when compared to the non-posted write approach, making the problem less likely to appear. The failure mode is also less severe. This isn't the 100% solution we need though. That will involve estimating how long the LUT update will take, and pushing frame start and/or delayed vblank forward to guarantee that the update will have finished by the time the pipe prefill starts... Cc: stable@vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12494 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28drm/i915/dsb: Don't use indexed register writes needlesslyVille Syrjälä
Turns out the DSB indexed register write command has rather significant initial overhead compared to the normal MMIO write command. Based on some quick experiments on TGL you have to write the register at least ~5 times for the indexed write command to come out ahead. If you write the register less times than that the MMIO write is faster. So it seems my automagic indexed write logic was a bit misguided. Go back to the original approach only use indexed writes for the cases we know will benefit from it (indexed LUT register updates). Currently we shouldn't have any cases where this truly matters (just some rare double writes to the precision LUT index registers), but we will need to switch the legacy LUT updates to write each LUT register twice (to avoid some palette anti-collision logic troubles). This would be close to the worst case for using indexed writes (two writes per register, and 256 separate registers). Using the MMIO write command should shave off around 30% of the execution time compared to using the indexed write command. Cc: stable@vger.kernel.org Fixes: 34d8311f4a1c ("drm/i915/dsb: Re-instate DSB for LUT updates") Fixes: 25ea3411bd23 ("drm/i915/dsb: Use non-posted register writes for legacy LUT") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241120164123.12706-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2024-11-28Revert "drm/i915/dpt: Make DPT object unshrinkable"Ville Syrjälä
This reverts commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c. Now that we forcefully evict all DPT VMAs during suspend there should be no problem allowing the shrinker to eat the DPT objects. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12965 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-5-ville.syrjala@linux.intel.com Acked-by: Brian Geffon <bgeffon@google.com> Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915/dpt: Evict all DPT VMAs on suspendVille Syrjälä
Currently intel_dpt_resume() tries to blindly rewrite all the PTEs for currently bound DPT VMAs. That is problematic because the CPU mapping for the DPT is only really guaranteed to exist while the DPT object has been pinned. In the past we worked around this issue by making DPT objects unshrinkable, but that is undesirable as it'll waste physical RAM. Let's instead forcefully evict all the DPT VMAs on suspend, thus guaranteeing that intel_dpt_resume() has nothing to do. To guarantee that all the DPT VMAs are evictable by intel_dpt_suspend() we need to flush the cleanup workqueue after the display output has been shut down. And for good measure throw in a few extra WARNs to catch any mistakes. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-4-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915: Intruduce display.wq.cleanupVille Syrjälä
Introduce a dedicated workqueue for the commit cleanup work. In the future we'll need this to guarantee all the cleanup works have finished at a specific point during suspend. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-3-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/i915: Don't reuse commit_work for the cleanupVille Syrjälä
Currently we reuse the commit_work for a later cleanup step. Let's not do that so that atomic ioctl handler won't accidentally wait for the cleanup work when it really wants to just wait on the commit_tail() part. We'll just add another work struct for the cleanup. Cc: Brian Geffon <bgeffon@google.com> Cc: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127061117.25622-2-ville.syrjala@linux.intel.com Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
2024-11-28drm/xe: Take PM ref in delayed snapshot capture workerMatthew Brost
The delayed snapshot capture worker can access the GPU or VRAM both of which require a PM reference. Take a reference in this worker. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 4f04d07c0a94 ("drm/xe: Faster devcoredump") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-5-matthew.brost@intel.com (cherry picked from commit 1c6878af115a4586a40d6c14d530fa9f93e0bd83) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/xe/migrate: use XE_BO_FLAG_PAGETABLEMatthew Auld
On some HW we want to avoid the host caching PTEs, since access from GPU side can be incoherent. However here the special migrate object is mapping PTEs which are written from the host and potentially cached. Use XE_BO_FLAG_PAGETABLE to ensure that non-cached mapping is used, on platforms where this matters. Fixes: 7a060d786cc1 ("drm/xe/mtl: Map PPGTT as CPU:WC") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126181259.159713-4-matthew.auld@intel.com (cherry picked from commit febc689b27d28973cd02f667548a5dca383d859a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/xe/migrate: fix pat index usageMatthew Auld
XE_CACHE_WB must be converted into the per-platform pat index for that particular caching mode, otherwise we are just encoding whatever happens to be the value of that enum. Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: <stable@vger.kernel.org> # v6.12+ Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126181259.159713-3-matthew.auld@intel.com (cherry picked from commit f3dc9246f9c3cd5a7d8fd70cfd805bfc52214e2e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/xe/guc_submit: fix race around suspend_pendingMatthew Auld
Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3371 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241122161914.321263-6-matthew.auld@intel.com (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/xe/guc_submit: fix race around pending_disableMatthew Auld
Currently in some testcases we can trigger: [drm] *ERROR* GT0: SCHED_DONE: Unexpected engine state 0x02b1, guc_id=8, runnable_state=0 [drm] *ERROR* GT0: G2H action 0x1002 failed (-EPROTO) len 3 msg 02 10 00 90 08 00 00 00 00 00 00 00 Looking at a snippet of corresponding ftrace for this GuC id we can see: 498.852891: xe_sched_msg_add: dev=0000:03:00.0, gt=0 guc_id=8, opcode=3 498.854083: xe_sched_msg_recv: dev=0000:03:00.0, gt=0 guc_id=8, opcode=3 498.855389: xe_exec_queue_kill: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x3, flags=0x0 498.855436: xe_exec_queue_lr_cleanup: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x83, flags=0x0 498.856767: xe_exec_queue_close: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x83, flags=0x0 498.862889: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0xa9, flags=0x0 498.863032: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x2b9, flags=0x0 498.875596: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x2b9, flags=0x0 498.875604: xe_exec_queue_deregister: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x2b1, flags=0x0 499.074483: xe_exec_queue_deregister_done: dev=0000:03:00.0, 5:0x1, gt=0, width=1, guc_id=8, guc_state=0x2b1, flags=0x0 This looks to be the two scheduling_disable racing with each other, one from the suspend (opcode=3) and then again during lr cleanup. While those two operations are serialized, the G2H portion is not, therefore when marking the queue as pending_disabled and then firing off the first request, we proceed do the same again, however the first disable response only fires after this which then clears the pending_disabled. At this point the second comes back and is processed, however the pending_disabled is no longer set, hence triggering the warning. To fix this wait for pending_disabled when doing the lr cleanup and calling disable_scheduling_deregister. Also do the same for all other disable_scheduling callers. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3515 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <mattheq.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241122161914.321263-5-matthew.auld@intel.com (cherry picked from commit ddb106d2120a0bf1c5ff87c71d059d193814da41) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/xe: Update xe2_graphics name stringMatt Roper
Since both Xe2 and Xe3 platforms currently use the same set of graphics IP feature flags, we associate the "graphics_xe2" structure with both IPs. Update the name string on that IP structure to clarify this and avoid confusion as Xe3 platforms start going into public CI. Fixes: 800d75bf20ae ("drm/xe/xe3: Define Xe3 feature flags") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241125194838.1190599-2-matthew.d.roper@intel.com (cherry picked from commit 4fe70f664a105391321c85b2af241001e8118d24) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2024-11-28drm/panfrost: Add GPU ID for MT8188 Mali-G57 MC3AngeloGioacchino Del Regno
The MediaTek MT8188 SoC has a Mali-G57 MC3 GPU and, similarly to MT8192, it has yet another special GPU ID. Add the GPU ID to the list and treat it as a standard Mali-G57. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241113112622.123044-1-angelogioacchino.delregno@collabora.com
2024-11-28drm/panthor: Fix a typo in the FW iface flag definitionsBoris Brezillon
Drop the _RD_ in the flag names. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241113160257.2002333-1-boris.brezillon@collabora.com
2024-11-27drm/xe: Only allow contiguous BOs to use xe_bo_vmapMatthew Brost
xe_bo_vmap only works on contiguous BOs, disallow xe_bo_vmap on BO unless we are certain the BO is contiguous. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-9-matthew.brost@intel.com
2024-11-27drm/xe: Set XE_BO_FLAG_PINNED in migrate selftest BOsMatthew Brost
We only allow continguous BOs to be vmapped, set XE_BO_FLAG_PINNED on BOs in migrate selftest as this forces continguous BOs and selftest uses vmaps. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-8-matthew.brost@intel.com
2024-11-27drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayedMatthew Brost
Non-contiguous mapping of BO in VRAM doesn't work, use ttm_bo_access instead. v2: - Fix error handling Fixes: 0eb2a18a8fad ("drm/xe: Implement VM snapshot support for BO's and userptr") Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-7-matthew.brost@intel.com
2024-11-27drm/xe/display: Update intel_bo_read_from_page to use ttm_bo_accessMatthew Brost
Don't open code vmap of a BO, use ttm_bo_access helper which is safe for non-contiguous BOs and non-visible BOs. Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-6-matthew.brost@intel.com
2024-11-27drm/xe: Take PM ref in delayed snapshot capture workerMatthew Brost
The delayed snapshot capture worker can access the GPU or VRAM both of which require a PM reference. Take a reference in this worker. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 4f04d07c0a94 ("drm/xe: Faster devcoredump") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-5-matthew.brost@intel.com
2024-11-27drm/xe: Add xe_ttm_access_memoryMatthew Brost
Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible VRAM easily be accessed. Add xe_ttm_access_memory which hooks into ttm_bo_access to access such memory. v4: - Assert memory access rather than taking RPM ref (Thomas / Auld) - Fix warning on xe_res_cursor.h for non-zero offset (Mika) Reported-by: Christoph Manszewski <christoph.manszewski@intel.com> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-4-matthew.brost@intel.com
2024-11-27drm/ttm: Add ttm_bo_accessMatthew Brost
Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible VRAM easily be accessed. Add ttm_bo_access, which is similar to ttm_bo_vm_access, to access such memory. v4: - Fix checkpatch warnings (CI) v5: - Fix checkpatch warnings (CI) v6: - Fix kernel doc (Auld) v7: - Move ttm_bo_access to ttm_bo_vm.c (Christian) Cc: Christian König <christian.koenig@amd.com> Reported-by: Christoph Manszewski <christoph.manszewski@intel.com> Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-3-matthew.brost@intel.com
2024-11-27drm/xe: Add xe_bo_vm_accessMatthew Brost
Add xe_bo_vm_access which is wrapper around ttm_bo_vm_access which takes rpm refs for device access. Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-2-matthew.brost@intel.com
2024-11-27drm/vc4: Drop planes that are completely off-screen or 0 crtc sizeDave Stevenson
It is permitted for a plane to be configured such that none of it is on-screen via either negative dest rectangle X,Y offset, or an offset that is greater than the crtc dimensions. These planes were resized via drm_atomic_helper_check_plane_state such that the source rectangle had a zero width or height, but they still created a dlist entry even though they contributed no pixels. In the case of vc6_plane_mode_set, that it could result in negative values being written into registers, which caused incorrect behaviour. Drop planes that result in a source width or height of 0 pixels or an on-screen size of 0 pixels to avoid the incorrect rendering. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-28-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Enable bg_fill if there are no planes enabledDave Stevenson
The default was to have enable_bg_fill disabled and the first plane set it if it wasn't opaque and covering the whole screen. However that meant that if no planes were enabled, then the background fill wasn't enabled, and would give a striped output from the uninitialised output buffer. Initialise it to enabled to avoid this. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-27-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Add additional warn_on for incorrect revisionsMaxime Ripard
Some code path in vc4 are conditional to a generation and cannot be executed on others. Let's put a WARN_ON if that ever happens. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-26-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
generated by cgit (git 2.34.1) at 2025-09-21 04:09:26 +0000