[PATCH] drm/amd/pm: Fix missing thermal throttler status

On aldebaran, when thermal throttling happens due to excessive GPU temperature, the reason for throttling event is missed in warning message. This patch fixes it. Signed-off-by: Lijo Lazar --- drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 1 + 1 file changed, 1 insertion(+) diff --git

答复: [PATCH Review 1/1] drm/amdgpu: support ras on SRIOV

[AMD Official Use Only - General] [AMD Official Use Only - General] Thanks tao, will update before submit. Regards, Stanley 发件人: Zhou1, Tao 日期: 星期四, 2022年5月19日 上午10:30 收件人: Yang, Stanley , amd-gfx@lists.freedesktop.org , Zhang, Hawking 抄送: Yang, Stanley 主题: RE: [PATCH Review 1/1]

RE: [PATCH Review 1/1] drm/amdgpu: support ras on SRIOV

> -Original Message- > From: Stanley.Yang > Sent: Wednesday, May 18, 2022 11:44 PM > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking > ; Zhou1, Tao > Cc: Yang, Stanley > Subject: [PATCH Review 1/1] drm/amdgpu: support ras on SRIOV > > support umc/gfx/sdma ras on guest side > >

[linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific files for 20220518 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https

Re: [PATCH 2/2] drm/amdkfd: track unified memory reservation with xnack off

On 2022-05-18 14:36, philip yang wrote: On 2022-05-17 19:11, Alex Sierra wrote: [WHY] Unified memory with xnack off should be tracked, as userptr mappings and legacy allocations do. To avoid oversuscribe system memory when xnack off. [How] Exposing functions reserve_mem_limit and

Re: [PATCH 1/2] drm/amdgpu: remove acc_size from reserve/unreserve mem

On 2022-05-18 13:55, philip yang wrote: On 2022-05-17 19:11, Alex Sierra wrote: TTM used to track the "acc_size" of all BOs internally. We needed to keep track of it in our memory reservation to avoid TTM running out of memory in its own accounting. However, that "acc_size" accounting has

[pull] amdgpu, amdkfd drm-next-5.19

Hi Dave, Daniel, Stuff for 5.19. A bit late for new stuff, but it's just additional enablement for new IPs so they shouldn't affect existing parts. The rest is just the usual fixes. The following changes since commit 81c5495910e81c2cadcb9118ca0c8803ab3bde61: drm/amdgpu: Remove duplicated

[pull] amdgpu drm-fixes-5.18

Hi Dave, Daniel, Just one suspend/resume regression fix. The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git

[PATCH] umr: Completion: Fix regex for PCI bus names

Fix regex for PCI bus names. Previously we may see something like this: :0b:00.0 master=pci::0b:00.0 while the correct output should be this: :0b:00.0 This commit fixes the regex to do just this. Cc: Tom StDenis Signed-off-by: Luben Tuikov --- scripts/umr-completion.bash | 4

Re: [PATCH 2/2] drm/amdkfd: track unified memory reservation with xnack off

On 2022-05-17 19:11, Alex Sierra wrote: [WHY] Unified memory with xnack off should be tracked, as userptr mappings and legacy allocations do. To avoid oversuscribe system memory when xnack off. [How] Exposing functions reserve_mem_limit and unreserve_mem_limit to

Re: [PATCH] drm/amdgpu/pm: smu_v13_0_4: delete duplicate condition

Applied. Thanks! Alex On Wed, May 18, 2022 at 1:39 PM Dan Carpenter wrote: > > There is no need to check if "clock_ranges' is non-NULL. It is checked > already on the line before. > > Signed-off-by: Dan Carpenter > --- > .../drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 62 +--

Re: [PATCH 1/2] drm/amdgpu: remove acc_size from reserve/unreserve mem

On 2022-05-17 19:11, Alex Sierra wrote: TTM used to track the "acc_size" of all BOs internally. We needed to keep track of it in our memory reservation to avoid TTM running out of memory in its own accounting. However, that "acc_size" accounting has since been

Re: [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails

On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote: > Typically the acpi_video driver will initialize before nouveau, which > used to cause /sys/class/backlight/acpi_video0 to get registered and then > nouveau would register its own nv_backlight device later. After which > the

[PATCH] drm/amdgpu/pm: smu_v13_0_4: delete duplicate condition

There is no need to check if "clock_ranges' is non-NULL. It is checked already on the line before. Signed-off-by: Dan Carpenter --- .../drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 62 +-- 1 file changed, 30 insertions(+), 32 deletions(-) diff --git

Re: [PATCH 05/14] drm/nouveau: Don't register backlight when another backlight should be used

Reviewed-by: Lyude Paul Also, ack on this being pushed to drm-misc, along with any other patches I r-b On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote: > Before this commit when we want userspace to use the acpi_video backlight > device we register both the GPU's native backlight device

[PATCH Review 1/1] drm/amdgpu: support ras on SRIOV

support umc/gfx/sdma ras on guest side Changed from V1: move sriov judgment in amdgpu_ras_interrupt_fatal_error_handler Change-Id: Ic7dda45d8f8cf2d5f1abc7705abc153d558da8a1 Signed-off-by: Stanley.Yang --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++

Re: [PATCH v2 0/7] Fix multiple GPU resets in XGMI hive.

On 2022-05-18 02:07, Christian König wrote: Am 17.05.22 um 21:20 schrieb Andrey Grodzovsky: Problem: During hive reset caused by command timing out on a ring extra resets are generated by triggered by KFD which is unable to accesses registers on the resetting ASIC. Fix: Rework GPU reset to

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

On 5/18/22 01:38, Modem, Bhanuprakash wrote: > On Mon-16-05-2022 02:09 pm, Jani Nikula wrote: >> On Mon, 02 May 2022, Harry Wentland wrote: >>> Both the kernel and IGT series look good to me. >>> >>> I recommend you merge the entire kernel set as one into drm-next. We >>> can pull it into

Re: [PATCH 1/2] drm/amdkfd: port cwsr trap handler from dkms branch

On Tue, May 17, 2022 at 6:15 PM Eric Huang wrote: > > Most of changes are for debugger feature, and it is > to simplify trap handler support for new asics in the > future. > > Signed-off-by: Eric Huang Series is: Acked-by: Alex Deucher

Re: [PATCH] dc: Add HDMI_ACP_SEND register

On 5/18/22 03:49, Alan Liu wrote: > Define HDMI_ACP_SEND register shift/mask. > > Signed-off-by: Alan Liu Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/include/asic_reg/dce/dce_10_0_sh_mask.h | 2 ++ > drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_0_sh_mask.h | 2 ++ >

Re: [QUESTION] sh_mem_bases: amdkfd vs amdgpu

Am 2022-05-17 um 20:32 schrieb robert.d...@yahoo.com: Hi, There is an interesting feature divergence between amdgpu and amdkfd concerning the shared/private apertures. I restricted my analysis to gfx9, it may differ with other gfx. In amdgpu, the pair of aperture start addresses is defined

Re: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

[Public] DCN 3.1.6 needs it, but I don't know if yellow carp needs it. I think this is only applicable to kernel 5.18. @Kazlauskas, Nicholas can you verify? Alex From: VURDIGERENATARAJ, CHANDAN Sent: Wednesday, May 18,

Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

Hi, On 5/18/22 10:44, Jani Nikula wrote: > On Tue, 17 May 2022, Hans de Goede wrote: >> Hi All, >> >> As mentioned in my RFC titled "drm/kms: control display brightness through >> drm_connector properties": >> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ >>

Re: [PATCH 01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type()

Hi, On 5/18/22 10:55, Jani Nikula wrote: > On Tue, 17 May 2022, Hans de Goede wrote: >> ATM on x86 laptops where we want userspace to use the acpi_video backlight >> device we often register both the GPU's native backlight device and >> acpi_video's firmware acpi_video# backlight device. This

RE: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

Hi, Is S0i3 verified for DCN 3.1.6 with this? BR, Chandan V N >From: Eric Yang > >[ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ] > > [Why] >Z10 and S0i3 have some shared path. Previous code clean up , incorrectly >removed these pointers, which breaks s0i3 restore > > [How] >Do

[PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

From: Eric Yang [ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ] [Why] Z10 and S0i3 have some shared path. Previous code clean up , incorrectly removed these pointers, which breaks s0i3 restore [How] Do not clear the function pointers based on Z10 disable. Reviewed-by: Nicholas

RE: [PATCH Review 1/1] drm/amdgpu: support ras on SRIOV

[AMD Official Use Only - General] > -Original Message- > From: Stanley.Yang > Sent: Wednesday, May 18, 2022 4:32 PM > To: amd-gfx@lists.freedesktop.org; Zhang, Hawking > ; Zhou1, Tao > Cc: Yang, Stanley > Subject: [PATCH Review 1/1] drm/amdgpu: support ras on SRIOV > > support

Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

On Wed, 18 May 2022, Hans de Goede wrote: > Hi, > > On 5/18/22 10:44, Jani Nikula wrote: >> On Tue, 17 May 2022, Hans de Goede wrote: >>> Hi All, >>> >>> As mentioned in my RFC titled "drm/kms: control display brightness through >>> drm_connector properties": >>>

Re: [PATCH 01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type()

On Tue, 17 May 2022, Hans de Goede wrote: > ATM on x86 laptops where we want userspace to use the acpi_video backlight > device we often register both the GPU's native backlight device and > acpi_video's firmware acpi_video# backlight device. This relies on > userspace preferring firmware type

Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

On Tue, 17 May 2022, Hans de Goede wrote: > Hi All, > > As mentioned in my RFC titled "drm/kms: control display brightness through > drm_connector properties": > https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ > > The first step towards this is to deal with some

[PATCH Review 1/1] drm/amdgpu: support ras on SRIOV

support umc/gfx/sdma ras on guest side Signed-off-by: Stanley.Yang --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 4 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 23 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c |

Re: [PATCH 2/3] drm/amdgpu: add AMDGPU_VM_NOALLOC

Found and fixed. If nobody has any more objections are batter names for the new flags I'm going to push this to amd-staging-drm-next tomorrow. Thanks, Christian. Am 17.05.22 um 08:33 schrieb Christian König: Ok that sounds like a rather simple bug. I will try to take a look. Thanks,

[PATCH] dc: Add HDMI_ACP_SEND register

Define HDMI_ACP_SEND register shift/mask. Signed-off-by: Alan Liu --- drivers/gpu/drm/amd/include/asic_reg/dce/dce_10_0_sh_mask.h | 2 ++ drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_0_sh_mask.h | 2 ++ drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_sh_mask.h | 2 ++

[QUESTION] sh_mem_bases: amdkfd vs amdgpu

Hi, There is an interesting feature divergence between amdgpu and amdkfd concerning the shared/private apertures. I restricted my analysis to gfx9, it may differ with other gfx. In amdgpu, the pair of aperture start addresses is defined the following way (in gmc_v9_0.c): *

Re: [PATCH v2 0/7] Fix multiple GPU resets in XGMI hive.

Am 17.05.22 um 21:20 schrieb Andrey Grodzovsky: Problem: During hive reset caused by command timing out on a ring extra resets are generated by triggered by KFD which is unable to accesses registers on the resetting ASIC. Fix: Rework GPU reset to actively stop any pending reset works while

Re: [PATCH v2 2/7] drm/amdgpu: Switch to delayed work from work_struct.

Am 17.05.22 um 21:20 schrieb Andrey Grodzovsky: We need to be able to non blocking cancel pending reset works from within GPU reset. Currently kernel API allows this only for delayed_work and not for work_struct. Switch to delayed work and queue it with delay 0 which is equal to queueing work

Re: [PATCH v2 1/7] drm/amdgpu: Cache result of last reset at reset domain level.

Am 17.05.22 um 21:20 schrieb Andrey Grodzovsky: Will be read by executors of async reset like debugfs. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 -- drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h |