Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

On Wed, Dec 08, 2021 at 10:31:58PM +1100, Alistair Popple wrote: > On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote: > > Avoid long term pinning for Coherent device type pages. This could > > interfere with their own device memory manager. > > If caller tries to get user device coheren

Recall: [PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV

Shi, Leslie would like to recall the message, "[PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV".

[PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV

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: [d

[PATCH] drm/amd/pm: skip gfx cgpg in the s0ix suspend-resume

In the s0ix entry need retain gfx in the gfxoff state,we don't disable gfx cgpg in the suspend so there is also needn't enable gfx cgpg in the s0ix resume. Signed-off-by: Prike Liang --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 1/2] drm/amdgpu: Detect if amdgpu in IOMMU isolation mode

On 2021-12-07 5:16 p.m., Alex Deucher wrote: On Tue, Dec 7, 2021 at 4:59 PM Felix Kuehling wrote: On 2021-12-07 9:59 a.m., Philip Yang wrote: If host and amdgpu IOMMU is not enabled or IOMMU is pass through mode, dma_map_

Re: [PATCH 1/3] amdgpu/pm: Implement new API function "emit" that accepts buffer base and write offset

[AMD Official Use Only] > The whole idea seems fine to me. However, we are trying to do some cleanups > to avoid spiking into power internals(as above via > adev->powerplay.pp_funcs->emit_clock_levels). > Check the patch series below: > https://lists.freedesktop.org/archives/amd-gfx/2021-Decembe

[PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV

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: [d

Re: Various problems trying to vga-passthrough a Renoir iGPU to a xen/qubes-os hvm

On Wed, Dec 8, 2021 at 5:50 PM Yann Dirson wrote: > > Hi Alex, > > > > > On Mon, Dec 6, 2021 at 4:36 PM Yann Dirson wrote: > > > > > > Hi Alex, > > > > > > > We have not validated virtualization of our integrated GPUs. I > > > > don't > > > > know that it will work at all. We had done a bit of

[PATCH 2/2] drm/amdkfd: Use prange->update_list head for remove_list

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 cases are mutually exclusive (i.e. the same range will never be on both lists). Therefore w

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

On Tuesday, 7 December 2021 5:52:43 AM AEDT Alex Sierra wrote: > Avoid long term pinning for Coherent device type pages. This could > interfere with their own device memory manager. > If caller tries to get user device coherent pages with PIN_LONGTERM flag > set, those pages will be migrated back t

Re: [PATCH] drm/amd/pm: skip gfx cgpg in the s0ix suspend-resume

[Public] Acked-by: Alex Deucher From: Liang, Prike Sent: Wednesday, December 8, 2021 8:51 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Huang, Ray ; Limonciello, Mario ; Liang, Prike Subject: [PATCH] drm/amd/pm: skip gfx cgpg in the s0ix suspe

[PATCH 1/2] drm/amdkfd: Use prange->list head for insert_list

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 insert_list head was only used for new ranges that are not on the svms->list yet. So we can us

RE: [PATCH] drm/amdgpu: add modifiers in amdgpu_vkms_plane_init()

[Public] Reviewed-by: Guchun Chen Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Leslie Shi Sent: Wednesday, December 8, 2021 4:46 PM To: amd-gfx@lists.freedesktop.org Subject: [PATCH] drm/amdgpu: add modifiers in amdgpu_vkms_plane_init() Fix following warning in SRIOV

RE: [PATCH 1/3] amdgpu/pm: Implement new API function "emit" that accepts buffer base and write offset

[AMD Official Use Only] > -Original Message- > From: amd-gfx On Behalf Of > Darren Powell > Sent: Wednesday, December 8, 2021 2:36 PM > To: amd-gfx@lists.freedesktop.org > Cc: Powell, Darren > Subject: [PATCH 1/3] amdgpu/pm: Implement new API function "emit" that > accepts buffer base

Re: gpu block diagram

On Tue, Dec 7, 2021 at 5:07 PM Yann Dirson wrote: > > Thanks for the details Alex! > > Here is an attempt to formalize the decomposition of a > (mostly Renoir) APU, using plantuml. That's highly preliminary, > focusing on blocks/sub-blocks/firmware, based on my current > partial (and surely incor

[pull] amdgpu drm-fixes-5.16

Hi Dave, Daniel, Fixes for 5.16. The following changes since commit a687efed194bdc185fd7cb33920fe8b4e60ecb9e: Merge tag 'drm-intel-fixes-2021-12-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-12-03 05:59:31 +1000) are available in the Git repository at: https://g

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

Am 08.12.21 um 21:53 schrieb Rajneesh Bhardwaj: When an application having open file access to a node forks, its shared mappings also get reflected in the address space of child process even though it cannot access them with the object permissions applied. With the existing permission checks on t

[PATCH] drm/amdkfd: explicitly create/destroy queue attributes under /sys

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 level kernel code deletes all attributes under this directory. T

Re: [PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV

On 12/9/2021 10:55 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: ring vcn_enc_1.0 uses

[PATCH 1/2] drm/amdgpu: introduce a kind of halt state for amdgpu device

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 stable at least for SSH access. Then it shoul

Re: [PATCH V4 03/17] drm/amd/pm: do not expose power implementation details to display

On 12/3/2021 8:35 AM, Evan Quan wrote: Display is another client of our power APIs. It's not proper to spike into power implementation details there. Signed-off-by: Evan Quan Change-Id: Ic897131e16473ed29d3d7586d822a55c64e6574a --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +- .

Re: [PATCH V4 02/17] drm/amd/pm: do not expose power implementation details to amdgpu_pm.c

On 12/3/2021 8:35 AM, Evan Quan wrote: amdgpu_pm.c holds all the user sysfs/hwmon interfaces. It's another client of our power APIs. It's not proper to spike into power implementation details there. Signed-off-by: Evan Quan Change-Id: I397853ddb13eacfce841366de2a623535422df9a -- v1->v2: -

[PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV

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: [d

RE: [PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV

[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 OS

Re: [PATCH 1/2] drm/amdgpu: introduce a kind of halt state for amdgpu device

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 st

[PATCH 2/2] drm/amdgpu: add support for SMU debug option

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 enabled,

Re: [PATCH] drm/amdgpu: Handle fault with same timestamp

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 tr

Re: [PATCH V4 05/17] drm/amd/pm: do not expose those APIs used internally only in si_dpm.c

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) --- drivers/gpu/d

RE: [PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV

[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, Li

Re: [PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV

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

Re: [PATCH v3] drm/amdgpu: fix incorrect VCN revision in SRIOV

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 for

Re: [PATCH V4 09/17] drm/amd/pm: optimize the amdgpu_pm_compute_clocks() implementations

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) --- .../gpu/

Re: [PATCH V4 11/17] drm/amd/pm: correct the usage for amdgpu_dpm_dispatch_task()

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 --- drivers/gpu/drm/amd/pm/amdgpu_

Re: [PATCH V4 14/17] drm/amd/pm: relocate the power related headers

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 --- drivers/

Re: [PATCH] drm/amdgpu: don't skip runtime pm get on A+A config

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 conf

[PATCH v4 3/6] Documentation/gpu: Document pipe split visual confirmation

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(-) d

[PATCH v4 5/6] Documentation/gpu: Add basic overview of DC pipeline

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 | 4

[PATCH v4 4/6] Documentation/gpu: How to collect DTN log

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 i

[PATCH v4 0/6] Expand display core documentation

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, thi

[PATCH v4 6/6] Documentation/gpu: Add amdgpu and dc glossary

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 - Daniel:

[PATCH v2 00/10] drm/amd: fix various compilation warnings

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 wer

[PATCH v2 2/2] drm/amdgpu: Reduce SG bo memory usage for mGPUs

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 --- drivers/gpu/drm/amd/amdgpu/amdgpu_am

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

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 know.

RE: [PATCH v4 2/6] drm: improve drm_buddy_alloc function

[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; P

[PATCH v4 2/6] Documentation/gpu: Document amdgpu_dm_visual_confirm debugfs entry

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 ++

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

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 res

Re: [PATCH 1/2] drm/amdgpu: introduce a kind of halt state for amdgpu device

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.

Re: [PATCH] drm/amdgpu: don't skip runtime pm get on A+A config

[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 confi

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

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 case)

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

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 Rajn

[PATCH v2 03/10] drm/amdgpu: fix amdgpu_ras_mca_query_error_status scope

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 --- driv

[PATCH v2 06/10] drm/amd/display: fix function scopes

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 hw_internal_rev,

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

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 Popple

[PATCH v4 1/6] Documentation/gpu: Reorganize DC documentation

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 redu

[PATCH v2 10/10] drm/amdgpu: re-format file header comments

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 --- drivers/

Re: [PATCH 1/2] drm/amdgpu: introduce a kind of halt state for amdgpu device

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 ha

Re: [PATCH v2] drm/amdgpu: fix incorrect VCN revision in SRIOV

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: ri

Re: Reuse framebuffer after a kexec (amdgpu / efifb)

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 looped

[PATCH v2 1/2] drm/amdgpu: Detect if amdgpu in IOMMU direct map mode

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 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_devi

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

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

[PATCH 1/2] drm/amd/display: Reduce stack size for dml31_ModeSupportAndSystemConfigurationFull

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 ‘dml31_ModeSupportAndSyst

[PATCH 2/2] drm/amdgpu: Reserve Bad pages early for SRIOV VF

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 b/drivers/gpu/drm/amd/

[PATCH v2 09/10] drm/amdgpu: remove unnecessary variables

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 funct

Re: [PATCH v4 0/6] Expand display core documentation

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 document

RE: [PATCH v4 4/6] drm: implement a method to free unused pages

[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; Koeni

[PATCH 2/2] drm/amd/display: Reduce stack size for dml31 UseMinimumDCFCLK

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): ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c

[PATCH 1/2] drm/amdgpu: Separate vf2pf work item init from virt data exchange

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 time

Re: [PATCH v2 09/10] drm/amdgpu: remove unnecessary variables

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

[PATCH] drm/amdgpu: SRIOV flr_work should use down_write

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 +++-- 2

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

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 Al

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

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

Re: [PATCH v2 03/11] mm/gup: migrate PIN_LONGTERM dev coherent pages to system

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

Potential Bug in drm/amd/display/dc_link

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(),

Reuse framebuffer after a kexec (amdgpu / efifb)

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 d

[PATCH] drm/amdgpu: Fix reference leak in psp_xgmi_reflect_topology_info()

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() o

Re: [BUG] gpu: drm: amd: amdgpu: possible ABBA deadlock in amdgpu_set_power_dpm_force_performance_level() and amdgpu_debugfs_process_reg_op()

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()   mutex_loc

[PATCH] drm:amdgpu:remove unneeded variable

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(+),

Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC

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 filtering)

A Potential Bug in drm/amd/display/dc_link.c

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

Re: Reuse framebuffer after a kexec (amdgpu / efifb)

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 loo

Re: Reuse framebuffer after a kexec (amdgpu / efifb)

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

Re: Reuse framebuffer after a kexec (amdgpu / efifb)

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 a

RE: [PATCH] drm/amdgpu: SRIOV flr_work should use down_write

[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: Skvortso

Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process

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,   Felix

RE: [PATCH] drm/amdgpu: SRIOV flr_work should use down_write

[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 ; amd-gfx@

[PATCH] drm/amdkfd: add Navi2x to GWS init conditions

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 facc28f58

Re: [PATCH] drm/amdkfd: explicitly create/destroy queue attributes under /sys

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 lev

RE: [PATCH] drm/amdgpu: SRIOV flr_work should use down_write

[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 flr_work

RE: [PATCH] drm/amdkfd: add Navi2x to GWS init conditions

[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 wit

Re: [PATCH 1/2] drm/amdkfd: Use prange->list head for insert_list

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 insert_

Re: [PATCH 2/2] drm/amdkfd: Use prange->update_list head for remove_list

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 case

Re: Reuse framebuffer after a kexec (amdgpu / efifb)

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 the

Re: [PATCH v2 1/2] drm/amdgpu: Detect if amdgpu in IOMMU direct map mode

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 > -

Re: [bisected][regression] Applications that need amdgpu doesn't run after waking up from suspend

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 r

Re: [PATCH v4 0/6] Expand display core documentation

> 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 > > mu

[PATCH v2] drm/amdkfd: fix svm_bo release invalid wait context warning

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 ---

Re: [PATCH] drm/amdkfd: explicitly create/destroy queue attributes under /sys

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 inclu

Re: [PATCH] drm/amdkfd: explicitly create/destroy queue attributes under /sys

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 >>> entr

Re: [PATCH v2 2/2] drm/amdgpu: Reduce SG bo memory usage for mGPUs

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. > > Signed-of

Re: Potential Bug in drm/amd/display/dc_link

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 fi

  1   2   >