RE: [PATCH] drm/amd/powerplay: grant Arcturus softmin/max setting on latest PM firmware

[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:

[PATCH] drm/amd/powerplay: grant Arcturus softmin/max setting on latest PM firmware

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,

RE: [PATCH 17/17] drm/amd/powerplay: add control method to bypass metrics cache on Vega12

[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

Re: Enabling AMDGPU by default for SI & CIK

[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

Re: [PATCH v3] drm/amdkfd: option to disable system mem limit

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

[PATCH v3] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH] drm/amd/display: Fix wrong return value in dm_update_plane_state()

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

[PATCH 6/8] drm/amd/display: Set DC options from modifiers.

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.

[PATCH 0/8] amd/display: Add GFX9+ modifier support.

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

[PATCH 8/8] drm/amd/display: Expose modifiers.

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

[PATCH 5/8] drm/amd/display: Refactor surface tiling setup.

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

[PATCH 1/8] drm/amd/display: Do not silently accept DCC for multiplane formats.

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

[PATCH 4/8] drm/fourcc: Add AMD DRM modifiers.

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

[PATCH 2/8] drm/amd: Init modifier field of helper fb.

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

[PATCH 3/8] drm/amd/display: Honor the offset for plane 0.

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

[PATCH 7/8] drm/amd/display: Add formats for DCC with 2/3 planes.

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.

Re: [PATCH v2] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH 0/3] drm/amd/display: Constify static resource_funcs

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 >

[PATCH v2] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH 17/17] drm/amd/powerplay: add control method to bypass metrics cache on Vega12

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

Re: [PATCH 11/17] drm/amd/powerplay: add Vega12 support for gpu metrics export

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

Re: [PATCH] drm/amd/display: Indent an if statement

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

[PATCH v2] drm/amd/display: use correct scale for actual_brightness

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'

[PATCH 1/3] drm/amd/display: Constify dcn20_res_pool_funcs

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(-)

[PATCH 0/3] drm/amd/display: Constify static resource_funcs

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:

[PATCH 3/3] drm/amd/display: Constify dcn30_res_pool_funcs

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(-)

[PATCH 2/3] drm/amd/display: Constify dcn21_res_pool_funcs

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(-)

Re: Amdgpu kernel oops and freezing graphics

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 ;) > >> > >>

Re: [PATCH 2/2] drm/amd/powerplay: put VCN/JPEG into PG ungate state before dpm table setup

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

NAK: [PATCH][next] drm/amd/display: fix spelling mistake "Usupported" -> "Unsupported"

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(-) > >

[PATCH][next] drm/amd/display: fix spelling mistake "Usupported" -> "Unsupported"

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

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

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

Re: Enabling AMDGPU by default for SI & CIK

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

Re: [PATCH] drm/amdgpu/smu: rework i2c adpater registration

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

Re: [PATCH] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH] drm/amdkfd: option to disable system mem limit

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

Re: [PATCH] drm/amdgpu/smu: rework i2c adpater registration

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

Re: [PATCH] drm/amdkfd: option to disable system mem limit

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

Re: [RFC PATCH v1 0/22] backlight: add init macros and accessors

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

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

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

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

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

Re: [PATCH] drm/amd/display: use correct scale for actual_brightness

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,

RE: [PATCH] drm/amd/dc: Read from DP_SINK_COUNT_ESI for DPDC r1.2 or higher

[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]

Re: [PATCH] drm/amd/dc: Read from DP_SINK_COUNT_ESI for DPDC r1.2 or higher

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

Re: Enabling AMDGPU by default for SI & CIK

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.

Re: Enabling AMDGPU by default for SI & CIK

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

RE: [PATCH 1/2] drm/amdgpu: fix reload KMD hang on KIQ

[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

Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID

> 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

[PATCH] drm/amd/display: use correct scale for actual_brightness

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'

RE: [PATCH 1/2] drm/amdgpu: fix reload KMD hang on KIQ

[AMD Official Use Only - Internal Distribution Only] Ping ... this is a severe bug fix _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: amd-gfx On Behalf Of Liu, Monk Sent: Monday, August 3, 2020 9:55 AM To: Kuehling, Felix ;