We have a wait in the amdgpu_bo_kmap() code for quite a while now, so
waiting here isn't needed any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
We only need one offset and not an array of it.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
Variable optc is not effectively used, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c:325:27: warning:
variable ‘optc’ set but not used.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3782
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/
On 16/01/2023 20:00, Alex Deucher wrote:
> [...]
>
> It's not clear to me when this would be used. We only disable it
> briefly during new asic bring up, after that we never touch it again.
> No end user on production hardware should ever have to change it and
> doing so would break VCN on their
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_hpd.c:140 get_hpd_line()
warn: inconsistent indenting.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3787
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/lin
16.01.2023 18:11, Christian König пишет:
>
>
>> mmapping the memory with that new offset should still work. The
>> imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
>> supports mapping of SG BOs.
>
> Actually it shouldn't. This can go boom really easily.
>>
Variable value0 is not effectively used, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:1222:11:
warning: variable ‘value0’ set but not used.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3783
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Hi
Am 16.01.23 um 19:37 schrieb Alex Deucher:
On Mon, Jan 16, 2023 at 11:20 AM Jani Nikula
wrote:
On Mon, 16 Jan 2023, Thomas Zimmermann wrote:
A lot of source files include drm_crtc_helper.h for its contained
include statements. This leads to excessive compile-time dependencies.
Where pos
Hi
Am 16.01.23 um 21:47 schrieb Sam Ravnborg:
Hi Thomas.
On Mon, Jan 16, 2023 at 02:12:13PM +0100, Thomas Zimmermann wrote:
A lot of source files include drm_crtc_helper.h for its contained
include statements. This leads to excessive compile-time dependencies.
Where possible, remove the inclu
On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote:
> Several lastclose helpers call vga_switcheroo_process_delayed_switch().
> It's better to call the helper from drm_lastclose() after the kernel
> client's screen has been restored. This way, all drivers can benefit
> without having
Hi
Am 17.01.23 um 10:44 schrieb Lukas Wunner:
On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote:
Several lastclose helpers call vga_switcheroo_process_delayed_switch().
It's better to call the helper from drm_lastclose() after the kernel
client's screen has been restored. This w
On Fri, Jan 13, 2023 at 12:30:16PM -0700, Jim Cromie wrote:
> __jump_label_patch currently will "crash the box" if it finds a
> jump_entry not as expected. ISTM this overly harsh; it doesn't
> distinguish between "alternate/opposite" state, and truly
> "insane/corrupted".
>
> The "opposite" (but
Series is:
Reviewed-by: Alex Deucher
On Tue, Jan 17, 2023 at 3:12 AM Christian König
wrote:
>
> We only need one offset and not an array of it.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 21 +
> 1 file changed, 9 insertions(+), 12 d
On Mon, Jan 16, 2023 at 10:05 PM Jane Jian wrote:
>
> sriov does not need to init pptable from amdgpu driver
> we finish it from PF
>
> Signed-off-by: Jane Jian
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
> 1 file changed, 6 insertions(+)
>
Hi Simon,
On 1/13/23 14:06, Simon Ser wrote:
Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.
I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check i
On 16/01/2023 23:33, Limonciello, Mario wrote:
> [...]
>
> For debugging these type of problems, I think an effective debugging
> tactic would have been to mask the IP block (amdgpu.ip_block_mask).
Thank you, it worked indeed - nice suggestion!
Though I see two problems with that: first, I'm no
On Tue, Jan 17, 2023 at 9:33 AM Guilherme G. Piccoli
wrote:
>
> On 16/01/2023 23:33, Limonciello, Mario wrote:
> > [...]
> >
> > For debugging these type of problems, I think an effective debugging
> > tactic would have been to mask the IP block (amdgpu.ip_block_mask).
>
> Thank you, it worked ind
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, January 17, 2023 09:11
> To: Guilherme G. Piccoli
> Cc: Limonciello, Mario ; Liu, Leo
> ; amd-gfx@lists.freedesktop.org; Jiang, Sonny
> ; ker...@gpiccoli.net; Pan, Xinhui
> ; dri-de...@lists.freedesktop.org; Lazar, Lij
On 17/01/2023 13:24, Limonciello, Mario wrote:
> [...]
>>> Though I see two problems with that: first, I'm not sure what's the
>>> impact in the GPU functioning when I disable some IP block.
>>>
>
> It depends on the individual block what the impact is. For example
> if you don't have VCN, then y
Hi!
On 1/17/23 18:01, Geert Uytterhoeven wrote:
The issue is that some of the parameters are not arrays, but
NULL. E.g.:
arch/sh/kernel/cpu/sh2/setup-sh7619.c:static
DECLARE_INTC_DESC(intc_desc, "sh7619", vectors, NULL,
arch/sh/kernel/cpu/sh2/setup-sh7619.c- NULL,
prio_registe
Hi Adrian,
On Tue, Jan 17, 2023 at 5:42 PM John Paul Adrian Glaubitz
wrote:
> On 1/6/23 16:17, Geert Uytterhoeven wrote:
> >> I'm not seeing this one, but I am getting this one instead:
> >>
> >> In file included from ./arch/sh/include/asm/hw_irq.h:6,
> >>from ./include/linux/
Hi Geert!
On 1/6/23 16:17, Geert Uytterhoeven wrote:
I'm not seeing this one, but I am getting this one instead:
In file included from ./arch/sh/include/asm/hw_irq.h:6,
from ./include/linux/irq.h:596,
from ./include/asm-generic/hardirq.h:17,
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_l
On Tue, Jan 17, 2023 at 12:45 PM Nirmoy Das wrote:
>
> Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
> with proper APIs.
>
> Cc: Alex Deucher
> Cc: Christian König
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
> 1 file changed, 2 ins
There are no current users of DRM_DEBUG_KMS_RATELIMITED()
so remove it.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Signed-off-by: Nirmoy Das
---
include/drm/drm_print.h | 3 ---
1 file changed, 3 deletions(-)
diff --g
Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
with proper APIs.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_d
On 1/17/2023 6:48 PM, Alex Deucher wrote:
On Tue, Jan 17, 2023 at 12:45 PM Nirmoy Das wrote:
Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
with proper APIs.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5
On Tue, Jan 17, 2023 at 06:44:47PM +0100, Nirmoy Das wrote:
> There are no current users of DRM_DEBUG_KMS_RATELIMITED()
> so remove it.
Thanks
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
>
> Signed-off-by: N
This is an incredibly trivial fix, just for the sake of
"aesthetical" organization of the defines. Some were space based,
most were tab based and there was a lack of "alignment", now it's
all the same and aligned.
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
The HW model validation that guards the indirect SRAM checking in the
VCN code path is redundant - there's no model that's not included in the
switch, making it useless in practice [0].
So, let's remove this switch statement for good.
[0]
lore.kernel.org/amd-gfx/mn0pr12mb61013d20b8a2263b22ae1bcf
Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
with proper APIs.
v2: replace pr_err with dev_err(Alex).
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff
There are no current users of DRM_DEBUG_KMS_RATELIMITED()
so remove it.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Signed-off-by: Nirmoy Das
Reviewed-by: Sam Ravnborg
---
include/drm/drm_print.h | 3 ---
1 file change
On Tue, Jan 17, 2023 at 1:05 PM Nirmoy Das wrote:
>
> There are no current users of DRM_DEBUG_KMS_RATELIMITED()
> so remove it.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
>
> Signed-off-by: Nirmoy Das
> Rev
[Public]
> -Original Message-
> From: Guilherme G. Piccoli
> Sent: Tuesday, January 17, 2023 11:59
> To: amd-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> ker...@gpiccoli.net; kernel-...@igalia.com; Guilherm
[Public]
> -Original Message-
> From: Guilherme G. Piccoli
> Sent: Tuesday, January 17, 2023 12:14
> To: Limonciello, Mario ; amd-
> g...@lists.freedesktop.org; Deucher, Alexander
>
> Cc: dri-de...@lists.freedesktop.org; Koenig, Christian
> ; Pan, Xinhui ;
> ker...@gpiccoli.net; kernel
On 17/01/2023 15:08, Limonciello, Mario wrote:
> [...]
>
> Should have added this tag too:
> Suggested-by: Alexander Deucher
>
> Looks good to me, thanks!
> Reviewed-by: Mario Limonciello
>
You're totally right, thanks for the reminder and apologies for missing
that! Just sending V3 heheh
Ah
The HW model validation that guards the indirect SRAM checking in the
VCN code path is redundant - there's no model that's not included in the
switch, making it useless in practice [0].
So, let's remove this switch statement for good.
[0]
lore.kernel.org/amd-gfx/mn0pr12mb61013d20b8a2263b22ae1bcf
This is an incredibly trivial fix, just for the sake of
"aesthetical" organization of the defines. Some were space based,
most were tab based and there was a lack of "alignment", now it's
all the same and aligned.
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
On 17/01/2023 15:14, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -Original Message-
>> From: Guilherme G. Piccoli
>> Sent: Tuesday, January 17, 2023 12:14
>> To: Limonciello, Mario ; amd-
>> g...@lists.freedesktop.org; Deucher, Alexander
>>
>> Cc: dri-de...@lists.freedesktop.org; Koe
Hi Alex,
On 1/17/2023 7:06 PM, Alex Deucher wrote:
On Tue, Jan 17, 2023 at 1:05 PM Nirmoy Das wrote:
There are no current users of DRM_DEBUG_KMS_RATELIMITED()
so remove it.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Applied the series. Thanks!
Alex
On Tue, Jan 17, 2023 at 1:15 PM Guilherme G. Piccoli
wrote:
>
> The HW model validation that guards the indirect SRAM checking in the
> VCN code path is redundant - there's no model that's not included in the
> switch, making it useless in practice [0].
>
> So,
Looks good to me. It might be good to add a comment above pcie_gen in
amdgpu_drm.h to specify that this is the max common pcie gen supported
by both the GPU and the slot. With that fixed, the patch is:
Reviewed-by: Alex Deucher
On Fri, Jan 13, 2023 at 6:33 PM Marek Olšák wrote:
>
> There is no
SQ_WAVE_INST_DW0 isn't present on gfx11 compared to gfx10, so update
wave data type to signify a difference.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/dr
Only VCN0 supports AV1.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 101 +---
1 file changed, 81 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index 6853b93ac82e..d972025f0d20 10064
Only VCN0 supports AV1.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/soc21.c | 61 +++---
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc21.c
b/drivers/gpu/drm/amd/amdgpu/soc21.c
index bea6b499568a..e03cf7f766c
Only VCN0 supports AV1.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index bd228512424a..66439388faee 100644
--- a/drivers/gpu/drm/amd/a
Only VCN0 supports AV1.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index a79b6088374b..efb22d0975b3 100644
--- a/drivers/gpu/drm/amd/a
Hi Adrian,
On Tue, Jan 17, 2023 at 6:06 PM John Paul Adrian Glaubitz
wrote:
> On 1/17/23 18:01, Geert Uytterhoeven wrote:
> > The issue is that some of the parameters are not arrays, but
> > NULL. E.g.:
> >
> > arch/sh/kernel/cpu/sh2/setup-sh7619.c:static
> > DECLARE_INTC_DESC(intc_desc, "sh7619"
Hi!
On 1/17/23 21:05, Geert Uytterhoeven wrote:
Isn't this supposed to be caught by this check:
a, __same_type(a, NULL)
?
Yeah, but gcc thinks it is smarter than us...
Probably it drops the test, assuming UB cannot happen.
Hmm, sounds like a GGC bug to me then. Not sure how to fix
Currently, we run into a number of WARN()s when attempting to unload the
amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from
calling drm_encoder_cleanup() too early. So, to fix this we can stop
calling drm_encoder_cleanup() in amdgpu_dm_fini() and instead have it be
called from amd
On Tue, Jan 17, 2023 at 3:55 PM Hamza Mahfooz wrote:
>
> Currently, we run into a number of WARN()s when attempting to unload the
> amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from
> calling drm_encoder_cleanup() too early. So, to fix this we can stop
> calling drm_encoder_clea
Implements the 'content type' property for HDMI connectors.
Verified by checking the avi infoframe on a connected TV.
This also simplifies a lot of the code in that area as well, there were
a lot of temp variables doing very little and unnecessary logic
that was quite confusing.
It is not necessa
This was never filled in and thus never truly used.
Checking the EDID for content_type support is not required for sending
the avi infoframe packet.
Signed-off-by: Joshua Ashton
---
drivers/gpu/drm/amd/display/dc/dc_stream.h | 1 -
drivers/gpu/drm/amd/display/dc/dc_types.h | 14 --
[AMD Official Use Only - General]
The series are:
Reviewed-by: Leo Liu
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: January 17, 2023 3:00 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 1/4] drm/amdgpu/nv: don't expose AV1 if VCN0 is ha
Am 17.01.23 um 19:12 schrieb Das, Nirmoy:
Hi Alex,
On 1/17/2023 7:06 PM, Alex Deucher wrote:
On Tue, Jan 17, 2023 at 1:05 PM Nirmoy Das wrote:
There are no current users of DRM_DEBUG_KMS_RATELIMITED()
so remove it.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David
55 matches
Mail list logo