Re: [PATCH] drm/amdkfd: Provide SMI events watch

[AMD Official Use Only - Internal Distribution Only] From: Alex Deucher Sent: Tuesday, March 17, 2020 3:03 PM To: Lin, Amber Cc: amd-gfx list Subject: Re: [PATCH] drm/amdkfd: Provide SMI events watch On Tue, Mar 17, 2020 at 1:57 PM Amber Lin wrote: > > When

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On 3/17/20 5:59 AM, Christoph Hellwig wrote: On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: I've been using v7 of Ralph's tester and it is working well - it has DEVICE_PRIVATE support so I think it can test this flow too. Ralph are you able? This hunk seems trivial enough to

Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault

On 3/17/20 4:56 AM, Jason Gunthorpe wrote: On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote: The reason for it being backwards is that "normally" a device doesn't want the device private page to be faulted back to system memory, it wants to get the device private struct page so

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On 3/17/20 12:34 AM, Christoph Hellwig wrote: On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote: On 3/16/20 12:32 PM, Christoph Hellwig wrote: Remove the code to fault device private pages back into system memory that has never been used by any driver. Also replace the usage of

amdgpu kernel oops?

I don't have a lot of experience reading kernel logs, so I apologize if I misread something, but it seems like I'm having some trouble with amdgpu in kernel 5.5.9. Here's the gist of the bug . Thank you for your help. Tris

Re: [PATCH 1/1] drm/amdgpu: disable gpu_sched load balancer for vcn jobs

On 2020-03-12 06:56, Nirmoy wrote: > > On 3/12/20 9:50 AM, Christian König wrote: >> Am 11.03.20 um 21:55 schrieb Nirmoy: >>> >>> On 3/11/20 9:35 PM, Andrey Grodzovsky wrote: On 3/11/20 4:32 PM, Nirmoy wrote: > > On 3/11/20 9:02 PM, Andrey Grodzovsky wrote: >> >> On 3/11/

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Tue, Mar 17, 2020 at 01:59:55PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: > > I've been using v7 of Ralph's tester and it is working well - it has > > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are > > you able? > >

Re: [PATCH] drm/amdkfd: Provide SMI events watch

On Tue, Mar 17, 2020 at 1:57 PM Amber Lin wrote: > > When the compute is malfunctioning or performance drops, the system admin > will use SMI (System Management Interface) tool to monitor/diagnostic what > went wrong. This patch provides an event watch interface for the user > space to register ev

[PATCH] drm/amdkfd: Provide SMI events watch

When the compute is malfunctioning or performance drops, the system admin will use SMI (System Management Interface) tool to monitor/diagnostic what went wrong. This patch provides an event watch interface for the user space to register events they are interested. After the event is registered, the

[PATCH] drm/amdgpu/sriov : Don't resume RLCG for SRIOV guest

RLCG is enabled by host driver, no need to enable it in guest for none-PSP load path Change-Id: I2f313743bf3d492f06aaef07224da6eda3878a28 Signed-off-by: shaoyunl --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v1

Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem

Hi Tejun, What's your thoughts on this latest series? Regards, Kenny On Wed, Feb 26, 2020 at 2:02 PM Kenny Ho wrote: > > This is a submission for the introduction of a new cgroup controller for the > drm subsystem follow a series of RFCs [v1, v2, v3, v4] > > Changes from PR v1 > * changed cgro

Re: [PATCH RESEND v2 2/2] PCI: Use ioremap(), not phys_to_virt() for platform ROM

