Hello Yifan Zhang,
The patch 068ea8bdc0aa: "drm/amd/pm: add smu_v13_0_5_ppt
implementation" from Jan 21, 2022, leads to the following Smatch
static checker warning:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu13/smu_v13_0_5_ppt.c:444
smu_v13_0_5_set_watermarks_table()
warn: duplica
this patch updates message definition for smu 13.0.5
Signed-off-by: Yifan Zhang
---
.../inc/pmfw_if/smu13_driver_if_v13_0_5.h | 1 -
.../pm/swsmu/inc/pmfw_if/smu_v13_0_5_ppsmc.h | 56 +--
.../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 4 +-
3 files changed, 29 insertions(
Based on smu 13.0.5 features, refine pp table code.
Signed-off-by: Yifan Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 131 --
.../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.h | 1 +
2 files changed, 27 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/amd/
On 2/21/22 15:16, Alex Deucher wrote:
Is this system S0i3 or regular S3?
>>
>> For me it is real S3.
>>
>> The proposed patch is intended for INTEl + intel gpu + amdgpu but I have
>> dual amd GPU.
> It doesn't really matter what the platform is, it could still
> potentially help on your sys
Based on smu 13.0.5 features, refine pp table code.
Signed-off-by: Yifan Zhang
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 134 --
.../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.h | 1 +
2 files changed, 28 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/amd/
Am 2022-02-23 um 19:54 schrieb Alex Sierra:
This parameter controls xGMI p2p communication, which is enabled by
default. However, it can be disabled by setting it to 0. In case xGMI
p2p is disabled in a dGPU, PCIe p2p interface will be used instead.
This parameter is ignored in GPUs that do not s
On Tue, Feb 22, 2022 at 10:07 AM Guchun Chen wrote:
>
> Due to faulty VBIOS out there, harvest bit setting is not
> consistently correct especially for display IP. So far,
> it's hard to work out a solution on all the legacy Navi1x
> ASICs in a short time, so to avoid regression, limit harvest
> b
No because all the patch-set including this patch was landed into
drm-misc-next and will reach amd-staging-drm-next on the next upstream
rebase i guess.
Andrey
On 2022-02-24 01:47, JingWen Chen wrote:
Hi Andrey,
Will you port this patch into amd-staging-drm-next?
on 2/10/22 2:06 AM, Andrey
[Public]
If it applies cleanly, feel free to drop it in. I'll drop those patches for
drm-next since they are already in drm-misc.
Alex
From: amd-gfx on behalf of Andrey
Grodzovsky
Sent: Thursday, February 24, 2022 11:24 AM
To: Chen, JingWen ; Christian König
No problem if so but before I do,
JingWen - why you think this patch is needed as a standalone now ? It
has no use without the
entire feature together with it. Is it some changes you want to do on
top of that code ?
Andrey
On 2022-02-24 12:12, Deucher, Alexander wrote:
[Public]
If it
According to my investigation of the state of PCI
reset recently it's not working. The reason is
due to the fact the kernel PCI code rejects SBR
when there are more then one PF under same bridge
which we always have (at least AUDIO PF but usually
more) and that because SBR will reset all the PFS
an
On Thu, Feb 24, 2022 at 1:05 PM Andrey Grodzovsky
wrote:
>
> According to my investigation of the state of PCI
> reset recently it's not working. The reason is
> due to the fact the kernel PCI code rejects SBR
> when there are more then one PF under same bridge
> which we always have (at least AUD
From: Leo Li
[Why]
During DC init, we read power management tables from PMFW. This info is
exchanged in the form of a binary blob inside gpu memory. In order to
parse the binary blob, the correct struct needs to be used.
[How]
Fix dcn316's definition of the DfPstateTable_t struct to align with
Acked-by: Alex Deucher
On Thu, Feb 24, 2022 at 1:24 PM wrote:
>
> From: Leo Li
>
> [Why]
>
> During DC init, we read power management tables from PMFW. This info is
> exchanged in the form of a binary blob inside gpu memory. In order to
> parse the binary blob, the correct struct needs to be us
On 2022-02-24 13:24, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> During DC init, we read power management tables from PMFW. This info is
> exchanged in the form of a binary blob inside gpu memory. In order to
> parse the binary blob, the correct struct needs to be used.
>
> [How]
On 2022-02-24 13:11, Alex Deucher wrote:
On Thu, Feb 24, 2022 at 1:05 PM Andrey Grodzovsky
wrote:
According to my investigation of the state of PCI
reset recently it's not working. The reason is
due to the fact the kernel PCI code rejects SBR
when there are more then one PF under same bridge
Series is
Reviewed-by: Harry Wentland
Harry
On 2022-02-24 14:15, Magali Lemes wrote:
> This patchset addresses a few warnings reported by the Kernel Test Robot and
> sparse.
>
> Magali Lemes (4):
> drm/amd/display: Adjust functions documentation
> drm/amd/display: Add conditional around fun
Silence the following sparse warnings:
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:865:16:
sparse: warning: Using plain integer as NULL pointer
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:1588:84:
sparse: warning: Using plain integer as NULL p
This patchset addresses a few warnings reported by the Kernel Test Robot and
sparse.
Magali Lemes (4):
drm/amd/display: Adjust functions documentation
drm/amd/display: Add conditional around function
drm/amd/display: Use NULL instead of 0
drm/amd/display: Turn functions into static
drive
When CONFIG_DRM_AMD_DC_DCN is not set, the function
'dm_helpers_enable_periodic_detection' doesn't have its prototype defined,
causing the following warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:805:6:
warning: no previous prototype for function
'dm_helpers_enable_p
Part of the documentation of the 'dc_process_dmub_aux_transfer_async'
function was misplaced, being put together with the
‘dc_enable_dmub_notifications’ documentation. This caused the following
warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3757: warning:
expecting prototype for dc_pr
Silence [-Wmissing-prototypes] sparse warnings from the display folder
such as:
../drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn315/dcn315_smu.c:126:5:
warning: no previous prototype for ‘dcn315_smu_send_msg_with_param’
[-Wmissing-prototypes]
126 | int dcn315_smu_send_msg_with_param(
Applied with some minor modifications to patches 3 and 4 to avoid
adding new warnings.
Alex
On Thu, Feb 24, 2022 at 2:44 PM Harry Wentland wrote:
>
> Series is
> Reviewed-by: Harry Wentland
>
> Harry
>
> On 2022-02-24 14:15, Magali Lemes wrote:
> > This patchset addresses a few warnings reporte
Don't fill up the logs with:
[253557.859575] [drm:amdgpu_dm_atomic_check [amdgpu]] DSC precompute is not
needed.
[253557.892966] [drm:amdgpu_dm_atomic_check [amdgpu]] DSC precompute is not
needed.
[253557.926070] [drm:amdgpu_dm_atomic_check [amdgpu]] DSC precompute is not
needed.
[253557.959344
Various drivers in the kernel use `is_thunderbolt` or
`pci_is_thunderbolt_attached` to designate behaving differently
from a device that is internally in the machine. This currently works
by an attribute in PCI core "is_thunderbolt" which makes those drivers
only apply differences when Intel Thunde
`pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
controller to indicate that D3 is possible.
This is used solely for older Apple systems, due to a variety of factors:
* Apple used SW connection manager from the beginning, other manufacturers
used a FW connection manager (IC
The `is_thunderbolt` attribute originally had a well defined list of
quirks that it existed for, but it has been overloaded with more
meaning.
Instead use the driver core removable attribute to indicate the
detail a device is attached to a thunderbolt or USB4 chain.
Signed-off-by: Mario Limonciel
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Reviewed-by: Macpaul Lin
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
1 file changed, 2 inse
The `is_thunderbolt` check is currently used to indicate the lack of
command completed support for a number of older Thunderbolt devices.
This however is heavy handed and should have been done via a quirk. Move
the affected devices outlined in commit 493fb50e958c ("PCI: pciehp: Assume
NoCompl+ fo
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
As all drivers now look at the removable attribute, drop this function.
Signed-off-by: Mario Limonciello
---
include/linux/pci.h | 22 --
1 file changed, 22 deletions(-)
diff --git
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
drivers/gpu/drm/radeo
On Thu, Feb 24, 2022 at 4:46 PM Luben Tuikov wrote:
>
> Don't fill up the logs with:
>
> [253557.859575] [drm:amdgpu_dm_atomic_check [amdgpu]] DSC precompute is not
> needed.
> [253557.892966] [drm:amdgpu_dm_atomic_check [amdgpu]] DSC precompute is not
> needed.
> [253557.926070] [drm:amdgpu_dm_
I could, but if they enable KMS debug, this prints 100s of times a second.
It literally overflows the log. It needs to be printed "ONCE" in whichever mode.
Either that, or not print it at all--it is "DEBUG" after all.
Regards,
Luben
On 2022-02-24 17:21, Alex Deucher wrote:
> On Thu, Feb 24, 2022
If one thread takes read lock, one thread to acquire write lock, then
other thread can not acquire read lock while the writer is stalled. This
causes below deadlock case:
thread 1: prefetch range migrate to VRAM, take mmap read lock
thread 2: svm_range_evict_svm_bo_worker, migrate to RAM, take mma
On Thu, 24 Feb 2022, Christian König wrote:
> Interesting to know that it turned out to be the motherboard, going to keep
> that in mind if somebody else is having similar problems.
Looks like I might have spoke too soon, getting random resets again. I
have no idea why my nvidia card runs perfec
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with more
> > meaning.
> >
> > Ins
Hi Alex,
Exactly, I have the same idea, but I need to double confirm the harvest bit
settings are correct on all these listed ASICs. Once confirmed, I will drop the
redundant check.
Regards,
Guchun
-Original Message-
From: Alex Deucher
Sent: Thursday, February 24, 2022 11:58 PM
To: C
Hi Andrey,
Sorry for the misleading, I mean the whole patch series. We are depending on
this patch series to fix the concurrency issue within SRIOV TDR sequence.
On 2/25/22 1:26 AM, Andrey Grodzovsky wrote:
> No problem if so but before I do,
>
>
> JingWen - why you think this patch is needed
When PMFW is really busy, it will respond with 0xFC. However, it doesn't
change the response register state when it becomes free. Driver should
retry and proceed to send message if the response status is 0xFC.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c | 2 --
1 file ch
On Thu, Feb 24, 2022 at 10:48:14PM +0800, Zhang, Yifan wrote:
> Based on smu 13.0.5 features, refine pp table code.
>
> Signed-off-by: Yifan Zhang
Reviewed-by: Huang Rui
> ---
> .../drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c | 134 --
> .../drm/amd/pm/swsmu/smu13/smu_v13_0_5_pp
[AMD Official Use Only]
This may introduce some problems for two callers scenarios. That is the 2nd one
will still proceed even if the 1st one was already blocked.
Maybe the logics here should be performed by the caller. That is the caller can
perform something like issuing the same message agai
[AMD Official Use Only]
> That is the caller can perform something like issuing the same message again
> without prerequisites check on PMFW busy
This patch expects this method. Caller may try to resend message again. As part
of message sending, driver first checks response register. Current l
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Friday, February 25, 2022 1:47 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking ; Deucher, Alexander
> ; Wang, Yang(Kevin)
>
> Subject: RE: [PATCH] drm/amd/pm: Send message when resp status
On 2/25/2022 11:25 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Friday, February 25, 2022 1:47 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Wang, Yang(Kevin)
Subject: RE: [PATCH] drm/amd/pm
[AMD Official Use Only]
> -Original Message-
> From: Chai, Thomas
> Sent: Monday, February 21, 2022 6:16 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai, Thomas
> Subject: [PATCH 01/12] drm/amdgpu: Modify .ras_fini fun
[AMD Official Use Only]
> -Original Message-
> From: Chai, Thomas
> Sent: Monday, February 21, 2022 6:16 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai, Thomas
> Subject: [PATCH 02/12] drm/amdgpu: Optimize xxx_ras_fin
[AMD Official Use Only]
> -Original Message-
> From: Chai, Thomas
> Sent: Monday, February 21, 2022 6:16 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai, Thomas
> Subject: [PATCH 03/12] drm/amdgpu: centrally calls the
[AMD Official Use Only]
Other than my suggestions, the series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Chai, Thomas
> Sent: Monday, February 21, 2022 6:16 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai,
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Friday, February 25, 2022 2:03 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking ; Deucher, Alexander
> ; Wang, Yang(Kevin)
>
> Subject: Re: [PATCH] drm/amd/pm: Send message when resp status
On 2/25/2022 1:02 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Friday, February 25, 2022 2:03 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Deucher, Alexander
; Wang, Yang(Kevin)
Subject: Re: [PATCH] drm/amd/pm:
52 matches
Mail list logo
