Am 2022-07-25 um 22:18 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 20:40 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 20:15 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 06:32 schrieb Lang Yu:
We have memory leak issue
[AMD Official Use Only - General]
> -Original Message-
> From: André Almeida
> Sent: Tuesday, July 26, 2022 12:15 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Zhang, Hawking
> ; Zhou1, Tao ; Kuehling,
> Felix ; Xiao,
On 7/18/2022 3:32 PM, Andrew Morton wrote:
On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
/*
* Try to move out any movable page before pinning the range.
*/
@@ -1919,7 +1948,8 @@ static long
Am 2022-07-25 um 20:40 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 20:15 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 06:32 schrieb Lang Yu:
We have memory leak issue in current implenmention, i.e.,
the allocated struct kgd_mem memory is not
Am 2022-07-25 um 20:15 schrieb Lang Yu:
On 07/25/ , Felix Kuehling wrote:
Am 2022-07-25 um 06:32 schrieb Lang Yu:
We have memory leak issue in current implenmention, i.e.,
the allocated struct kgd_mem memory is not handled properly.
The idea is always creating a buffer object when importing
a
On 07/25, Magali Lemes wrote:
> Add missing headers to solve the following warnings from sparse:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/dcn20_fpu.c:656:17:
> warning: symbol 'ddr4_wm_table_gs' was not declared. Should it be static?
>
On 07/25, Magali Lemes wrote:
>
> On 7/25/22 16:42, André Almeida wrote:
> > Hi Magali,
> >
> > Às 15:15 de 25/07/22, Magali Lemes escreveu:
> > > As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
> > > _vcs_dpi_soc_bounding_box_st", change their types accordingly.
> > >
> > I can see that
On Mon, Jul 25, 2022 at 02:34:08PM -0500, Timothy Pearson wrote:
> >> Further digging shows that the build failures only occur with compilers
> >> that default to 64-bit long double.
> >
> > Where the heck do we have 'long double' things anywhere in the kernel?
> >
> > I tried to grep for it,
On 2022-07-22 03:34, Victor Zhao wrote:
For some hang caused by slow tests, engine cannot be stopped which
may cause resume failure after reset. In this case, force halt
engine by reverting context addresses
Can you maybe explain a bit more what exactly you mean by slow test and
why engine
Hi Magali
On 7/25/22 15:15, Magali Lemes wrote:
> As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
> _vcs_dpi_soc_bounding_box_st", change their types accordingly.
>
> Signed-off-by: Magali Lemes
> ---
Great catch! To the whole series:
Reviewed-by: Maíra Canal
Best Regards,
- Maíra
Giant svm range split to smaller ranges, align the range start address
to max svm range pages to improve MMU TLB usage.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 49 +++-
1 file changed, 33 insertions(+), 16
Acked-by: Andrey Grodzovsky
Andrey
On 2022-07-22 03:34, Victor Zhao wrote:
Save and restore gfxhub regs as they will be reset during mode 2
Signed-off-by: Victor Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfxhub.h| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 26 +++
This will be used to split giant svm range into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry fault
recover on giant range.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 ++
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 21
On 2022-07-22 03:34, Victor Zhao wrote:
In multi container use case, reset time is important, so skip ring
tests and cp halt wait during ip suspending for reset as they are
going to fail and cost more time on reset
Why are they failing in this case ? Skipping ring tests is not the best
On 2022-07-25 14:02, Felix Kuehling
wrote:
Am 2022-07-25 um 13:19 schrieb Philip Yang:
This will be used to split giant svm range
into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU
On 2022-07-25 13:37, Christian König wrote:
Hi Victor,
Am 25.07.22 um 12:45 schrieb Zhao, Victor:
[AMD Official Use Only - General]
Hi @Grodzovsky, Andrey,
Please help review the series, thanks a lot.
Hi @Koenig, Christian,
I thought a module parameter will be exposed to a common user,
On 2022-07-22 03:33, Victor Zhao wrote:
To meet the requirement for multi container usecase which needs
a quicker reset and not causing VRAM lost, adding the Mode2
reset handler for sienna_cichlid. Adding a AMDGPU_SKIP_MODE2_RESET
flag so driver can fallback to default reset method when mode2
On 7/25/22 16:42, André Almeida wrote:
Hi Magali,
Às 15:15 de 25/07/22, Magali Lemes escreveu:
As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
_vcs_dpi_soc_bounding_box_st", change their types accordingly.
I can see that indeed this type change sense for those variables, but
isn't a
Applied. Thanks!
On Mon, Jul 25, 2022 at 3:23 AM wangjianli wrote:
>
> Delete the redundant word 'in'.
>
> Signed-off-by: wangjianli
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
- Original Message -
> From: "Linus Torvalds"
> To: "Michael Ellerman"
> Cc: "linuxppc-dev" , "Alex Deucher"
> , "amd-gfx"
> , li...@roeck-us.net, "linux-kernel"
> , "Dan Horák"
> , "Timothy Pearson"
> Sent: Monday, July 25, 2022 2:19:57 PM
> Subject: Re: [PATCH] drm/amdgpu:
Hi Magali,
Às 15:15 de 25/07/22, Magali Lemes escreveu:
> As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
> _vcs_dpi_soc_bounding_box_st", change their types accordingly.
>
I can see that indeed this type change sense for those variables, but
isn't a bit strange that the type was wrong
Às 01:56 de 22/07/22, Roy Sun escreveu:
> The comments say that the product number is a 16-digit HEX string so the
> buffer needs to be at least 17 characters to hold the NUL terminator. Expand
> the buffer size to 20 to avoid the alignment issues.
>
> The comment:Product number should only be 16
On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman wrote:
>
> Further digging shows that the build failures only occur with compilers
> that default to 64-bit long double.
Where the heck do we have 'long double' things anywhere in the kernel?
I tried to grep for it, and failed miserably. I found
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Guchun Chen
Sent: Monday, July 25, 2022 2:18 AM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zhang, Hawking ;
Koenig, Christian ; Pan, Xinhui
Cc: Chen, Guchun
Subject: [PATCH]
Add missing headers to solve the following warnings from sparse:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/dcn20_fpu.c:656:17: warning:
symbol 'ddr4_wm_table_gs' was not declared. Should it be static?
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/dcn20_fpu.c:693:17: warning:
As "dcn3_15_soc" and "dcn3_16_soc" are of type "struct
_vcs_dpi_soc_bounding_box_st", change their types accordingly.
Signed-off-by: Magali Lemes
---
drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.h | 2 +-
drivers/gpu/drm/amd/display/dc/dcn316/dcn316_resource.h | 2 +-
2 files changed,
[Public]
> -Original Message-
> From: amd-gfx On Behalf Of
> Michael Ellerman
> Sent: Monday, July 25, 2022 8:39 AM
> To: linuxppc-...@lists.ozlabs.org
> Cc: d...@danny.cz; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; tpear...@raptorengineering.com;
>
Am 2022-07-25 um 13:19 schrieb Philip Yang:
Giant svm range split to smaller ranges, align the range start address
to max svm range pages to improve MMU TLB usage.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 49
Am 2022-07-25 um 13:19 schrieb Philip Yang:
This will be used to split giant svm range into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry fault
recover on giant range.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 ++
Am 2022-07-25 um 13:14 schrieb Daniel Phillips:
Rounding up allocations in the allocation path caused test regressions,
so now just round in the availability path.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff
Hi Victor,
Am 25.07.22 um 12:45 schrieb Zhao, Victor:
[AMD Official Use Only - General]
Hi @Grodzovsky, Andrey,
Please help review the series, thanks a lot.
Hi @Koenig, Christian,
I thought a module parameter will be exposed to a common user, this control was
added to help debug and test
Giant svm range split to smaller ranges, align the range start address
to max svm range pages to improve MMU TLB usage.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 49 +++-
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git
This will be used to split giant svm range into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry fault
recover on giant range.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 ++
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 19
To support SVM range VRAM overcommitment, TTM should be able to evict
svm bo of same process to system memory, to get space to alloc new svm
bo.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 9 ++---
1 file changed, 6
Rounding up allocations in the allocation path caused test regressions,
so now just round in the availability path.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
Am 25.07.22 um 17:27 schrieb Tvrtko Ursulin:
On 24/07/2022 19:28, Thomas Zimmermann wrote:
Hi
Am 22.07.22 um 17:47 schrieb Christian König:
Hi Tvrtko,
scratching my head what exactly is going on here.
I've build tested drm-tip a couple of test in the last week and it
always worked
Reviewed-by: Andrey Grodzovsky
Andrey
On 2022-07-19 06:39, Andrey Strachuk wrote:
Local variable 'rq' is initialized by an address
of field of drm_sched_job, so it does not make
sense to compare 'rq' with NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by:
Às 10:04 de 25/07/22, André Almeida escreveu:
> Às 07:27 de 25/07/22, Quan, Evan escreveu:
>> [AMD Official Use Only - General]
>>
>> Using "uint64_t" instead of "uint32_t" for entry counter may be better.
>>
>
> Indeed, it's a good idea. I'll send a v2 with that change, thanks.
>
However, SMU
On Mon, 25 Jul 2022 22:39:18 +1000
Michael Ellerman wrote:
> Commit d11219ad53dc ("amdgpu: disable powerpc support for the newer
> display engine") disabled the DCN driver for all of powerpc due to
> unresolved build failures with some compilers.
>
> Further digging shows that the build
On 24/07/2022 19:28, Thomas Zimmermann wrote:
Hi
Am 22.07.22 um 17:47 schrieb Christian König:
Hi Tvrtko,
scratching my head what exactly is going on here.
I've build tested drm-tip a couple of test in the last week and it
always worked flawlessly.
It looks like that some conflict
On 2022-07-25 10:34, Felix Kuehling
wrote:
Am
2022-07-25 um 08:23 schrieb Philip Yang:
This will be used to split giant svm range
into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry
This patch moves the non-dynamic dma-buf users over to the dynamic
locking specification. The strict locking convention prevents deadlock
situation for dma-buf importers and exporters.
Previously the "unlocked" versions of the dma-buf API functions weren't
taking the reservation lock and this
Hello,
This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs
in accordance to the locking specification. This allows us to utilize
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Tomasz Figa
Signed-off-by:
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to
Am 2022-07-25 um 08:23 schrieb Philip Yang:
To support SVM range VRAM overcommitment, TTM should be able to evict
svm bo of same process to system memory, to get space to alloc new svm
bo.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 9 ++---
1 file
Am 2022-07-25 um 08:23 schrieb Philip Yang:
Giant svm range split to smaller ranges, align the range start address
to max svm range pages to improve MMU TLB usage.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 52 +++-
1 file changed, 36
Am 2022-07-25 um 08:23 schrieb Philip Yang:
This will be used to split giant svm range into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry fault
recover on giant range.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 ++
Am 2022-07-25 um 06:32 schrieb Lang Yu:
We have memory leak issue in current implenmention, i.e.,
the allocated struct kgd_mem memory is not handled properly.
The idea is always creating a buffer object when importing
a gfx BO based dmabuf.
Signed-off-by: Lang Yu
---
Reviewed-by: Alex Deucher
On Mon, Jul 25, 2022 at 3:29 AM Sun, Roy wrote:
>
> [AMD Official Use Only - General]
>
> Ping
>
> -Original Message-
> From: Roy Sun
> Sent: Friday, July 22, 2022 12:57 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Sun, Roy
> Subject: [PATCH] drm/amdgpu: Fix
Dan Horák writes:
> On Fri, 22 Jul 2022 22:32:06 +1000
> Michael Ellerman wrote:
>> Dan Horák writes:
>> > Commit d11219ad53dc disabled the DCN driver for all platforms that
>> > define PPC64 due long build issues during "make allmodconfig" using
>> > cross-compilation. Cross-compilation
Commit d11219ad53dc ("amdgpu: disable powerpc support for the newer
display engine") disabled the DCN driver for all of powerpc due to
unresolved build failures with some compilers.
Further digging shows that the build failures only occur with compilers
that default to 64-bit long double.
Both
Replace zero-length array allocation with flexible-array member
because Dynamic calculations should not be performed for memory
allocator due to the risk of them overflowing. So using struct_size()
helper instead of an open-coded version in order to avoid any potential
type mistakes.
Às 07:27 de 25/07/22, Quan, Evan escreveu:
> [AMD Official Use Only - General]
>
> Using "uint64_t" instead of "uint32_t" for entry counter may be better.
>
Indeed, it's a good idea. I'll send a v2 with that change, thanks.
> BR
> Evan
>> -Original Message-
>> From: amd-gfx On Behalf
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Sapphire Pulse RX5700XT
Reference AMD RX6800
Engineering board with Ryzen 9 5900H
These systems were tested on the following
This will be used to split giant svm range into smaller ranges, to
support VRAM overcommitment by giant range and improve GPU retry fault
recover on giant range.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 ++
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 15
Giant svm range split to smaller ranges, align the range start address
to max svm range pages to improve MMU TLB usage.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 52 +++-
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git
To support SVM range VRAM overcommitment, TTM should be able to evict
svm bo of same process to system memory, to get space to alloc new svm
bo.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
Apply new intersect and compatible callback instead
of having a generic placement range verfications.
v2: Added a separate callback for compatiblilty
checks (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 45
Implemented a new intersect and compatible callback function
fetching the start offset from struct ttm_resource.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/nouveau/nouveau_mem.c | 29 +++
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 43 +++
1 file changed, 43 insertions(+)
diff
Implemented a new intersect and compatible callback function
fetching start offset from backend drm buddy allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 38
We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.
v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
Implemented a new intersect and compatible callback functions
to ttm range manager fetching start offset from drm mm range
allocator.
Signed-off-by: Christian König
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 33 +
1 file
[AMD Official Use Only - General]
Hi @Grodzovsky, Andrey,
Please help review the series, thanks a lot.
Hi @Koenig, Christian,
I thought a module parameter will be exposed to a common user, this control was
added to help debug and test so I put it as a debugfs. I can make it module
parameter
No need to reference the BO here, dmabuf framework will handle that.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
We have memory leak issue in current implenmention, i.e.,
the allocated struct kgd_mem memory is not handled properly.
The idea is always creating a buffer object when importing
a gfx BO based dmabuf.
Signed-off-by: Lang Yu
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 99
For clients(e.g., kfd) who want to determine whether to
create a buffer object by themselves especially when
importing a gfx BO based dmabuf.
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 38 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 ++
2
[AMD Official Use Only - General]
Using "uint64_t" instead of "uint32_t" for entry counter may be better.
BR
Evan
> -Original Message-
> From: amd-gfx On Behalf Of
> André Almeida
> Sent: Saturday, July 23, 2022 4:34 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
[Why]
Under SR-IOV, we are not sure whether pipe status is
good or not when doing initialization. The compute engine
maybe fail to bringup if pipe status is bad.
[How]
Do an RS64 pipe reset for MEC before we do initialization.
Also apply to bare-metal.
Signed-off-by: Horace Chen
---
[Why]
Under SR-IOV, we are not sure whether pipe status is
good or not when doing initialization. The compute engine
maybe fail to bringup if pipe status is bad.
[How]
For SR-IOV, disable the compute engine to do a pipe reset
before we do initialization.
Signed-off-by: Horace Chen
---
[AMD Official Use Only - General]
Ping
-Original Message-
From: Roy Sun
Sent: Friday, July 22, 2022 12:57 PM
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Roy
Subject: [PATCH] drm/amdgpu: Fix the incomplete product number
The comments say that the product number is a 16-digit HEX string
Hi all,
On Mon, 25 Jul 2022 07:41:09 +1000 Stephen Rothwell wrote:
>
> On Fri, 22 Jul 2022 14:12:44 -0400 Alex Deucher wrote:
> >
> > On Fri, Jul 22, 2022 at 1:56 PM Rodrigo Siqueira
> > wrote:
> > >
> > > When we use the allmodconfig option we see the following error:
> > >
> > >
Hi all,
On Fri, 22 Jul 2022 14:12:44 -0400 Alex Deucher wrote:
>
> On Fri, Jul 22, 2022 at 1:56 PM Rodrigo Siqueira
> wrote:
> >
> > When we use the allmodconfig option we see the following error:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:
> > In
Delete the redundant word 'in'.
Signed-off-by: wangjianli
---
drivers/gpu/drm/amd/display/dc/dce/dce_audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
index
Keep code consistency when accessing drm_device from amdgpu driver.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index
78 matches
Mail list logo
