RE: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

See inline comments > -Original Message- > From: dri-devel On Behalf Of > zhuweixi > Sent: Thursday, November 30, 2023 5:48 AM > To: Christian König ; Zeng, Oak > ; Christian König ; linux- > m...@kvack.org; linux-ker...@vger.kernel.org; a...@linux-foundation.or

RE: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

Hi Weixi, Even though Christian has listed reasons rejecting this proposal (yes they are very reasonable to me), I would open my mind and further explore the possibility here. Since the current GPU driver uses a hmm based implementation (AMD and NV has done this; At Intel we are catching up),

Re: [PATCH 1/1] drm/amdkfd: make needs_pcie_atomics FW-version dependent

A nit-pick inline. Otherwise this patch is Reviewed-by: Oak Zeng Regards, Oak On 2021-08-31, 5:57 PM, "amd-gfx on behalf of Felix Kuehling" wrote: On some GPUs the PCIe atomic requirement for KFD depends on the MEC firmware version. Add a firmware version check for this. The

Re: [PATCH v6 05/13] drm/amdkfd: generic type as sys mem on migration to ram

Regards, Oak On 2021-08-16, 3:53 PM, "amd-gfx on behalf of Sierra Guiza, Alejandro (Alex)" wrote: On 8/15/2021 10:38 AM, Christoph Hellwig wrote: > On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote: >> migrate.vma = vma; >> migrate.start =

Re: [PATCH v4 06/13] include/linux/mm.h: helpers to check zone device generic type

Regards, Oak On 2021-07-17, 3:22 PM, "amd-gfx on behalf of Alex Sierra" wrote: Two helpers added. One checks if zone device page is generic type. The other if page is either private or generic type. Signed-off-by: Alex Sierra --- include/linux/mm.h | 8

Re: [PATCH 1/1] drm/amdgpu: Use spinlock_irqsave for pasid_lock

Reviewed-by: Oak Zeng Regards, Oak On 2021-06-14, 6:07 PM, "amd-gfx on behalf of Felix Kuehling" wrote: This should fix a kernel LOCKDEP warning on Vega10: [ 149.416604] [ 149.420877] WARNING: inconsistent lock state [ 149.425152]

Re: [PATCH v2 1/1] drm/amdkfd: use allowed domain for vmbo validation

Hi Nirmoy, Why keep a unused parameter: +static int amdgpu_amdkfd_validate_vm_bo(void *_unused. When I looked the codes, the only logic change is the validate page table bo in allowed_domain instead of vram domain. Can you explain why validate page table bo in vram domain cause a problem?

Re: [PATCH v2 3/3] drm/amdgpu: Workaround IOMMU driver bug

[Public] Reviewed-by: oak zeng Get Outlook for Android From: amd-gfx on behalf of Felix Kuehling Sent: Friday, May 21, 2021 9:47:17 AM To: Christian König ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH v2 3/3] drm/amdgpu:

Re: [PATCH 0/2] Use MTYPE_NC for coarse-grain remote memory

This series is Reviewed-by: Oak Zeng Regards, Oak On 2021-05-10, 7:36 PM, "amd-gfx on behalf of Felix Kuehling" wrote: These patches are the result of deliberations with multiple AMD SW and HW teams with the goal of improving Aldebaran performance and harmonizing the

Re: [PATCH] drm/amdgpu: Quit RAS initialization earlier if RAS is disabled

ng -Original Message----- From: Zeng, Oak Sent: Friday, May 7, 2021 09:15 To: amd-gfx@lists.freedesktop.org Cc: Zhang, Hawking ; Lazar, Lijo ; Clements, John ; Joshi, Mukul ; Zeng, Oak Subject: [PATCH] drm/amdgpu: Quit RAS initialization earlier if RAS is disabled

Re: [PATCH] drm/amdkfd: add ACPI SRAT parsing for topology

2021-05-03 2:43 p.m., Zeng, Oak wrote: > I feel such parsing work should be part of the ACPI generic work so should be done in drivers/acpi/num/srat.c (see acpi_table_parse_srat) and the acpi subsystem should expose APIs for rest drivers to query such numa information. > >

Re: [PATCH] drm/amdkfd: fix no atomics settings in the kfd topology

