- 10 Nov, 2023 1 commit
-
-
Daniel Vetter authored
Merge tag 'drm-intel-next-fixes-2023-11-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 fixes for v6.7-rc1: - Fix null dereference when perf interface is not available - Fix a -Wstringop-overflow warning - Fix a -Wformat-truncation warning in intel_tc_port_init - Flush WC GGTT only on required platforms - Fix MTL HBR3 rate support on C10 phy and eDP - Fix MTL notify_guc for multi-GT - Bump GLK CDCLK frequency when driving multiple pipes - Fix potential spectre vulnerability Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878r78xrxd.fsf@intel.com
-
- 06 Nov, 2023 6 commits
-
-
Nirmoy Das authored
Fix below compiler warning: intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] "%c/TC#%d", port_name(port), tc_port + 1); ^~ intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 8 snprintf(tc->port_name, sizeof(tc->port_name), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%c/TC#%d", port_name(port), tc_port + 1); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v2: use kasprintf(Imre) v3: use const for port_name, and fix tc mem leak(Imre) Fixes: 3eafcddf ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231026125636.5080-1-nirmoy.das@intel.com (cherry picked from commit 70a3cbbe) Signed-off-by:
-
Kunwu Chan authored
Fix smatch warning: drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu() warn: potential spectre issue 'pc->user_engines' [r] (local cap) Fixes: d4433c76 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: <stable@vger.kernel.org> # v5.15+ Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103110922.430122-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 27b08638) Signed-off-by:
-
Ville Syrjälä authored
On GLK CDCLK frequency needs to be at least 2*96 MHz when accessing the audio hardware. Currently we bump the CDCLK frequency up temporarily (if not high enough already) whenever audio hardware is being accessed, and drop it back down afterwards. With a single active pipe this works just fine as we can switch between all the valid CDCLK frequencies by changing the cd2x divider, which doesn't require a full modeset. However with multiple active pipes the cd2x divider trick no longer works, and thus we end up blinking all displays off and back on. To avoid this let's just bump the CDCLK frequency to >=2*96MHz whenever multiple pipes are active. The downside is slightly higher power consumption, but that seems like an acceptable tradeoff. With a single active pipe we can stick to the current more optiomal (from power comsumption POV) behaviour. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9599Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231031160800.18371-1-ville.syrjala@linux.intel.comReviewed-by:
-
Nirmoy Das authored
Handle platforms with multiple GTs by iterate over all GTs. Add a Fixes commit so this gets propagated for MTL support. Fixes: 213c4367 ("drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake") Suggested-by:
John Harrison <john.c.harrison@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.7-2023-11-03: amdgpu: - Fix RAS support check - RAS fixes - MES fixes - SMU13 fixes - Contiguous memory allocation fix - BACO fixes - GPU reset fixes - Min power limit fixes - GFX11 fixes - USB4/TB hotplug fixes - ARM regression fix - GFX9.4.3 fixes - KASAN/KCSAN stack size check fixes - SR-IOV fixes - SMU14 fixes - PSP13 fixes - Display blend fixes - Flexible array size fixes amdkfd: - GPUVM fix radeon: - Flexible array size fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103173203.4912-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2023-11-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes for v6.7-rc1: - dt binding fix for ssd132x - Initialize ssd130x crtc_state to NULL. Signed-off-by:
-
- 03 Nov, 2023 30 commits
-
-
Ilya Bakoulin authored
[Why] Full update is not required on surface blend TF change. [How] Update full_update_required condition. Reviewed-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Hersen Wu <hersenxs.wu@amd.com> Signed-off-by:
Ilya Bakoulin <ilya.bakoulin@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Ilya Bakoulin authored
[Why] LUT write index does not get reset to zero when writing the LUT values for each separate RGB component, which results in wrong data for 2 of the 3 components. [How] Reset LUT write index to zero before writing each component's data. Reviewed-by:
Krunoslav Kovac <krunoslav.kovac@amd.com> Acked-by:
-
Sung Joon Kim authored
[why] There are some registers for plane color that are skipped programming on resume. Need to add those as part of the sequence. [how] Add new function hook for programming plane color control. Reviewed-by:
Duncan Ma <duncan.ma@amd.com> Acked-by:
Sung Joon Kim <sungkim@amd.com> Tested-by:
-
Hawking Zhang authored
Query boot status and report boot errors. A follow up change is needed to stop GPU initialization if boot fails. v2: only invoke the call for dGPU (Le/Lijo) Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Yang Wang <kevinyang.wang@amd.com> Reviewed-by:
Le Ma <le.ma@amd.com> Signed-off-by:
-
Hawking Zhang authored
Add psp v13 function to query boot status. v2: limit the use case to dGPU only (Lijo) Signed-off-by:
-
Li Ma authored
dorp fw version check and using max table size to init table. Signed-off-by:
Li Ma <li.ma@amd.com> Reviewed-by:
Yifan Zhang <yifan1.zhang@amd.com> Reviewed-by:
-
Li Ma authored
Update driver if headers and metrics table in smu v14_0_0 after smu fw promotion. Drop the legacy metrics table and add warning of checking pmfw version. Signed-off-by:
-
Hawking Zhang authored
Add MP0_C2PMSG_109/126 register field shift/masks that are used to identify boot status by driver. Signed-off-by:
-
Ma Jun authored
Use a new struct array to define the asic information which asic type needs to be fixed. Signed-off-by:
Ma Jun <Jun.Ma2@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
-
Tim Huang authored
Use a proper MEID to make sure the CP_HQD_* and CP_GFX_HQD_* registers can be touched when initialize the compute and gfx mqd in mes_self_test. Otherwise, we expect no response from CP and an GRBM eventual timeout. Signed-off-by:
Tim Huang <Tim.Huang@amd.com> Acked-by:
-
Tao Zhou authored
Handle xgmi hive case. Suggested-by:
Stanley.Yang <Stanley.Yang@amd.com> Signed-off-by:
-
Ma Jun authored
The current code checks sriov vf flag multiple times when creating hwmon sysfs. So fix it. Signed-off-by:
-
Felix Kuehling authored
Instead of attaching the eviction fence when a KFD BO is first mapped, attach it when it is allocated or imported. This in preparation to allow KFD BOs to be mapped using the render node API. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Felix Kuehling authored
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by the caller. This will be useful for handling extra BO VA mappings in KFD VMs that are managed through the render node API. v2: rebase against drm_exec changes (Alex) Signed-off-by:
-
Nathan Chancellor authored
When building ARCH=x86_64 allmodconfig with clang, which will typically have sanitizers enabled, there is a warning about a large stack frame. drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6265:13: error: stack frame size (2520) exceeds limit (2048) in 'dml_prefetch_check' [-Werror,-Wframe-larger-than] 6265 | static void dml_prefetch_check(struct display_mode_lib_st *mode_lib) | ^ 1 error generated. Notably, GCC 13.2.0 does not do too much of a better job, as it is right at the current limit of 2048 (and others have reported being over with older GCC versions): drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In function 'dml_prefetch_check': drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:6705:1: error: the frame size of 2048 bytes is larger than 1800 bytes [-Werror=frame-larger-than=] 6705 | } | ^ In the past, these warnings have been avoided by reducing the number of parameters to various functions so that not as many arguments need to be passed on the stack. However, these patches take a good amount of effort to write despite being mechanical due to code structure and complexity and they are never carried forward to new generations of the code so that effort has to be expended every new hardware generation, which becomes harder to justify as time goes on. To avoid having a noticeable or lengthy breakage in all{mod,yes}config, which are easy testing targets that have -Werror enabled, increase the limit for configurations that have KASAN or KCSAN enabled by 50% so that cases of extremely poor code generation can still be caught while not breaking the majority of builds. CONFIG_KMSAN also causes high stack usage but the frame limit is already set to zero when it is enabled, which is accounted for by the check for CONFIG_FRAME_WARN=0 in the dml2 Makefile. Signed-off-by:Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
Wayne Lin authored
[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference. Reviewed-by:
Jun Lei <jun.lei@amd.com> Acked-by:
Wayne Lin <wayne.lin@amd.com> Tested-by:
-
Mukul Joshi authored
Update cache info reporting based on compute and memory partitioning modes. Signed-off-by:
Mukul Joshi <mukul.joshi@amd.com> Reviewed-by:
-
Mukul Joshi authored
GFX 9.4.3 uses a new version of the GC info table which contains the cache info. This patch adds a new function to populate the cache info from IP discovery for GFX 9.4.3. Signed-off-by:
-
Alex Deucher authored
Issues were reported with commit 1cfb4d61 ("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere Altra Developer Platform (AVA developer platform). Various ARM systems seem to have problems related to PCIe and MMIO access. In this case, I'm not sure if this is specific to the ADLINK platform or ARM in general. Seems to be some coherency issue with VRAM. For now, just don't put MQDs in VRAM on ARM. Link: https://lists.freedesktop.org/archives/amd-gfx/2023-October/100453.html Fixes: 1cfb4d61 ("drm/amdgpu: put MQDs in VRAM") Acked-by:
-
Alex Deucher authored
This was fixed in PMFW before launch and is no longer required. Reviewed-by:
-
Alex Deucher authored
AMD dGPUs have integrated FW that runs as soon as the device gets power and initializes the board (determines the amount of memory, provides configuration details to the driver, etc.). For direct PCIe attached cards this happens as soon as power is applied and normally completes well before the OS has even started loading. However, with hotpluggable ports like USB4, the driver needs to wait for this to complete before initializing the device. This normally takes 60-100ms, but could take longer on some older boards periodically due to memory training. Retry for up to a second. In the non-hotplug case, there should be no change in behavior and this should complete on the first try. v2: adjust test criteria v3: adjust checks for the masks, only enable on removable devices v4: skip bif_fb_en check Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Perry Yuan authored
[Why] During suspend, if GFX DPM is enabled and GFXOFF feature is enabled the system may get hung. So, it is suggested to disable GFXOFF feature during suspend and enable it after resume. [How] Update the code to disable GFXOFF feature during suspend and enable it after resume. [ 311.396526] amdgpu 0000:03:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000001E SMN_C2PMSG_82:0x00000000 [ 311.396530] amdgpu 0000:03:00.0: amdgpu: Fail to disable dpm features! [ 311.396531] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block <smu> failed -62 Acked-by:
Perry Yuan <perry.yuan@amd.com> Signed-off-by:
Kun Liu <kun.liu2@amd.com> Signed-off-by:
-
José Pekkarinen authored
Reported by coccinelle, the following patch will move the following 1 element arrays to flexible arrays. drivers/gpu/drm/radeon/atombios.h:5523:32-48: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:5545:32-48: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:5461:34-44: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4447:30-40: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4236:30-41: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7095:28-45: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:3896:27-37: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:5443:16-25: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:5454:34-43: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4603:21-32: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4628:32-46: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:6285:29-39: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4296:30-36: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4756:28-36: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:4064:22-35: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7327:9-24: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7332:32-53: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7362:26-41: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7369:29-44: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7349:24-32: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) drivers/gpu/drm/radeon/atombios.h:7355:27-35: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) Signed-off-by:
José Pekkarinen <jose.pekkarinen@foxhound.fi> Signed-off-by:
-
Alex Deucher authored
For pptable structs that use flexible array sizes, use flexible arrays. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926Reviewed-by:
-
Alex Deucher authored
It's only valid on Intel systems with the Intel VSEC. Use dev_is_removable() instead. This should do the right thing regardless of the platform. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925Reviewed-by:
-
Alex Deucher authored
The ATRM ACPI method is for fetching the dGPU vbios rom image on laptops and all-in-one systems. It should not be used for external add in cards. If the dGPU is thunderbolt connected, don't try ATRM. v2: pci_is_thunderbolt_attached only works for Intel. Use pdev->external_facing instead. v3: dev_is_removable() seems to be what we want Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925Reviewed-by: -
Alex Deucher authored
Since they were moved to VRAM, we need to use the IO variants of memcpy. Fixes: 1cfb4d61 ("drm/amdgpu: put MQDs in VRAM") Reviewed-by:
-
Tao Zhou authored
Switch from mode-1 reset to mode-2 for poison consumption. Signed-off-by:
-
Lin.Cao authored
GFX doorbell range should be set after flr otherwise the gfx doorbell range will be overlap with MEC. v2: remove "amdgpu_sriov_vf" and "amdgpu_in_reset" check, and add grbm select for the case of 2 gfx rings. Signed-off-by:
Lin.Cao <lincao12@amd.com> Acked-by:
ZhenGuo Yin <zhenguo.yin@amd.com> Signed-off-by:
-
Ma Jun authored
Return 0 as the default min power limit for the asics use powerplay. Signed-off-by:
-
- 02 Nov, 2023 1 commit
-
-
Dave Airlie authored
Merge tag 'shmob-drm-atomic-dt-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into drm-next drm: renesas: shmobile: Atomic conversion + DT support Currently, there are two drivers for the LCD controller on Renesas SuperH-based and ARM-based SH-Mobile and R-Mobile SoCs: 1. sh_mobile_lcdcfb, using the fbdev framework, 2. shmob_drm, using the DRM framework. However, only the former driver is used, as all platform support integrates the former. None of these drivers support DT-based systems. Convert the SH-Mobile DRM driver to atomic modesetting, and add DT support, complemented by the customary set of fixes and improvements. Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/cover.1694767208.git.geert+renesas@glider.be/Signed-off-by:
-
- 31 Oct, 2023 2 commits
-
-
Yang Wang authored
remove unused macro HW_REV Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Ma Jun authored
MACO only works if BACO is supported Signed-off-by:
-