On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote: > /** > + * pci_platform_rom - ioremap() the ROM image provided by the platform > * @pdev: pointer to pci device struct > * @size: pointer to receive size of pci window over ROM > + * > + * Return: kernel virtual pointer to image

Re: [PATCH 2/4] PCI: Use ioremap, not phys_to_virt for platform rom

Any reason drivers can't just use pci_map_rom insteadἅ which already does the right thing? ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/4] drm/radeon: iounmap unused mapping

On Mon, Mar 02, 2020 at 10:34:56PM -0500, Mikel Rychliski wrote: > Now that pci_platform_rom creates a new mapping to access the ROM > image, we should remove this mapping after extracting the BIOS. This and the next patch really need to be folded into the previous one to avoid regressions (assumi

[PATCH] Remove stable HAINAN board from max_sclk override check in radeon and amdgpu modules

Signed-off-by: Yassine Oudjana --- drivers/gpu/drm/amd/amdgpu/si_dpm.c | 1 - drivers/gpu/drm/radeon/si_dpm.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c b/drivers/gpu/drm/amd/amdgpu/si_dpm.c index 4cb4c891120b..0860e85a2d35 100644 --- a/drivers/g

[PATCH][next] drm: amd: fix spelling mistake "shoudn't" -> "shouldn't"

From: Colin Ian King There are spelling mistakes in pr_err messages and a comment. Fix these. Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +- drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 2 +- 3 files

[PATCH] drm/amd/powerplay: remove redundant check in smu_set_soft_freq_range

min(max) is type of uint32_t, min < 0(max < 0) is never true. move it. Addressed-Coverity: ("Unsigned compared against 0") Signed-off-by: Qiujun Huang --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: > I've been using v7 of Ralph's tester and it is working well - it has > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are > you able? > > This hunk seems trivial enough to me, can we include it now? I can send

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote: > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a driver > > can > > look at the struct page but what if a driver needs to fault in a page from > > another device's private memory? Should it call handle_mm_faul

Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling

On Mon, Mar 16, 2020 at 02:12:01PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote: > > > Ok. I had some cleanups like this based of older trees, but if you are > > > active in this area I think I'll let you handle it. > > > > You once said you wa

Re: [PATCH 2/2] mm: remove device private page support from hmm_range_fault

On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote: > The reason for it being backwards is that "normally" a device doesn't want > the device private page to be faulted back to system memory, it wants to > get the device private struct page so it can update its page table to point > to

Re: ensure device private pages have an owner v2

On Mon, Mar 16, 2020 at 08:32:12PM +0100, Christoph Hellwig wrote: > When acting on device private mappings a driver needs to know if the > device (or other entity in case of kvmppc) actually owns this private > mapping. This series adds an owner field and converts the migrate_vma > code over to c

Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling

On Tue, Mar 17, 2020 at 09:53:17AM -0300, Jason Gunthorpe wrote: > > Thinking out loud a bit more: > > > > - do we really need HMM_PFN_ERROR, or is just a return value from > >hmm_range_fault enough? > > I'm not totally clear on this. The only use for ERROR is to signal to a > non-faulting h

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Mon, Mar 16, 2020 at 04:59:23PM -0300, Jason Gunthorpe wrote: > However, between patch 3 and 4 doesn't this break amd gpu as it will > return device_private pages now if not requested? Squash the two? No change in behavior in this patch as long as HMM_PFN_DEVICE_PRIVATE isn't set in ->pfns or -

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote: > > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a > > > driver can > > > look at the struct page but what if a driver needs to fault in a p

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote: > On 3/16/20 12:32 PM, Christoph Hellwig wrote: >> Remove the code to fault device private pages back into system memory >> that has never been used by any driver. Also replace the usage of the >> HMM_PFN_DEVICE_PRIVATE flag in the pf

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Tue, Mar 17, 2020 at 01:28:13PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote: > > On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote: > > > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a > > > > driver c

Re: [PATCH 3/4] mm: simplify device private page handling in hmm_range_fault

On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote: > > On 3/16/20 12:32 PM, Christoph Hellwig wrote: > > Remove the code to fault device private pages back into system memory > > that has never been used by any driver. Also replace the usage of the > > HMM_PFN_DEVICE_PRIVATE flag in

Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling

On Tue, Mar 17, 2020 at 01:32:10PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 02:12:01PM +0100, Christoph Hellwig wrote: > > On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote: > > > > Ok. I had some cleanups like this based of older trees, but if you are > > > > active

Re: [PATCH hmm 8/8] mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling

On Tue, Mar 17, 2020 at 02:06:08PM +0100, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:53:17AM -0300, Jason Gunthorpe wrote: > > > Thinking out loud a bit more: > > > > > > - do we really need HMM_PFN_ERROR, or is just a return value from > > >hmm_range_fault enough? > > > > I'm not