- 27 Jun, 2024 26 commits
-
-
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:
Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240627-congenial-pistachio-nyala-848cf4@houat
-
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:
-
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:
-
Thomas Zimmermann authored
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 <tzimmermann@suse.de> Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2024-06-12' of 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 authored
Merge tag 'amd-drm-next-6.11-2024-06-22' of 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 <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240622152523.2267072-1-alexander.deucher@amd.comSigned-off-by:
-
- 26 Jun, 2024 14 commits
-
-
Ashutosh Dixit authored
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 <jose.souza@intel.com> Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626181817.1516229-3-ashutosh.dixit@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ashutosh Dixit authored
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:
-
Michal Wajdeczko authored
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 <michal.wajdeczko@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626111827.1389-2-michal.wajdeczko@intel.comSigned-off-by:
-
Ilia Levi authored
The cleanup is done by devres in irq_uninstall. Commit bbc9651f ("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 <illevi@habana.ai> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240606124705.822451-1-illevi@habana.aiSigned-off-by:
-
Michal Wajdeczko authored
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 authored
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:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625141258.1257-4-michal.wajdeczko@intel.comSigned-off-by:
-
Michal Wajdeczko authored
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 authored
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 authored
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:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240622094253.1081-1-michal.wajdeczko@intel.comSigned-off-by:
-
Ashutosh Dixit authored
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 authored
If applicable, we prefer GT oriented dmesg messages. Update all HuC related messages and use more user friendly error codes. Signed-off-by:
-
Vinay Belgaumkar authored
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 <rodrigo.vivi@intel.com> Reviewed-by:
-
Vinay Belgaumkar authored
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 <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Need to sync some header include that propagated through drm-intel-next. v2: After some changes in drm/drm-next Signed-off-by:
-
