On 2021-10-19 00:38, Lazar, Lijo wrote:
>
> On 10/19/2021 9:45 AM, Luben Tuikov wrote:
>> On 2021-10-18 23:38, Lazar, Lijo wrote:
>>> On 10/19/2021 5:19 AM, Luben Tuikov wrote:
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state.
On 10/19/2021 9:45 AM, Luben Tuikov wrote:
On 2021-10-18 23:38, Lazar, Lijo wrote:
On 10/19/2021 5:19 AM, Luben Tuikov wrote:
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the
Kent,
What is the command which fails?
I can try to duplicate it here.
So far, things I've tried, I cannot make rocm-smi fail. Command
arguments?
Regards,
Luben
On 2021-10-18 21:06, Russell, Kent wrote:
On 2021-10-18 23:38, Lazar, Lijo wrote:
On 10/19/2021 5:19 AM, Luben Tuikov wrote:
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible
[AMD Official Use Only]
> -Original Message-
> From: Liu, Aaron
> Sent: Tuesday, October 19, 2021 11:23 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Ray
> ; Liu, Aaron
> Subject: [PATCH] drm/amdgpu: support B0 external revision id for yellow
> carp
>
> B0
On 10/19/2021 5:19 AM, Luben Tuikov wrote:
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible operating (non-zero)
frequencies of the block requested. So, if the
current
B0 internal rev_id is 0x01, B1 internal rev_id is 0x02.
The external rev_id for B0 and B1 is 0x20.
The original expression is not suitable for B1.
Signed-off-by: Aaron Liu
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, October 18, 2021 6:47 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; b...@alien8.de
> Subject: Re: [PATCH] drm/amdgpu: fix the hang observed on Carrizo due to
> UVD suspend
[AMD Official Use Only]
The * is required for the rocm-smi's functionality for showing what the current
clocks are. We had a bug before where the * was removed, then the SMI died
fantastically. Work could be done to try to handle that type of situation, but
the SMI has a "show current clocks"
[AMD Official Use Only]
+Harish, rocm-smi falls under his purview now.
Kent
From: Tuikov, Luben
Sent: Monday, October 18, 2021 4:30 PM
To: Deucher, Alexander ; Quan, Evan
; Lazar, Lijo ;
amd-gfx@lists.freedesktop.org; Russell, Kent
Subject: Re: [PATCH 0/5] 0 MHz is not a valid current
Rename "cur_value", which stands for "cursor
value" to "curr_value", which stands for "current
value".
Cc: Alex Deucher
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 12 ++--
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 15 ---
2
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible operating (non-zero)
frequencies of the block requested. So, if the
current clock value is 0, then print the DPM
frequencies,
A current value of a clock frequency of 0, means
that the IP block is in some kind of low power
state. Ignore it and don't report it here. Here we
only report the possible operating (non-zero)
frequencies of the block requested. So, if the
current clock value is 0, then print the DPM
frequencies,
By usage: read freq_values[x] to freq_value[x].
Cc: Alex Deucher
Signed-off-by: Luben Tuikov
---
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 16
.../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 18 +-
2 files changed, 17 insertions(+), 17 deletions(-)
Some ASICs support low-power functionality for the whole ASIC or just
an IP block. When in such low-power mode, some sysfs interfaces would
report a frequency of 0, e.g.,
$cat /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 0Mhz *
2: 2200Mhz
$_
An operating frequency of 0 MHz doesn't make
Rename
sienna_cichlid_is_support_fine_grained_dpm() to
sienna_cichlid_supports_fine_grained_dpm().
Rename
navi10_is_support_fine_grained_dpm() to
navi10_supports_fine_grained_dpm().
v2: Fix function name in commit message to reflect
the change being done: add a missing 's'.
v3: Start the subject
Dear Augustin,
Am 15.10.21 um 20:43 schrieb Agustin Gutierrez:
This reverts commit 50ac5b14c74c5706796cb6378f25a2121dba5b2d.
This patch introduced a couple of dmesg warnings,
Please give one example warning for people searching through the git
history.
this is not a valid approach
Dear Augustin,
Am 15.10.21 um 20:43 schrieb Agustin Gutierrez:
This reverts commit 4e605d4b6a510f751b22df4d13829aefb8a0ccec.
Why?
(Do revert commits need a Signed-off-by line?)
Kind regards,
Paul
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
1 file changed, 2
Dear Simon,
Am 19.10.21 um 01:06 schrieb Simon Ser:
On Tuesday, October 19th, 2021 at 01:03, Paul Menzel wrote:
Excuse my ignorance. Reading the commit message, there was a Linux
kernel change, that broke Chrome OS userspace, right? If so, and we do
not know if there is other userspace using
On Tuesday, October 19th, 2021 at 01:03, Paul Menzel
wrote:
> Excuse my ignorance. Reading the commit message, there was a Linux
> kernel change, that broke Chrome OS userspace, right? If so, and we do
> not know if there is other userspace using the API incorrectly,
> shouldn’t the patch
On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > device-dax uses PUD, along with TTM, they are the only places. I'm not
> > sure TTM is a real place though.
>
> I was setting device-dax aside because it can use Joao's changes to
> get compound-page support.
Ideally, but that
Dear Simon,
Am 14.10.21 um 17:35 schrieb Simon Ser:
This reverts commits ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication
when using overlay") and e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay
validation by considering cursors"").
tl;dr ChromeOS uses the atomic interface for
Okay, no problem--I'll add a verb there and resend the patch set. Thanks for
letting me know.
Regards,
Luben
On 2021-10-18 18:52, Paul Menzel wrote:
> Dear Luben,
>
>
> Am 13.10.21 um 05:10 schrieb Luben Tuikov:
>
> […]
>
> A small nit regarding the subject. It’d be great if you made it a
>
Dear Nicholas, dear Eric, dear Augustin,
Am 18.10.21 um 19:14 schrieb Kazlauskas, Nicholas:
On 2021-10-15 7:53 p.m., Mike Lothian wrote:
This patch seems to change z8 - not that I know what z8 or z9 are
It's a little misleading but the patch and terminology is correct.
Z9 is the usecase
Dear Nikola, dear Augustin,
Am 15.10.21 um 20:43 schrieb Agustin Gutierrez:
From: Nikola Cornij
[why]
The original latencies were causing underflow in some modes
Which modes exactly? On what hardware? How can it be reproduced?
[how]
Replace with the up-to-date watermark values based on
Dear Luben,
Am 13.10.21 um 05:10 schrieb Luben Tuikov:
[…]
A small nit regarding the subject. It’d be great if you made it a
statement by adding a verb (in imperative mood). git standard messages
are doing the same with *Merge …* and *Revert …*.
Kind regards,
Paul
I think Kent is already seen these
patches as he did comment on 1/5 patch.
The v3 version of the patch, posted last week, removes the
asterisk to report the lowest frequency as the current frequency,
when the current frequency is 0, i.e. when the block is in
[Public]
We the current behavior (0 for clock) already crashes the tool, so I don't
think we can really make things worse.
Alex
From: Quan, Evan
Sent: Thursday, October 14, 2021 10:25 PM
To: Lazar, Lijo ; Tuikov, Luben ;
amd-gfx@lists.freedesktop.org ;
On Mon, Oct 18, 2021 at 11:26 AM Jason Gunthorpe wrote:
>
> On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
>
> > > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > > THP would make using normal refconting much simpler. I looked at
> > > teaching the mm core
On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
> > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > THP would make using normal refconting much simpler. I looked at
> > teaching the mm core to deal with page arrays - it is certainly
> > doable, but it is
On 2021-10-15 7:53 p.m., Mike Lothian wrote:
This patch seems to change z8 - not that I know what z8 or z9 are
It's a little misleading but the patch and terminology is correct.
Z9 is the usecase for these watermarks even if the calculation is shared
with Z8/Z9.
Regards,
Nicholas
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, with the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
AMD
Am 18.10.21 um 09:34 schrieb Evan Quan:
It's confirmed that on some APUs the interaction with SMU(about DPM disablement)
will power off the UVD. That will make the succeeding interactions with UVD on
the
suspend path impossible. And the system will hang due to that. To workaround the
issue, we
Am 13.10.21 um 15:38 schrieb Arunpravin:
Move vram related defines and inline functions into
a separate header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 72
1 file changed, 72 insertions(+)
create mode 100644
On Mon, Oct 18, 2021 at 09:37:13AM -0400, Harry Wentland wrote:
> On 2021-10-17 07:34, Claudio Suarez wrote:
> >
> > From the TODO list Documentation/gpu/todo.rst
> > ---
> > Once EDID is parsed, the monitor HDMI support information is available
> > through
> >
On Mon, Oct 18, 2021 at 10:30 AM Guchun Chen wrote:
>
> Otherwise, hw_id_name string is NULL for SDMA 2 and 3 when dumping
> ip version from VBIOS.
>
> Signed-off-by: Guchun Chen
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
> 1 file changed, 2
Otherwise, hw_id_name string is NULL for SDMA 2 and 3 when dumping
ip version from VBIOS.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
[Public]
> -Original Message-
> From: Wentland, Harry
> Sent: Monday, October 18, 2021 9:57 AM
> To: Limonciello, Mario ; Li, Roman
> ; amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Siqueira, Rodrigo
>
> Cc: sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/amd/display: Fully
On 2021-10-18 09:41, Limonciello, Mario wrote:
> On 10/15/2021 17:31, roman...@amd.com wrote:
>> From: Roman Li
>>
>> [Why]
>> On renoir usb-c port stops functioning on resume after f/w update.
>> New dmub firmware caused regression due to conflict with dmcu.
>> With new dmub f/w dmcu is
On 10/15/2021 17:31, roman...@amd.com wrote:
From: Roman Li
[Why]
On renoir usb-c port stops functioning on resume after f/w update.
New dmub firmware caused regression due to conflict with dmcu.
With new dmub f/w dmcu is superseded and should be disabled.
[How]
- Disable dmcu for all dcn21.
On 10/18/2021 08:38, Harry Wentland wrote:
On 2021-10-15 18:31, roman...@amd.com wrote:
From: Roman Li
[Why]
On renoir usb-c port stops functioning on resume after f/w update.
New dmub firmware caused regression due to conflict with dmcu.
With new dmub f/w dmcu is superseded and should be
On 2021-10-15 18:31, roman...@amd.com wrote:
> From: Roman Li
>
> [Why]
> On renoir usb-c port stops functioning on resume after f/w update.
> New dmub firmware caused regression due to conflict with dmcu.
> With new dmub f/w dmcu is superseded and should be disabled.
>
> [How]
> - Disable dmcu
On 2021-10-17 07:34, Claudio Suarez wrote:
>
> From the TODO list Documentation/gpu/todo.rst
> ---
> Once EDID is parsed, the monitor HDMI support information is available through
> drm_display_info.is_hdmi. Many drivers still call drm_detect_hdmi_monitor() to
> retrieve the
On Fri, Oct 15, 2021 at 6:33 PM wrote:
>
> From: Roman Li
>
> [Why]
> On renoir usb-c port stops functioning on resume after f/w update.
> New dmub firmware caused regression due to conflict with dmcu.
> With new dmub f/w dmcu is superseded and should be disabled.
>
> [How]
> - Disable dmcu for
On Mon, Oct 18, 2021 at 03:34:32PM +0800, Evan Quan wrote:
> It's confirmed that on some APUs the interaction with SMU(about DPM
> disablement)
> will power off the UVD. That will make the succeeding interactions with UVD
> on the
> suspend path impossible. And the system will hang due to that.
[AMD Official Use Only]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zhou1, Tao
Sent: Monday, October 18, 2021 18:50
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ;
Clements, John ; Yang, Stanley
Cc: Zhou1, Tao
Subject: [PATCH 2/2] drm/amdgpu:
Output a warning message if RAS TA returns UNSUPPORTED_ERROR_INJ status.
v2: implement it in psp_ras_ta_check_status function.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4
drivers/gpu/drm/amd/amdgpu/ta_ras_if.h | 7 ++-
2 files changed, 10 insertions(+), 1
Create new function to check status returned by RAS TA.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
On 10/18/2021 3:21 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Monday, October 18, 2021 3:58 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; b...@alien8.de
Subject: Re: [PATCH] drm/amdgpu: fix the hang
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, October 18, 2021 3:58 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; b...@alien8.de
> Subject: Re: [PATCH] drm/amdgpu: fix the hang observed on Carrizo due to
> UVD suspend
On 10/18/2021 2:38 PM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Monday, October 18, 2021 4:05 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Grodzovsky,
Andrey
Subject: Re: [PATCH] drm/amdgpu: fix Polaris12
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, October 18, 2021 4:05 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Grodzovsky,
> Andrey
> Subject: Re: [PATCH] drm/amdgpu: fix Polaris12 uvd crash on driver unload
>
>
On 10/18/2021 1:06 PM, Quan, Evan wrote:
[AMD Official Use Only]
Ping..
-Original Message-
From: Quan, Evan
Sent: Monday, October 11, 2021 4:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Grodzovsky,
Andrey ; Quan, Evan
Subject: [PATCH] drm/amdgpu: fix Polaris12
On 10/18/2021 1:04 PM, Evan Quan wrote:
It's confirmed that on some APUs the interaction with SMU(about DPM disablement)
will power off the UVD. That will make the succeeding interactions with UVD on
the
suspend path impossible. And the system will hang due to that. To workaround the
issue,
[AMD Official Use Only]
Ping..
> -Original Message-
> From: Quan, Evan
> Sent: Monday, October 11, 2021 4:28 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Grodzovsky,
> Andrey ; Quan, Evan
>
> Subject: [PATCH] drm/amdgpu: fix Polaris12 uvd crash on driver unload
>
It's confirmed that on some APUs the interaction with SMU(about DPM disablement)
will power off the UVD. That will make the succeeding interactions with UVD on
the
suspend path impossible. And the system will hang due to that. To workaround the
issue, we will skip the UVD(or VCE) power off during
On Thu, Oct 14, 2021 at 10:45:52PM -0500, Sierra Guiza, Alejandro (Alex) wrote:
>
> On 10/14/2021 3:57 PM, Ralph Campbell wrote:
> >
> > On 10/14/21 11:01 AM, Jason Gunthorpe wrote:
> > > On Thu, Oct 14, 2021 at 10:35:27AM -0700, Ralph Campbell wrote:
> > >
> > > > I ran xfstests-dev using the
57 matches
Mail list logo
