store swsmu user power configurations which include
power limit, clock frequencies, fan speed and fan mode
on suspend and reinstate on resume.
V2: Addressed Lijo's review comments
added a function to set clock interdependencies
add check on fan control mode to reapply fan speed
V3:
On Tue, 26 Jan 2021 21:23:17 +0100,
Bjorn Helgaas wrote:
>
> From: Bjorn Helgaas
>
> The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
> Replace it with "if (ACPI_SUCCESS(status))".
>
> Signed-off-by: Bjorn Helgaas
> ---
>
> This isn't really an ACPI patch, but I'm
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
Actually the FA DCS is dependent on the workload type.
FA DCS is applied only when there's 3D fullscreen workload or VR workload.
So we need to disable it if there's a request from the sysfs/user to set the
workload type to 3D
[AMD Public Use]
Agree and the patch looks good so far.
Thanks,
Lijo
From: Deucher, Alexander
Sent: Wednesday, January 27, 2021 10:13 AM
To: Lazar, Lijo ; Chen, Guchun ; Quan,
Evan ; Alex Deucher ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/pm/smu11: fix static fan speed
So mesa can check when to query the kernel vs use hardcoded
codec bandwidth data.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
We currently hardcode these in mesa, but querying them from
the kernel makes more sense since there may be board specific
limitations that the kernel driver is better suited to
determining.
Userpace patches that use this interface:
For each asic family. Will be used to populate tables
for the new INFO ioctl query.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 70 ++
drivers/gpu/drm/amd/amdgpu/nv.c| 162 ++
drivers/gpu/drm/amd/amdgpu/si.c| 104 +++
This will be used by a new INFO ioctl query to fetch the decode
and encode capabilities from the kernel driver rather than
hardcoding them in mesa. This gives us more fine grained control
of capabilities using information that is only availabl in the
kernel (e.g., platform limitations or
On Tue, Jan 26, 2021 at 8:42 PM Kenneth Feng wrote:
>
> Background:
> Gfx Duty Cycle Scaling(DCS) is applied on the small power limit skus.
> When the current/power/temperature exceeds the limit with the heavy workload,
> the gfx core can be shut off and powered on back and forth.
> The ON time
[AMD Public Use]
+ if (adev->asic_type == CHIP_NAVY_FLOUNDER || adev->asic_type ==
CHIP_DIMGREY_CAVEFISH)
We shall consider merge the logic to adev->asic_type > CHIP_ SIENNA_CICHLID. I
think it is also supported in SIENNA_CICHLID, right? So we haven't verified on
SIENNA_CICHLID yet?
[AMD Public Use]
> -Original Message-
> From: Bjorn Helgaas
> Sent: Tuesday, January 26, 2021 3:23 PM
> To: Rafael J . Wysocki ; Len Brown ;
> Deucher, Alexander ; Koenig, Christian
> ; Jean Delvare ; Guenter
> Roeck ; Corentin Chary ;
> Mark Brown ; Jaroslav Kysela ;
> Takashi Iwai
>
[AMD Public Use]
As Evan said, this code is unused anyway and I have a patch in the works to
drop all of this anyway. The manual manual rpm interface seems to not work on
some boards at all. I guess the pwm interface is a better bet for manual fan
control. See:
[AMD Public Use]
As far as I know, refclk is fixed at 25M for TACH; no need to consider ASIC
refclk.
Thanks,
Lijo
From: amd-gfx On Behalf Of Deucher,
Alexander
Sent: Wednesday, January 27, 2021 10:05 AM
To: Chen, Guchun ; Quan, Evan ; Alex
Deucher ; amd-gfx@lists.freedesktop.org
Subject:
[AMD Public Use]
Is the xclk really 25 Mhz or is there some divider for the fan stuff? Changing
the xclk value will affect other places where this is used.
Alex
From: Chen, Guchun
Sent: Tuesday, January 26, 2021 11:33 PM
To: Quan, Evan ; Alex Deucher ;
[AMD Public Use]
In soc15_get_xclk, we have independent handling for CHIP_RAVEN case.
If (adev->asic_type == CHIP_RAVEN)
return reference_clock / 4;
I am not sure if it's better to squash the patch into the asic specific
function? Then we have one unified place to handle it.
Regards,
[AMD Public Use]
As crystal clock is not guaranteed to be 100M always, it's better to hardcode
to 25M.
Thanks,
Lijo
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Wednesday, January 27, 2021 9:16 AM
To: Alex Deucher ; amd-gfx@lists.freedesktop.org
Cc: Deucher,
[AMD Public Use]
> -Original Message-
> From: Kenneth Feng
> Sent: Wednesday, January 27, 2021 9:42 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhou1, Tao ; Feng, Kenneth
>
> Subject: [PATCH] drm/amd/pm: Enable gfx DCS feature
>
> Background:
> Gfx Duty Cycle Scaling(DCS) is applied
[AMD Official Use Only - Internal Distribution Only]
Actually after switching to retrieve fan speed from metrics table always, this
API is not used any more.
Maybe we can just drop it. Either way the patch is reviewed-by: Evan Quan
BR
Evan
-Original Message-
From: amd-gfx On Behalf
Until the issues in the SMU firmware are fixed.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
drivers/gpu/drm/amd/amdgpu/nv.c| 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
On Tue, Jan 26, 2021 at 02:23:17PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
> Replace it with "if (ACPI_SUCCESS(status))".
>
> Signed-off-by: Bjorn Helgaas
> ---
>
> This isn't really an ACPI patch, but I'm
Background:
Gfx Duty Cycle Scaling(DCS) is applied on the small power limit skus.
When the current/power/temperature exceeds the limit with the heavy workload,
the gfx core can be shut off and powered on back and forth.
The ON time and OFF time is determined by the firmware according to
the
This patch adds tracking of which cgroup to make charges against for a
given GEM object. We associate the current task's cgroup with GEM objects
as they are created. First user of this is for charging DRM cgroup for
device memory allocations. The intended behavior is for device drivers to
make
Add basic .seq_show and .write functions for use with DRM cgroup control
files. This is based on original work from Kenny Ho and extracted from
patches [1] and [2]. Has been simplified to remove having different file
types and functions for each.
[1]
To charge device memory allocations, we need to (1) identify appropriate
cgroup to charge (currently decided at object creation time), and (2)
make the charging call at the time that memory pages are being allocated.
For (1), see prior DRM patch which associates current task's cgroup with
GEM
Single control below is added to DRM cgroup controller in order to track
user execution time for GPU devices. It is up to device drivers to
charge execution time to the cgroup via drm_cgroup_try_charge().
sched.runtime
Read-only value, displays current user execution time for each DRM
Here we introduce a general purpose drm_cgroup_try_charge and uncharge
pair of functions. This is modelled after the existing RDMA cgroup controller,
and the idea is for these functions to be used for charging/uncharging all
current and future DRM resource controls.
Two new controls are added in
From: Kenny Ho
Since the drm subsystem can be compiled as a module and drm devices can
be added and removed during run time, add several functions to bind the
drm subsystem as well as drm devices with drmcg.
Two pairs of functions:
drmcg_bind/drmcg_unbind - used to bind/unbind the drm subsystem
We'd like to revisit the proposal of a GPU cgroup controller for managing
GPU devices but with just a basic set of controls. This series is based on
the prior patch series from Kenny Ho [1]. We take Kenny's base patches
which implement the basic framework for the controller, but we propose an
Following control is introduced in order to display total memory that
exists for the DRM device. DRM drivers can advertise this value by
writing to drm_device.drmcg_props. This is needed in order to effectively
use the other memory controls.
Normally for system memory this is available to the user
From: Kenny Ho
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
From: Kenny Ho
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after
From: Bjorn Helgaas
The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
Replace it with "if (ACPI_SUCCESS(status))".
Signed-off-by: Bjorn Helgaas
---
This isn't really an ACPI patch, but I'm sending it to you, Rafael, since
it seems easier to just apply these all at once.
The xclk needs to be divided by 4.
Fixes: acab02c1af43d3 ("drm/amdgpu/pm/smu11: Fix fan set speed bug")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Hi,
This update doesn't match the gc_9_0_0 headers from the drm-next branch as
such cannot be made to umr. You need to first update the kernel headers
and then we circle back to umr.
Tom
On Tue, Jan 26, 2021 at 12:43 AM wrote:
> From: Guo Lei
>
> sync form drm-next
>
> Signed-off-by: Guo
On 2021-01-26 9:51 a.m., Ernst Sjöstrand wrote:
No problems with amdgpu, but when my headphone port is glitching I often
end up with some HDMI audio output selected instead.
Wouldn't this be better fixed in the audio management service, like
PulseAudio? It sounds like it's not remembering
No problems with amdgpu, but when my headphone port is glitching I often
end up with some HDMI audio output selected instead.
It also cleans up the clutter in the audio selection list.
//E
Den tis 26 jan. 2021 kl 15:34 skrev Alex Deucher :
> On Tue, Jan 26, 2021 at 9:32 AM Ernst Sjöstrand
On Tue, Jan 26, 2021 at 9:32 AM Ernst Sjöstrand wrote:
>
> With the pre-DC path you could set audio=0 to disable audio.
> This adds a similar feature for the DC path with
> amdgpu.dcfeaturemask=0x10.
>
> Signed-off-by: Ernst Sjöstrand
Is there a reason you want this? I.e., is audio causing
With the pre-DC path you could set audio=0 to disable audio.
This adds a similar feature for the DC path with
amdgpu.dcfeaturemask=0x10.
Signed-off-by: Ernst Sjöstrand
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 7 ---
38 matches
Mail list logo
