RE: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov

2020-06-10 Thread Deng, Emily
[AMD Official Use Only - Internal Distribution Only] Hi Evan, The multiple vf detect is amdgpu_device_ip_init. Best wishes Emily Deng >-Original Message- >From: Quan, Evan >Sent: Thursday, June 11, 2020 12:41 PM >To: Deng, Emily ; amd-gfx@lists.freedesktop.org >Cc: Deng, Emily

RE: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov

2020-06-10 Thread Quan, Evan
[AMD Official Use Only - Internal Distribution Only] Can this be moved to smu_early_init()? Or just do not adding the SMU ip for multiple vf sriov? Evan -Original Message- From: amd-gfx On Behalf Of Emily Deng Sent: Tuesday, June 2, 2020 8:40 PM To: amd-gfx@lists.freedesktop.org Cc:

Re: [PATCH] drm/amdgpu: Reconfigure ULV for gfx9 server SKUs

2020-06-10 Thread Zhang, Hawking
Reviewed-by: Hawking Zhang Regards, Hawking Sent from my iPhone > On Jun 11, 2020, at 07:22, Joseph Greathouse > wrote: > > SDMA ULV can benefit low-power modes, but can sometimes cause > latency increases in small SDMA transfers. Server SKUs have a > different trade-off space in this

RE: [PATCH] drm/amdgpu/sriov: Add clear vf fw support

2020-06-10 Thread Liu, Monk
Ack-by: Monk.liu _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: amd-gfx On Behalf Of Emily Deng Sent: Thursday, June 11, 2020 10:29 AM To: amd-gfx@lists.freedesktop.org Cc: Deng, Emily Subject: [PATCH] drm/amdgpu/sriov: Add clear

RE: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov

2020-06-10 Thread Liu, Monk
Ack-by: Monk.liu _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: amd-gfx On Behalf Of Emily Deng Sent: Tuesday, June 2, 2020 8:40 PM To: amd-gfx@lists.freedesktop.org Cc: Deng, Emily Subject: [PATCH] drm/amdgpu/sriov: Disable pm

[PATCH] drm/amdgpu/sriov: Add clear vf fw support

2020-06-10 Thread Emily Deng
Guest VM issue the PSP clear_vf_fw command at 2 points: 1.On VF driver loading, after VF message PSP to setup rings, the next command is “clear_vf_fw” 2.On VF driver unload before VF message to destroy rings Change-Id: Ia31add38a69037d1cbbf9b48ad827fa63b4860f7 Signed-off-by: Emily Deng ---

RE: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov

2020-06-10 Thread Deng, Emily
[AMD Official Use Only - Internal Distribution Only] Hi Monk, Could you help to review this patch for multiple vf? Best wishes Emily Deng >-Original Message- >From: Deng, Emily >Sent: Wednesday, June 10, 2020 7:01 PM >To: Deng, Emily ; amd-gfx@lists.freedesktop.org >Cc: Min,

[PATCH] drm/amdgpu: Reconfigure ULV for gfx9 server SKUs

2020-06-10 Thread Joseph Greathouse
SDMA ULV can benefit low-power modes, but can sometimes cause latency increases in small SDMA transfers. Server SKUs have a different trade-off space in this domain, so this configures the server SKUs' ULV hysteresis times differently than consumer SKUs'. Signed-off-by: Joseph Greathouse

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Andrey Grodzovsky
On 6/10/20 4:30 PM, Thomas Hellström (Intel) wrote: On 6/10/20 5:30 PM, Daniel Vetter wrote: On Wed, Jun 10, 2020 at 04:05:04PM +0200, Christian König wrote: Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky: On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: On 6/9/20 7:21 PM, Koenig,

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Daniel Vetter
On Wed, Jun 10, 2020 at 10:30 PM Thomas Hellström (Intel) wrote: > > > On 6/10/20 5:30 PM, Daniel Vetter wrote: > > On Wed, Jun 10, 2020 at 04:05:04PM +0200, Christian König wrote: > >> Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky: > >>> > >>> On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote:

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Intel
On 6/10/20 5:30 PM, Daniel Vetter wrote: On Wed, Jun 10, 2020 at 04:05:04PM +0200, Christian König wrote: Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky: On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: On 6/9/20 7:21 PM, Koenig, Christian wrote: Am 09.06.2020 18:37 schrieb

[PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release

2020-06-10 Thread Daniel Vetter
fs_reclaim_acquire/release nicely catch recursion issues when allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend to use to keep the excessive caches in check). For mmu notifier recursions we do have lockdep annotations since 23b68395c7c7 ("mm/mmu_notifiers: add a lockdep map

Re: [PATCH v2] drm/amdgpu: Fix a buffer overflow handling the serial number

2020-06-10 Thread Alex Deucher
On Wed, Jun 10, 2020 at 6:57 AM Quan, Evan wrote: > > [AMD Official Use Only - Internal Distribution Only] > > Reviewed-by: Evan Quan Applied. Thanks! Alex > > -Original Message- > From: Dan Carpenter > Sent: Wednesday, June 10, 2020 4:57 PM > To: Deucher, Alexander > Cc: Koenig,

Re: [PATCH] drm/amdgpu/jpeg: fix race condition issue for jpeg start

2020-06-10 Thread Nirmoy
Acked-by: Nirmoy Das On 6/10/20 6:36 PM, James Zhu wrote: Fix race condition issue when multiple jpeg starts are called. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 16 drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 2 ++ 2 files changed, 14

[PATCH] drm/amdgpu/jpeg: fix race condition issue for jpeg start

2020-06-10 Thread James Zhu
Fix race condition issue when multiple jpeg starts are called. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.c | 16 drivers/gpu/drm/amd/amdgpu/amdgpu_jpeg.h | 2 ++ 2 files changed, 14 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Daniel Vetter
On Wed, Jun 10, 2020 at 04:05:04PM +0200, Christian König wrote: > Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky: > > > > > > On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: > > > > > > > > > On 6/9/20 7:21 PM, Koenig, Christian wrote: > > > > > > > > > > > > Am 09.06.2020 18:37 schrieb

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-10 Thread Daniel Vetter
On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin wrote: > > > On 04/06/2020 09:12, Daniel Vetter wrote: > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > >this explicit

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-10 Thread Tvrtko Ursulin
On 04/06/2020 09:12, Daniel Vetter wrote: Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Intel
On 6/10/20 3:54 PM, Andrey Grodzovsky wrote: On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: On 6/9/20 7:21 PM, Koenig, Christian wrote: Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" : On 6/5/20 2:40 PM, Christian König wrote: > Am 05.06.20 um 16:29 schrieb Andrey

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Christian König
Am 10.06.20 um 15:54 schrieb Andrey Grodzovsky: On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: On 6/9/20 7:21 PM, Koenig, Christian wrote: Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" : On 6/5/20 2:40 PM, Christian König wrote: > Am 05.06.20 um 16:29 schrieb Andrey

Re: [PATCH 5/6] drm/ttm: Add destroy flag in TTM BO eviction interface

2020-06-10 Thread Andrey Grodzovsky
On 6/10/20 6:25 AM, Thomas Hellström (Intel) wrote: On 5/9/20 8:51 PM, Andrey Grodzovsky wrote: This will allow to invalidate, destroy backing storage and notify users of BOs when device is unpluged. Signed-off-by: Andrey Grodzovsky Please add a motivation in the commit message and use

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Andrey Grodzovsky
On 6/10/20 6:15 AM, Thomas Hellström (Intel) wrote: On 6/9/20 7:21 PM, Koenig, Christian wrote: Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" : On 6/5/20 2:40 PM, Christian König wrote: > Am 05.06.20 um 16:29 schrieb Andrey Grodzovsky: >> >> On 5/11/20 2:45 AM,

Re: [PATCH] drm/amdgpu: fix the nullptr issue as for PWR IP not existing in discovery table

2020-06-10 Thread Alex Deucher
Acked-by: Alex Deucher On Fri, Jun 5, 2020 at 7:35 AM Prike.Liang wrote: > > fix e467ab869f57 drm/amdgpu: use IP discovery table for renoir. > > This nullptr issue should be specific on the Renoir series during try access > the PWR_MISC_CNTL_STATUS > when PWR IP not been detected by discovery

Re: close() on some Intel CNP-LP PCI devices takes up to 2.7 s

2020-06-10 Thread Mika Westerberg
On Wed, Jun 10, 2020 at 08:18:07AM +0200, Paul Menzel wrote: > Thank you for replying so quickly. Hopefully, I’ll be able to test the > commit tomorrow. > > One question though. The commit talks about resuming from suspend. I > understand that training happens there. > > In my case the system is

Re: [PATCH 02/18] dma-buf: minor doc touch-ups

2020-06-10 Thread Intel
On 6/4/20 10:12 AM, Daniel Vetter wrote: Just some tiny edits: - fix link to struct dma_fence - give slightly more meaningful title - the polling here is about implicit fences, explicit fences (in sync_file or drm_syncobj) also have their own polling Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release

2020-06-10 Thread Daniel Vetter
On Wed, Jun 10, 2020 at 2:01 PM Thomas Hellström (Intel) wrote: > > Hi, Daniel, > > Please see below. > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > > fs_reclaim_acquire/release nicely catch recursion issues when > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend > > to

Re: [PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release

2020-06-10 Thread Intel
Hi, Daniel, Please see below. On 6/4/20 10:12 AM, Daniel Vetter wrote: fs_reclaim_acquire/release nicely catch recursion issues when allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend to use to keep the excessive caches in check). For mmu notifier recursions we do have

RE: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov

2020-06-10 Thread Deng, Emily
[AMD Official Use Only - Internal Distribution Only] >-Original Message- >From: Emily Deng >Sent: Tuesday, June 2, 2020 8:40 PM >To: amd-gfx@lists.freedesktop.org >Cc: Deng, Emily >Subject: [PATCH] drm/amdgpu/sriov: Disable pm for multiple vf sriov > >Signed-off-by: Emily Deng >--- >

RE: [PATCH v2] drm/amdgpu: Fix a buffer overflow handling the serial number

2020-06-10 Thread Quan, Evan
[AMD Official Use Only - Internal Distribution Only] Reviewed-by: Evan Quan -Original Message- From: Dan Carpenter Sent: Wednesday, June 10, 2020 4:57 PM To: Deucher, Alexander Cc: Koenig, Christian ; David Airlie ; Daniel Vetter ; Quan, Evan ; Zhang, Hawking ; Kuehling, Felix ;

Re: [PATCH 5/6] drm/ttm: Add destroy flag in TTM BO eviction interface

2020-06-10 Thread Intel
On 5/9/20 8:51 PM, Andrey Grodzovsky wrote: This will allow to invalidate, destroy backing storage and notify users of BOs when device is unpluged. Signed-off-by: Andrey Grodzovsky Please add a motivation in the commit message and use imperative wording ("Allow to invalidate..." instead

Re: [PATCH 1/6] drm/ttm: Add unampping of the entire device address space

2020-06-10 Thread Intel
On 6/9/20 7:21 PM, Koenig, Christian wrote: Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" : On 6/5/20 2:40 PM, Christian König wrote: > Am 05.06.20 um 16:29 schrieb Andrey Grodzovsky: >> >> On 5/11/20 2:45 AM, Christian König wrote: >>> Am 09.05.20 um 20:51 schrieb

[PATCH v2] drm/amdgpu: Fix a buffer overflow handling the serial number

2020-06-10 Thread Dan Carpenter
The comments say that the serial number is a 16-digit HEX string so the buffer needs to be at least 17 characters to hold the NUL terminator. The other issue is that "size" returned from sprintf() is the number of characters before the NUL terminator so the memcpy() wasn't copying the terminator.

Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)

2020-06-10 Thread Chunming Zhou
在 2020/6/10 15:41, Christian König 写道: That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag

Re: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)

2020-06-10 Thread Christian König
That's true, but for now we are stuck with the implicit sync for quite a number of use cases. My problem is rather that we already tried this and it backfired immediately. I do remember that it was your patch who introduced the pipeline sync flag handling and I warned that this could be

Re: close() on some Intel CNP-LP PCI devices takes up to 2.7 s

2020-06-10 Thread Paul Menzel
Dear Mika, Am 09.06.20 um 17:44 schrieb Mika Westerberg: On Tue, Jun 09, 2020 at 05:39:21PM +0200, Paul Menzel wrote: On the Intel Cannon Point-LP laptop Dell Precision 3540 with a dedicated AMD graphics card (both graphics devices can be used) with Debian Sid/unstable with Linux 5.6.14,

RE: [PATCH] drm/amdgpu: remove distinction between explicit and implicit sync (v2)

2020-06-10 Thread Zhou, David(ChunMing)
[AMD Official Use Only - Internal Distribution Only] Not sue if this is right direction, I think usermode wants all synchronizations to be explicit. Implicit sync often confuses people who don't know its history. I remember Jason from Intel is driving explicit synchronization through the