- 05 Jul, 2024 1 commit
-
-
https://gitlab.freedesktop.org/drm/xe/kernelDaniel Vetter authored
Driver Changes: - Fix in migration code (Auld) - Simplification in HWMon related code (Karthik) - Fix in forcewake logic (Nirmoy) - Fix engine utilization information (umesh) - Clean up on MOCS related code (Roper) - Fix on multicast register (Roper) - Fix TLB invalidation timeout (Nirmoy) - More SRIOV preparation (Michal) - Fix out-of-bounds array access (Lucas) - Fixes around some mutex utilization (Ashutosh, Vinay) - Expand LNL workaround to BMG (Vinay) Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZoROvquFrTFhk3Pb@intel.com
-
- 02 Jul, 2024 2 commits
-
-
Vinay Belgaumkar authored
Extend this WA to BMG GT as well. In this case media GT is not affected. The cap frequencies and max allowed ggtt writes are different as well. On BMG, we need to do a flush after 1100 GGTT writes, and we need to limit the GT frequency request to 2133 Mhz during driver load and leave it at that value after driver unloads. v3: Fix checkpatch issue Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240701231529.2582452-2-vinay.belgaumkar@intel.comSigned-off-by:
-
Vinay Belgaumkar authored
When skip_guc_pc is set and/or this is for a VF. Fixes: 3b1592fb ("drm/xe/lnl: Apply Wa_22019338487") Signed-off-by:
-
- 01 Jul, 2024 6 commits
-
-
Ashutosh Dixit authored
The mutex allocated in xe_oa_stream_init() was never previously destroyed. Do so now. Fixes: e936f885 ("drm/xe/oa/uapi: Expose OA stream fd") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628052125.1847989-1-ashutosh.dixit@intel.com
-
Lucas De Marchi authored
Increment the counter before checking for number of rules, otherwise when there's no XE_RTP_MATCH_OR an out-of-bounds access is done, as reported by kasan: BUG: KASAN: global-out-of-bounds in rule_matches+0xb6d/0x11c0 [xe] Read of size 1 at addr ffffffffa0a50b70 by task systemd-udevd/243 Fixes: dc72c52a ("drm/xe/rtp: Allow to OR rules") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628161726.836734-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Michal Wajdeczko authored
Any prior configurations pushed to the GuC are lost when the GT is reset. Push again all non-empty VF configurations to the GuC as part of the GuC reset procedure. This will also help restore early manual provisioning, when the PF was in the meantime suspended and then resumed. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240701102738.934-3-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Our debugfs allows to view and change VFs' provisioning configs. If we attempt to experiment with VFs provisioning before enabling them, this early config will affect fair provisioning calculations, and will also be overwritten, which is undesirable behavior. To improve this, check if the VFs configs are empty (unprovisioned) before starting the fair provisioning procedure. Signed-off-by:
-
Michal Wajdeczko authored
We can remove #ifdef CONFIG_PCI_IOV in .c files if we provide dummy replacement of the xe_pci_sriov_configure() function. Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627104305.1477-1-michal.wajdeczko@intel.com
-
Nirmoy Das authored
GuC TLB invalidation depends on GuC to process the request from the CT queue and then the real time to invalidate TLB. Add a function to return overestimated possible time a TLB inval H2G might take which can be used as timeout value for TLB invalidation wait time. v4: Make sure CTB is in 4K blocks(Michal) and other doc fixes v3: Pass CT to xe_guc_ct_queue_proc_time_jiffies() (Michal) Add tlb_timeout_jiffies() that replaces TLB_TIMEOUT(Michal) v2: Address reviews from Michal. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1622 Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Suggested-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
- 28 Jun, 2024 4 commits
-
-
Matt Roper authored
A couple copy/paste mistakes in the code that selects steering targets for OADDRM and INSTANCE0 unintentionally clobbered the steering target for DSS ranges in some cases. The OADDRM/INSTANCE0 values were also not assigned as intended, although that mistake wound up being harmless since the desired values for those specific ranges were '0' which the kzalloc of the GT structure should have already taken care of implicitly. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
It's not very obvious what the difference is between the 'size' and 'n_entries' fields of the MOCS structure. Rename both fields slightly and add some comments explaining that one is the documentation-defined table size, while the other is the number of entries that can be programmed into the hardware (and the documented table size can potentially be smaller than the number of hardware entries). Signed-off-by:
-
Matt Roper authored
Rely more heavily on assertions to describe the MOCS programming invariants. CI checks these assertions and will ensure no violations sneak in due to programmer error, so we can remove some of the redundant WARN and silent return checks from non-debug builds. Also tweak/augment some of the existing assertions: there's no reason we'd ever want a platform not to have a MOCS 'ops' structure hooked up so ensure info->ops is non-NULL. Likewise, we should never have a case where the bspec-defined MOCS setting table is larger than the number of MOCS registers exposed by the hardware, so add an extra assert on those sizes as well. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
Per client engine utilization uses RING_TIMESTAMP to return drm-total-cycles to the user. Current code uses XE_FW_GT to read this register on the first available engine in a GT. When testing on DG2, it is observed that this value is 0 when running test on some engines. To resolve that, get the hwe domain specific FW for reading the engine timestamp. v2: - update commit message - use domain specific FW (Matt) v3: - Drop check for hwe in the helper (Matt, Michal) v4: - checkpatch fixes v5: Rebase Fixes: 188ced1e ("drm/xe/client: Print runtime to fdinfo") Signed-off-by:
-
- 27 Jun, 2024 27 commits
-
-
Dave Airlie authored
Merge tag 'drm-habanalabs-next-2024-06-23' of https://github.com/HabanaAI/drivers.accel.habanalabs.kernel into drm-next This tag contains habanalabs driver changes for v6.11. The notable changes are: - uAPI changes: - Use device-name directory in debugfs-driver-habanalabs. - Expose server type in debugfs. - New features and improvements: - Gradual sleep in polling memory macro. - Reduce Gaudi2 MSI-X interrupt count to 128. - Add Gaudi2-D revision support. - Firmware related changes: - Add timestamp to CPLD info. - Gaudi2: Assume hard-reset by firmware upon MC SEI severe error. - Align Gaudi2 interrupt names. - Check for errors after preboot is ready. - Bug fixes and code cleanups: - Move heartbeat work initialization to early init. - Fix a race when receiving events during reset. - Change the heartbeat scheduling point. - Maintainers: - Change habanalabs maintainer and git repo path. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Ofir Bitton <obitton@habana.ai> Link: https://patchwork.freedesktop.org/patch/msgid/ZnfIjTH5AYQvPe7n@obitton-vm-u22.habana-labs.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-2024-06-27' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.11: UAPI Changes: Cross-subsystem Changes: Core Changes: - panic: Monochrome logo support, Various fixes - ttm: Improve the number of page faults on some platforms, Fix test build breakage with PREEMPT_RT, more test coverage and various test improvements Driver Changes: - Add missing MODULE_DESCRIPTION where needed - ipu-v3: Various fixes - vc4: Monochrome TV support - bridge: - analogix_dp: Various improvements and reworks, handle AUX transfers timeout - tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR, Fix clock calculations - panels: - More transitions to mipi_dsi wrapped functions - New panels: Lincoln Technologies LCD197, Ortustech COM35H3P70ULC, Signed-off-by:
-
https://gitlab.freedesktop.org/drm/xe/kernelDave Airlie authored
UAPI Changes: - New uapi adding OA functionality to Xe (Ashutosh) Cross-subsystem Changes: - devcoredump: Add dev_coredumpm_timeout (Jose) Driver Changes: - More SRIOV preparation, including GuC communication improvements (Michal) - Kconfig update: do not select ACPI_BUTTON (Jani) - Rework GPU page fault handling (Brost) - Forcewake clean-up and fixes (Himal, Michal) - Drop EXEC_QUEUE_FLAG_BANNED (Brost) - Xe/Xe2 Workarounds fixes and additions (Tejas, Akshata, Sai, Vinay) - Xe devcoredump changes (Jose) - Tracing cleanup and add mmio tracing (RK) - Add BMG PCI IDs (Roper) - Scheduler fixes and improvements (Brost) - Some overal driver clean-up around headers and print macros (Michal) - Rename xe_exec_queue::compute to xe_exec_queue::lr (Francois) - Improve RTP rules to allow easier 'OR' conditions in WA declaration (Lucas) - Use ttm_uncached for BO with NEEDS_UC flag (Michal) - Other OA related work and fixes (Ashutosh, Michal, Jose) - Simplify locking in new_vma (Brost) - Remove xe_irq_shutdown (Ilia) Signed-off-by:
-
Nirmoy Das authored
xe_force_wake_get() can return error so check it's return value before reading gpu_timestamp value. v2: set HWE to NULL instead of setting timestamp to 0(Lucas) Add a warn on for xe_force_wake_put(Himal) Fixes: 188ced1e ("drm/xe/client: Print runtime to fdinfo") Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: -
Karthik Poosa authored
Remove xe_hwmon_process_reg as it is a umbrella function which can be avoided (Lucas). v2: Improve commit message. (Badal) v3: Add couple of comments. (Lucas) Signed-off-by:
Karthik Poosa <karthik.poosa@intel.com> Suggested-by:
-
Matthew Auld authored
Don't call drm_suballoc_free with sa_bo pointing to PTR_ERR. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2120 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240620102025.127699-2-matthew.auld@intel.com
-
Lucas Stach authored
Timeouts on the AUX bus are to be expected in certain normal operating conditions. There is no need to raise an error log or re-initialize the whole AUX state machine. Simply acknowledge the AUX_ERR interrupt and let upper layers know about the timeout. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Robert Foss <rfoss@kernel.org> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Lucas Stach authored
All AUX error responses raise the AUX_ERR interrupt, so there is no need to read the AUX status register in normal operation. Only read the status when an error occurred and we can expect a different status than OK. Signed-off-by:
-
Lucas Stach authored
Move the wait loop into its own function, so it doesn't need to be replicated in multiple locations. Also move the PLL lock checks between setting the link bandwidth, which may cause the PLL to unlock, and the MACRO_RST which needs the PLL to be locked. Signed-off-by:
-
Lucas Stach authored
The PLL will be reconfigured later, which may cause it to go out of lock anyway, so there is no point in waiting for the PLL to lock here. Instead we can continue execution of the link setup, which will properly set the PLL parameters and will wait for the PLL to lock at the appropriate times. Signed-off-by:
-
Lucas Stach authored
Setting the link bandwidth may change the PLL parameters, which will cause the PLL to go out of lock, so make sure to apply the MACRO_RST, which according to the comment is required to be pulsed after the PLL is locked. Signed-off-by:
-
Lucas Stach authored
This check is way too late in the DP enable flow. The PLL must be locked much earlier, before any link training can happen. If the PLL is unlocked at that point in time there is something seriously wrong in the enable flow. Signed-off-by:
-
Lucas Stach authored
Make sure the controller is in a basic working state after runtime resume. Keep the analog function enable in the mode set path as this enables parts of the PHY that are only required to be powered when there is a data stream being sent out. Signed-off-by:
-
Lucas Stach authored
Platform and PHY power isn't only required when the actual display data stream is active, but may be required earlier to support AUX channel transactions. Move them into the runtime PM calls, so they are properly managed whenever various other parts of the driver need them to be active. Signed-off-by:
-
Lucas Stach authored
The clock is already managed by runtime PM, which is properly invoked from the analogix_dp_set_bridge function, so there is no need for an additional reference. Signed-off-by:
-
Lucas Stach authored
Now that the clock is handled dynamically through analogix_dp_resume/suspend and it isn't statically enabled in the driver probe routine, there is no need for the remove function anymore. Signed-off-by:
-
Lucas Stach authored
There is no reason to enable the controller clock in driver probe, as there is no HW initialization done in this function. Instead rely on either runtime PM to handle the controller clock or statically enable it in the driver bind routine, after which real hardware access is required to work. Signed-off-by:
-
Lucas Stach authored
AUX transactions require the controller to be in working state and take a runtime PM reference. To avoid potential races beween the first transactions on the bus and runtime PM being set up, move the AUX registration behind the runtime PM setup. Signed-off-by:
-
Lucas Stach authored
Hook up the runtime PM suspend/resume paths to make the rockchip glue behave more like the exynos one. The same suspend/resume functions are used for system sleep via the runtime PM force suspend/resume. Signed-off-by:
-
Lucas Stach authored
This isn't used, but gives the impression of the power on and power off platform calls being non-symmetrical. Remove the unused callback and rename the power_on_start to simply power_on. Signed-off-by:
-
Geert Uytterhoeven authored
When CONFIG_DRM_PANIC=y, but CONFIG_DRM=m: ld: drivers/gpu/drm/drm_panic.o: in function `drm_panic_setup_logo': drivers/gpu/drm/drm_panic.c:99: multiple definition of `init_module'; drivers/gpu/drm/drm_drv.o:drivers/gpu/drm/drm_drv.c:1079: first defined here Fix this by restricting the graphical logo handling and its device_initcall() to the built-in case. Logos are freed during late kernel initialization, so they are no longer available at module load time anyway. Fixes: 294bbd1f ("drm/panic: Add support for drawing a monochrome graphical logo") Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406261341.GYsbLpN1-lkp@intel.com/Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Signed-off-by:
-
Geert Uytterhoeven authored
DRM core code cannot call into DRM helper code, as this would lead to circular references in the modular case. Hence drop the selection of DRM_KMS_HELPER. It was unused anyway, as v10 switched from using the DRM format helpers to its own color format conversion, cfr. commit 95443097 ("drm/panic: Add support for color format conversion"). Remove the unneeded include of <drm/drm_format_helper.h>. Fixes: bf9fb17c ("drm/panic: Add a drm panic handler") Signed-off-by:
-
Marek Vasut authored
This reverts commit 01338bb8. With clock improvements in place, this seems to be no longer necessary. Set the CLRSIPO to default setting recommended by manufacturer. Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Marek Vasut authored
The only information in the datasheet regarding this divider is a note in SYS_PLLPARAM register documentation which states that when LSCLK is 270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test confirms using LSCLK_DIV 1 has no adverse effects either. In the worst case, the internal TC358767 clock would run faster. Reviewed-by:
-
Marek Vasut authored
This line_pixel_subtract is no longer needed now that the bridge can request and obtain specific pixel clock on input to the bridge, with clock frequency that matches the Pixel PLL frequency. The line_pixel_subtract is now always 0, so drop it entirely. The line_pixel_subtract was not reliable as it never worked when the Pixel PLL and input clock were off just so that the required amount of pixels to subtract would not be whole integer. Reviewed-by:
-
Marek Vasut authored
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and pass it down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by:
-
Marek Vasut authored
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc() and then configures the Pixel PLL register. This is a preparatory patch for further rework, where tc_pxl_pll_calc() will also be used to find out the exact clock frequency generated by the Pixel PLL. This frequency will be used as adjusted_mode clock frequency and passed down the display pipeline to obtain exactly this frequency on input into this bridge. The precise input frequency that matches the Pixel PLL frequency is important for this bridge, as if the frequencies do not match, the bridge does suffer VFIFO overruns or underruns. Reviewed-by:
-
