On 12/10/ , Christian KKKnig wrote:
> Am 10.12.21 um 04:21 schrieb Lang Yu:
> > On 12/10/ , Quan, Evan wrote:
> > > [AMD Official Use Only]
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Yu, Lang
> > > > Sent: Friday, December 10, 2021 10:34 AM
> > > > To: Quan, Evan
> > >
Am 09.12.21 um 23:27 schrieb Felix Kuehling:
Am 2021-12-09 um 5:14 p.m. schrieb Chen, Xiaogang:
On 12/9/2021 12:40 PM, Felix Kuehling wrote:
Am 2021-12-09 um 2:49 a.m. schrieb Xiaogang.Chen:
From: Xiaogang Chen
When application is about finish it destroys queues it has created by
an ioctl.
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers,
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, December 9, 2021 8:09 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V4 05/17] drm/amd/pm: do not expose those
Am 10.12.21 um 04:21 schrieb Lang Yu:
On 12/10/ , Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Yu, Lang
Sent: Friday, December 10, 2021 10:34 AM
To: Quan, Evan
Cc: amd-gfx@lists.freedesktop.org; Grodzovsky, Andrey
; Lazar, Lijo ; Huang,
Ray ; Deucher,
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, December 9, 2021 8:05 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V4 03/17] drm/amd/pm: do not expose power
>
Am 09.12.21 um 19:28 schrieb Felix Kuehling:
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
That still won't work.
But I think we could do this change for the amdgpu mmap callback only.
If graphics user mode has problems with it, we could even make this
specific to KFD BOs in the
On 12/10/2021 10:50 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, December 9, 2021 7:58 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Feng, Kenneth
Subject: Re: [PATCH V4 02/17]
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, December 9, 2021 7:58 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Feng, Kenneth
> Subject: Re: [PATCH V4 02/17] drm/amd/pm: do not expose power
>
Thanks again Alex! Some comments inlined below:
On 09/12/2021 15:06, Alex Deucher wrote:
> Not really in a generic way. It's asic and platform specific. In
> addition most modern displays require link training to bring up the
> display, so you can't just save and restore registers.
Oh sure, I
On Friday, 10 December 2021 3:54:31 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/9/2021 10:29 AM, Felix Kuehling wrote:
> > Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> >> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro
> >> (Alex) wrote:
> >>> On
On 12/10/ , Quan, Evan wrote:
> [AMD Official Use Only]
>
>
>
> > -Original Message-
> > From: Yu, Lang
> > Sent: Friday, December 10, 2021 10:34 AM
> > To: Quan, Evan
> > Cc: amd-gfx@lists.freedesktop.org; Grodzovsky, Andrey
> > ; Lazar, Lijo ; Huang,
> > Ray ; Deucher, Alexander
> >
This patch reverts the following:
'commit fc547b2b1816 ("drm/amdkfd: add Navi2x to GWS init conditions")'
Disable GWS usage in default settings for now due to FW bugs.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 5 +
1 file changed, 1 insertion(+), 4
[AMD Official Use Only]
> -Original Message-
> From: Yu, Lang
> Sent: Friday, December 10, 2021 10:34 AM
> To: Quan, Evan
> Cc: amd-gfx@lists.freedesktop.org; Grodzovsky, Andrey
> ; Lazar, Lijo ; Huang,
> Ray ; Deucher, Alexander
> ; Koenig, Christian
>
> Subject: Re: [PATCH 2/2]
[Public]
Re: We can probably just drop the conditional here and just clear the high bits
for everything.
It's addressed in v3 by Leslie.
Regards,
Guchun
-Original Message-
From: Alex Deucher
Sent: Friday, December 10, 2021 12:02 AM
To: Shi, Leslie
Cc: Lazar, Lijo ; amd-gfx list
;
On 12/10/ , Quan, Evan wrote:
> [AMD Official Use Only]
>
>
>
> > -Original Message-
> > From: amd-gfx On Behalf Of Lang
> > Yu
> > Sent: Thursday, December 9, 2021 4:49 PM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Grodzovsky, Andrey ; Lazar, Lijo
> > ; Huang, Ray ; Deucher,
> >
[AMD Official Use Only]
> -Original Message-
> From: amd-gfx On Behalf Of
> Prike Liang
> Sent: Thursday, December 9, 2021 9:51 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Liang, Prike
> ; Huang, Ray ; Limonciello,
> Mario
> Subject: [PATCH] drm/amd/pm: skip gfx
[AMD Official Use Only]
> -Original Message-
> From: amd-gfx On Behalf Of Lang
> Yu
> Sent: Thursday, December 9, 2021 4:49 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Grodzovsky, Andrey ; Lazar, Lijo
> ; Huang, Ray ; Deucher,
> Alexander ; Yu, Lang ;
> Koenig, Christian
> Subject:
This is Alex' description from the "gpu block diagram" thread, edited to
fit as ReST.
Originally-by: Alex Deucher
Signed-off-by: Yann Dirson
---
Documentation/gpu/amdgpu/driver-core.rst | 81
1 file changed, 81 insertions(+)
diff --git
This is Alex' description from the "Looking for clarifications around
gfx/kcq/kiq"
thread, edited to fit as ReST.
Originally-by: Alex Deucher
Signed-off-by: Yann Dirson
---
Documentation/gpu/amdgpu/driver-core.rst | 35
1 file changed, 35 insertions(+)
diff --git
This starts to make the formated index much more manageable to the reader.
Signed-off-by: Yann Dirson
---
Documentation/gpu/amdgpu/driver-core.rst | 65
Documentation/gpu/amdgpu/driver-misc.rst | 112 +++
Documentation/gpu/amdgpu/index.rst| 298 +-
This series starts by splitting the amdgpu/index file to make some
room for additional contents, but I'm not really happy with the
result, we can certainly do better.
The rest is basically bringing Alex' descriptions of the hardware and
driver internals into the doc.
Yann Dirson (3):
On 2021-12-09 03:02, Yizhuo Zhai wrote:
> Hi All:
> I just found a bug in the cramfs using the static analysis tool, but
> not sure if this could happen in reality, could you please advise me
> here? Thanks for your attention : ) And please ignore the last one
> with HTML format if you did not
Am 2021-12-09 um 10:47 a.m. schrieb Philip Yang:
> For userptr bo, if adev is not in IOMMU isolation mode, RAM direct map
> to GPU, multiple GPUs use same system memory dma mapping address, they
> can share the original mem->bo in attachment to reduce dma address array
> memory usage.
>
>
Am 2021-12-09 um 5:14 p.m. schrieb Chen, Xiaogang:
>
> On 12/9/2021 12:40 PM, Felix Kuehling wrote:
>> Am 2021-12-09 um 2:49 a.m. schrieb Xiaogang.Chen:
>>> From: Xiaogang Chen
>>>
>>> When application is about finish it destroys queues it has created by
>>> an ioctl. Driver deletes queue
>>>
On 12/9/2021 12:40 PM, Felix Kuehling wrote:
Am 2021-12-09 um 2:49 a.m. schrieb Xiaogang.Chen:
From: Xiaogang Chen
When application is about finish it destroys queues it has created by
an ioctl. Driver deletes queue
entry(/sys/class/kfd/kfd/proc/pid/queues/queueid/)
which is directory
Add svm_range_bo_unref_async to schedule work to wait for svm_bo
eviction work done and then free svm_bo. __do_munmap put_page
is atomic context, call svm_range_bo_unref_async to avoid warning
invalid wait context. Other non atomic context call svm_range_bo_unref.
Signed-off-by: Philip Yang
---
> Thanks for this. It's really good to see this.
>
> Reviewed-by: Harry Wentland
Hearfully seconded, let's get this rolling :)
Reviewed-by: Yann Dirson
>
> Harry
>
> On 2021-12-09 09:20, Rodrigo Siqueira wrote:
> > Display Core (DC) is one of the components under amdgpu, and it has
> >
Hi,
thank you for the report!
> No issues in Kernel 5.13.13 and the issues exist in 5.14 to 5.15.7 .So
> I bisected the bug with
> git(https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux).first
> bad commit: [5a7b95fb993ec399c8a685552aa6a8fc995c40bd] i2c: core:
> support bus
On Thu, Dec 9, 2021 at 12:02 PM Philip Yang wrote:
>
> If host and amdgpu IOMMU is not enabled or IOMMU is pass through mode,
> set adev->ram_is_direct_mapped flag which will be used to optimize
> memory usage for multi GPU mappings.
>
> Signed-off-by: Philip Yang
Reviewed-by: Alex Deucher
>
On Thu, Dec 9, 2021 at 1:18 PM Guilherme G. Piccoli wrote:
>
> Thanks again Alex! Some comments inlined below:
>
> On 09/12/2021 15:06, Alex Deucher wrote:
> > Not really in a generic way. It's asic and platform specific. In
> > addition most modern displays require link training to bring up
On 2021-12-08 7:03 p.m., Felix Kuehling
wrote:
The remove_list head was only used for keeping track of existing ranges
that are to be removed from the svms->list. The update_list was used for
new or existing ranges that need updated attributes. These two
On 2021-12-08 7:03 p.m., Felix Kuehling
wrote:
There are seven list_heads in struct svm_range: list, update_list,
remove_list, insert_list, svm_bo_list, deferred_list, child_list. This
patch and the next one remove two of them that are redundant.
The
[AMD Official Use Only]
> -Original Message-
> From: Sider, Graham
> Sent: December 9, 2021 1:33 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kim, Jonathan ; Kuehling, Felix
> ; Sider, Graham
> Subject: [PATCH] drm/amdkfd: add Navi2x to GWS init conditions
>
> Initalize GWS on Navi2x
[AMD Official Use Only]
Sounds reasonable.
This patch is Reviewed by : Shaoyun.liu
Regards
Shaoyun.liu
-Original Message-
From: Skvortsov, Victor
Sent: Thursday, December 9, 2021 1:33 PM
To: Liu, Shaoyun ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: SRIOV
Am 2021-12-09 um 2:49 a.m. schrieb Xiaogang.Chen:
> From: Xiaogang Chen
>
> When application is about finish it destroys queues it has created by
> an ioctl. Driver deletes queue
> entry(/sys/class/kfd/kfd/proc/pid/queues/queueid/)
> which is directory including this queue all attributes. Low
Initalize GWS on Navi2x with mec2_fw_version >= 0x42.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index
[AMD Official Use Only]
I wanted to keep the order the same as in amdgpu_device_lock_adev()
(Set flag then acquire lock) to prevent any weird race conditions.
Thanks,
Victor
-Original Message-
From: Liu, Shaoyun
Sent: Thursday, December 9, 2021 1:25 PM
To: Skvortsov, Victor ;
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
> That still won't work.
>
> But I think we could do this change for the amdgpu mmap callback only.
If graphics user mode has problems with it, we could even make this
specific to KFD BOs in the amdgpu_gem_object_mmap callback.
Regards,
[AMD Official Use Only]
I think it's a good catch for reset_sem, any reason to change the
adev->in_gpu_reset ?
Regards
Shaoyun.liu
-Original Message-
From: amd-gfx On Behalf Of Victor
Skvortsov
Sent: Thursday, December 9, 2021 12:02 PM
To: amd-gfx@lists.freedesktop.org
Cc:
On Thu, Dec 9, 2021 at 1:00 PM Guilherme G. Piccoli wrote:
>
> On 09/12/2021 14:31, Alex Deucher wrote:
> > [...]
> > Once the driver takes over, none of the pre-driver state is retained.
> > You'll need to load the driver in the new kernel to initialize the
> > displays. Note the efifb doesn't
On 09/12/2021 14:31, Alex Deucher wrote:
> [...]
> Once the driver takes over, none of the pre-driver state is retained.
> You'll need to load the driver in the new kernel to initialize the
> displays. Note the efifb doesn't actually have the ability to program
> any hardware, it just takes over
On Thu, Dec 9, 2021 at 12:04 PM Guilherme G. Piccoli
wrote:
>
> Hi all, I have a question about the possibility of reusing a framebuffer
> after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
> a separate GPU hardware), but I guess the question is kinda generic
> hence I've
Hi All:
I just found a bug in the cramfs using the static analysis tool, but not
sure if this could happen in reality, could you please advisehere? Thanks
for your attention : )
In function enable_stream_features(), the variable "old_downspread.raw
On Wed, Dec 08, 2021 at 06:16:10AM +0100, jim.cro...@gmail.com wrote:
> are you planning to dust this patchset off and resubmit it ?
>
> Ive been playing with it and learning ftrace (decade+ late),
> I found your boot-line example very helpful as 1st steps
> (still havent even tried the
Hello,
Could you please provide the feedback to my previous report?
Thanks a lot :)
Best wishes,
Jia-Ju Bai
On 2021/9/15 17:39, Jia-Ju Bai wrote:
Hello,
My static analysis tool reports a possible ABBA deadlock in the amdgpu
driver in Linux 5.10:
amdgpu_debugfs_process_reg_op()
In line 1138 (#1), amdgpu_get_xgmi_hive() increases the kobject reference
counter of the hive it returned. The hive returned by
amdgpu_get_xgmi_hive()should be released with the help of
amdgpu_put_xgmi_hive() to balance its kobject reference counter properly.
Forgetting the amdgpu_put_xgmi_hive()
Hi All:
I just found a bug in the cramfs using the static analysis tool, but
not sure if this could happen in reality, could you please advise me
here? Thanks for your attention : ) And please ignore the last one
with HTML format if you did not filter it out.
In function enable_stream_features(),
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've looped most of the lists / people I think does make sense
(apologies for
On Thu, Dec 09, 2021 at 12:45:24PM +1100, Alistair Popple wrote:
> On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote:
> > > I think a similar problem exists for device private fault handling as
> > > well and
> > > it has been on my list of things to fix for a while. I think the
On Thursday, 9 December 2021 12:53:45 AM AEDT Jason Gunthorpe wrote:
> > I think a similar problem exists for device private fault handling as well
> > and
> > it has been on my list of things to fix for a while. I think the solution
> > is to
> > call try_get_page(), except it doesn't work with
From: chiminghao
return value form directly instead of
taking this in another redundant variable.
Reported-by: Zeal Robot
Signed-off-by: chiminghao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c | 5 +
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 6 ++
2 files changed, 3 insertions(+),
On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
> > Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
> >> Am 2021-12-08 um 6:31 a.m. schrieb Alistair Popple:
> >>> On Tuesday, 7 December 2021 5:52:43 AM AEDT
Host initiated VF FLR may fail if someone else
is already holding a read_lock. Change from
down_write_trylock to down_write to guarantee
the reset goes through.
Signed-off-by: Victor Skvortsov
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 5 +++--
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 5 +++--
Am 2021-12-09 um 10:47 a.m. schrieb Isabella Basso:
> This fixes the warnings below, and also drops the display_count
> variable, as it's unused.
>
> In function 'svm_range_map_to_gpu':
> warning: variable 'bo_va' set but not used [-Wunused-but-set-variable]
> 1172 | struct amdgpu_bo_va
We want to be able to call virt data exchange conditionally
after gmc sw init to reserve bad pages as early as possible.
Since this is a conditional call, we will need to call
it again unconditionally later in the init sequence.
Refactor the data exchange function so it can be
called multiple
From: Michel Dänzer
Use the struct display_mode_lib pointer instead of passing lots of large
arrays as parameters by value.
Addresses this warning (resulting in failure to build a RHEL debug kernel
with Werror enabled):
[Public]
Hi Matthew,
Ping?
Regards,
Arun
-Original Message-
From: Paneer Selvam, Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-de...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-gfx@lists.freedesktop.org
Cc: matthew.a...@intel.com; dan...@ffwll.ch;
Thanks for this. It's really good to see this.
Reviewed-by: Harry Wentland
Harry
On 2021-12-09 09:20, Rodrigo Siqueira wrote:
> Display Core (DC) is one of the components under amdgpu, and it has
> multiple features directly related to the KMS API. Unfortunately, we
> don't have enough
This fixes the warnings below, and also drops the display_count
variable, as it's unused.
In function 'svm_range_map_to_gpu':
warning: variable 'bo_va' set but not used [-Wunused-but-set-variable]
1172 | struct amdgpu_bo_va bo_va;
| ^
...
In
Add a pf-vf exchange right after GMC sw init in
order to reserve bad pages as early as possible
Signed-off-by: Victor Skvortsov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
On 12/9/2021 10:29 AM, Felix Kuehling wrote:
Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
On 12/8/2021 11:30 AM, Felix Kuehling wrote:
Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08
From: Michel Dänzer
Move code using the Pipe struct to a new helper function.
Works around[0] this warning (resulting in failure to build a RHEL debug
kernel with Werror enabled):
../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In
function
If host and amdgpu IOMMU is not enabled or IOMMU is pass through mode,
set adev->ram_is_direct_mapped flag which will be used to optimize
memory usage for multi GPU mappings.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
Hi Guilherme,
Am 09.12.21 um 17:00 schrieb Guilherme G. Piccoli:
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've
On Thu, Dec 9, 2021 at 12:18 AM Leslie Shi wrote:
>
> Guest OS will setup VCN instance 1 which is disabled as an enabled instance
> and
> execute initialization work on it, but this causes VCN ib ring test failure
> on the disabled VCN instance during modprobe:
>
> amdgpu :00:08.0: amdgpu:
Am 09.12.21 um 16:38 schrieb Andrey Grodzovsky:
On 2021-12-09 4:00 a.m., Christian König wrote:
Am 09.12.21 um 09:49 schrieb Lang Yu:
It is useful to maintain error context when debugging
SW/FW issues. We introduce amdgpu_device_halt() for this
purpose. It will bring hardware to a kind of
Fix the warning below:
warning: Cannot understand * \file amdgpu_ioc32.c
on line 2 - I thought it was a doc line
Changes since v1:
- As suggested by Alexander Deucher:
1. Reduce diff to minimum as this DOC section doesn't provide much
value.
Signed-off-by: Isabella Basso
---
Display core documentation is not well organized, and it is hard to find
information due to the lack of sections. This commit reorganizes the
documentation layout, and it is preparation work for future changes.
Changes since V1:
- Christian: Group amdgpu documentation together.
- Daniel: Drop
This turns previously global functions into static, thus removing
compile-time warnings such as:
warning: no previous prototype for 'get_highest_allowed_voltage_level'
[-Wmissing-prototypes]
742 | unsigned int get_highest_allowed_voltage_level(uint32_t chip_family,
uint32_t
Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro (Alex)
> wrote:
>> On 12/8/2021 11:30 AM, Felix Kuehling wrote:
>>> Am 2021-12-08 um 11:58 a.m. schrieb Felix Kuehling:
Am 2021-12-08 um 6:31 a.m. schrieb Alistair
This commit fixes the compile-time warning below:
warning: no previous prototype for ‘amdgpu_ras_mca_query_error_status’
[-Wmissing-prototypes]
Changes since v1:
- As suggested by Alexander Deucher:
1. Make function static instead of adding prototype.
Signed-off-by: Isabella Basso
---
That still won't work.
But I think we could do this change for the amdgpu mmap callback only.
Regards,
Christian.
Am 09.12.21 um 16:29 schrieb Bhardwaj, Rajneesh:
Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank
you!
On 12/9/2021 10:27 AM, Christian König wrote:
Hi
[Public]
No objections from me.
Acked-by: Alex Deucher
From: Christian König
Sent: Thursday, December 9, 2021 10:34 AM
To: Quan, Evan ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: don't skip runtime pm get on A+A
Sounds good. I will send a v2 with only ttm_bo_mmap_obj change. Thank you!
On 12/9/2021 10:27 AM, Christian König wrote:
Hi Rajneesh,
yes, separating this from the drm_gem_mmap_obj() change is certainly a
good idea.
The child cannot access the BOs mapped by the parent anyway with
access
On 2021-12-09 4:00 a.m., Christian König wrote:
Am 09.12.21 um 09:49 schrieb Lang Yu:
It is useful to maintain error context when debugging
SW/FW issues. We introduce amdgpu_device_halt() for this
purpose. It will bring hardware to a kind of halt state,
so that no one can touch it any more.
Thanks Christian. Would it make it less intrusive if I just use the flag
for ttm bo mmap and remove the drm_gem_mmap_obj change from this patch?
For our use case, just the ttm_bo_mmap_obj change should suffice and we
don't want to put any more work arounds in the user space (thunk, in our
Display core provides a feature that makes it easy for users to debug
Multiple planes by enabling a visual notification at the bottom of each
plane. This commit introduces how to use such a feature.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 34
[AMD Official Use Only]
Hi Matthew,
Ping on this?
Regards,
Arun
-Original Message-
From: amd-gfx On Behalf Of Arunpravin
Sent: Wednesday, December 1, 2021 10:10 PM
To: dri-de...@lists.freedesktop.org; intel-...@lists.freedesktop.org;
amd-gfx@lists.freedesktop.org
Cc: dan...@ffwll.ch;
Hi Rajneesh,
yes, separating this from the drm_gem_mmap_obj() change is certainly a
good idea.
The child cannot access the BOs mapped by the parent anyway with
access restrictions applied
exactly that is not correct. That behavior is actively used by some
userspace stacks as far as I
For userptr bo, if adev is not in IOMMU isolation mode, RAM direct map
to GPU, multiple GPUs use same system memory dma mapping address, they
can share the original mem->bo in attachment to reduce dma address array
memory usage.
Signed-off-by: Philip Yang
---
In the DC driver, we have multiple acronyms that are not obvious most of
the time; the same idea is valid for amdgpu. This commit introduces a DC
and amdgpu glossary in order to make it easier to navigate through our
driver.
Changes since V3:
- Yann: Add new acronyms to amdgpu glossary
-
This patchset aims at fixing various compilation warnings in the AMD GPU
driver. All warnings were generated using gcc and the W=1 flag. I
decided to deal with them in the same order as the issues were presented
in the log, with the exception of those that were about the lack of
protypes, which
Introduce how to collect DTN log from debugfs.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst
b/Documentation/gpu/amdgpu/display/dc-debug.rst
This commit describes how DCN works by providing high-level diagrams
with an explanation of each component. In particular, it details the
Global Sync signals.
Change since V2:
- Add a comment about MMHUBBUB.
Signed-off-by: Rodrigo Siqueira
---
.../gpu/amdgpu/display/config_example.svg |
Display Core (DC) is one of the components under amdgpu, and it has
multiple features directly related to the KMS API. Unfortunately, we
don't have enough documentation about DC in the upstream, which makes
the life of some external contributors a little bit more challenging.
For these reasons,
Display core provides a feature that makes it easy for users to debug
Pipe Split. This commit introduces how to use such a debug option.
Signed-off-by: Rodrigo Siqueira
---
Documentation/gpu/amdgpu/display/dc-debug.rst | 28 +--
1 file changed, 26 insertions(+), 2 deletions(-)
Am 07.12.21 um 08:40 schrieb Quan, Evan:
[AMD Official Use Only]
-Original Message-
From: Christian König
Sent: Tuesday, December 7, 2021 3:03 PM
To: Quan, Evan ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: don't skip runtime pm get on A+A
On 12/3/2021 8:35 AM, Evan Quan wrote:
Instead of centralizing all headers in the same folder. Separate them into
different folders and place them among those source files those who really
need them.
Signed-off-by: Evan Quan
Change-Id: Id74cb4c7006327ca7ecd22daf17321e417c4aa71
---
On 12/3/2021 8:35 AM, Evan Quan wrote:
We should avoid having multi-function APIs. It should be up to the caller
to determine when or whether to call amdgpu_dpm_dispatch_task().
Signed-off-by: Evan Quan
Change-Id: I78ec4eb8ceb6e526a4734113d213d15a5fbaa8a4
---
On 12/3/2021 8:35 AM, Evan Quan wrote:
Drop cross callings and multi-function APIs. Also avoid exposing
internal implementations details.
Signed-off-by: Evan Quan
Change-Id: I55e5ab3da6a70482f5f5d8c256eed2f754feae20
--
v1->v2:
- add back the adev->pm.dpm_enabled check(Lijo)
---
On 12/9/2021 2:46 PM, Chen, Guchun wrote:
[Public]
Hi Lijo,
The check is not necessary. It has a guard by for loop in the caller.
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
...
if (amdgpu_vcn_is_disabled_vcn(adev, VCN_ENCODE_RING, i)) {
..
}
Thanks
On 12/9/2021 1:56 PM, Leslie Shi wrote:
Guest OS will setup VCN instance 1 which is disabled as an enabled instance and
execute initialization work on it, but this causes VCN ib ring test failure
on the disabled VCN instance during modprobe:
amdgpu :00:08.0: amdgpu: ring vcn_enc_1.0 uses
[Public]
Hi Lijo,
The check is not necessary. It has a guard by for loop in the caller.
for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {
...
if (amdgpu_vcn_is_disabled_vcn(adev, VCN_ENCODE_RING, i)) {
..
}
Regards,
Guchun
-Original Message-
From: Lazar,
SMU firmware guys expect the driver maintains error context
and doesn't interact with SMU any more when SMU errors occurred.
That will aid in debugging SMU firmware issues.
Add SMU debug option support for this request, it can be
enabled or disabled via amdgpu_smu_debug debugfs file.
When
Am 08.12.21 um 21:27 schrieb Alex Deucher:
On Wed, Dec 8, 2021 at 3:25 PM Alex Deucher wrote:
On Wed, Dec 8, 2021 at 3:17 PM Philip Yang wrote:
Remove not unique timestamp WARNING as same timestamp interrupt happens
on some chips,
Drain fault need to wait for the processed_timestamp to be
On 12/3/2021 8:35 AM, Evan Quan wrote:
Move them to si_dpm.c instead.
Signed-off-by: Evan Quan
Change-Id: I288205cfd7c6ba09cfb22626ff70360d61ff0c67
--
v1->v2:
- rename the API with "si_" prefix(Alex)
v2->v3:
- rename other data structures used only in si_dpm.c(Lijo)
---
[Public]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Shi, Leslie
Sent: Thursday, December 9, 2021 4:27 PM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
Cc: Chen, Guchun ; Shi, Leslie
Subject: [PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV
Guest
Am 09.12.21 um 09:49 schrieb Lang Yu:
It is useful to maintain error context when debugging
SW/FW issues. We introduce amdgpu_device_halt() for this
purpose. It will bring hardware to a kind of halt state,
so that no one can touch it any more.
Compare to a simple hang, the system will keep
Guest OS will setup VCN instance 1 which is disabled as an enabled instance and
execute initialization work on it, but this causes VCN ib ring test failure
on the disabled VCN instance during modprobe:
amdgpu :00:08.0: amdgpu: ring vcn_enc_1.0 uses VM inv eng 5 on hub 1
amdgpu :00:08.0:
1 - 100 of 122 matches
Mail list logo
