summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-04-25drm/xe/pf: Expose PF service details via debugfsMichal Wajdeczko
For debug purposes we might want to verify which registers values PF is sharing with VFs and to view which VF/PF ABI versions were negotiated by the VFs. Plug the 'print' functions already provided by the PF service code into our debugfs. 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/20240424171030.2177-1-michal.wajdeczko@intel.com
2024-04-25drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHYAdam Ford
When enabling i.MX8MP DWC HDMI driver, it automatically selects PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy. This may cause some Kconfig warnings during various build tests. Fix this by implying the phy instead of selecting the phy. To prevent this from happening with the DRM_IMX8MP_HDMI_PVI, also imply it instead of selecting it. Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404190103.lLm8LtuP-lkp@intel.com/ Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240422103352.8886-1-aford173@gmail.com
2024-04-25drm/{i915, xe}: Implement fbdev emulation as in-kernel clientThomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-7-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/{i915,xe}: Implement fbdev client callbacksThomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-6-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/{i915,xe}: Unregister in-kernel clientsThomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-5-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/i915: Initialize fbdev DRM client with callback functionsThomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-4-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/i915: Move fbdev functionsThomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-3-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/client: Export drm_client_dev_unregister()Thomas Zimmermann
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 <tzimmermann@suse.de> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240409081029.17843-2-tzimmermann@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/i915: pass dev_priv to _MMIO_PIPE2, _MMIO_TRANS2, _MMIO_CURSOR2Jani Nikula
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 <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3a865664898586ff6cb8e74eab3d1f36eafc0557.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25drm/i915: convert _MMIO_PIPE3()/_MMIO_PORT3() to accept baseJani Nikula
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 <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4b95f125f5021abc00b5fc661b2728f1b583c01e.1713890614.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-25gpu: drm: exynos: hdmi: eliminate uses of of_node_put()Shivani Gupta
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 <julia.lawall@inria.fr> Signed-off-by: Shivani Gupta <shivani07g@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: mixer: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: hdmi: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: vidi: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: scaler: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: rotator: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: mic: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: gsc: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: g2d: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: dsi: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: fimd: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-25drm/exynos: fimc: drop driver owner initializationKrzysztof Kozlowski
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 <krzysztof.kozlowski@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2024-04-24drm/xe: Check result of drmm_mutex_init()Michal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240409153132.1111-1-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-24drm/xe/xe2: Add workaround 14021567978Tejas Upadhyay
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 <tejas.upadhyay@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240410064640.1010098-1-tejas.upadhyay@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-24drm/i915: Fix gt reset with GuC submission is disabledNirmoy Das
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 <john.c.harrison@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422201951.633-2-nirmoy.das@intel.com
2024-04-24drm/i915: Refactor confusing __intel_gt_reset()Nirmoy Das
__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 <john.c.harrison@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422201951.633-1-nirmoy.das@intel.com
2024-04-24drm/xe/guc: Improve GuC doorbell/context ID manager intro messageMichal Wajdeczko
We can use recently added str_plural() helper. 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/20240419153407.402-1-michal.wajdeczko@intel.com
2024-04-24drm/xe: Introduce the wedged_mode debugfsRodrigo Vivi
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 <lucas.demarchi@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423221817.1285081-4-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-24drm/xe: Force wedged state and block GT reset upon any GPU hangRodrigo Vivi
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 <matthew.brost@intel.com> Cc: Dafna Hirschfeld <dhirschfeld@habana.ai> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Himanshu Somaiya <himanshu.somaiya@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423221817.1285081-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-24drm/xe: declare wedged upon GuC load failureRodrigo Vivi
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 <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423221817.1285081-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-24drm/xe: Introduce a simple wedged stateRodrigo Vivi
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 <ashutosh.dixit@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20240423221817.1285081-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-24drm/xe: Add INSTDONE registers to devcoredumpJosé Roberto de Souza
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 <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240424140319.61651-3-jose.souza@intel.com
2024-04-24drm/xe: Add helpers to loop over geometry and compute DSSJosé Roberto de Souza
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 <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240424140319.61651-2-jose.souza@intel.com
2024-04-24drm/xe: Store xe_hw_engine in xe_hw_engine_snapshotJosé Roberto de Souza
A future patch will require gt and xe device structs, so here replacing class by hwe. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240424140319.61651-1-jose.souza@intel.com
2024-04-24drm/xe/guc: Fix arguments passed to relay G2H handlersMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419150351.358-1-michal.wajdeczko@intel.com (cherry picked from commit 48c64d495fbef343c59598a793d583dfd199d389) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-24drm/xe: call free_gsc_pkt only once on action add failureHimal Prasad Ghimiray
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 <rodrigo.vivi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412181211.1155732-4-himal.prasad.ghimiray@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 22bf0bc04d273ca002a47de55693797b13076602) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-24drm/xe: Remove sysfs only once on action add failureHimal Prasad Ghimiray
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 <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412181211.1155732-3-himal.prasad.ghimiray@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit a99641e38704202ae2a97202b3d249208c9cda7f) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-24drm: xlnx: zynqmp_dpsub: Set input live formatAnatoliy Klymenko
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 <anatoliy.klymenko@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-6-c7f379b7168e@amd.com
2024-04-24drm: xlnx: zynqmp_dpsub: Minimize usage of global flagAnatoliy Klymenko
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 <anatoliy.klymenko@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkainen@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-5-c7f379b7168e@amd.com
2024-04-24drm: xlnx: zynqmp_dpsub: Anounce supported input formatsAnatoliy Klymenko
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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-4-c7f379b7168e@amd.com
2024-04-24drm: xlnx: zynqmp_dpsub: Add connected live layer helperAnatoliy Klymenko
Add a helper function capturing the first connected live display layer discovery logic. Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkainen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-3-c7f379b7168e@amd.com
2024-04-24drm: xlnx: zynqmp_dpsub: Update live format definesAnatoliy Klymenko
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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-2-c7f379b7168e@amd.com
2024-04-24drm: xlnx: zynqmp_dpsub: Set layer mode during creationAnatoliy Klymenko
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 <anatoliy.klymenko@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkainen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240416-dp-live-fmt-v4-1-c7f379b7168e@amd.com
2024-04-24drm/xe/pf: Clamp maximum execution quantum to 100sMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419123543.270-3-michal.wajdeczko@intel.com
2024-04-24drm/xe/guc: Update VF configuration KLVs definitionsMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419123543.270-2-michal.wajdeczko@intel.com
2024-04-24drm/xe/pf: Expose SR-IOV policy settings over debugfsMichal Wajdeczko
We already have functions to configure SR-IOV policies. Allow to tweak those policy settings over debugfs. Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423131244.2045-4-michal.wajdeczko@intel.com
2024-04-24drm/xe/pf: Expose SR-IOV VF control commands over debugfsMichal Wajdeczko
We already have functions to control the VF. Allow to control the VF using debugfs. Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423131244.2045-3-michal.wajdeczko@intel.com
2024-04-24drm/xe/pf: Expose SR-IOV VFs configuration over debugfsMichal Wajdeczko
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 <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423131244.2045-2-michal.wajdeczko@intel.com
2024-04-24drm/xe/kunit: Add PF service testsMichal Wajdeczko
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 <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423180436.2089-6-michal.wajdeczko@intel.com
2024-04-24drm/xe/pf: Add SR-IOV GuC Relay PF servicesMichal Wajdeczko
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 <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423180436.2089-5-michal.wajdeczko@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-30 12:13:59 +0000