summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-02-27drm/i915/dp: Factor out intel_dp_read_dprx_caps()Imre Deak
Factor out a function to read the sink's DPRX capabilities used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-10-imre.deak@intel.com
2024-02-27drm/i915/dp: Factor out intel_dp_update_sink_caps()Imre Deak
Factor out a function updating the sink's link rate and lane count capabilities, used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-9-imre.deak@intel.com
2024-02-27drm/i915/dp: Export intel_dp_max_common_rate/lane_count()Imre Deak
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-8-imre.deak@intel.com
2024-02-27drm/i915/dp: Factor out intel_dp_config_required_rate()Imre Deak
Factor out intel_dp_config_required_rate() used by a follow-up patch enabling the DP tunnel BW allocation mode. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-7-imre.deak@intel.com
2024-02-27drm/i915/dp: Use drm_dp_max_dprx_data_rate()Imre Deak
Instead of intel_dp_max_data_rate() use the equivalent drm_dp_max_dprx_data_rate() which was copied from the former one in a previous patch. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-6-imre.deak@intel.com
2024-02-27drm/i915/dp: Add support to notify MST connectors to retry modesetsImre Deak
On shared (Thunderbolt) links with DP tunnels, the modeset may need to be retried on all connectors on the link due to a link BW limitation arising only after the atomic check phase. To support this add a helper function queuing a work to retry the modeset on a given port's connector and at the same time any MST connector with streams through the same port. A follow-up change enabling the DP tunnel Bandwidth Allocation Mode will take this into use. v2: - Send the uevent only to enabled MST connectors. (Jouni) Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-5-imre.deak@intel.com
2024-02-27drm/i915: Fix display bpp limit computation during system resumeImre Deak
The system resume display mode restoration should happen with an output configuration matching that of the suspend time saved mode. Since the restored mode configuration is subject to the bpp fallback logic, starting out with an unlimited bpp and reducing the bpp as required by any (MST) link BW limit, the resulting bpp will match the one during suspend only if the BW limit checks during suspend and resume are applied in an identical way. The latter is not guaranteed at the moment, since the pre-suspend MST topology may not be in place during resume (for instance if the MST sink was disconnected while being suspended), which makes the MST link BW check accept the unlimited bpp mode configuration unconditionally without ensuring that the required BW fits into the available MST link BW. To fix the above, initialize the bpp fallback logic with the max link bpp / force-FEC limits left behind by the suspend time mode save. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220211841.448846-4-imre.deak@intel.com
2024-02-27drm/dp: Add support for DP tunnelingImre Deak
Add support for Display Port tunneling. For now this includes the support for Bandwidth Allocation Mode (BWA), leaving adding Panel Replay support for later. BWA allows using displays that share the same (Thunderbolt) link with their maximum resolution. Atm, this may not be possible due to the coarse granularity of partitioning the link BW among the displays on the link: the BW allocation policy is in a SW/FW/HW component on the link (on Thunderbolt it's the SW or FW Connection Manager), independent of the driver. This policy will set the DPRX maximum rate and lane count DPCD registers the GFX driver will see (0x00000, 0x00001, 0x02200, 0x02201) based on the available link BW. The granularity of the current BW allocation policy is coarse, based on the required link rate in the 1.62Gbs..8.1Gbps range and it may prevent using higher resolutions all together: the display connected first will get a share of the link BW which corresponds to its full DPRX capability (regardless of the actual mode it uses). A subsequent display connected will only get the remaining BW, which could be well below its full capability. BWA solves the above coarse granularity (reducing it to a 250Mbs..1Gps range) and first-come/first-served issues by letting the driver request the BW for each display on a link which reflects the actual modes the displays use. This patch adds the DRM core helper functions, while a follow-up change in the patchset takes them into use in the i915 driver. v2: - Fix prepare_to_wait vs. wake-up cond check order in allocate_tunnel_bw(). (Ville) - Move tunnel==NULL checks from callers in drivers to here. (Ville) - Avoid var inits in declaration blocks that can fail or have side-effects. (Ville) - Use u8 for driver and group IDs. (Ville) - Simplify API removing drm_dp_tunnel_get/put_untracked(). (Ville) - Reuse str_yes_no() instead of a local yes_no_chr(). (Ville) - s/drm_dp_tunnel_atomic_clear_state()/free_tunnel_state() and unexport the function. (Ville) - s/clear_tunnel_group_state()/free_group_state() and move kfree() to this function. (Ville) - Add separate group_free_bw() helper and describe what the tunnel estimated BW includes. (Ville) - Improve help text for CONFIG_DRM_DISPLAY_DP_TUNNEL. (Ville) - Add code comment explaining the purpose of DPCD reg read helpers. (Ville) - Add code comment describing the tunnel group name prefix format. (Ville) - Report the allocated BW as undetermined until the first allocation request. - Skip allocation requests matching the previous request. - Clear any stale BW request status flags before a new request. - Add missing error return check of drm_dp_tunnel_atomic_get_group_state() in drm_dp_tunnel_atomic_set_stream_bw(). - Add drm_dp_tunnel_get_allocated_bw(). - s/drm_dp_tunnel_atomic_get_tunnel_bw/drm_dp_tunnel_atomic_get_required_bw - Fix return value description in function doc of drm_dp_tunnel_detect(). - Add function documentation to all exported functions. v3: - Improve grouping of fields in drm_dp_tunnel_group struct. (Uma) - Fix validating the BW granularity DPCD reg value. (Uma) - Document return value of check_and_clear_status_change(). (Uma) - Fix resetting drm_dp_tunnel_ref::tunnel in drm_dp_tunnel_ref_put(). (Ville) - Allow for ALLOCATED_BW to change after a BWA enable/disable sequence. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226185246.1276018-2-imre.deak@intel.com
2024-02-27drm/dp: Add drm_dp_max_dprx_data_rate()Imre Deak
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a follow-up DP tunnel patch, checking the maximum rate the DPRX (sink) supports. Accordingly use the drm_dp_max_dprx_data_rate() name for clarity. This patchset will also switch calling the new DRM function in i915 instead of intel_dp_max_data_rate(). While at it simplify the function documentation/comments, removing parts described already by drm_dp_bw_channel_coding_efficiency(). v2: (Ville) - Remove max_link_rate_kbps. - Simplify the function documentation. v3: - Rebased on latest drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226185246.1276018-1-imre.deak@intel.com
2024-02-27drm/i915/hdcp: Extract hdcp structure from correct connectorSuraj Kandpal
Currently intel_hdcp is not being extracted from primary connector this patch fixes that. Fixes: 524240b231ea ("drm/i915/hdcp: Propagate aux info in DP HDCP functions") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-3-suraj.kandpal@intel.com (cherry picked from commit 909fff3e46c08eb6fcbb52e7a49dfb359007ae79) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-02-27Merge branch 'x86/urgent' into x86/apic, to resolve conflictsIngo Molnar
Conflicts: arch/x86/kernel/cpu/common.c arch/x86/kernel/cpu/intel.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2024-02-27drm/i915/hdcp: Read Rxcaps for robustibilitySuraj Kandpal
We see some monitors and docks report incorrect hdcp version and capability in first few reads so we read rx_caps three times before we conclude the monitor's or docks HDCP capability --v2 -Add comment to justify the 3 time read loop for hdcp capability[Ankit] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-7-suraj.kandpal@intel.com
2024-02-27drm/i915/hdcp: Allocate stream id after HDCP AKE stageSuraj Kandpal
Allocate stream id after HDCP AKE stage and not before so that it can also be done during link integrity check. Right now for MST scenarios LIC fails after hdcp enablement for this reason. --v2 -no need for else block in prepare_streams function [Ankit] --v3 -remove intel_hdcp argument from required_content_stream function [Ankit] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-6-suraj.kandpal@intel.com
2024-02-27drm/i915/hdcp: Don't enable HDCP1.4 directly from check_linkSuraj Kandpal
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP1.4 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-5-suraj.kandpal@intel.com
2024-02-27drm/i915/hdcp: Don't enable HDCP2.2 directly from check_linkSuraj Kandpal
Whenever LIC fails instead of moving from ENABLED to DESIRED CP property we directly enable HDCP2.2 without informing the userspace of this failure in link integrity check. Now we will just update the value to DESIRED send the event to userspace and then continue with the normal flow of HDCP enablement. --v2 -Don't change the function prototype in this function [Ankit] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-4-suraj.kandpal@intel.com
2024-02-27drm/i915/hdcp: Extract hdcp structure from correct connectorSuraj Kandpal
Currently intel_hdcp is not being extracted from primary connector this patch fixes that. Fixes: 524240b231ea ("drm/i915/hdcp: Propagate aux info in DP HDCP functions") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226063051.1685326-3-suraj.kandpal@intel.com
2024-02-27drm/mediatek: Filter modes according to hardware capabilityHsiao Chien Sung
We found a stability issue on MT8188 when connecting an external monitor in 2560x1440@144Hz mode. Checked with the designer, there is a function called "prefetch" which is working during VBP (triggered by VSYNC). If the duration of VBP is too short, the throughput requirement could increase more than 3 times and lead to stability issues. The mode settings that VDOSYS supports are mainly affected by clock rate and throughput, display driver should filter these settings according to the SoC's limitation to avoid unstable conditions. Since currently the mode filter is only available on MT8195 and MT8188 and they share the same compatible name, the reference number (8250) is hard coded instead of in the driver data. Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240220093711.20546-2-shawn.sung@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2024-02-26drm/xe/guc: Handle timing out of signaled jobs gracefullyMatthew Brost
Timing out of signaled jobs can happen during regular operations (e.g. an exec queue closed immediately after last fence signaled). The TDR can pass the worker which free jobs. Rather than running through the TDR if signaled job is found, simply free it without any debug messages. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reported-by: José Roberto de Souza <jose.souza@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1271 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Tested-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240223204659.40750-1-matthew.brost@intel.com
2024-02-26drm/xe: get rid of MAX_BINDSPaulo Zanoni
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240215005353.1295420-1-paulo.r.zanoni@intel.com
2024-02-26drm/xe: Use vmalloc for array of bind allocation in bind IOCTLMatthew Brost
Use vmalloc in effort to allow a user pass in a large number of binds in an IOCTL (mesa use case). Also use array allocations rather open coding the size calculation. v2: Use __GFP_ACCOUNT for allocations (Thomas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240226155554.103384-1-matthew.brost@intel.com
2024-02-26drm/amdkfd: Add partition id field to location_idLijo Lazar
On devices which have multi-partition nodes, keep partition id in location_id[31:28]. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Jonathan Kim <jonathan.kim@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu: reserve more memory for MES runtime DRAMTim Huang
This patch fixes a MES firmware boot failure issue when backdoor loading the MES firmware. MES firmware runtime DRAM size is changed to 512k, the driver needs to reserve this amount of memory in FB, otherwise adjacent memory will be overwritten by the MES firmware startup code. Signed-off-by: Tim Huang <Tim.Huang@amd.com> Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu: Enable gpu reset for S3 abort cases on Raven seriesPrike Liang
Currently, GPU resets can now be performed successfully on the Raven series. While GPU reset is required for the S3 suspend abort case. So now can enable gpu reset for S3 abort cases on the Raven series. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu/pm: Fix the power1_min_cap valueMa Jun
It's unreasonable to use 0 as the power1_min_cap when OD is disabled. So, use the same lower limit as the value used when OD is enabled. Fixes: 1958946858a6 ("drm/amd/pm: Support for getting power1_cap_min value") Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu: Do not program SQ_TIMEOUT_CONFIG in SRIOVVictor Lu
VF should not program this register. Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Reviewed-by: Zhigang Luo <Zhigang.Luo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu: Fix ineffective ras_mask settingsStanley.Yang
Check amdgpu_ras_mask to fix ineffective ras_mask setting due to special asic without sram ecc enable but with poison supported. Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdkfd: Skip packet submission on fatal errorLijo Lazar
If fatal error is detected, packet submission won't go through. Return error in such cases. Also, avoid waiting for fence when fatal error is detected. 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>
2024-02-26drm/amdgpu: Add fatal error detected flagLijo Lazar
For a RAS error that needs a full reset to recover, set the fatal error status. Clear the status once the device is reset. 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>
2024-02-26drm/amd/display: Prevent potential buffer overflow in map_hw_resourcesSrinivasan Shanmugam
Adds a check in the map_hw_resources function to prevent a potential buffer overflow. The function was accessing arrays using an index that could potentially be greater than the size of the arrays, leading to a buffer overflow. Adds a check to ensure that the index is within the bounds of the arrays. If the index is out of bounds, an error message is printed and break it will continue execution with just ignoring extra data early to prevent the buffer overflow. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7 Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2") Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Qingqing Zhuo <Qingqing.Zhuo@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Suggested-by: Roman Li <roman.li@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/amdgpu: Fix the runtime resume failure issueMa Jun
Don't set power state flag when system enter runtime suspend, or it may cause runtime resume failure issue. Fixes: 3a9626c816db ("drm/amd: Stop evicting resources on APUs in suspend") Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-26drm/mgag200: Add a workaround for low-latencyJocelyn Falempe
We found a regression in v5.10 on real-time server, using the rt-kernel and the mgag200 driver. It's some really specialized workload, with <10us latency expectation on isolated core. After the v5.10, the real time tasks missed their <10us latency when something prints on the screen (fbcon or printk) The regression has been bisected to 2 commits: commit 0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages") commit 4862ffaec523 ("drm/mgag200: Move vmap out of commit tail") The first one changed the system memory framebuffer from Write-Combine to the default caching. Before the second commit, the mgag200 driver used to unmap the framebuffer after each frame, which implicitly does a cache flush. Both regressions are fixed by this commit, which restore WC mapping for the framebuffer in system memory, and add a cache flush. This is only needed on x86_64, for low-latency workload, so the new kconfig DRM_MGAG200_IOBURST_WORKAROUND depends on PREEMPT_RT and X86. For more context, the whole thread can be found here [1] Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/dri-devel/20231019135655.313759-1-jfalempe@redhat.com/ # 1 Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240208095125.377908-1-jfalempe@redhat.com
2024-02-26drm/msm/adreno: Add A702 supportKonrad Dybcio
The A702 is a weird mix of 600 and 700 series.. Perhaps even a testing ground for some A7xx features with good ol' A6xx silicon. It's basically A610 that's been beefed up with some new registers and hw features (like APRIV!), that was then cut back in size, memory bus and some other ways. Add support for it, tested with QCM2290 / RB1. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/579752/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm: Fix page fault client detection on a660 family and a7xxConnor Abbott
Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/575918/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm: More fully implement devcoredump for a7xxConnor Abbott
Use the vendor-provided snapshot headers to dump the contextless registers, shader blocks, and cluster registers. Still unimplemented are the GMU registers and "external core" registers, which would require more work because they use register spaces we don't have described in devicetree and dump registers from multiple spaces in a single list. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/575919/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm: Fix snapshotting a7xx indexed regsConnor Abbott
We were overwriting the last indexed reg (CP_ROQ) and we were snapshotting the same CP_MEMPOOL block twice instead of snapshotting CP_BV_MEMPOOL as intended. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/575920/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm: Import a7xx crashdump register lists from kgslConnor Abbott
This imports these files as-is, the following commits will have to make slight changes to get them to compile because downstream uses un-namespaced enums that conflict with a6xx. However we should try as much as possible to stick to downstream's format to make importing new gens easier. Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/575921/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm: add support for A750 GPUNeil Armstrong
Add support for the A750 GPU found on the SM8650 platform Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU doesn't have an HWCFG block but a separate register set. The A750 GPU info are added under the adreno_is_a750() macro and the ADRENO_7XX_GEN3 family id. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/578693/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm/adreno: Add A305B supportLuca Weiss
Add support for the Adreno 305B GPU that is found in MSM8226(v2) SoC. Previously this was mistakenly claimed to be supported but using wrong a configuration. In MSM8226v1 there's also a A305B but with chipid 0x03000510 which should work with the same configuration but due to lack of hardware for testing this is not added. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: David Heidelberg <david@ixit.cz> Patchwork: https://patchwork.freedesktop.org/patch/575274/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm/a7xx: Fix LLC typoRob Clark
We'd miss actually activating LLC. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/573043/
2024-02-26drm/msm/adreno: Update generated headersRob Clark
This updates the GPU headers to latest from mesa, using gen_header.py (which is used to generate headers at bulid time for mesa), rather than headergen2 (which doesn't have proper support for A6XX vs A7XX register variants). Mostly just uninteresting churn, but there are a couple spots in a7xx paths which update REG_A6XX_foo to REG_A7XX_foo for registers which are a7xx specific. Cc: Connor Abbott <cwabbott0@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/574880/
2024-02-26drm/msm/adreno: Add support for SM7150 SoC machineDanila Tikhonov
SM7150 has 5 power levels which correspond to 5 speed-bin values: 0, 128, 146, 167, 172. Speed-bin value is calulated as FMAX/4.8MHz round up to zero decimal places. Also a618 on SM7150 uses a615 zapfw. Add a squashed version (.mbn). Add this as machine = "qcom,sm7150", because speed-bin values are different from atoll (sc7180/sm7125). Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/578902/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/msm/a6xx: specify UBWC config for sc7180Dmitry Baryshkov
Historically the Adreno driver has not been updating memory configuration registers on a618 (SC7180 platform) implying that the default configuration is fine. After the rework performed in the commit 8814455a0e54 ("drm/msm: Refactor UBWC config setting") the function a6xx_calc_ubwc_config() still contained this shortcut and did not calculate UBWC configuration. However the function which now actually updates hardware registers, a6xx_set_ubwc_config(), doesn't contain such check. Rather than adding the check to a6xx_set_ubwc_config(), fill in the UBWC config for a618 (based on readings from SC7180). Reported-by: Leonard Lausen <leonard@lausen.nl> Link: https://gitlab.freedesktop.org/drm/msm/-/issues/49 Fixes: 8814455a0e54 ("drm/msm: Refactor UBWC config setting") Cc: Connor Abbott <cwabbott0@gmail.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/579113/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2024-02-26drm/ttm/tests: depend on UML || COMPILE_TESTChristian König
At least the device test requires that no other driver using TTM is loaded. So make those unit tests depend on UML || COMPILE_TEST to prevent people from trying them on bare metal. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/all/20240219230116.77b8ad68@yea/
2024-02-26Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard
Sima needs a more recent release to apply a patch. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-02-26drm/xe: Extend uAPI to query HuC micro-controler firmware versionFrancois Dugast
The infrastructure to query GuC firmware version is already in place. It is extended with a new micro-controller type to query the HuC firmware version. It can be used from user space to know if HuC is running. Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Francois Dugast <francois.dugast@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208183539.185095-2-jose.souza@intel.com
2024-02-26Merge drm/drm-next into drm-misc-next-fixesThomas Zimmermann
Backmerging from drm/drm-next to prepare drm-misc-next-fixes for the rest of the release cycle. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2024-02-26drm/xe: Remove useless mem_access on PAT dumpsRodrigo Vivi
PAT dumps are already protected by the xe_pm_runtime_{get,put} around the debugfs call. So, these can be removed. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222163937.138342-14-rodrigo.vivi@intel.com
2024-02-26drm/xe: Convert gt_reset from mem_access to xe_pm_runtimeRodrigo Vivi
We need to ensure that device is in D0 on any kind of GT reset. We are likely already protected by outer bounds like exec, but if exec/sched ref gets dropped on a hang, we might transition to D3 before we are able to perform the gt_reset and recover. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222163937.138342-13-rodrigo.vivi@intel.com
2024-02-26drm/xe: Remove mem_access from suspend and resume functionsRodrigo Vivi
At these points, we are sure that device is awake in D0. Likely in the middle of the transition, but awake. So, these extra protections are useless. Let's remove it and continue with the killing of xe_device_mem_access. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222163937.138342-12-rodrigo.vivi@intel.com
2024-02-26drm/xe: Convert gsc_work from mem_access to xe_pm_runtimeRodrigo Vivi
Let's directly use xe_pm_runtime_{get,put} instead of the mem_access helpers that are going away soon. Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240222163937.138342-11-rodrigo.vivi@intel.com
generated by cgit v1.2.3 (git 2.51.0) at 2026-11-11 00:10:37 +0000