aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-06-27drm/xe/hwmon: Remove xe_hwmon_process_regKarthik Poosa1-49/+40
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 <[email protected]> Suggested-by: Lucas De Marchi <[email protected]> Cc: Badal Nilawar <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-06-27drm/mediatek: Log errors in probe with dev_err_probe()Nícolas F. R. A. Prado15-176/+125
Use dev_err_probe() to log errors in the probe function of all drm mediatek drivers. This avoids -EPROBE_DEFER return values from being logged as errors, like the following: mediatek-disp-rdma 1c002000.rdma: Failed to add component: -517 As a side benefit it also standardizes the format of the error in the log messages. Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240606-mtk-disp-rdma-dev-err-probe-v2-1-3898621767b8@collabora.com/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-06-27drm/mediatek: Call drm_atomic_helper_shutdown() at shutdown timeDouglas Anderson1-0/+8
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. This driver users the component model and shutdown happens in the base driver. The "drvdata" for this driver will always be valid if shutdown() is called and as of commit 2a073968289d ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop") we don't need to confirm that "drm" is non-NULL. Suggested-by: Maxime Ripard <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Fei Shao <[email protected]> Tested-by: Fei Shao <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240611102744.v2.1.I2b014f90afc4729b6ecc7b5ddd1f6dedcea4625b@changeid/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-06-27drm/mediatek: Remove less-than-zero comparison of an unsigned valueHsiao Chien Sung1-1/+1
Fix a Coverity error that less-than-zero comparison of an unsigned value is never true. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-06-27drm/i915/dsb: Try to document that DSB_STATUS bit 16 is level triggeredVille Syrjälä1-1/+1
DSB_STATUS bit 16 is supposed to be a sticky bit informing us whether the DSB was idle or not when the pipe's delayed vblank (when double buffered registers latch) occurred. Unfortunately it turns out this is a level triggred signal, ie. the bit will be set whenever the DSB is busy during the scanline window between start of delayed vblank and vtotal. Try to document that fact by renaming the bit. Sadly this also thwarts my plan to use this bit to sanity check that the (to be introduced) DSB based vblank evasion did its job correctly. That would require an edge triggered signal instead. So looks like we'll have to rely mostly on luck instead :( Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2024-06-27drm/xe: fix error handling in xe_migrate_update_pgtablesMatthew Auld1-4/+4
Don't call drm_suballoc_free with sa_bo pointing to PTR_ERR. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2120 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Cc: <[email protected]> # v6.8+ Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: handle AUX transfer timeoutsLucas Stach2-0/+12
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: only read AUX status when an error occuredLucas Stach1-4/+5
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: simplify and correct PLL lock checksLucas Stach3-35/+18
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: don't wait for PLL lock too earlyLucas Stach1-13/+1
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: move macro reset after link bandwidth settingLucas Stach1-8/+10
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: remove PLL lock check from analogix_dp_config_videoLucas Stach1-5/+0
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Robet Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: move basic controller init into runtime PMLucas Stach1-9/+5
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: move platform and PHY power handling into runtime PMLucas Stach1-13/+10
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: remove clk handling from analogix_dp_set_bridgeLucas Stach1-10/+1
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: remove unused analogix_dp_removeLucas Stach3-16/+1
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: handle clock via runtime PMLucas Stach1-33/+44
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: register AUX bus after enabling runtime PMLucas Stach1-8/+11
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/rockchip: analogix_dp: add runtime PM handlingLucas Stach1-9/+4
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 <[email protected]> Reviewed-by: Robert Foss <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: analogix_dp: remove unused platform power_on_end callbackLucas Stach3-8/+5
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: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/panic: Restrict graphical logo handling to built-inGeert Uytterhoeven1-1/+1
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: 294bbd1f2697 ("drm/panic: Add support for drawing a monochrome graphical logo") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4009fca99a7c05f617cc9899c6d0a5748415595d.1719391132.git.geert+renesas@glider.be
2024-06-27drm/panic: Do not select DRM_KMS_HELPERGeert Uytterhoeven2-2/+0
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 9544309775c3 ("drm/panic: Add support for color format conversion"). Remove the unneeded include of <drm/drm_format_helper.h>. Fixes: bf9fb17c6672 ("drm/panic: Add a drm panic handler") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/60155f8c939ed286e324a7c12a1daa69fe49fcf6.1719391132.git.geert+renesas@glider.be
2024-06-27Revert "drm/bridge: tc358767: Set default CLRSIPO count"Marek Vasut1-4/+4
This reverts commit 01338bb82fed40a6a234c2b36a92367c8671adf0. 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 <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: tc358767: Set LSCLK divider for SYSCLK to 1Marek Vasut1-1/+1
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: Alexander Stein <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: tc358767: Drop line_pixel_subtractMarek Vasut1-20/+1
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: Alexander Stein <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clockMarek Vasut1-0/+24
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: Alexander Stein <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/bridge: tc358767: Split tc_pxl_pll_en() into parameter calculation and ↵Marek Vasut1-7/+25
enablement 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: Alexander Stein <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27drm/ast: Inline drm_simple_encoder_init()Thomas Zimmermann1-5/+40
The function drm_simple_encoder_init() is a trivial helper and deprecated. Replace it with the regular call to drm_encoder_init(). Resolves the dependency on drm_simple_kms_helper.h. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27Merge tag 'amd-drm-fixes-6.10-2024-06-26' of ↵Dave Airlie12-15/+156
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.10-2024-06-26: amdgpu: - SMU 14.x fix - vram info parsing fix - mode1 reset fix - LTTPR fix - Virtual display fix - Avoid spurious error in PSP init Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27Merge tag 'drm-misc-fixes-2024-06-26' of ↵Dave Airlie4-4/+14
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.10-rc6: - nouveau tv mode fixes. - Add KOE TX26D202VM0BWA timings. - Fix fb_info when vmalloc is used, regression from CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-27Merge tag 'drm-intel-gt-next-2024-06-12' of ↵Dave Airlie20-143/+219
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next UAPI Changes: - Support replaying GPU hangs with captured context image (Tvrtko Ursulin) Driver Changes: Fixes/improvements/new stuff: - Automate CCS Mode setting during engine resets [gt] (Andi Shyti) - Revert "drm/i915: Remove extra multi-gt pm-references" (Janusz Krzysztofik) - Fix HAS_REGION() usage in intel_gt_probe_lmem() (Ville Syrjälä) - Disarm breadcrumbs if engines are already idle [gt] (Chris Wilson) - Shadow default engine context image in the context (Tvrtko Ursulin) - Support replaying GPU hangs with captured context image (Tvrtko Ursulin) - avoid FIELD_PREP warning [guc] (Arnd Bergmann) - Fix CCS id's calculation for CCS mode setting [gt] (Andi Shyti) - Increase FLR timeout from 3s to 9s (Andi Shyti) - Update workaround 14018575942 [mtl] (Angus Chen) Future platform enablement: - Enable w/a 16021333562 for DG2, MTL and ARL [guc] (John Harrison) Miscellaneous: - Pass the region ID rather than a bitmask to HAS_REGION() (Ville Syrjälä) - Remove counter productive REGION_* wrappers (Ville Syrjälä) - Fix typo [gem/i915_gem_ttm_move] (Deming Wang) - Delete the live_hearbeat_fast selftest [gt] (Krzysztof Niemiec) Signed-off-by: Dave Airlie <[email protected]> From: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/Zmmazub+U9ewH9ts@linux
2024-06-27Merge tag 'amd-drm-next-6.11-2024-06-22' of ↵Dave Airlie271-2015/+3226
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.11-2024-06-22: amdgpu: - HPD fixes - PSR fixes - DCC updates - DCN 4.0.1 fixes - FAMS fixes - Misc code cleanups - SR-IOV fixes - GPUVM TLB flush cleanups - Make VCN less verbose - ACPI backlight fixes - MES fixes - Firmware loading cleanups - Replay fixes - LTTPR fixes - Trap handler fixes - Cursor and overlay fixes - Primary plane zpos fixes - DML 2.1 fixes - RAS updates - USB4 fixes - MALL fixes - Reserved VMID fix - Silence UBSAN warnings amdkfd: - Misc code cleanups From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Airlie <[email protected]>
2024-06-26drm/xe/oa/uapi: Allow preemption to be disabled on the stream exec queueAshutosh Dixit2-1/+72
Mesa VK_KHR_performance_query use case requires preemption and timeslicing to be disabled for the stream exec queue. Implement this functionality here. v2: Minor change to debug print to print both ret values (Umesh) Acked-by: José Roberto de Souza <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Signed-off-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/oa: Allow stream enable/disable functions to return errorAshutosh Dixit1-16/+22
Stream enable/disable functions previously had void return because failure during function execution was not possible. This will change when we introduce functionality to disable preemption on the stream exec queue. Therefore, in preparation for this functionality, prepare this code to be able to handle error returns. Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/pf: Disable VFs on removeMichal Wajdeczko1-0/+5
We shouldn't leave VFs enabled when unloading the PF driver. Otherwise we will get a message like: [ ] xe 0000:4d:00.0: driver left SR-IOV enabled after remove Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Piotr Piórkowski <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/irq: remove xe_irq_shutdownIlia Levi3-14/+4
The cleanup is done by devres in irq_uninstall. Commit bbc9651fe9f4 ("drm/xe/irq: move irq_uninstall over to devm") resolved the ordering issue where irq_uninstall (registered with drmm) was called after pci_free_irq_vectors (registered with devm upon calling pci_alloc_irq_vectors). This happened because drmm action list is registered with devm very early in the init flow - before pci_alloc_irq_vectors. Now that irq_uninstall is registered with devm, it will be called before pci_free_irq_vectors and we can remove xe_irq_shutdown. Signed-off-by: Ilia Levi <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/pf: Trigger explicit FLR while disabling VFsMichal Wajdeczko3-0/+36
We attempt to unprovision all VFs GuC when disabling them, but GuC may reject such request if the target VF was previously active but VF driver didn't unload with explicit VF reset H2G action or the VMM has not started the VF FLR. To avoid mismatches between configs maintained the PF and GuC, trigger an explicit FLR sequences just before releasing resources. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/guc: Print GuC error codes as hex valueMichal Wajdeczko1-1/+1
We maintain GuC error code values in hex format. Also print them in that format for easier matching. While at it, slightly reformat the log and add missing \n. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/guc: Add more GuC error codes to ABIMichal Wajdeczko1-0/+31
There are many more error codes used that the GuC firmware can return in the RESPONSE_FAILURE message. Add to the ABI header those which are more likely to be seen by the PF or VF drivers. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/guc: Demote the H2G retry log message to debugMichal Wajdeczko1-2/+2
The G2H RETRY message sent by the GuC does not necessary indicate any serious problem and can be a part of the normal communication flow. Switch the log level from warning to more appropriate debug. This will also let the CI ignore these logs which were seen in few SR-IOV scenarios. While at it, use hex to print the reason and add missing \n. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/vf: Skip attempt to start GuC PC if VFMichal Wajdeczko1-4/+13
We have already marked the GuC PC feature as not applicable for VF devices, but we missed the fact that there may be still some privileged activities performed by this component, who does much more than its name suggests. Explicitly skip xe_guc_pc_start() if running as a VF driver and use a GT oriented message to report any error. v2: also skip xe_guc_pc_stop (Vinay) Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Vinay Belgaumkar <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Vinay Belgaumkar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/oa: Fix kernel doc in xe_drm.hAshutosh Dixit1-1/+2
Fix kernel doc in xe_drm.h. Also eliminate private/non-abi enum definitions. v2: Remove __DRM_XE_PERF_TYPE_MAX since it is unused (Michal) v3: Also remove DRM_XE_OA_PROPERTY_MAX since it can also be eliminated (Michal) Suggested-by: Michal Wajdeczko <[email protected]> Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/huc: Use GT oriented error messages in xe_huc.cMichal Wajdeczko1-11/+11
If applicable, we prefer GT oriented dmesg messages. Update all HuC related messages and use more user friendly error codes. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/guc: Request max GT freq during resumeVinay Belgaumkar3-3/+17
We already request max freq in the load path, moving it to __xe_guc_upload will ensure this speeds up GuC load in the resume path as well. v2: Rename xe_guc_pc_init_early since we now call it per GuC load (Michal W) v3: Keep pc_init_early() and init RPx values there (Rodrigo) Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/xe/lnl: Apply Wa_22019338487Vinay Belgaumkar13-13/+159
This WA requires us to limit media GT frequency requests to a certain cap value during driver load. Freq limits are restored after load completes, so perf will not be affected during normal operations. During normal driver operation, this WA requires dummy writes to media offset 0x380D8C after every ~63 GGTT writes. This will ensure completion of the LMEM writes originating from Gunit. During driver unload(before FLR), the WA requires that we set requested frequency to the cap value again. v3: Do not use WA number in function name. Call WA wrapper from xe_device. Rename some variables, check for locks in the correct function (Rodrigo). Ensure reset path is also covered for this WA. v4: Fix BAT failure v5: Add a function pointer for ggtt_ops (Michal W) v6: Fix name collision and use static function (Rodrigo) Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26Merge drm/drm-next into drm-xe-nextRodrigo Vivi507-14239/+21463
Need to sync some header include that propagated through drm-intel-next. v2: After some changes in drm/drm-next Signed-off-by: Rodrigo Vivi <[email protected]>
2024-06-26drm/panel: add Ilitek ILI9806E panel driverMichael Walle3-0/+412
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display controller. Co-developed-by: Gunnar Dibbern <[email protected]> Signed-off-by: Gunnar Dibbern <[email protected]> Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26drm/panel: add lincolntech lcd197 supportJerome Brunet3-0/+274
Add support for the Lincoln Technologies LCD197 1080x1920 DSI panel. Signed-off-by: Jerome Brunet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26drm/panel: sitronix-st7703: transition to mipi_dsi wrapped functionsTejas Vipin1-436/+400
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline handling") for sitronix-st7703 based panels. Signed-off-by: Tejas Vipin <[email protected]> Reviewed-by: Guido Günther <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-26gpu: ipu-v3: pre: don't use fixed timeout when waiting for safe windowLucas Stach1-8/+14
The timeout when waiting for the PRE safe window is rather short, as normally we would only need to wait a few dozen usecs for the problematic scanline region to pass and we don't want to spin too long in case something goes wrong. This however mixes badly with preemption, as we can easily get scheduled away from the CPU for a longer time than our timeout, in which case we would hit a spurious timeout and wrongly skip the PRE update. Instead of disabling preemption across the wait loop, potentially impacting the overall system latency, use a wait loop with a fixed max number of iterations, so time spent away from the CPU is not accounted against the timeout budget. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.