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 70eaac017624..f
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:
> > >
> > > drivers/gp
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 function
[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
[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
---
drivers/g
[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
---
drivers/gpu
[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 ; David
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
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 +---
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
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
[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 i
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 changed
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
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_
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 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 +++
drivers/gpu/drm/nouveau/nouveau_mem
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 +
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 --
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 a/drivers/g
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 +++
[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 displ
À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 O
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.
Signed-off-by
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 th
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 default
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 t
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
---
.../gpu/drm/amd/amdgpu
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 ++
drive
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 insert
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 c
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 take
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.
Ack
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 loc
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:
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
reserv
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 patc
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
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 resolu
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 failures
À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 m
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:
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 flawless
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
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 insertion
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 +++
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 a/drivers/g
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 so
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 --git
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 ++
dri
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 +++---
[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;
> alexdeuc...@gmail
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, 2
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:
symbol
[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] drm/am
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 s
À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
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 in
- 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: Re-enab
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 a/drivers/gpu/drm/amd/display/dc/d
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
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
r
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, th
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 r
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
idea
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 +++
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 +++
dri
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 deletio
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 Can
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 ca
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, and
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 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?
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dc
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
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 hand
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 check_and_migrate_movable_pages(unsign
[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, J
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 i
From: Shikai Guo
add get_gfx_off_status interface to yellow_carp_ppt_funcs structure.
Signed-off-by: Shikai Guo
---
.../drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
b/dri
[AMD Official Use Only - General]
Reviewed-by: Aaron Liu
> -Original Message-
> From: amd-gfx On Behalf Of
> shikai@amd.com
> Sent: Tuesday, July 26, 2022 2:29 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Liang, Prike
> ; Quan, Evan ; Liu, Aaron
>
> Subject: [P
79 matches
Mail list logo
