[PATCH v2] drm/amdgpu/psp: fix psp gfx ctrl cmds

psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm/amdgpu/psp: fix psp gfx ctrl cmds

psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct Signed-off-by: Victor Zhao --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 26 + 1 file changed, 14 insertions(+), 12 deletions(-) diff --git

[PATCH] drm/amdgpu/psp: fix psp gfx ctrl cmds

psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct Signed-off-by: Victor --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 26 + 1 file changed, 14 insertions(+), 12 deletions(-) diff --git

RE: [PATCH] drm/amdgpu: drop ras ta firmware loading for non-ras asic

[AMD Public Use] Thanks Hawking. Then let's skip this patch, and I will work out another reasonable approach. Regards, Guchun -Original Message- From: Zhang, Hawking Sent: Monday, January 4, 2021 3:52 PM To: Zhang, Hawking ; Chen, Guchun ; amd-gfx@lists.freedesktop.org; Deucher,

RE: [PATCH] drm/amdgpu: Fix issue no bad_pages after umc ue injection

[AMD Public Use] Modifying subject to "fix no bad page issue after umc ue injection" is better. With above fixed, the patch is: Reviewed-by: Guchun Chen Regards, Guchun -Original Message- From: Dennis Li Sent: Tuesday, January 5, 2021 8:57 AM To: amd-gfx@lists.freedesktop.org; Chen,

[PATCH] drm/amdgpu: Fix issue no bad_pages after umc ue injection

old code wrongly used the bad page status as the function return value, which cause amdgpu_ras_badpages_read always return failed. Signed-off-by: Dennis Li diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index c136bd449744..82e952696d24 100644 ---

Re: Couple of issues with amdgpu on my WX4100

On Mon, 4 Jan 2021 21:13:53 +0100 Christian König wrote: > Am 04.01.21 um 19:43 schrieb Alex Williamson: > > On Mon, 4 Jan 2021 18:39:33 +0100 > > Christian König wrote: > > > >> Am 04.01.21 um 17:45 schrieb Alex Williamson: > >>> On Mon, 4 Jan 2021 12:34:34 +0100 > >>> Christian König

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-8/10/11.

Applied the series. Thanks! Alex On Mon, Jan 4, 2021 at 4:17 PM Kazlauskas, Nicholas wrote: > > On 2020-12-28 1:50 p.m., Mario Kleiner wrote: > > The hw supports fp16, this is not only useful for HDR, > > but also for standard dynamic range displays, because > > it allows to get more precise

Re: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.

On 2020-12-29 9:54 a.m., Deucher, Alexander wrote: [AMD Public Use] I don't know if these fixes related to modifiers make sense in the pre-modifier code base.  Bas, Nick? Alex Mesa should be the only userspace trying to make use of DCC and it doesn't do it for video formats. From the

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-8/10/11.

On 2020-12-28 1:50 p.m., Mario Kleiner wrote: The hw supports fp16, this is not only useful for HDR, but also for standard dynamic range displays, because it allows to get more precise color reproduction with about 11 - 12 bpc linear precision in the unorm range 0.0 - 1.0. Working fp16

Re: [PATCH 1/2] drm/amd/display: Check plane scaling against format specific hw plane caps.

On 2020-12-28 1:50 p.m., Mario Kleiner wrote: This takes hw constraints specific to pixel formats into account, e.g., the inability of older hw to scale fp16 format framebuffers. It should now allow safely to enable fp16 formats also on DCE-8, DCE-10, DCE-11.0 Signed-off-by: Mario Kleiner

[PATCH v3 2/3] drm/amd/display: Add freesync video modes based on preferred modes

[Why] If experimental freesync video mode module parameter is enabled, add few extra display modes into the driver's mode list corresponding to common video frame rates. When userspace sets these modes, no modeset will be performed (if current mode was one of freesync modes or the base freesync

[PATCH v3 3/3] drm/amd/display: Skip modeset for front porch change

[Why] Inorder to enable freesync video mode, driver adds extra modes based on preferred modes for common freesync frame rates. When commiting these mode changes, a full modeset is not needed. If the change in only in the front porch timing value, skip full modeset and continue using the same

[PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode

[Why] Adds a module parameter to enable experimental freesync video mode modeset optimization. Enabling this mode allows the driver to skip a full modeset when freesync compatible modes are requested by the userspace. This paramters also adds some standard modes based on the connected monitor's

[PATCH v3 0/3] Experimental freesync video mode optimization

Changes in V4 = 1) Add module parameter for freesync video mode * Change module parameter name to freesync_video 2) Add freesync video modes based on preferred modes: * Cosmetic fixes * Added comments about all modes being added by the driver. 3) Skip modeset for front porch

Re: [PATCH v2 2/3] drm/amd/display: Add freesync video modes based on preferred modes

On Mon, 2021-01-04 at 11:06 -0500, Kazlauskas, Nicholas wrote: > On 2020-12-11 12:54 a.m., Shashank Sharma wrote: > > > > On 11/12/20 12:18 am, Aurabindo Pillai wrote: > > > [Why] > > > If experimental freesync video mode module parameter is enabled, > > > add > > > few extra display modes into

Re: [PATCH] drm: Check actual format for legacy pageflip.

[AMD Official Use Only - Internal Distribution Only] + Ville On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner wrote: > > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen > wrote: > > > > With modifiers one can actually have different format_info structs > > for the same format, which now matters

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On Mon, 2021-01-04 at 11:16 -0500, Kazlauskas, Nicholas wrote: > On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote: > > [Why] > > Inorder to enable freesync video mode, driver adds extra > > modes based on preferred modes for common freesync frame rates. > > When commiting these mode changes, a full

Re: Couple of issues with amdgpu on my WX4100

Am 04.01.21 um 19:43 schrieb Alex Williamson: On Mon, 4 Jan 2021 18:39:33 +0100 Christian König wrote: Am 04.01.21 um 17:45 schrieb Alex Williamson: On Mon, 4 Jan 2021 12:34:34 +0100 Christian König wrote: [SNIP] That's a rather bad idea. See our GPUs for example return way more than

Re: Couple of issues with amdgpu on my WX4100

On Mon, 4 Jan 2021 18:39:33 +0100 Christian König wrote: > Am 04.01.21 um 17:45 schrieb Alex Williamson: > > On Mon, 4 Jan 2021 12:34:34 +0100 > > Christian König wrote: > > > >> Hi Maxim, > >> > >> I can't help with the display related stuff. Probably best approach to > >> get this fixes

Re: [PATCH] drm: Check actual format for legacy pageflip.

+ Ville On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner wrote: > > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen > wrote: > > > > With modifiers one can actually have different format_info structs > > for the same format, which now matters for AMDGPU since we convert > > implicit modifiers to

[PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs (v2)

Make sure the copy succeeded. Also fixes a warning. v2: fix the error check Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c

Re: [PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs

Am 04.01.21 um 18:43 schrieb Alex Deucher: Make sure the copy succeeded. Also fixes a warning. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs

Make sure the copy succeeded. Also fixes a warning. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c

Re: Couple of issues with amdgpu on my WX4100

Am 04.01.21 um 17:45 schrieb Alex Williamson: On Mon, 4 Jan 2021 12:34:34 +0100 Christian König wrote: Hi Maxim, I can't help with the display related stuff. Probably best approach to get this fixes would be to open up a bug tracker for this on FDO. But I'm the one who implemented the

Re: [PATCH] drm: Check actual format for legacy pageflip.

On Sat, Jan 2, 2021 at 9:02 AM Bas Nieuwenhuizen wrote: > > With modifiers one can actually have different format_info structs > for the same format, which now matters for AMDGPU since we convert > implicit modifiers to explicit modifiers with multiple planes. > > I checked other drivers and it

Re: [PATCH] drm/amd/display: fix comparison pointer to bool warning in dc.c

On Tue, Dec 29, 2020 at 4:42 AM Tian Tao wrote: > > Fixes coccicheck warning: > drivers/gpu/drm/amd/display/dc/core/dc.c:1543:12-19: WARNING: Comparison > to bool > drivers/gpu/drm/amd/display/dc/core/dc.c:1496:14-42: WARNING: Comparison > to bool >

Re: Enable fp16 display support for DCE8+, next try.

On Mon, Dec 28, 2020 at 1:51 PM Mario Kleiner wrote: > > Hi and happy post-christmas! > > I wrote a patch 1/1 that now checks plane scaling factors against > the pixel-format specific limits in the asic specific dc_plane_cap > structures during atomic check and other appropriate places. > > This

Re: [PATCH] drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if condition

Applied. Thanks! Alex On Sun, Dec 27, 2020 at 3:56 PM Chenyang Li wrote: > > Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H". > > Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") > Signed-off-by: Chenyang Li > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- > 1

Re: [PATCH -next] gpu/drm/radeon: use DIV_ROUND_UP macro to do calculation

On Wed, Dec 23, 2020 at 2:06 AM Zheng Yongjun wrote: > > Don't open-code DIV_ROUND_UP() kernel macro. > > Signed-off-by: Zheng Yongjun Applied. Thanks! Alex > --- > drivers/gpu/drm/radeon/r600_cs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH] drm/radeon:avoid null pointer dereference when dev is not bound

On Sun, Dec 27, 2020 at 3:56 PM Defang Bo wrote: > > [Why] > Similar to commit<0fa375e6>. If the set_state/can_switch code access the > drm_device when dev is not bound, > a null pointer dereference can happen. > > [How] > Add sanity checks to prevent it. > > Signed-off-by: Defang Bo Are you

Re: [PATCH] drm/amd/display: remove useless else if

On Mon, Dec 21, 2020 at 9:40 AM Tian Tao wrote: > > Fix the following coccinelle report: > drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c:1357:6-8: > WARNING: possible condition with no effect (if == else) > > Signed-off-by: Tian Tao Applied. Thanks! Alex > --- >

Re: [PATCH] drm/amd/display: remove unused including

On Thu, Dec 31, 2020 at 5:42 AM Tian Tao wrote: > > Remove including that don't need it. > > Signed-off-by: Tian Tao Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 1 - >

Re: [PATCH] drm/amdgpu: fix potential memory leak during navi12 deinitialization

On Thu, Dec 31, 2020 at 4:06 AM Jiawei Gu wrote: > > Navi12 HDCP & DTM deinitialization needs continue to free bo if already > created though initialized flag is not set. > > Signed-off-by: Jiawei Gu Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 18

Re: Couple of issues with amdgpu on my WX4100

On Mon, 4 Jan 2021 12:34:34 +0100 Christian König wrote: > Hi Maxim, > > I can't help with the display related stuff. Probably best approach to > get this fixes would be to open up a bug tracker for this on FDO. > > But I'm the one who implemented the resizeable BAR support and your >

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Mon, 4 Jan 2021 at 17:27, Alex Deucher wrote: > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel

Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use

Hey Daniel, back from vacation and going over our last long thread i think you didn't reply to my last question bellow (Or at least I can't find it). Andrey On 12/17/20 4:13 PM, Andrey Grodzovsky wrote: Ok, so I assumed that with vmap_local you were trying to solve the problem of quick

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel wrote: > > > > > > > > This reverts commit

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote: [Why] Inorder to enable freesync video mode, driver adds extra modes based on preferred modes for common freesync frame rates. When commiting these mode changes, a full modeset is not needed. If the change in only in the front porch timing value,

Re: [PATCH v2 2/3] drm/amd/display: Add freesync video modes based on preferred modes

On 2020-12-11 12:54 a.m., Shashank Sharma wrote: On 11/12/20 12:18 am, Aurabindo Pillai wrote: [Why] If experimental freesync video mode module parameter is enabled, add few extra display modes into the driver's mode list corresponding to common video frame rates. When userspace sets these

Re: [PATCH 1/3] drm/amd/display: Add module parameter for freesync video mode

On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote: [Why] Adds a module parameter to enable experimental freesync video mode modeset optimization. Enabling this mode allows the driver to skip a full modeset when freesync compatible modes are requested by the userspace. This paramters also adds some

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

