aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-04-25drm/{i915, xe}: Implement fbdev emulation as in-kernel clientThomas Zimmermann5-140/+80
Replace all code that initializes or releases fbdev emulation throughout the driver. Instead initialize the fbdev client by a single call to intel_fbdev_setup() after i915 has registered its DRM device. Just like similar code in other drivers, i915 fbdev emulation now acts like a regular DRM client. Do the same for xe. The fbdev client setup consists of the initial preparation and the hot-plugging of the display. The latter creates the fbdev device and sets up the fbdev framebuffer. The setup performs display hot-plugging once. If no display can be detected, DRM probe helpers re-run the detection on each hotplug event. A call to drm_client_dev_unregister() releases all in-kernel clients automatically. No further action is required within i915. If the fbdev framebuffer has been fully set up, struct fb_ops.fb_destroy implements the release. For partially initialized emulation, the fbdev client reverts the initial setup. Do the same for xe and remove its call to intel_fbdev_fini(). v8: - setup client in intel_display_driver_register (Jouni) - mention xe in commit message v7: - update xe driver - reword commit message v6: - use 'i915' for i915 device (Jouni) - remove unnecessary code for non-atomic mode setting (Jouni, Ville) - fix function name in commit message (Jouni) v3: - as before, silently ignore devices without displays v2: - let drm_client_register() handle initial hotplug - fix driver name in error message (Jani) - fix non-fbdev build (kernel test robot) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/{i915,xe}: Implement fbdev client callbacksThomas Zimmermann5-49/+25
Move code from ad-hoc fbdev callbacks into DRM client functions and remove the old callbacks. The functions instruct the client to poll for changed output or restore the display. The DRM core calls both, the old callbacks and the new client helpers, from the same places. The new functions perform the same operation as before, so there's no change in functionality. Fox xe, remove xe_display_last_close(), which restored the fbdev display. As with i915, the DRM core's drm_lastclose() performs this operation automatically. v8: - mention xe in commit message v7: - update xe driver v6: - return errors from client callbacks (Jouni) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/{i915,xe}: Unregister in-kernel clientsThomas Zimmermann2-0/+4
Unregister all in-kernel clients before unloading the i915 driver. For other drivers, drm_dev_unregister() does this automatically. As i915 and xe do not use this helper, they have to perform the call by themselves. Note that there are currently no in-kernel clients in i915 or xe. The patch prepares the drivers for a related update of their fbdev support. v8: - unregister clients in intel_display_driver_unregister() (Jani) - mention xe in commit message (Rodrigo, Jani) v7: - update xe driver Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/i915: Initialize fbdev DRM client with callback functionsThomas Zimmermann1-4/+39
Initialize i915's fbdev client by giving an instance of struct drm_client_funcs to drm_client_init(). Also clean up with drm_client_release(). Doing this in i915 prevents fbdev helpers from initializing and releasing the client internally (see drm_fb_helper_init()). No functional change yet; the client callbacks will be filled later. v6: - rename client to "intel-fbdev" (Jouni) v2: - call drm_fb_helper_unprepare() in error handling (Jani) - fix typo in commit message (Sam) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/i915: Move fbdev functionsThomas Zimmermann1-77/+77
Move functions within intel_fbdev.c to simplify later updates. Minor style fixes to make checkpatch happy, but no functional changes. v5: - style fixes (checkpatch) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/client: Export drm_client_dev_unregister()Thomas Zimmermann1-0/+13
Export drm_client_dev_unregister() for use by the i915 driver. The driver does not use drm_dev_unregister(), so it has to clean up the in-kernel DRM clients by itself. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2Jani Nikula4-128/+128
Pass the dev_priv parameter to the low-level helpers, and move the implicit dev_priv usage one level higher. sed -i "s/\(_MMIO_PIPE2(\|_MMIO_TRANS2(\|_MMIO_CURSOR2(\)/\1dev_priv, /" \ $(git ls-files drivers/gpu/drm/i915) Name the parameter "display", as the generics allow it to be display already. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/3a865664898586ff6cb8e74eab3d1f36eafc0557.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept baseJani Nikula2-40/+44
Most users of _MMIO_PIPE3() and _MMIO_PORT3() need to add the MMIO base to the registers. Convert the macros to _MMIO_BASE_PIPE3() and _MMIO_BASE_PORT3() to move the base addition until after the register selection. If the register address depends on DISPLAY_MMIO_BASE(), this removes the need to figure the base out for each register, and it only needs to be added once. Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4b95f125f5021abc00b5fc661b2728f1b583c01e.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-04-25gpu: drm: exynos: hdmi: eliminate uses of of_node_put()Shivani Gupta1-10/+5
Utilize the __free() cleanup handler within the hdmi_get_phy_io function to automatically release the device node when it is out of scope. This eliminates the manual invocation of of_node_put(), reducing the potential for memory leaks. The modification requires initializing the device node at the beginning of the function, ensuring that the automatic cleanup is safely executed. Consequently, this removes the need for error cleanup paths that utilize goto statements and the jump to out is no longer necessary. Suggested-by: Julia Lawall <[email protected]> Signed-off-by: Shivani Gupta <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: mixer: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: hdmi: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: vidi: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: scaler: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: rotator: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: mic: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: gsc: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: g2d: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: dsi: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: fimd: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-25drm/exynos: fimc: drop driver owner initializationKrzysztof Kozlowski1-1/+0
Core in platform_driver_register() already sets the .owner, so driver does not need to. Whatever is set here will be anyway overwritten by main driver calling platform_driver_register(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2024-04-24drm/xe: Check result of drmm_mutex_init()Michal Wajdeczko1-1/+4
Although it's unlikely that drmm_mutex_init() will fail during driver initialization, however we shouldn't ignore this case. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-24drm/xe/xe2: Add workaround 14021567978Tejas Upadhyay1-0/+5
Workaround 14021567978 applies to RenderCS xe2 V3: - Cover xe2_hpg as its landed upstream now V2(MattR): - Move tuning to wa and apply to xe2 Signed-off-by: Tejas Upadhyay <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-24drm/i915: Fix gt reset with GuC submission is disabledNirmoy Das1-2/+14
Currently intel_gt_reset() kills the GuC and then resets requested engines. This is problematic because there is a dedicated CSB FIFO which only GuC can access and if that FIFO fills up, the hardware will block on the next context switch until there is space that means the system is effectively hung. If an engine is reset whilst actively executing a context, a CSB entry will be sent to say that the context has gone idle. Thus if reset happens on a very busy system then killing GuC before killing the engines will lead to deadlock because of filled up CSB FIFO. To address this issue, the GuC should be killed only after resetting the requested engines and before calling intel_gt_init_hw(). v2: Improve commit message(John) Cc: John Harrison <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: John Harrison <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/i915: Refactor confusing __intel_gt_reset()Nirmoy Das8-13/+37
__intel_gt_reset() is really for resetting engines though the name might suggest something else. So add a helper function to remove confusions with no functional changes. v2: Move intel_gt_reset_all_engines() next to intel_gt_reset_engine() to make diff simple(John) Cc: John Harrison <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: John Harrison <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/guc: Improve GuC doorbell/context ID manager intro messageMichal Wajdeczko2-2/+4
We can use recently added str_plural() helper. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe: Introduce the wedged_mode debugfsRodrigo Vivi7-23/+149
So, the wedged mode can be selected per device at runtime, before the tests or before reproducing the issue. v2: - s/busted/wedged - some locking consistency v3: - remove mutex - toggle guc reset policy on any mode change Cc: Lucas De Marchi <[email protected]> Cc: Alan Previn <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-24drm/xe: Force wedged state and block GT reset upon any GPU hangRodrigo Vivi8-31/+129
In many validation situations when debugging GPU Hangs, it is useful to preserve the GT situation from the moment that the timeout occurred. This patch introduces a module parameter that could be used on situations like this. If xe.wedged module parameter is set to 2, Xe will be declared wedged on every single execution timeout (a.k.a. GPU hang) right after devcoredump snapshot capture and without attempting any kind of GT reset and blocking entirely any kind of execution. v2: Really block gt_reset from guc side. (Lucas) s/wedged/busted (Lucas) v3: - s/busted/wedged - Really use global_flags (Dafna) - More robust timeout handling when wedging it. v4: A really robust clean exit done by Matt Brost. No more kernel warns on unbind. v5: Simplify error message (Lucas) Cc: Matthew Brost <[email protected]> Cc: Dafna Hirschfeld <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Alan Previn <[email protected]> Cc: Himanshu Somaiya <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-24drm/xe: declare wedged upon GuC load failureRodrigo Vivi1-23/+17
Let's block the device upon any GuC load failure. But let's continue with the probe so guc logs can be read from the debugfs. v2: - s/wedged/busted - do not block probe or we lose guc_logs in debugfs (Matt) v3: - s/busted/wedged v4: Do not change __xe_guc_upload return. (Himal) Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-24drm/xe: Introduce a simple wedged stateRodrigo Vivi5-1/+36
Introduce a very simple 'wedged' state where any attempt to access the GPU is entirely blocked. On some critical cases, like on gt_reset failure, we need to block any other attempt to use the GPU. Otherwise we are at a risk of reaching cases that would force us to reboot the machine. So, when this cases are identified we corner and block any GPU access. No IOCTL and not even another GT reset should be attempted. The 'wedged' state in Xe is an end state with no way back. Only a device "re-probe" (unbind + bind) can restore the GPU access. v2: - s/wedged/busted (Lucas) - use unbind+bind instead of module reload (Lucas) - added more info on unbind operations and instruction on bug report - only print the message once. v3: - s/busted/wedged (Ashutosh, Tvrtko, Thomas) - don't assume user has sudo and tee available (Lucas) v4: - remove unnecessary cases around ct communication or migration. Cc: Ashutosh Dixit <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Anshuman Gupta <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-04-24drm/xe: Add INSTDONE registers to devcoredumpJosé Roberto de Souza4-0/+158
This registers contains important information that can help with debug of GPU hangs. While at it also fixing the double line jump at the end of engine registers for CCS engines. v2: - print other INSTDONE registers v3: - add for_each_geometry/compute_dss() v4: - print one slice_common_instdone per glice in DG2+ v5: - rename registers prefix from DG2 to XEHPG (Zhanjun) Cc: Rodrigo Vivi <[email protected]> Cc: Matt Roper <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe: Add helpers to loop over geometry and compute DSSJosé Roberto de Souza3-0/+37
Some DSS can only be available for geometry while others can only be available for compute. So here adding helpers to loop only available DSS for given usage. User of this helper will come in the next patch. v2: - drop has_dss() Cc: Rodrigo Vivi <[email protected]> Cc: Matt Roper <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe: Store xe_hw_engine in xe_hw_engine_snapshotJosé Roberto de Souza2-5/+5
A future patch will require gt and xe device structs, so here replacing class by hwe. Cc: Rodrigo Vivi <[email protected]> Cc: Matt Roper <[email protected]> Cc: Zhanjun Dong <[email protected]> Cc: Himal Prasad Ghimiray <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/guc: Fix arguments passed to relay G2H handlersMichal Wajdeczko1-2/+2
By default CT code was passing just payload of the G2H event message, while Relay code expects full G2H message including HXG header which contains DATA0 field. Fix that. Fixes: 26d4481ac23f ("drm/xe/guc: Start handling GuC Relay event messages") Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 48c64d495fbef343c59598a793d583dfd199d389) Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-24drm/xe: call free_gsc_pkt only once on action add failureHimal Prasad Ghimiray1-8/+1
The drmm_add_action_or_reset function automatically invokes the action (free_gsc_pkt) in the event of a failure; therefore, there's no necessity to call it within the return check. -v2 Fix commit message. (Lucas) Fixes: d8b1571312b7 ("drm/xe/huc: HuC authentication via GSC") Cc: Rodrigo Vivi <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit 22bf0bc04d273ca002a47de55693797b13076602) Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-24drm/xe: Remove sysfs only once on action add failureHimal Prasad Ghimiray3-14/+11
The drmm_add_action_or_reset function automatically invokes the action (sysfs removal) in the event of a failure; therefore, there's no necessity to call it within the return check. Modify the return type of xe_gt_ccs_mode_sysfs_init to int, allowing the caller to pass errors up the call chain. Should sysfs creation or drmm_add_action_or_reset fail, error propagation will prompt a driver load abort. -v2 Edit commit message (Nikula/Lucas) use err_force_wake label instead of new. (Lucas) Avoid unnecessary warn/error messages. (Lucas) Fixes: f3bc5bb4d53d ("drm/xe: Allow userspace to configure CCS mode") Cc: Lucas De Marchi <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Niranjana Vishwanathapura <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Himal Prasad Ghimiray <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit a99641e38704202ae2a97202b3d249208c9cda7f) Signed-off-by: Lucas De Marchi <[email protected]>
2024-04-24drm: xlnx: zynqmp_dpsub: Set input live formatAnatoliy Klymenko3-17/+90
Program live video input format according to selected media bus format. In the bridge mode of operation, DPSUB is connected to FPGA CRTC which almost certainly supports a single media bus format as its output. Expect this to be delivered via the new bridge atomic state. Program DPSUB registers accordingly. Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm: xlnx: zynqmp_dpsub: Minimize usage of global flagAnatoliy Klymenko1-9/+3
Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer context. This flag signals whether the driver runs in DRM CRTC or DRM bridge mode, assuming that all display layers share the same live or non-live mode of operation. Using per-layer mode instead of global flag will simplify future support of the hybrid scenario. Remove redundant checks in DMA request/release contexts as zynqmp_disp_layer.info is well-defined for all layer types, including the correct number of DMA channels required for each particular layer. Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm: xlnx: zynqmp_dpsub: Anounce supported input formatsAnatoliy Klymenko3-4/+139
DPSUB in bridge mode supports multiple input media bus formats. Announce the list of supported input media bus formats via drm_bridge.atomic_get_input_bus_fmts callback. Introduce a set of live input formats supported by DPSUB. Add safeguards to format list functions to prevent their misuse in the different layer modes contexts. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm: xlnx: zynqmp_dpsub: Add connected live layer helperAnatoliy Klymenko1-14/+23
Add a helper function capturing the first connected live display layer discovery logic. Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm: xlnx: zynqmp_dpsub: Update live format definesAnatoliy Klymenko1-4/+4
Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register layout. These defines were never referenced before, so no other changes required. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm: xlnx: zynqmp_dpsub: Set layer mode during creationAnatoliy Klymenko4-18/+20
Set layer mode of operation (live or dma-based) during layer creation. Each DPSUB layer mode of operation is defined by corresponding DT node port connection, so it is possible to assign it during layer object creation. Previously it was set in layer enable functions, although it is too late as setting layer format depends on layer mode, and should be done before given layer enabled. Signed-off-by: Anatoliy Klymenko <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/pf: Clamp maximum execution quantum to 100sMichal Wajdeczko1-6/+12
GuC is silently clamping values of the execution quantum and preemption timeout KLVs to 100s. Perform explicit clamping on the driver side as later there is no way to read back values used by the firmware and we shouldn't mislead the user about actual values being used when we print them in dmesg or debugfs. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/guc: Update VF configuration KLVs definitionsMichal Wajdeczko1-2/+12
GuC firmware specification says that maximum value for the execution quantum KLV is 100s and anything exceeding that will be clamped. The same limitation applies to the preemption timeout KLV. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/pf: Expose SR-IOV policy settings over debugfsMichal Wajdeczko1-0/+53
We already have functions to configure SR-IOV policies. Allow to tweak those policy settings over debugfs. Reviewed-by: Piotr Piórkowski <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/pf: Expose SR-IOV VF control commands over debugfsMichal Wajdeczko1-0/+79
We already have functions to control the VF. Allow to control the VF using debugfs. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/pf: Expose SR-IOV VFs configuration over debugfsMichal Wajdeczko4-0/+227
We already have functions to configure VF resources and to print actual provisioning details. Expose this functionality in debugfs to allow experiment with different settings or inspect details in case of unexpected issues with the provisioning. As debugfs attributes are per-VF, we use parent d_inode->i_private to store VFID, similarly how we did for per-GT attributes. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/kunit: Add PF service testsMichal Wajdeczko2-0/+236
Start with basic tests for VF/PF ABI version negotiation. As we treat all platforms in the same way, we can run the tests on one platform. More tests will likely come later. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe/pf: Add SR-IOV GuC Relay PF servicesMichal Wajdeczko6-2/+646
We already have mechanism that allows a VF driver to communicate with the PF driver, now add PF side handlers for VF2PF requests defined in version 1.0 of VF/PF GuC Relay ABI specification. The VF2PF_HANDSHAKE request must be used by the VF driver to negotiate the ABI version prior to sending any other request. We will reset any negotiated version later during FLR. The outcome of the VF2PF_QUERY_RUNTIME requests depends on actual platform, for legacy platforms used as SDV is provided as-is, for latest platforms it is preliminary, and might be changed. Signed-off-by: Michal Wajdeczko <[email protected]> Reviewed-by: Piotr Piórkowski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe: Add few more GT register definitionsMichal Wajdeczko1-0/+3
While we are not using these registers right now, they are part of some runtime register lists that PF driver share with VFs on some legacy platforms that we might want to support as SDV. Reviewed-by: Piotr Piórkowski <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/xe: Add helper to calculate adjusted register offsetMichal Wajdeczko2-23/+22
Our MMIO accessing functions automatically adjust addresses for the media registers based on mmio.adj_limit and mmio.adj_offset logic. Move it to the separate helper to avoid code duplication and to allow using it by the upcoming changes to PF driver code. 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]
Powered by cgit, Gruvboxed by Blaster4385.