[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kenneth Feng
-Original Message-
From: Quan, Evan
Sent: Wednesday, August 5, 2020 11:24 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Feng, Kenneth
; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: grant
For Arcturus, the softmin/max settings from driver are permitted on the
latest(54.26 later) SMU firmware. Thus enabling them in driver.
Change-Id: Iff9ac326610075aa7f61cb89c64d2c4128678755
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 10 ++
1 file changed,
[AMD Official Use Only - Internal Distribution Only]
The cache is useful for the case like sysfs "amdgpu_pm_info". Which inquires
many metrics data in a very short period.
Without the cache, there will be multiple table transfers triggered(unnecessary
as the PMFW sample interval is 1ms).
The un
[AMD Official Use Only - Internal Distribution Only]
At the risk of asking a dumb question, does amdgpu default to using DC on SI
and CI ?
I'm asking because a lot of people seem to be using amdgpu successfully with
analog outputs today on SI/CI... suggests that they are not using DC ?
If so t
Am 2020-08-04 um 8:43 p.m. schrieb Philip Yang:
> If multiple process share system memory through /dev/shm, KFD allocate
> memory should not fail if it reaches the system memory limit because
> one copy of physical system memory are shared by multiple process.
>
> Add module parameter no_system_mem
If multiple process share system memory through /dev/shm, KFD allocate
memory should not fail if it reaches the system memory limit because
one copy of physical system memory are shared by multiple process.
Add module parameter no_system_mem_limit to provide user option to
disable system memory li
On Mon, Aug 3, 2020 at 4:21 AM Tianjia Zhang
wrote:
>
> On an error exit path, a negative error code should be returned
> instead of a positive return value.
>
> Fixes: 9e869063b0021 ("drm/amd/display: Move iteration out of
> dm_update_planes")
> Cc: Leo Li
> Signed-off-by: Tianjia Zhang
Appli
This adds modifier support to radeonsi.
It has been tested on
- VEGA10, RAVEN, NAVI14
- weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works)
and includes some basic testing of the layout code.
The main goal is to keep it somewhat simple and regression free, so
on the display sid
This sets the DC tiling options from the modifier, if modifiers
are used for the FB. This patch by itself does not expose the
support yet though.
There is not much validation yet to limit the scope of this
patch, but the current validation is at the same level as
the BO metadata path.
Signed-off-
This expose modifier support on GFX9+.
Only modifiers that can be rendered on the current GPU are
added. This is to reduce the number of modifiers exposed.
The HW could expose more, but the best mechanism to decide
what to expose without an explosion in modifiers is still
to be decided, and in th
Prepare for inserting modifiers based configuration, while sharing
a bunch of DCC validation & initializing the device-based configuration.
Signed-off-by: Bas Nieuwenhuizen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 209 ++
1 file changed, 116 insertions(+), 93 deletions
This adds modifiers for GFX9+ AMD GPUs.
As the modifiers need a lot of parameters I split things out in
getters and setters.
- Advantage: simplifies the code a lot
- Disadvantage: Makes it harder to check that you're setting all
the required fields.
The tiling modes seem to
Otherwise the field ends up being used uninitialized when
enabling modifiers, failing validation with high likelihood.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu
With modifiers I'd like to support non-dedicated buffers for
images.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/driv
Silently accepting it could result in corruption.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/
For DCC we will use 2/3 planes to avoid X rendering to the frontbuffer
with DCC compressed images. To make this work with the core KMS
validation we need to add extra formats with the extra planes.
However, due to flexibility we set bpp = 0 for the extra planes and
do the validation ourselves.
Si
Am 2020-08-04 um 4:42 p.m. schrieb Philip Yang:
> If multiple process share system memory through /dev/shm, KFD allocate
> memory should not fail if it reaches the system memory limit because
> one copy of physical system memory are shared by multiple process.
>
> Add module parameter no_system_m
Applied the series. Thanks!
Alex
On Tue, Aug 4, 2020 at 4:08 PM Rikard Falkeborn
wrote:
>
> Constify a couple of instances of resource_funcs that are never
> modified to allow the compiler to put it in read-only memory.
>
> The other drivers in drivers/gpu/drm/amd/display/dc already have
> thes
If multiple process share system memory through /dev/shm, KFD allocate
memory should not fail if it reaches the system memory limit because
one copy of physical system memory are shared by multiple process.
Add module parameter no_system_mem_limit to provide user option to
disable system memory li
Do we want the metrics cache at all? I can see arguments both ways.
Patches 12-17 are:
Reviewed-by: Alex Deucher
On Thu, Jul 30, 2020 at 10:45 PM Evan Quan wrote:
>
> As for the gpu metric export, metrics cache makes no sense. It's up to
> user to decide how often the metrics should be retrieved
Patches 9-11 are:
Reviewed-by: Alex Deucher
On Thu, Jul 30, 2020 at 10:44 PM Evan Quan wrote:
>
> Add Vega12 gpu metrics export interface.
>
> Change-Id: I2c910f523049f0f90eecb8d74cb73ebb39a22bd9
> Signed-off-by: Evan Quan
> ---
> .../drm/amd/powerplay/hwmgr/vega12_hwmgr.c| 111 +++
Applied. Thanks!
Alex
On Mon, Aug 3, 2020 at 10:35 AM Dan Carpenter wrote:
>
> The if statement wasn't indented so it's confusing.
>
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.
With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' a
The only usage of dcn20_res_pool_funcs is to assign its address to a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Constify a couple of instances of resource_funcs that are never
modified to allow the compiler to put it in read-only memory.
The other drivers in drivers/gpu/drm/amd/display/dc already have
these as const.
Rikard Falkeborn (3):
drm/amd/display: Constify dcn20_res_pool_funcs
drm/amd/display:
The only usage of dcn30_res_pool_funcs is to assign its address to a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The only usage of dcn21_res_pool_funcs is to assign its address to a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Jul 21, 2020 at 2:21 PM Harvey wrote:
>
> Alex,
>
> tnak you so much - you're my hero!
>
> Am 21.07.20 um 18:17 schrieb Alex Deucher:
> > On Mon, Jul 20, 2020 at 4:22 AM Harvey wrote:
> >>
> >> Hello,
> >>
> >> this is my first post to this list so please be patient with me ;)
> >>
> >> T
On Mon, Aug 3, 2020 at 12:47 AM Evan Quan wrote:
>
> As VCN related dpm table setup needs VCN be in PG ungate state. Same logics
> applies to JPEG.
>
> Change-Id: I94335efc4e0424cfe0991e984c938998fd8f1287
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 38
On 04/08/2020 18:34, Colin King wrote:
> From: Colin Ian King
>
> There are spelling mistakes in two DRM_ERROR error messages. Fix them.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
From: Colin Ian King
There are spelling mistakes in two DRM_ERROR error messages. Fix them.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_d
On Tue, 4 Aug 2020, Kazlauskas, Nicholas wrote:
> This is a cleaner change the other proposed patch since it doesn't need to
Can you give a URL to the other patch please?
> modify the exist conversion functions but I'd be worried about broken
> userspace relying on 0-255 as the only acceptabl
On Tue, Aug 4, 2020 at 4:38 AM Michel Dänzer wrote:
>
> On 2020-08-03 1:45 a.m., Bas Nieuwenhuizen wrote:
> > Hi all,
> >
> > Now that we have recently made some progress on getting feature parity
> > with the Radeon driver for SI, I'm wondering what it would take to
> > make AMDGPU the default dr
Reviewed-By: Kevin Wang
Best Regards
Kevin
> 在 2020年8月5日，上午12:57，Alex Deucher 写道：
>
> Ping?
>
>
>> On Thu, Jul 30, 2020 at 3:24 PM Alex Deucher wrote:
>>
>> The i2c init/fini functions just register the i2c adapter.
>> There is no need to call them during hw init/fini. They only
>> need
Am 2020-08-04 um 1:29 p.m. schrieb Alex Deucher:
> On Tue, Aug 4, 2020 at 1:27 PM Felix Kuehling wrote:
>> Am 2020-07-27 um 9:24 a.m. schrieb Philip Yang:
>>> If multiple process share system memory through /dev/shm, KFD allocate
>>> memory should not fail if it reachs the system memory limit beca
On Tue, Aug 4, 2020 at 1:27 PM Felix Kuehling wrote:
>
> Am 2020-07-27 um 9:24 a.m. schrieb Philip Yang:
> > If multiple process share system memory through /dev/shm, KFD allocate
> > memory should not fail if it reachs the system memory limit because
> > one copy of physical system memory are sha
Am 2020-07-27 um 9:24 a.m. schrieb Philip Yang:
> If multiple process share system memory through /dev/shm, KFD allocate
> memory should not fail if it reachs the system memory limit because
> one copy of physical system memory are shared by multiple process.
>
> Add module parameter to provide use
Ping?
On Thu, Jul 30, 2020 at 3:24 PM Alex Deucher wrote:
>
> The i2c init/fini functions just register the i2c adapter.
> There is no need to call them during hw init/fini. They only
> need to be called once per driver init/fini. The previous
> behavior broke runtime pm because we unregistere
Ping.
On 2020-07-27 9:24 a.m., Philip Yang wrote:
If multiple process share system memory through /dev/shm, KFD allocate
memory should not fail if it reachs the system memory limit because
one copy of physical system memory are shared by multiple process.
Add module parameter to provide user op
On Sun, Aug 02, 2020 at 01:06:14PM +0200, Sam Ravnborg wrote:
> The backlight drivers uses several different patterns when registering
> a backlight:
>
> - Register backlight and assign properties later
> - Define a local backlight_properties variable and use memset
> - Define a const backlight_pr
On 2020-08-04 12:28 p.m., Alexander Monakov wrote:
On Tue, 4 Aug 2020, Kazlauskas, Nicholas wrote:
This is a cleaner change the other proposed patch since it doesn't need to
Can you give a URL to the other patch please?
Sorry, replied to the wrong email by accident here.
The other change
On 2020-08-03 4:02 p.m., Alexander Monakov wrote:
Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.
With amdgpu, max_brightness gives 255
This is a cleaner change the other proposed patch since it doesn't need
to modify the exist conversion functions but I'd be worried about broken
userspace relying on 0-255 as the only acceptable range.
Not an expert on existing implementations to point out a specific one
though.
Regards,
Nic
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Pillai, Aurabindo
Sent: Tuesday, August 4, 2020 9:56 AM
To: Lin, Wayne ; amd-gfx@lists.freedesktop.org
Cc: Wu, Hersen ; Kazlauskas, Nicholas
; Siqueira, Rodrigo ;
Zuo, Jerry
Subject: Re: [PATCH] drm/amd/dc
On Tue, 2020-08-04 at 11:42 +0800, Wayne Lin wrote:
> [Why]
> According to DP spec, DPRX with DPCD r1.2 or higher shall have the
> same Link/Sink Device Status field registers at DPCD Addresses 00200h
> through 00205h to the corresponding DPRX Event Status Indicator
> registers at DPCD Addresses 02
Am 04.08.20 um 10:37 schrieb Michel Dänzer:
On 2020-08-03 1:45 a.m., Bas Nieuwenhuizen wrote:
Hi all,
Now that we have recently made some progress on getting feature parity
with the Radeon driver for SI, I'm wondering what it would take to
make AMDGPU the default driver for these generations.
On 2020-08-03 1:45 a.m., Bas Nieuwenhuizen wrote:
> Hi all,
>
> Now that we have recently made some progress on getting feature parity
> with the Radeon driver for SI, I'm wondering what it would take to
> make AMDGPU the default driver for these generations.
>
> As far as I understand AMDGPU has
[AMD Official Use Only - Internal Distribution Only]
>-Original Message-
>From: amd-gfx On Behalf Of Liu,
>Monk
>Sent: Tuesday, August 4, 2020 2:31 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: RE: [PATCH 1/2] drm/amdgpu: fix reload KMD hang on KIQ
>
>[AMD Official Use Only - Internal D
Documentation for sysfs backlight level interface requires that
values in both 'brightness' and 'actual_brightness' files are
interpreted to be in range from 0 to the value given in the
'max_brightness' file.
With amdgpu, max_brightness gives 255, and values written by the user
into 'brightness' a
> On Aug 3, 2020, at 10:34 AM, Dave Hansen wrote:
>
> On 8/3/20 10:16 AM, Andy Lutomirski wrote:
>> - TILE: genuinely per-thread, but it's expensive so it's
>> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
>> fully disambiguated from the other use of #NM. So it sort of
50 matches
Mail list logo
