summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
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
2024-04-24drm/xe: Add few more GT register definitionsMichal Wajdeczko
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 <piotr.piorkowski@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423180436.2089-4-michal.wajdeczko@intel.com
2024-04-24drm/xe: Add helper to calculate adjusted register offsetMichal Wajdeczko
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 <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/20240423180436.2089-3-michal.wajdeczko@intel.com
2024-04-24drm/xe/guc: Add GuC Relay ABI version 1.0 definitionsMichal Wajdeczko
This initial GuC Relay ABI specification includes messages for ABI version negotiation and to query values of runtime/fuse registers. We will start handling those messages on the PF driver soon. 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-2-michal.wajdeczko@intel.com
2024-04-24drm/bridge: tc358764: drop driver owner assignmentKrzysztof Kozlowski
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240330202741.83867-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-04-24drm/bridge: chipone-icn6211: drop driver owner assignmentKrzysztof Kozlowski
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240330202741.83867-1-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-04-24drm/xe: Fix unexpected backmerge resultsThomas Hellström
The recent backmerge from drm-next to drm-xe-next brought with it some silent unexpected results. One code snippet was added twice and a partial revert had merge errors. Fix that up to reinstate the affected code as it was before the backmerge. v2: - Commit log message rewording (Lucas DeMarchi) Fixes: 79790b6818e9 ("Merge drm/drm-next into drm-xe-next") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423121114.39325-1-thomas.hellstrom@linux.intel.com
2024-04-24drm/panel: jdi-fhd-r63452: make use of prepare_prev_firstBarnabás Czémán
The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. Signed-off-by: Barnabás Czémán <trabarni@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240423-jdi-fix-v1-1-808970662b40@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240423-jdi-fix-v1-1-808970662b40@gmail.com
2024-04-24drm/bridge: adv7511: make it honour next bridge in DTDmitry Baryshkov
DT bindings for adv7511 and adv7533 bridges specify HDMI output to be present at the port@1. This allows board DT to add e.g. HDMI connector nodes or any other next chained bridge. Make adv7511 driver discover that bridge and attach it to the chain. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240331-adv7511-next-bridge-v2-1-7356d61dc7b2@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240331-adv7511-next-bridge-v2-1-7356d61dc7b2@linaro.org
2024-04-24drm/panel: visionox-rm69299: stop calling regulator_set_load manuallyDmitry Baryshkov
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240404-drop-panel-unregister-v1-6-9f56953c5fb9@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240404-drop-panel-unregister-v1-6-9f56953c5fb9@linaro.org
2024-04-24drm/panel: novatek-nt36672a: stop calling regulator_set_load manuallyDmitry Baryshkov
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240404-drop-panel-unregister-v1-5-9f56953c5fb9@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240404-drop-panel-unregister-v1-5-9f56953c5fb9@linaro.org
2024-04-24drm/panel: novatek-nt36672e: stop calling regulator_set_load manuallyDmitry Baryshkov
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240404-drop-panel-unregister-v1-4-9f56953c5fb9@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240404-drop-panel-unregister-v1-4-9f56953c5fb9@linaro.org
2024-04-24drm/panel: novatek-nt36672e: stop setting register load before disableDmitry Baryshkov
It is pointless to set register load before disabling the register. This vote is going to be dropped as soon as the register is disabled. Drop these register_set_load calls. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240404-drop-panel-unregister-v1-3-9f56953c5fb9@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240404-drop-panel-unregister-v1-3-9f56953c5fb9@linaro.org
2024-04-23drm/amdgpu/mes: fix use-after-free issueJack Xiao
Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Acked-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-23drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3Alex Deucher
This avoids a potential conflict with firmwares with the newer HDP flush mechanism. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-04-23drm/amdgpu: Fix the ring buffer size for queue VM flushPrike Liang
Here are the corrections needed for the queue ring buffer size calculation for the following cases: - Remove the KIQ VM flush ring usage. - Add the invalidate TLBs packet for gfx10 and gfx11 queue. - There's no VM flush and PFP sync, so remove the gfx9 real ring and compute ring buffer usage. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-23drm/amdkfd: Add VRAM accounting for SVM migrationMukul Joshi
Do VRAM accounting when doing migrations to vram to make sure there is enough available VRAM and migrating to VRAM doesn't evict other possible non-unified memory BOs. If migrating to VRAM fails, driver can fall back to using system memory seamlessly. Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-23drm/amd/pm: Restore config space after resetLijo Lazar
During mode-2 reset, pci config space registers are affected at device side. However, certain platforms have switches which assign virtual BAR addresses and returns the same even after device is reset. This affects pci_restore_state() as it doesn't issue another config write, if the value read is same as the saved value. Add a workaround to write saved config space values from driver side. Presently, these switches are in platforms with SMU v13.0.6 SOCs, hence restrict the workaround only to those. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-10 14:07:16 +0000