Reviewed-by: Oak Zeng Regards, Oak On 2021-05-03, 3:49 PM, "amd-gfx on behalf of Jonathan Kim" wrote: To account for various PCIe and xGMI setups, check the no atomics settings for a device in relation to every direct peer. v2: apply suggested clean ups in main loop.

Re: [PATCH] drm/amdkfd: add ACPI SRAT parsing for topology

I feel such parsing work should be part of the ACPI generic work so should be done in drivers/acpi/num/srat.c (see acpi_table_parse_srat) and the acpi subsystem should expose APIs for rest drivers to query such numa information. Regards, Oak On 2021-04-28, 11:12 AM, "amd-gfx on behalf of

Re: [PATCH 1/1] drm/amdkfd: Make svm_migrate_put_sys_page static

Reviewed-by: Oak Zeng Regards, Oak On 2021-04-30, 5:10 AM, "amd-gfx on behalf of Felix Kuehling" wrote: This function is only used in this source file. Reported-by: kernel test robot Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2

Re: [PATCH] drm/amdkfd: report atomics support in io_links over xgmi

;Kuehling, Felix" wrote: Am 2021-04-29 um 9:12 p.m. schrieb Zeng, Oak: > I think part of this can be done more clean in amdgpu_device_init: > > r = 0; > If (!adev->gmc.xgmi.connected_to_cpu) > /* enable PCIE a

Re: [PATCH] drm/amdkfd: report atomics support in io_links over xgmi