SOLVED I opened a ticket here: https://gitlab.freedesktop.org/drm/amd/-/issues/1425 and they suggested, at the end, the same hint (amdgpu.dc=1). ... which, I was sure, I already tried with no results. Maybe I just misspelled it, and it didn't work. It's working now, thank you so much for your

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Btw, should the driver switch to the lower supported resolution then? Il Lun 4 Gen 2021, 13:04 Davide Corrado ha scritto: > Hello. This resolution is supported by the Apu and the motherboard specs. > Will try what you suggest and let you know > > Il Lun 4 Gen 2021, 12:10 Christian König > ha

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Hello. This resolution is supported by the Apu and the motherboard specs. Will try what you suggest and let you know Il Lun 4 Gen 2021, 12:10 Christian König ha scritto: > Hi Davide, > > adding a few of our AMD display people. > > In general as already suggested by others opening a bug report

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

[AMD Official Use Only - Internal Distribution Only] You might try enabling DC (the newer modesetting infrastructure). Append amdgpu.dc=1 to the kernel command line in grub. Alex From: Davide Corrado Sent: Saturday, January 2, 2021 1:50 PM To: Deucher,

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Yes, absolutely. Do you only get a black screen? That would certainly be a rather big bug. Christian. Am 04.01.21 um 13:37 schrieb Davide Corrado: Btw, should the driver switch to the lower supported resolution then? Il Lun 4 Gen 2021, 13:04 Davide Corrado >

Re: [PATCH 5/5] drm/amdgpu: remove redundant logic related HDP

Looks like a nice cleanup to me. Just one question: We have a flush_hdp and invalidate_hdp callback in the asic structure as well. Would it make sense to replace those as well in the long term? Thanks, Christian. Am 28.12.20 um 10:18 schrieb Likun Gao: From: Likun Gao Remove hdp_flush

Re: Couple of issues with amdgpu on my WX4100

Hi Maxim, I can't help with the display related stuff. Probably best approach to get this fixes would be to open up a bug tracker for this on FDO. But I'm the one who implemented the resizeable BAR support and your analysis of the problem sounds about correct to me. The reason why this

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Hi Davide, adding a few of our AMD display people. In general as already suggested by others opening a bug report to track this is the right thing to do. In the past we had a few bug reports like this because amdgpu is more strict in checking hardware limitations. For example it can be

Re: [PATCH] drm: Check actual format for legacy pageflip.

Am 02.01.21 um 15:02 schrieb Bas Nieuwenhuizen: With modifiers one can actually have different format_info structs for the same format, which now matters for AMDGPU since we convert implicit modifiers to explicit modifiers with multiple planes. I checked other drivers and it doesn't look like

Re: [PATCH] drm: Check actual format for legacy pageflip.

Hi Bas, On 02/01/2021 15:02, Bas Nieuwenhuizen wrote: > With modifiers one can actually have different format_info structs > for the same format, which now matters for AMDGPU since we convert > implicit modifiers to explicit modifiers with multiple planes. > > I checked other drivers and it

RE: [PATCH] drm/amdgpu: remove redundant include of navi10_enum

[AMD Public Use] Reviewed-by: Hawking Zhang Regards, Hawking -Original Message- From: Gao, Likun Sent: Monday, January 4, 2021 17:33 To: amd-gfx@lists.freedesktop.org Cc: Zhang, Hawking ; Gao, Likun Subject: [PATCH] drm/amdgpu: remove redundant include of navi10_enum From: Likun Gao

[PATCH] drm/amdgpu: remove redundant include of navi10_enum

From: Likun Gao Remove unnecessary include of navi10_enum header file. Signed-off-by: Likun Gao Change-Id: Id9697d0cf68339b3005b634ab5cf2f7bc39e47ef --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 1 -

Bug: RX 580 screen goes dark after switching monitor to different input and back

Hi, I would like to report the following issue which begain with kernel 5.4.86. Please let me know if I should also file a bug in bugzilla. Note that I have narrowed it down to the change which causes the issue (e1b1f10c3404c8d40c45c3a6846d304fd403fa2c in linux-5.4 series, upstream

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Cool, thanks! Il Dom 3 Gen 2021, 12:06 Mike Lothian ha scritto: > Hi > > You're probably best reporting the bug here: > > https://gitlab.freedesktop.org/drm/amd/-/issues > > Attach the output of dmesg from both Radeon and AMDGPU and the compositor > / Wayland logs (as you're not using X) > >