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 include statements for drm_crtc_helper.h
and include the required source files directly. Also remove the
include statements from
Am 16.01.23 um 03:44 schrieb Ma, Jun:
On 1/13/2023 5:37 PM, Christian König wrote:
Am 13.01.23 um 06:34 schrieb Ma Jun:
Check the ttm_debugfs_root before creating files under it.
If the ttm_debugfs_root is NULL, all the files created for
ttm/ will be placed in the /sys/kerne/debug/ but not
[SNIP]
When the BO is imported into the same GPU, you get a reference to
the same BO, so the imported BO has the same mmap_offset as the
original BO.
When the BO is imported into a different GPU, it is a new BO with a
new mmap_offset.
That won't work.
I don't think this is incorrect.
Several DRM core and helper source files include drm_crtc_helper.h
without needing it or only to get its transitive include statements;
leading to unnecessary compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible. The header file, drm_fixed.h,
Align a closing brace and remove trailing whitespaces. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Remove most include statements from crm_crtc_helper.h and forward-
declare the contained types in drm_crtc_helper.h. Only keep
for the definition of 'bool'.
Suggested-by: Sam Ravnborg
Signed-off-by: Thomas Zimmermann
---
include/drm/drm_crtc_helper.h | 14 +-
1 file changed, 9
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.
Directly include required headers and drop drm_crtc_helper.h where
possible.
Signed-off-by: Thomas Zimmermann
---
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 to implement their own lastclose helper. For drivers
without
Set the framebuffer info for drivers that support VGA switcheroo. Only
affects the amdgpu and nouveau drivers, which use VGA switcheroo and
generic fbdev emulation. For other drivers, this does nothing.
This fixes a potential regression in the console code. Both, amdgpu and
nouveau, invoked
(was: drm: Generic fbdev and vga-switcheroo)
This patchset fixes how fbdev helpers interact with vga-switcheroo. The
first two patches are bug fixes for the existing code. The third patch
cleans up the drivers.
Patch 1 fixes i915 to do the correct thing if the device has not been
initialized
Always allow switching away via vga-switcheroo if the display is
uninitalized. Instead prevent switching to i915 if the device has
not been initialized.
This issue was introduced by commit 5df7bd130818 ("drm/i915: skip
display initialization when there is no display") protected, which
protects
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation. Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue
Am 16.01.23 um 03:44 schrieb Ma, Jun:
On 1/13/2023 5:38 PM, Christian König wrote:
Am 13.01.23 um 06:34 schrieb Ma Jun:
Use debugfs_remove_recursive to remove the /sys/kernel/debug/ttm
directory for better compatibility. Becuase debugfs_remove fails
on older kernel.
Again NAK for upstreaming.
[Public]
This series is:
Reviewed-by: Yifan Zhang
Best Regards,
Yifan
-Original Message-
From: Yu, Lang
Sent: Monday, January 16, 2023 4:20 PM
To: amd-gfx@lists.freedesktop.org
Cc: Koenig, Christian ; Du, Xiaojian
; Zhang, Yifan ; Yu, Lang
Subject: [PATCH 2/2] drm/amdgpu: correct
On Sun, Jan 15, 2023 at 2:22 PM Mario Limonciello
wrote:
>
> The switch/case statement currently combines 10.0.0 and 10.0.1, but
> 10.0.1 is only used for Raven 2. So split the two cases up to
> make this clearer.
Keep the logic as is. We don't know the revision id which is used to
Always enable multipipe policy on ASICs with GC VERSION > 9.0.0
instead of MEC number > 1.
This will allow multipipe policy on ASICs with one MEC,
e.g., gfx11 APUs.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
There is only one MEC on these APUs.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index
Mhm, that sucks. Could we have the automated builds check for paddings
in the UAPi data structure?
Christian.
Am 14.01.23 um 00:33 schrieb Marek Olšák:
There is no hole on 32-bit unfortunately. It looks like the hole on
64-bit is now ABI.
I moved the field to replace _pad1. The patch is
Am 2023-01-16 um 06:42 schrieb Christian König:
[SNIP]
When the BO is imported into the same GPU, you get a reference to
the same BO, so the imported BO has the same mmap_offset as the
original BO.
When the BO is imported into a different GPU, it is a new BO with a
new mmap_offset.
That
Applied with the fixes tag. Thanks!
Alex
On Mon, Jan 16, 2023 at 9:41 AM Melissa Wen wrote:
>
> On 01/16, Melissa Wen wrote:
> > On 01/10, Joshua Ashton wrote:
> > > Code in get_output_color_space depends on knowing the pixel encoding to
> > > determine whether to pick between eg.
From: Luben Tuikov
[ Upstream commit 0be7ed8e7eb15282b5d0f6fdfea884db594ea9bf ]
Fix potential NULL dereference, in the case when "man", the resource manager
might be NULL, when/if we print debug information.
Cc: Alex Deucher
Cc: Christian König
Cc: AMD Graphics
Cc: Dan Carpenter
Cc: kernel
The problem is that base sched hasn't been assigned yet at this moment, causing
something like "ring=0"
all the time from trace.
mpv:cs0-3473[002] . 129.047431: amdgpu_cs:
bo_list=92ffb3070400, ring=0, dw=48, fences=0
mpv:cs0-3473[002] . 129.089125:
On Sun, Jan 15, 2023 at 11:49 AM Matthias Reichl wrote:
>
> I noticed some of the used HP Z240 workstations I recently bought had a
> Barco MXRT-5600 branded FirePro W5100 card installed - some others came with
> an unbranded W5100 (with the standard 6449 PCI ID).
>
> Except for a large Barco
[Public]
Hi all,
This week this patchset was tested on the following systems:
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U
Reference AMD RX6800
These systems were tested on the following display types:
eDP, (1080p 60hz [4500U, 5650U])
Applied. Thanks!
On Sun, Jan 15, 2023 at 4:26 AM Deepak R Varma wrote:
>
> Use swap() helper macro instead of open coded swap instructions. The
> change also facilitates code cleanup and realignment for improved
> readability. Issue identified using swap.cocci Coccinelle semantic
> patch
On 01/10, Joshua Ashton wrote:
The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
missing the values for the fourth column of the matrix.
The fourth column of the matrix is essentially just a value that is
added given that the color is 3 components in size.
These values are
Am 16.01.23 um 15:52 schrieb Felix Kuehling:
Am 2023-01-16 um 06:42 schrieb Christian König:
[SNIP]
When the BO is imported into the same GPU, you get a reference to
the same BO, so the imported BO has the same mmap_offset as the
original BO.
When the BO is imported into a different GPU, it
This is already fixed.
Thanks,
Alex
On Sun, Jan 15, 2023 at 4:32 AM Deepak R Varma wrote:
>
> The member variable set_odm_combine is already initialized and hence the
> reinitialization instruction can be removed. Issue identified using the
> dubleinit.cocci Coccinelle semantic patch script.
>
On Mon, Jan 16, 2023 at 6:54 AM Thomas Zimmermann wrote:
>
> (was: drm: Generic fbdev and vga-switcheroo)
>
> This patchset fixes how fbdev helpers interact with vga-switcheroo. The
> first two patches are bug fixes for the existing code. The third patch
> cleans up the drivers.
>
> Patch 1 fixes
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Monday, January 16, 2023 07:51
> To: Limonciello, Mario
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/amd: Adjust legacy IP discovery for
> Picasso/Raven/Raven2
>
> On Sun, Jan 15, 2023 at 2:22 PM Mario
From: Eric Huang
[ Upstream commit ba029e9991d9be90a28b6a0ceb25e9a6fb348829 ]
There will be data corruption on vram allocated by svm
if the initialization is not complete and application is
writting on the memory. Adding sync to wait for the
initialization completion is to resolve this issue.
From: Eric Huang
[ Upstream commit a6941f89d7c6a6ba49316bbd7da2fb2f719119a7 ]
The point bo->kfd_bo is NULL for queue's write pointer BO
when creating queue on mGPU. To avoid using the pointer
fixes the error.
Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Am 16.01.23 um 17:16 schrieb Leo Liu:
The problem is that base sched hasn't been assigned yet at this moment, causing something
like "ring=0"
all the time from trace.
mpv:cs0-3473[002] . 129.047431: amdgpu_cs:
bo_list=92ffb3070400, ring=0, dw=48, fences=0
Applied. Thanks!
Alex
On Sun, Jan 15, 2023 at 9:27 PM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
> Series is reviewed-by: Evan Quan
>
> > -Original Message-
> > From: Deepak R Varma
> > Sent: Sunday, January 15, 2023 3:16 PM
> > To: Quan, Evan ; Deucher, Alexander
> >
Applied with the fixes tag.
Thanks,
Alex
On Mon, Jan 16, 2023 at 9:50 AM Melissa Wen wrote:
>
> On 01/10, Joshua Ashton wrote:
> > The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
> > missing the values for the fourth column of the matrix.
> >
> > The fourth column of the
On 01/16, Melissa Wen wrote:
> On 01/10, Joshua Ashton wrote:
> > Code in get_output_color_space depends on knowing the pixel encoding to
> > determine whether to pick between eg. COLOR_SPACE_SRGB or
> > COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
> >
> > v2: Fixed
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 possible, remove the include statements for drm_crtc_helper.h
> and include the required source
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 possible, remove the include
On 01/10, Joshua Ashton wrote:
> Code in get_output_color_space depends on knowing the pixel encoding to
> determine whether to pick between eg. COLOR_SPACE_SRGB or
> COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.
>
> v2: Fixed patch being accidentally based on a personal
Applied. Thanks!
On Mon, Jan 16, 2023 at 8:13 AM Thomas Zimmermann wrote:
>
> Align a closing brace and remove trailing whitespaces. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
On Mon, Jan 16, 2023 at 4:21 PM Guilherme G. Piccoli
wrote:
>
> Currently the FW loading path perform some checks based on IP model
> and in case it is advertised as supported, the VCN indirect SRAM
> mode is used.
>
> Happens that in case there's any issue on FW and this mode ends-up
> not being
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian
Subject:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Chen,
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Cc: Koenig, Christian
Subject:
On Mon, Jan 16, 2023 at 5:34 PM Guilherme G. Piccoli
wrote:
>
> On 16/01/2023 19:27, Liu, Leo wrote:
> > Secure part requires PSP load VCN boot sequence which is with indirect
> > sram mode.
> >
> > Regards,
> > Leo
>
> With that said, and with the plans of just setting the indirect sram
> mode
On Mon, Jan 16, 2023 at 3:12 PM Christian König
wrote:
>
> It can be that neither fence were initialized when we run out of UVD
> streams for example.
>
> v2: fix typo breaking compile
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
>
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 include statements for drm_crtc_helper.h
> and
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
Currently the FW loading path perform some checks based on IP model
and in case it is advertised as supported, the VCN indirect SRAM
mode is used.
Happens that in case there's any issue on FW and this mode ends-up
not being properly supported, the driver probe fails [0]. Debugging
this requires
Currently both conditionals checked to enable indirect SRAM are
repeated for all HW/IP models. Let's just simplify it a bit so
code is more compact and readable.
While at it, add the legacy names as a comment per case block, to
help whoever is reading the code and doesn't have much experience
On 2023-01-16 17:12, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Chen,
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org;
Hi Thomas.
On Mon, Jan 16, 2023 at 02:12:15PM +0100, Thomas Zimmermann wrote:
> Several DRM core and helper source files include drm_crtc_helper.h
> without needing it or only to get its transitive include statements;
> leading to unnecessary compile-time dependencies.
>
> Directly include
On 2023-01-16 17:04, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
A minor comment, unrelated to the patch. The comments are inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To:
On 16/01/2023 19:27, Liu, Leo wrote:
> Secure part requires PSP load VCN boot sequence which is with indirect
> sram mode.
>
> Regards,
> Leo
With that said, and with the plans of just setting the indirect sram
mode nevertheless (with no switch/cases anymore - I'll submit the V2
tomorrow if
It can be that neither fence were initialized when we run out of UVD
streams for example.
v2: fix typo breaking compile
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
We only need one offset and not an array of it.
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 | 38 +++--
1 file changed, 10 insertions(+),
Secure part requires PSP load VCN boot sequence which is with indirect sram
mode.
Regards,
Leo
From: Alex Deucher
Sent: January 16, 2023 4:50 PM
To: Guilherme G. Piccoli
Cc: amd-gfx@lists.freedesktop.org ; Jiang, Sonny
; ker...@gpiccoli.net ; Pan, Xinhui
;
On 2023-01-16 17:11, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc:
[AMD Official Use Only - General]
The series is
Reviewed-by: Aaron Liu
> -Original Message-
> From: amd-gfx On Behalf Of Lang Yu
> Sent: Monday, January 16, 2023 4:20 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Yifan ; Yu, Lang ;
> Koenig, Christian ; Du, Xiaojian
>
> Subject:
On Mon, Jan 16, 2023 at 3:12 PM Christian König
wrote:
>
> We only need one offset and not an array of it.
>
> We have a wait in the amdgpu_bo_kmap() code for quite a while now, so
> waiting here isn't needed any more.
This should probably be two patches, one to clean up the offsets and
one to
On Mon, Jan 16, 2023 at 3:15 PM Alex Deucher wrote:
>
> On Mon, Jan 16, 2023 at 3:12 PM Christian König
> wrote:
> >
> > It can be that neither fence were initialized when we run out of UVD
> > streams for example.
> >
> > v2: fix typo breaking compile
> >
> > Signed-off-by: Christian König
>
>
On Mon, Jan 16, 2023 at 4:49 PM Limonciello, Mario
wrote:
>
> [Public]
>
>
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Monday, January 16, 2023 15:42
> > To: Guilherme G. Piccoli
> > Cc: amd-gfx@lists.freedesktop.org; Jiang, Sonny ;
> > ker...@gpiccoli.net; Pan, Xinhui ;
On 16/01/2023 18:49, Limonciello, Mario wrote:
> [...]
>
> The problem with adding a comment about which platform it's in is that
> this will probably go stale. Some IP blocks are re-used in multiple ASICs.
>
> VCN 3, 1, 1 is a great example. This is used in both Yellow Carp (Rembrandt)
> as
On 16/01/2023 18:41, Alex Deucher wrote:
> [...]
>> + case IP_VERSION(4, 0, 0): /* Vega10 */
>
> This comment is incorrect. Vega10 does not have VCN (it has UVD and VCE).
>
> Alex
Thanks Alex! I'll resubmit V2 with this comment removed.
I've stolen it from
On Mon, Jan 16, 2023 at 4:51 PM Guilherme G. Piccoli
wrote:
>
> On 16/01/2023 18:41, Alex Deucher wrote:
> > [...]
> >> + case IP_VERSION(4, 0, 0): /* Vega10 */
> >
> > This comment is incorrect. Vega10 does not have VCN (it has UVD and VCE).
> >
> > Alex
>
> Thanks Alex! I'll
[AMD Official Use Only - General]
A minor comment, unrelated to the patch. The comments are inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
On Mon, Jan 16, 2023 at 02:12:16PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
On Mon, Jan 16, 2023 at 02:12:31PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Monday, January 16, 2023 15:42
> To: Guilherme G. Piccoli
> Cc: amd-gfx@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ; Limonciello,
> Mario ;
On 1/16/2023 18:47, Guilherme G. Piccoli wrote:
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
On Mon, Jan 16, 2023 at 02:12:18PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
wrote:
>
> Currently both conditionals checked to enable indirect SRAM are
> repeated for all HW/IP models. Let's just simplify it a bit so
> code is more compact and readable.
>
> While at it, add the legacy names as a comment per case block,
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
wrote:
>
> 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
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Monday, January 16, 2023 15:54
> To: Limonciello, Mario
> Cc: Guilherme G. Piccoli ; amd-
> g...@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ;
sriov does not need to init pptable from amdgpu driver
we finish it from PF
Signed-off-by: Jane Jian
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
92 matches
Mail list logo