I think part of this can be done more clean in amdgpu_device_init: r = 0; If (!adev->gmc.xgmi.connected_to_cpu) /* enable PCIE atomic ops */ r = pci_enable_atomic_ops_to_root(adev->pdev,

Re: [PATCH] drm/amdgpu: fix no full coverage issue for gprs initialization

Hi Dennis, Should we check in the compute shader source codes? I only saw the shader binaries. This will be helpful if people want to modify those shaders/fix issues. The source code can be in a comment section above the binary. Regards, Oak On 2021-04-27, 11:31 AM, "amd-gfx on behalf of

Re: [PATCH v2 00/10] Implement multi-GPU DMA mappings for KFD

This series is Acked-by: Oak Zeng Regards, Oak On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling" wrote: This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Regards, Oak On 2021-04-26, 11:56 PM, "Kuehling, Felix" wrote: Am 2021-04-26 um 8:35 p.m. schrieb Zeng, Oak: > Regards, > Oak > > > > On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling" wrote: >

Re: [PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs

Regards, Oak On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling" wrote: Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +

Re: [PATCH v2 06/10] drm/amdgpu: DMA map/unmap when updating GPU mappings

Regards, Oak On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling" wrote: DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called with the BO and page tables reserved, so we can safely update the DMA mapping. DMA unmap when a BO is unmapped

Re: [PATCH v2 05/10] drm/amdgpu: Add multi-GPU DMA mapping helpers

As I understand it, when one GPU map another GPU's vram, this vram should also be mapped in iommu page table. Also normal GTT memory (versus userptr) also need to be mapped in iommu. But don't see this code below. I only see you map userptr in iommu. Maybe you map them in iommu not during

Re: [PATCH v2 04/10] drm/amdgpu: Simplify AQL queue mapping

Regards, Oak On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling" wrote: Do AQL queue double-mapping with a single attach call. That will make it easier to create per-GPU BOs later, to be shared between the two BO VA mappings on the same GPU. Freeing the

Re: [PATCH 1/4] drm/amdgpu: Macros for vram physical addr calculation

[AMD Official Use Only - Internal Distribution Only] Ping, can someone help review this series? Regards, Oak On 2021-03-25, 12:38 PM, "Zeng, Oak" wrote: Add one macro to calculate BO's GPU physical address. And another one to calculate BO's CPU physical address.

Re: [PATCH 2/2] drm/amdgpu: Introduce new SETUP_TMR interface

m: amd-gfx On Behalf Of Zeng, Oak Sent: Monday, March 22, 2021 7:33 PM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Zhang, Hawking Subject: Re: [PATCH 2/2] drm/amdgpu: Introduce new SETUP_TMR interface [AMD Official Use Only - Internal Distribution Only] [AMD Of

Re: [PATCH 2/2] drm/amdgpu: Introduce new SETUP_TMR interface

[AMD Official Use Only - Internal Distribution Only] Hello all, Can someone help to review below patches? We verified with firmware team and want to check-in together with psp firmware Regards, Oak On 2021-03-12, 4:24 PM, "Zeng, Oak" wrote: This new interface passes bo

Re: [PATCH] drm/amdgpu/ttm: fix ifdefs for non-x86

[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Oak Zeng Regards, Oak On 2021-03-15, 3:39 PM, "amd-gfx on behalf of Alex Deucher" wrote: The else clause needs to be CONFIG_64BIT not CONFIG_X86. Fixes: e98f250bddb5 ("drm/amdgpu: fix compile error on

Re: [PATCH] drm/amdgpu: Mark mmhub_v1_7_setup_vm_pt_regs() as static

[AMD Official Use Only - Internal Distribution Only] Thank you Joarder for the fix. But this has already been fixed in our Alex's drm-next branch. Regards, Oak On 2021-03-12, 5:19 PM, "Souptick Joarder" wrote: Kernel test robot throws below warning ->

RE: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

: Christian König Sent: Wednesday, March 3, 2021 5:46 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Daniel Vetter ; Dave Airlie ; Thomas Hellström (Intel) ; dan.j.willi...@intel.com Cc: kbuild-...@lists.01.org; Kuehling, Felix ; Kasiviswanathan, Harish ; Deucher

RE: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting

: Zeng, Oak ; kbuild-...@lists.01.org; Kuehling, Felix ; Kasiviswanathan, Harish ; Deucher, Alexander ; Huang, JinHuiEric ; Koenig, Christian Subject: Re: [PATCH] drm/ttm: ioremap buffer according to TTM mem caching setting Hi guys, adding the usual suspects direct. Does anybody of hand know

RE: [PATCH 1/8] drm/amdgpu: new resource cursor

[AMD Official Use Only - Internal Distribution Only] Very nice cleaning! Series is Acked-by: Oak Zeng Regards, Oak > -Original Message- > From: amd-gfx On Behalf Of > Christian König > Sent: Wednesday, February 17, 2021 2:00 PM > To: Errabolu, Ramesh ; amd- >

RE: [PATCH] drm/amdgpu: use function pointer for gfxhub functions

= gfxhub_v1_0_set_fault_enable_default, + .init = gfxhub_v1_0_init, +}; Regards, Oak From: amd-gfx On Behalf Of Zeng, Oak Sent: Monday, September 28, 2020 5:52 PM To: Ernst Sjöstrand ; Deucher, Alexander ; Koenig, Christian Cc: amd-gfx mailing list Subject: RE: [PATCH] drm/amdgpu: use function pointer

RE: [PATCH] drm/amdgpu: use function pointer for gfxhub functions

stian.koe...@amd.com> what do you think? Can you guys help to review this patch? Thanks Regards, Oak From: Ernst Sjöstrand Sent: Friday, September 18, 2020 5:03 AM To: Zeng, Oak Cc: amd-gfx mailing list ; Deucher, Alexander ; Koenig, Christian Subject: Re: [PATCH] drm/amdgpu: use func

RE: [PATCH] drm/amdgpu: Use function pointer for some mmhub functions

[AMD Official Use Only - Internal Distribution Only] Alex, Yes I saw the same clean up for gfxhub. Will do it when I get a chance. Regards, Oak -Original Message- From: Alex Deucher Sent: Tuesday, August 11, 2020 2:56 PM To: Zeng, Oak Cc: amd-gfx list ; Deucher, Alexander Subject

RE: [Patch v2 3/4] drm/amdkfd: refactor runtime pm for baco

[AMD Official Use Only - Internal Distribution Only] Hi Alex, I am trying to understand why prevent runtime pm when xgmi is active. Is it because other device's accessing suspended device's HBM? Here is my understanding: after device is suspend, the DF and HBM will still be alive. So as long

RE: [Patch v2 3/4] drm/amdkfd: refactor runtime pm for baco

[AMD Official Use Only - Internal Distribution Only] Patch 1,2,3 work for me. See one comment inline, otherwise Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Rajneesh Bhardwaj Sent: Friday, January 31, 2020 10:37 PM To:

RE: [Patch v1 5/5] drm/amdkfd: refactor runtime pm for baco

[AMD Official Use Only - Internal Distribution Only] Hi Felix, See one inline comment Regards, Oak -Original Message- From: amd-gfx On Behalf Of Felix Kuehling Sent: Thursday, January 30, 2020 6:24 PM To: Alex Deucher Cc: Deucher, Alexander ; Bhardwaj, Rajneesh ; amd-gfx list

RE: [Patch v1 5/5] drm/amdkfd: refactor runtime pm for baco

[AMD Official Use Only - Internal Distribution Only] Regards, Oak -Original Message- From: amd-gfx On Behalf Of Rajneesh Bhardwaj Sent: Monday, January 27, 2020 8:29 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Kuehling, Felix ; Bhardwaj, Rajneesh Subject: [Patch

RE: [PATCH] drm/amdgpu: initialize bo_va_list when add gws to process

[AMD Official Use Only - Internal Distribution Only] Thanks for the catch. Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: Pan, Xinhui Sent: Tuesday, January 21, 2020 10:10 PM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Zeng, Oak Subject: [PATCH] drm

RE: [PATCH 3/3] drm/amdgpu: Improve Vega20 XGMI TLB flush workaround

[AMD Official Use Only - Internal Distribution Only] Hi Felix/Shaoyun, Is this HW issue fixed on MI100? Regards, Oak -Original Message- From: amd-gfx On Behalf Of Felix Kuehling Sent: Friday, January 17, 2020 8:38 PM To: amd-gfx@lists.freedesktop.org Cc: Liu, Shaoyun Subject: [PATCH

RE: [PATCH 2/3] drm/amdgpu: Use the correct flush_type in flush_gpu_tlb_pasid

[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Felix Kuehling Sent: Friday, January 17, 2020 8:38 PM To: amd-gfx@lists.freedesktop.org Subject: [PATCH 2/3] drm/amdgpu: Use the correct flush_type in

RE: [PATCH 4/4] drm/amdkfd: Avoid hanging hardware in stop_cpsch

[AMD Official Use Only - Internal Distribution Only] I see. Thank you Felix for the explanation. Regards, Oak -Original Message- From: Kuehling, Felix Sent: Friday, December 20, 2019 12:28 PM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 4/4] drm/amdkfd: Avoid

RE: [PATCH 4/4] drm/amdkfd: Avoid hanging hardware in stop_cpsch

[AMD Official Use Only - Internal Distribution Only] Regards, Oak -Original Message- From: amd-gfx On Behalf Of Felix Kuehling Sent: Friday, December 20, 2019 3:30 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH 4/4] drm/amdkfd: Avoid hanging hardware in stop_cpsch Don't use

RE: [PATCH 3/4] drm/amdkfd: Improve HWS hang detection and handling

[AMD Official Use Only - Internal Distribution Only] With this improvement, it is still possible that two reset be scheduled. There is a period of time after HWS hang and before kfd pre-reset is called, during which, if a thread already passed the is_hws_hang check but was scheduled out, then

RE: [PATCH 2/3] drm/amdgpu/pm_runtime: update usage count in fence handling

[AMD Official Use Only - Internal Distribution Only] Regards, Oak -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Monday, December 16, 2019 3:25 PM To: Alex Deucher ; Koenig, Christian Cc: Deucher, Alexander ; amd-gfx list Subject: Re: [PATCH 2/3]

RE: [PATCH 2/3] drm/amdgpu: explicitely sync to VM updates

[AMD Official Use Only - Internal Distribution Only] Regards, Oak -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Wednesday, December 4, 2019 10:38 AM To: amd-gfx@lists.freedesktop.org; Kuehling, Felix ; Yang, Philip Subject: [PATCH 2/3] drm/amdgpu: explicitely

RE: Deadlock on PTEs update for HMM

[AMD Official Use Only - Internal Distribution Only] Is kmalloc with GFP_NOWAIT an option here? Regards, Oak From: amd-gfx On Behalf Of Sierra Guiza, Alejandro (Alex) Sent: Wednesday, November 27, 2019 9:55 AM To: Koenig, Christian ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org

RE: [PATCH] drm/amdgpu: Apply noretry setting for gfx10 and mmhub9.4

22, 2019 3:51 PM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Cornwall, Jay Subject: Re: [PATCH] drm/amdgpu: Apply noretry setting for gfx10 and mmhub9.4 On 2019-11-22 3:23 p.m., Oak Zeng wrote: > Config the translation retry behavior according to noretry kernel > parameter > &g

RE: [PATCH] drm/amdkfd: DIQ should not use HIQ way to allocate memory

Thanks for capture this. This is something I forget to do when I re-orged the mqd manager codes. Reviewed-by: Oak Zeng Oak -Original Message- From: amd-gfx On Behalf Of Yong Zhao Sent: Friday, November 15, 2019 11:09 AM To: amd-gfx@lists.freedesktop.org Cc: Zhao, Yong Subject

RE: 答复: [PATCH 1/2] drm/amdgpu: invalidate mmhub semphore workaround in amdgpu_virt

Thank you Christian. Maybe in the future we can make the invalidation ack to be interrupt based instead of polling. Regards, Oak -Original Message- From: Koenig, Christian Sent: Wednesday, November 20, 2019 10:14 AM To: Zeng, Oak ; Liu, Monk ; Zhu, Changfeng ; Xiao, Jack ; Zhou1, Tao

RE: 答复: [PATCH 1/2] drm/amdgpu: invalidate mmhub semphore workaround in amdgpu_virt

See an inline comment Regards, Oak -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Wednesday, November 20, 2019 8:21 AM To: Liu, Monk ; Zhu, Changfeng ; Xiao, Jack ; Zhou1, Tao ; Huang, Ray ; Huang, Shimmer ; amd-gfx@lists.freedesktop.org Subject: Re: 答复: [PATCH

RE: [PATCH] amd/amdgpu: force to trigger a no-retry-fault after a retry-fault

. Regards, Oak -Original Message- From: Christian König Sent: Monday, November 18, 2019 8:47 AM To: Zeng, Oak ; Yang, Philip ; Sierra Guiza, Alejandro (Alex) ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] amd/amdgpu: force to trigger a no-retry-fault after a retry-fault Hi Oak, well

RE: [PATCH] amd/amdgpu: force to trigger a no-retry-fault after a retry-fault

Hi Philip/Alex, I found I can't understand this patch without more details in the commit message. Is this preparation work for the page migration? Why setting the translation further bit can force a no-retry-fault? Won't setting this bit cause UTCL2 treat the PTE as a PDE and continue to walk

RE: [PATCH] drm/amdgpu: Add comments to gmc structure

: Thursday, November 7, 2019 12:16 PM To: Alex Deucher ; Zeng, Oak Cc: Kuehling, Felix ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: Add comments to gmc structure If this is not submitted, I would like to see some comments regarding the explanation of MC address

RE: [PATCH] drm/amdgpu: Add comments to gmc structure

Thanks Alex. > AGP is also used for page tables in system memory. I am not aware of this usage. I thought page table are all in frame buffer today. Was this a use case in old asics? Oak -Original Message- From: Alex Deucher Sent: Wednesday, November 6, 2019 12:37 PM To: Zeng,

[PATCH] drm/amdgpu: Add comments to gmc structure

Explain fields like aper_base, agp_start etc. The definition of those fields are confusing as they are from different view (CPU or GPU). Add comments for easier understand. Change-Id: I02c2a27cd0dbc205498eb86aafa722f2e0c25fe6 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h |

[PATCH] drm/amdgpu: Add comments to gmc structure

Explain fields like aper_base, agp_start etc. The definition of those fields are confusing as they are from different view (CPU or GPU). Add comments for easier understand. Change-Id: I02c2a27cd0dbc205498eb86aafa722f2e0c25fe6 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h |

RE: Stack out of bounds in KFD on Arcturus

: Grodzovsky, Andrey Sent: Tuesday, October 22, 2019 1:28 PM To: Zeng, Oak ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: Stack out of bounds in KFD on Arcturus I don't know - what Kconfig flag should I look at ? Andrey On 10/22/19 1:17 PM, Zeng, Oak wrote: > Sorry I meant is the ker

RE: Stack out of bounds in KFD on Arcturus

Sorry I meant is the kernel stack size 16KB in your kconfig? Oak -Original Message- From: Grodzovsky, Andrey Sent: Tuesday, October 22, 2019 12:49 PM To: Zeng, Oak ; Kuehling, Felix Cc: amd-gfx@lists.freedesktop.org Subject: Re: Stack out of bounds in KFD on Arcturus On 10/18/19 5:31

RE: [PATCH] drm/amdkfd: don't use dqm lock during device reset/suspend/resume

If we decline the queue creation request in suspend state by returning -EAGAIN, then this approach works for both hws and non-hws. This way the driver is clean but application need to re-create queue later when it get a EAGAIN. Currently application is not aware of the suspend/resume state, so

RE: [PATCH] drm/amdkfd: don't use dqm lock during device reset/suspend/resume

Nice fix. Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Yang, Philip Sent: Monday, October 21, 2019 5:05 PM To: amd-gfx@lists.freedesktop.org Cc: Yang, Philip Subject: [PATCH] drm/amdkfd: don't use dqm lock during device reset/suspend/resume If

RE: [PATCH v2] drm/amdkfd: kfd open return failed if device is locked

In current implementation, even dqm is stopped, user can still create (and start) new queue. This is not correct. We should forbid user create/start new queue if dqm is stopped - stop means stopping the current executing queues and stop receiving new creating request. Regards, Oak

RE: [PATCH] drm/amdgpu: disable c-states on xgmi perfmons

Is it the design that we have to disable cstate before r/w df, or this is only a workaround? - in this case we need to work with df to figure out the root cause of the hang. Regards, Oak -Original Message- From: amd-gfx On Behalf Of Kim, Jonathan Sent: Wednesday, October 16, 2019

[PATCH 2/2] drm/amdgpu: Enable gfx cache probing on HDP write for arcturus

This allows gfx cache to be probed and invalidated (for none-dirty cache lines) on a HDP write (from either another GPU or CPU). This should work only for the memory mapped as RW memory type newly added for arcturus, to achieve some cache coherence b/t multiple memory clients. Change-Id:

[PATCH 1/2] drm/amdgpu: Clean up gmc_v9_0_gart_enable

Many logic in this function are HDP set up, not gart set up. Moved those logic to gmc_v9_0_hw_init. No functional change. Change-Id: Ib00cc1ffd1e486e77571796dce53aa7506c0c55f Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 82 +-- 1 file

RE: [PATCH] drm/amdgpu: Enable gfx cache probing on HDP write for arcturus

Agreed. I will move none gart logic from gmc_v9_0_gart_enable to gmc_v9_0_hw_init Regards, Oak -Original Message- From: Kuehling, Felix Sent: Friday, October 4, 2019 11:03 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Koenig, Christian Subject: Re: [PATCH] drm/amdgpu: Enable

RE: [PATCH] drm/amdgpu: Enable gfx cache probing on HDP write for arcturus

Ping... Regards, Oak -Original Message- From: Zeng, Oak Sent: Thursday, September 19, 2019 5:17 PM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Koenig, Christian ; Zeng, Oak Subject: [PATCH] drm/amdgpu: Enable gfx cache probing on HDP write for arcturus This allows gfx

[PATCH 1/2] drm/amdkfd: Fix MQD size calculation

On device initialization, a trunk of GTT memory is pre-allocated for HIQ and all SDMA queues mqd. The size of this allocation was wrong. The correct sdma engine number should be PCIe-optimized SDMA engine number plus xgmi SDMA engine number. Change-Id: Iecd11ae4f5a314591566772aa2a23e1fe4b94275

[PATCH 2/2] drm/amdkfd: Print more sdma engine hqds in debug fs

Previously only PCIe-optimized SDMA engine hqds were exposed in debug fs. Print all SDMA engine hqds. Change-Id: I03756fc0fa99169d88e265560f505ed186242b02 Reported-by: Jonathan Kim Signed-off-by: Jonathan Kim Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c |

[PATCH] drm/amdgpu: Enable gfx cache probing on HDP write for arcturus

This allows gfx cache to be probed and invalidated (for none-dirty cache lines) on a HDP write (from either another GPU or CPU). This should work only for the memory mapped as RW memory type newly added for arcturus, to achieve some cache coherence b/t multiple memory clients. Change-Id:

RE: [PATCH 9/9] drm/amdgpu: add graceful VM fault handling v2

Regards, Oak -Original Message- From: Koenig, Christian Sent: Monday, September 9, 2019 1:14 PM To: Zeng, Oak ; Kuehling, Felix ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 9/9] drm/amdgpu: add graceful VM fault handling v2 > Well first of all we are not in interrupt cont

RE: [PATCH 9/9] drm/amdgpu: add graceful VM fault handling v2

Is looking up vm twice necessary? I think we are in interrupt context, is it possible that the user space application can be switched in between? My understanding is, if user space application is can't kick in during interrupt handling, application shouldn't have chance to exit (then their vm

RE: [PATCH 2/2] drm/amdgpu: Disable page faults while reading user wptrs

Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Kuehling, Felix Sent: Friday, August 30, 2019 1:15 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH 2/2] drm/amdgpu: Disable page faults while reading user wptrs These wptrs must be pinned and GPU

RE: [PATCH 1/2] drm/amdgpu: cleanup mtype mapping

This is nice clean up. Acked-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Monday, September 2, 2019 10:58 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH 1/2] drm/amdgpu: cleanup mtype mapping Unify how we map the UAPI flags to

RE: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub

Ping this series. @Koenig, Christian do you have more comments on this? Regards, Oak -Original Message- From: Zeng, Oak Sent: Friday, August 9, 2019 12:22 AM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Koenig, Christian ; Zhou1, Tao ; Zeng, Oak Subject: [PATCH 1/2] drm

RE: [PATCH 4/5] drm/amdgpu: Support snooped PTE flag

Regards, Oak -Original Message- From: Koenig, Christian Sent: Friday, August 9, 2019 8:31 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Keely, Sean Subject: Re: [PATCH 4/5] drm/amdgpu: Support snooped PTE flag Am 09.08.19 um 04:15 schrieb Zeng, Oak: >

RE: [PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time

Regards, Oak -Original Message- From: Koenig, Christian Sent: Friday, August 9, 2019 8:31 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Keely, Sean Subject: Re: [PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time Am 09.08.19 um

RE: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

Regards, Oak -Original Message- From: Koenig, Christian Sent: Friday, August 9, 2019 8:29 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Keely, Sean Subject: Re: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions Am 09.08.19 um 04:15 schrieb Zeng, Oak

[PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub

This is for kfd to reuse amdgpu TLB invalidation function. On gfx10, kfd only needs to flush TLB on gfx hub but not on mm hub. So export a function for KFD flush TLB only on specific hub. Change-Id: I58ff00969f88438cfd3dc7e9deb7bff0c1bb4133 Signed-off-by: Oak Zeng ---

[PATCH 2/2] drm/amdkfd/gfx10: Calling amdgpu functions to invalidate TLB

Calling amdgpu function to invalidate TLB, instead of using a kfd implementation. Delete the kfd local TLB invalidation implementation. Change-Id: Ia16fcf9091a93b8c0acdaf9981f8a5a1f9a5ca1d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 41 ++

[PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time

Some mapping flags are decided by memory mapping destination which is not know at memory object allocation time. So it is reasonable to decide memory mapping flags at mapping time, instead of alloc time. Record memory allocation flags during allocation time and calculate mapping flags during

[PATCH 5/5] amd/amdgpu: Introduce new page mapping scheme for arcturus

The new memory mapping scheme is: For vram: Fine-grain coherency: local CC and remote UC, with snoop. Coarse-grain coherency: local RW and remote UC, with snoop. For host memory (not changed) Fine-grain coherency: UC Coarse-grain coherency: NC Change-Id: I6a071249f953cbed813bfd953b6a2e0826f54f86

[PATCH 2/5] drm/amdgpu: Support new arcturus mtype

Arcturus repurposed mtype WC to RW. Modify gmc functions to support the new mtype Change-Id: Idc338e5386a57020f45262025e2664ab4ba9f291 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ drivers/gpu/drm/amd/include/vega10_enum.h | 1 + 2 files changed, 4 insertions(+)

[PATCH 4/5] drm/amdgpu: Support snooped PTE flag

Set snooped PTE flag according to mapping flag. Write request to a page with snooped bit set, will send out invalidate probe request to TCC of the remote GPU where the vram page resides. Change-Id: I799f68ec7a5a1abf32075f5ef31051641a0b3736 Signed-off-by: Oak Zeng ---

[PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

Add definition of all supported mtypes. The RW mtype is recently introduced for arcturus. Also add definition of a flag to probe and possibly invalidate remote GPU cache, which will be used later in this series. Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d Signed-off-by: Oak Zeng ---

RE: [PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time

Hi Felix/Sean, See one comment inline [Oak] Regards, Oak -Original Message- From: Kuehling, Felix Sent: Wednesday, August 7, 2019 12:05 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Koenig, Christian ; Keely, Sean Subject: Re: [PATCH 3/5] drm/amdkfd: Postpone memory mapping

RE: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

+@Mirza, Jimshed<mailto:jimshed.mi...@amd.com>: do we have the ability to snoop another GPU's cache, in a multiple GPU system? Regards, Oak From: Deucher, Alexander Sent: Thursday, August 8, 2019 12:10 PM To: Zeng, Oak ; Koenig, Christian ; amd-gfx@lists.freedesktop.org Cc: Kuehling,

RE: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

König Sent: Wednesday, August 7, 2019 4:42 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Koenig, Christian ; Keely, Sean Subject: Re: [PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions Am 07.08.19 um 04:31 schrieb Zeng, Oak: > Add definition of all supported mty

RE: [PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS"

Acked-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Alex Deucher Sent: Wednesday, August 7, 2019 11:01 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject: [PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS" This reverts commit

RE: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub

for 14. Regards, Oak -Original Message- From: Christian König Sent: Wednesday, August 7, 2019 4:51 AM To: Zeng, Oak ; Kuehling, Felix ; Koenig, Christian ; amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Deucher, Alexander Cc: Zhou1, Tao ; Liu, Shaoyun Subject: Re: [PATCH 1/2] drm

RE: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub

5, 2019 5:37 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Zhou1, Tao ; Liu, Shaoyun Subject: Re: [PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub Am 02.08.19 um 18:04 schrieb Zeng, Oak: > This is for kfd to reuse amdgpu TLB invalidation function. T

[PATCH 4/5] drm/amdgpu: Support snooped PTE flag

Set snooped PTE flag according to mapping flag Change-Id: I799f68ec7a5a1abf32075f5ef31051641a0b3736 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c

[PATCH 5/5] amd/amdgpu: Introduce new page mapping scheme for arcturus

The new memory mapping scheme is: Fine-grain coherency: local CC and remote UC, with snoop. Coarse-grain coherency: local RW and remote UC, with snoop. Change-Id: I6a071249f953cbed813bfd953b6a2e0826f54f86 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 +

[PATCH 1/5] drm/amdgpu: Extends amdgpu vm definitions

Add definition of all supported mtypes. The RW mtype is recently introduced for arcturus. Also add definition for the cachable/snoopable bit, which will be used later in this series. Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d Signed-off-by: Oak Zeng ---

[PATCH 2/5] drm/amdgpu: Support new arcturus mtype

Arcturus repurposed mtype WC to RW. Modify gmc functions to support the new mtype Change-Id: Idc338e5386a57020f45262025e2664ab4ba9f291 Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 61 ++- drivers/gpu/drm/amd/include/vega10_enum.h | 7

[PATCH 3/5] drm/amdkfd: Postpone memory mapping flags calculation to mapping time

Some mapping flags are decided by memory mapping destination which is not know at memory object allocation time. So it is reasonable to decide memory mapping flags at mapping time, instead of alloc time. Record memory allocation flags during allocation time and calculate mapping flags during

[PATCH 2/2] drm/amdkfd/gfx10: Calling amdgpu functions to invalidate TLB

Calling amdgpu function to invalidate TLB, instead of using a kfd implementation. Delete the kfd local TLB invalidation implementation. Change-Id: Ia16fcf9091a93b8c0acdaf9981f8a5a1f9a5ca1d Signed-off-by: Oak Zeng --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 41 ++

[PATCH 1/2] drm/amdgpu: Export function to flush TLB of specific vm hub

This is for kfd to reuse amdgpu TLB invalidation function. There is already a gmc function flush_gpu_tlb to flush TLB on all vm hub. On gfx10, kfd only needs to flush TLB on gfx hub but not on mm hub. So export a function for KFD flush TLB only on gfx hub. Change-Id:

RE: [PATCH 1/1] drm/amdkfd: Remove unused variable

Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: amd-gfx On Behalf Of Kuehling, Felix Sent: Wednesday, July 3, 2019 10:51 AM To: amd-gfx@lists.freedesktop.org Cc: Kuehling, Felix ; Xiao, Jack Subject: [PATCH 1/1] drm/amdkfd: Remove unused variable Fix an obvious compiler

RE: [PATCH 1/2] drm/amdkfd: Add chained_runlist_idle_disable flag to pm4_mes_runlist

Series is Reviewed-by: Oak Zeng Regards, Oak -Original Message- From: Kuehling, Felix Sent: Friday, June 21, 2019 3:34 AM To: Zeng, Oak ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH 1/2] drm/amdkfd: Add chained_runlist_idle_disable flag to pm4_mes_runlist Yes. MEC firmware

  1   2   3   >