Re: [RFC 2/7] drm/amdgpu: Add usermode queue for gfx work

On Fri, Dec 23, 2022 at 9:37 PM Shashank Sharma wrote: > > This patch adds skeleton code for usermode queue creation. It > typically contains: > - A new structure to keep all the user queue data in one place. > - An IOCTL function to create/free a usermode queue. > - A function to generate unique

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

On Mon, Jun 20, 2022 at 11:50 AM Alistair Popple wrote: > > > Oded Gabbay writes: > > > On Mon, Jun 20, 2022 at 3:33 AM Alistair Popple wrote: > >> > >> > >> Oded Gabbay writes: > >> > >> > On Fri, Ju

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

On Mon, Jun 20, 2022 at 3:33 AM Alistair Popple wrote: > > > Oded Gabbay writes: > > > On Fri, Jun 17, 2022 at 8:20 PM Sierra Guiza, Alejandro (Alex) > > wrote: > >> > >> > >> On 6/17/2022 4:40 AM, David Hildenbrand wrote: > >> &

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

On Fri, Jun 17, 2022 at 8:20 PM Sierra Guiza, Alejandro (Alex) wrote: > > > On 6/17/2022 4:40 AM, David Hildenbrand wrote: > > On 31.05.22 22:00, Alex Sierra wrote: > >> Device memory that is cache coherent from device and CPU point of view. > >> This is used on platforms that have an advanced

Re: [PATCH v7 0/2] Add p2p via dmabuf to habanalabs

On Sun, Oct 3, 2021 at 12:08 PM Oded Gabbay wrote: > > Hi, > I'm sending v7 after the latest review from Jason. > All the changes are detailed in the commit messages. > > Dave, I'll appreciate if you can also a-b this patchset. > > Thanks, > Oded Hi, I would

[PATCH v7 2/2] habanalabs: add support for dma-buf exporter

-by: Tomer Tayar Reviewed-by: Oded Gabbay Reviewed-by: Gal Pressman Reviewed-by: Greg Kroah-Hartman Acked-by: Daniel Vetter Signed-off-by: Oded Gabbay --- Changes in v7: - rename structure hl_dmabuf_wrapper to hl_dmabuf_priv - remove change that wasn't relevant to this patch - set orig_nents

[PATCH v7 1/2] habanalabs: define uAPI to export FD for DMA-BUF

that was created to match that allocation. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar Reviewed-by: Greg Kroah-Hartman Acked-by: Daniel Vetter --- Changes in v7: - Change the type of the fd variable returned from IOCTL to be __s32 include/uapi/misc/habanalabs.h | 28 +++- 1

[PATCH v7 0/2] Add p2p via dmabuf to habanalabs

Hi, I'm sending v7 after the latest review from Jason. All the changes are detailed in the commit messages. Dave, I'll appreciate if you can also a-b this patchset. Thanks, Oded Oded Gabbay (1): habanalabs: define uAPI to export FD for DMA-BUF Tomer Tayar (1): habanalabs: add support

Re: [PATCH v6 2/2] habanalabs: add support for dma-buf exporter

On Wed, Sep 29, 2021 at 12:17 AM Oded Gabbay wrote: > > On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote: > > > > On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote: > > > From: Tomer Tayar > > > > > > Implement the calls to the dma-bu

Re: [PATCH v6 2/2] habanalabs: add support for dma-buf exporter

On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote: > > On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote: > > From: Tomer Tayar > > > > Implement the calls to the dma-buf kernel api to create a dma-buf > > object backed by FD. > > > > We b

Re: [PATCH v6 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Sep 28, 2021 at 8:13 PM Jason Gunthorpe wrote: > > On Sun, Sep 12, 2021 at 07:53:08PM +0300, Oded Gabbay wrote: > > /* HL_MEM_OP_* */ > > __u32 op; > > - /* HL_MEM_* flags */ > > + /* HL_MEM_* flags. > > + * For the HL_MEM_OP

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Thu, Sep 23, 2021 at 12:22 PM Oded Gabbay wrote: > > On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote: > > > > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > > > > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > &g

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote: > > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote: > > >

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote: > > > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote: > > > >

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Thu, Sep 16, 2021 at 3:44 PM Oded Gabbay wrote: > > On Thu, Sep 16, 2021 at 3:31 PM Daniel Vetter wrote: > > > > Maybe I got the device security model all wrong, but I thought Guadi is > > single user, and the only thing it protects is the system against the > &

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Thu, Sep 16, 2021 at 3:31 PM Daniel Vetter wrote: > > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote: > > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote: > > > > > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote: > > &g

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote: > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote: > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote: > > > Hi, > > > Re-sending this patch-set following the release of our

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Tue, Sep 14, 2021 at 5:18 PM Daniel Vetter wrote: > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote: > > Hi, > > Re-sending this patch-set following the release of our user-space TPC > > compiler and runtime library. > > > > I would appr

[PATCH v6 2/2] habanalabs: add support for dma-buf exporter

-by: Tomer Tayar Reviewed-by: Oded Gabbay Reviewed-by: Gal Pressman Reviewed-by: Greg Kroah-Hartman Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/Kconfig | 1 + drivers/misc/habanalabs/common/habanalabs.h | 22 + drivers/misc/habanalabs/common/memory.c | 522

[PATCH v6 1/2] habanalabs: define uAPI to export FD for DMA-BUF

that was created to match that allocation. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar Reviewed-by: Greg Kroah-Hartman --- include/uapi/misc/habanalabs.h | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/include/uapi/misc/habanalabs.h b/include/uapi/misc

[PATCH v6 0/2] Add p2p via dmabuf to habanalabs

Hi, Re-sending this patch-set following the release of our user-space TPC compiler and runtime library. I would appreciate a review on this. Thanks, Oded Oded Gabbay (1): habanalabs: define uAPI to export FD for DMA-BUF Tomer Tayar (1): habanalabs: add support for dma-buf exporter

[PATCH v5 2/2] habanalabs: add support for dma-buf exporter

-by: Tomer Tayar Reviewed-by: Oded Gabbay Reviewed-by: Gal Pressman Signed-off-by: Oded Gabbay --- Changes in v5: - Use dma_get_max_seg_size() to get the max segment size of the importer. Use that value when we convert the pages array into an SGT, to make sure each SG is not larger than

[PATCH v5 1/2] habanalabs: define uAPI to export FD for DMA-BUF

that was created to match that allocation. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar --- include/uapi/misc/habanalabs.h | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/include/uapi/misc/habanalabs.h b/include/uapi/misc/habanalabs.h index 18765eb75b65

[PATCH v5 0/2] Add p2p via dmabuf to habanalabs

are in the changelog in the commit message of the second patch. There was one issue with your proposal to set the orig_nents to 0. I did that, but I also had to restore it to nents before calling sg_free_table because that function uses orig_nents to iterate. Thanks, Oded Oded Gabbay (1

Re: [PATCH v4 2/2] habanalabs: add support for dma-buf exporter

On Tue, Jul 6, 2021, 16:54 Jason Gunthorpe wrote: > On Tue, Jul 06, 2021 at 12:44:49PM +0300, Oded Gabbay wrote: > > > > > + /* In case we got a large memory area to export, we need to > divide it > > > > + * to smaller areas because each e

Re: [Linaro-mm-sig] [PATCH v4 0/2] Add p2p via dmabuf to habanalabs

On Tue, Jul 6, 2021 at 4:17 PM Daniel Vetter wrote: > > On Tue, Jul 6, 2021 at 2:46 PM Oded Gabbay wrote: > > > > On Tue, Jul 6, 2021 at 3:23 PM Daniel Vetter wrote: > > > > > > On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote: > > &g

Re: [Linaro-mm-sig] [PATCH v4 0/2] Add p2p via dmabuf to habanalabs

On Tue, Jul 6, 2021 at 3:23 PM Daniel Vetter wrote: > > On Tue, Jul 06, 2021 at 02:21:10PM +0200, Christoph Hellwig wrote: > > On Tue, Jul 06, 2021 at 10:40:37AM +0200, Daniel Vetter wrote: > > > > Greg, I hope this will be good enough for you to merge this code. > > > > > > So we're officially

Re: [PATCH v4 0/2] Add p2p via dmabuf to habanalabs

On Tue, Jul 6, 2021 at 11:40 AM Daniel Vetter wrote: > > On Mon, Jul 05, 2021 at 04:03:12PM +0300, Oded Gabbay wrote: > > Hi, > > I'm sending v4 of this patch-set following the long email thread. > > I want to thank Jason for reviewing v3 and pointing out the errors,

Re: [PATCH v4 2/2] habanalabs: add support for dma-buf exporter

On Mon, Jul 5, 2021 at 7:52 PM Jason Gunthorpe wrote: > > On Mon, Jul 05, 2021 at 04:03:14PM +0300, Oded Gabbay wrote: > > > + rc = sg_alloc_table(*sgt, nents, GFP_KERNEL | __GFP_ZERO); > > + if (rc) > > + goto error_free; > > If you are not g

[PATCH v4 2/2] habanalabs: add support for dma-buf exporter

Tayar Reviewed-by: Oded Gabbay Reviewed-by: Gal Pressman Signed-off-by: Oded Gabbay --- Changes in v4: - Using dma_map_resources() to map the physical address of the PCI BAR to a DMA'able address that the other device can use - Check the p2p distance using pci_p2pdma_distance_many

[PATCH v4 1/2] habanalabs: define uAPI to export FD for DMA-BUF

that was created to match that allocation. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar --- include/uapi/misc/habanalabs.h | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/include/uapi/misc/habanalabs.h b/include/uapi/misc/habanalabs.h index 18765eb75b65

[PATCH v4 0/2] Add p2p via dmabuf to habanalabs

-metal environment with IOMMU enabled, on a sky-lake CPU with a white-listed PCIe bridge (to make the pci_p2pdma_distance_many happy). Greg, I hope this will be good enough for you to merge this code. Thanks, Oded Oded Gabbay (1): habanalabs: define uAPI to export FD for DMA-BUF Tomer Tayar (1

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Wed, Jun 23, 2021 at 10:34 PM Jason Gunthorpe wrote: > > On Wed, Jun 23, 2021 at 10:00:29PM +0300, Oded Gabbay wrote: > > On Wed, Jun 23, 2021 at 9:50 PM Jason Gunthorpe wrote: > > > > > > On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote: > >

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Wed, Jun 23, 2021 at 9:50 PM Jason Gunthorpe wrote: > > On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote: > > > Can you please explain why it is so important to (allow) access them > > through the CPU ? > > It is not so much important, as it reflects

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Wed, Jun 23, 2021 at 9:24 PM Jason Gunthorpe wrote: > > On Wed, Jun 23, 2021 at 10:57:35AM +0200, Christian König wrote: > > > > > No it isn't. It makes devices depend on allocating struct pages for > > > > their > > > > BARs which is not necessary nor desired. > > > Which dramatically

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Wed, Jun 23, 2021 at 11:57 AM Christian König wrote: > > Am 22.06.21 um 18:05 schrieb Jason Gunthorpe: > > On Tue, Jun 22, 2021 at 05:48:10PM +0200, Christian König wrote: > >> Am 22.06.21 um 17:40 schrieb Jason Gunthorpe: > >>> On Tue, Jun 22, 2021 at 05:29:01PM +0200, Christian König wrote:

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 6:31 PM Christian König wrote: > > > > Am 22.06.21 um 17:28 schrieb Jason Gunthorpe: > > On Tue, Jun 22, 2021 at 05:24:08PM +0200, Christian König wrote: > > > I will take two GAUDI devices and use one as an exporter and one as an > importer. I want to see that

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 6:28 PM Jason Gunthorpe wrote: > > On Tue, Jun 22, 2021 at 05:24:08PM +0200, Christian König wrote: > > > > > I will take two GAUDI devices and use one as an exporter and one as an > > > > importer. I want to see that the solution works end-to-end, with real > > > > device

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 6:11 PM Jason Gunthorpe wrote: > > On Tue, Jun 22, 2021 at 04:12:26PM +0300, Oded Gabbay wrote: > > > > 1) Setting sg_page to NULL > > > 2) 'mapping' pages for P2P DMA without going through the iommu > > > 3) Allowing P2P DMA witho

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 3:15 PM Jason Gunthorpe wrote: > > On Tue, Jun 22, 2021 at 03:04:30PM +0300, Oded Gabbay wrote: > > On Tue, Jun 22, 2021 at 3:01 PM Jason Gunthorpe wrote: > > > > > > On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote: > >

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 3:01 PM Jason Gunthorpe wrote: > > On Tue, Jun 22, 2021 at 11:42:27AM +0300, Oded Gabbay wrote: > > On Tue, Jun 22, 2021 at 9:37 AM Christian König > > wrote: > > > > > > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe: > > > >

Re: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Tue, Jun 22, 2021 at 9:37 AM Christian König wrote: > > Am 22.06.21 um 01:29 schrieb Jason Gunthorpe: > > On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote: > > > >> Another thing I want to emphasize is that we are doing p2p only > >> throug

Re: [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Mon, Jun 21, 2021 at 9:27 PM Daniel Vetter wrote: > > On Mon, Jun 21, 2021 at 7:55 PM Jason Gunthorpe wrote: > > On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote: > > > On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote: > > > > > > >

Re: [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote: > > On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote: > > On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote: > > > > Also I'm wondering which is the other driver that we share buffers > > > with. The gaudi stuff doesn't

Re: [PATCH hmm] drm/amdkfd: fix a use after free race with mmu_notififer unregister

On Tue, Aug 6, 2019 at 10:31 AM Christoph Hellwig wrote: > > Btw, who maintains amkfd these days? MAINTAINERS still lists > Oded, but he seems to have moved on to Habanalabs and maintains that > drivers now while not having any action on amdkfd for over a year. I've sent a patch to update the

Re: [PATCH] drm/amdkfd: Fix incorrect use of process->mm

active = true; > retval = mqd_mgr->load_mqd(mqd_mgr, q->mqd, q->pipe, > - q->queue, >properties, > - q->process->mm); > + q->queue, >properties, mm); > if (retval) > goto out; > dqm->queue_count++; > } > qpd->evicted = 0; > out: > + if (mm) > + mmput(mm); > dqm_unlock(dqm); > return retval; > } > -- > 2.7.4 > This patch is: Reviewed-by: Oded Gabbay ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: KFD co-maintainership and branch model

On Thu, Aug 23, 2018 at 4:34 AM David Airlie wrote: > > On Thu, Aug 23, 2018 at 8:25 AM, Felix Kuehling > wrote: > > Hi all, > > > > Oded has offered to make me co-maintainer of KFD, as he's super busy at > > work and less responsive than he used to be. > > > > At the same time we're about to

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > > > Having said that, I think we *are* protected by the mmu_notifier > > release because if the process suddenly dies, we will gracefully clean > > th

Re: Possible use_mm() mis-uses

On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds wrote: > One of the complex ones is the amdgpu driver. It does a > "use_mm(mmptr)" deep deep in the guts of a macro that ends up being > used in fa few places, and it's very hard to tell if it's right. > > It looks almost certainly buggy (there is no

Re: [PATCH 6/6] drm/amdkfd: Enable Raven for KFD

Do you have IOMMUv2 enabled on this chipset ? If not, amdkfd won't include raven support. Oded On Mon, Jul 30, 2018 at 4:33 PM Paul Menzel wrote: > > Dear Felix, dear Yong, > > > On 07/13/18 22:17, Felix Kühling wrote: > > From: Yong Zhao > > > > Add DID and kfd_device_info for Raven. > > > >

[git pull] amdkfd next 4.19

Hi Dave, This is amdkfd pull for 4.19. The major changes are: - Add Raven support. Raven refers to Ryzen APUs with integrated GFXv9 GPU. - Integrate GPU reset support In addition, there are a couple of small fixes and improvements, such as: - Better handling and reporting to user of VM faults

Re: [PATCH 2/2] drm/amdkfd: Call kfd2kgd.set_compute_idle

Hi Felix, Both patches applied to -next. Oded On Tue, Jul 17, 2018 at 7:14 PM Alex Deucher wrote: > > On Mon, Jul 16, 2018 at 7:10 PM, Felix Kuehling > wrote: > > User mode queue submissions don't go through KFD. Therefore we don't > > know exactly when compute is idle or not idle. We use the

Re: [PATCH 2/2] drm/amdkfd: Add CU-masking ioctl to KFD

kfd/kfd_process_queue_manager.c > @@ -325,6 +325,8 @@ int pqm_destroy_queue(struct process_queue_manager *pqm, > unsigned int qid) > if (retval != -ETIME) > goto err_destroy_queue; > } > + kfree(pqn->q->properties.cu_mask); > + pqn->q->properties.cu_mask = NULL; > uninit_queue(pqn->q); > } > > @@ -365,6 +367,34 @@ int pqm_update_queue(struct process_queue_manager *pqm, > unsigned int qid, > return 0; > } > > +int pqm_set_cu_mask(struct process_queue_manager *pqm, unsigned int qid, > + struct queue_properties *p) > +{ > + int retval; > + struct process_queue_node *pqn; > + > + pqn = get_queue_by_qid(pqm, qid); > + if (!pqn) { > + pr_debug("No queue %d exists for update operation\n", qid); > + return -EFAULT; > + } > + > + /* Free the old CU mask memory if it is already allocated, then > +* allocate memory for the new CU mask. > +*/ > + kfree(pqn->q->properties.cu_mask); > + > + pqn->q->properties.cu_mask_count = p->cu_mask_count; > + pqn->q->properties.cu_mask = p->cu_mask; > + > + retval = pqn->q->device->dqm->ops.update_queue(pqn->q->device->dqm, > + pqn->q); > + if (retval != 0) > + return retval; > + > + return 0; > +} > + > struct kernel_queue *pqm_get_kernel_queue( > struct process_queue_manager *pqm, > unsigned int qid) > -- > 2.7.4 > This patch is: Acked-by: Oded Gabbay ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amd: Add CU-masking ioctl definition to kfd_ioctl.h

_CU_MASK \ > + AMDKFD_IOW(0x1A, struct kfd_ioctl_set_cu_mask_args) > + > #define AMDKFD_COMMAND_START 0x01 > -#define AMDKFD_COMMAND_END 0x1A > +#define AMDKFD_COMMAND_END 0x1B > > #endif > -- > 2.7.4 >

Re: [PATCH 0/6] Raven support for KFD v2

Hi Felix, Thanks for the patch-set. Applied to -next. Oded On Fri, Jul 13, 2018 at 11:24 PM Alex Deucher wrote: > > On Fri, Jul 13, 2018 at 4:17 PM, Felix Kuehling > wrote: > > Raven refers to Ryzen APUs with integrated GFXv9 GPU. > > This patch series completes Raven support for KFD: > > > >

Re: [PATCH 00/25] KFD fixes, robutness enhancements and cleanups

Hi Felix, Thanks for the patch-set. Applied to -next. Oded On Thu, Jul 12, 2018 at 10:52 AM Christian König wrote: > > Patches which don't already have my rb are Acked-by: Christian König > . > > Regards, > Christian. > > Am 12.07.2018 um 04:32 schrieb Felix Kuehling: > > This series fixes some

Re: [PATCH] [RESEND] amdgpu: kfd: use modern ktime accessors

On Wed, Jul 11, 2018 at 3:41 PM Arnd Bergmann wrote: > > getrawmonotonic64() and get_monotonic_boottime64() are deprecated > because of the nonstandard naming. > > The replacement functions ktime_get_raw_ns() and ktime_get_boot_ns() > also simplify the callers. > > Reviewed-by: Felix Kuehling . >

[git pull] amdkfd next 4.18

to ebe1d22b57b86b6739f2739b5a0f52435596d84d: drm/amdgpu: fix 32-bit build warning (2018-05-25 17:50:09 +0200) Arnd Bergmann (1): drm/amdgpu: fix 32-bit build warning Oded Gabbay (1): drm/amdgpu: conditionally compile amdgpu's amdkfd files Tom Stellard (1

Re: [PATCH 2/8] drm/amdgpu: fix 32-bit build warning

t; WREG32(SOC15_REG_OFFSET(GC, 0, mmCP_PQ_WPTR_POLL_CNTL1), >get_queue_mask(adev, pipe_id, queue_id)); > } > -- > 2.9.0 > There is a change scheduled for the next merge window that will cause this file to not build anymore on 32-bit targets (because the am

Re: [PATCH] drm/amdgpu: Use dev_info() to report amdkfd is not supported for this ASIC

"kfd not supported on this ASIC\n"); > + dev_info(adev->dev, "kfd not supported on this ASIC\n"); > return; > } > > -- > 2.17.0 > This patch is: Reviewed-by: Oded Gabbay <oded.gab...@gmail.com> _

Re: [PATCH v2] drm/amdgpu: conditionally compile amdgpu's amdkfd files

On Fri, May 18, 2018 at 11:06 PM, Felix Kuehling <felix.kuehl...@amd.com> wrote: > Two more comments inline. One cosmetic, one real issue. With that fixed, > this patch is Reviewed-by: Felix Kuehling <felix.kuehl...@amd.com> > > Regards, > Felix > > On 2018-

[PATCH v3] drm/amdgpu: conditionally compile amdgpu's amdkfd files

of the real functions. v2: instead of using function pointers, use stub functions v3: initialize kgd2kfd to NULL in case amdkfd is not compiled Signed-off-by: Oded Gabbay <oded.gab...@gmail.com> --- drivers/gpu/drm/amd/amdgpu/Makefile| 13 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_am

[PATCH v2] drm/amdgpu: conditionally compile amdgpu's amdkfd files

call the original functions using a function pointer to allow compilation without the original functions. v2: Instead of using function pointers, use stub functions that are compiled only if amdkfd is not compiled. Signed-off-by: Oded Gabbay <oded.gab...@gmail.com> --- drivers/gpu/drm/amd/

Re: [PATCH] drm/amdgpu: conditionally compile amdgpu's amdkfd files

u just define empty stub functions in > amdgpu_amdkfd.h if KFD is not enabled? I think that would make the code > shorter and remove the runtime overhead. > > Regards, > Felix Yes, I can definitely do that. I agree it would be better. Oded > > > On 2018-05-16 06:09

Re: [PATCH 04/21] drm/amdgpu: Add GFXv9 kfd2kgd interface functions

On Wed, May 16, 2018 at 1:08 AM, Felix Kuehling wrote: > On 2018-05-15 05:41 AM, Dave Airlie wrote: >>> +static int kgd_hqd_load(struct kgd_dev *kgd, void *mqd, uint32_t pipe_id, >>> + uint32_t queue_id, uint32_t __user *wptr, >>> +

Re: [PATCH 4/6] drm/amdkfd: GFP_NOIO while holding locks taken in MMU notifier

Cool, thanks! On Mon, 14 May 2018, 19:07 Felix Kuehling <felix.kuehl...@amd.com> wrote: > On 2018-05-11 03:59 AM, Oded Gabbay wrote: > > On Fri, Mar 23, 2018 at 10:32 PM, Felix Kuehling <felix.kuehl...@amd.com> > wrote: > >> When an MMU notifier runs in memory

[git pull] amdkfd next 4.18

Hi Dave, This is amdkfd pull for 4.18. The major new features are: - Add support for GFXv9 dGPUs (VEGA) - Add support for userptr memory mapping In addition, there are a couple of small fixes and improvements, such as: - Fix lock handling - Fix rollback packet in kernel kfd_queue - Optimize kfd

Re: [PATCH 00/12] Assorted KFD fixes

Thanks Felix! Series applied to amdkfd-next Oded On Wed, May 2, 2018 at 12:56 AM, Felix Kuehling wrote: > These are some random patches I noticed when comparing amdkfd-next against > amd-kfd-staging. > > Ben Goz (1): > drm/amdkfd: Locking PM mutex while allocating IB

Re: [PATCHv3] drm/amdkfd: Remove vla

On Thu, May 3, 2018 at 12:49 AM, Kees Cook wrote: > On Fri, Apr 13, 2018 at 2:24 PM, Laura Abbott wrote: >> >> There's an ongoing effort to remove VLAs[1] from the kernel to eventually >> turn on -Wvla. Switch to a constant value that covers all

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

On Tue, Apr 24, 2018 at 9:58 PM, Felix Kuehling wrote: > Reviewed-by: Felix Kuehling > > We could probably add a sanity check for n_devices to avoid user mode > causing excessive memory allocations in the kernel. There is no good > reason for this

Re: [PATCH 00/21] GFXv9/Vega10 support for KFD

er_gfx9.asm > create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c > create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c > create mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_v9.c > create mode 100644 drivers/gpu/

Re: [PATCH 16/21] drm/amdkfd: Add 64-bit doorbell and wptr support to kernel queue

applied this patch instead of original, thanks. On Wed, Apr 25, 2018 at 12:42 AM, Felix Kuehling wrote: > A minor update to this patch is attached. The rest of the series is > unchanged and rebased cleanly on 4.17-rc2 on my system. > > Regards, > Felix > > > On

Re: [PATCH 11/21] drm/amdkfd: Add GFXv9 MQD manager

say we will look at moving to that API in the future, I don't object to taking your patch-set as is now. Oded > > > On 2018-05-11 05:10 AM, Oded Gabbay wrote: >> On Wed, Apr 11, 2018 at 12:33 AM, Felix Kuehling <felix.kuehl...@amd.com> >> wrote: >>> Signed

Re: [PATCH 07/21] drm/amdkfd: Clean up KFD_MMAP_ offset handling

On Fri, May 11, 2018 at 6:57 PM, Felix Kuehling <felix.kuehl...@amd.com> wrote: > On 2018-05-11 04:52 AM, Oded Gabbay wrote: >>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h >>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h >>> @@ -41,9 +41,33 @@ >&

Re: [PATCH 11/21] drm/amdkfd: Add GFXv9 MQD manager

On Wed, Apr 11, 2018 at 12:33 AM, Felix Kuehling wrote: > Signed-off-by: John Bridgman > Signed-off-by: Jay Cornwall > Signed-off-by: Felix Kuehling > --- > drivers/gpu/drm/amd/amdkfd/Makefile

Re: [PATCH 07/21] drm/amdkfd: Clean up KFD_MMAP_ offset handling

On Wed, Apr 11, 2018 at 12:33 AM, Felix Kuehling wrote: > From: Harish Kasiviswanathan > > Use bit-rotate for better clarity and remove _MASK from the #defines as > these represent mmap types. > > Centralize all the parsing of the mmap

Re: [PATCH 0/6] Userptr memory mapping support for KFD

On Fri, Mar 23, 2018 at 10:32 PM, Felix Kuehling wrote: > Update of remaining patches from the GPUVM patch series. This should apply > on top of the fixes I just sent out. > > Felix Kuehling (6): > drm/amdgpu: Add MMU notifier type for KFD userptr > drm/amdgpu: Enable

Re: [PATCH 4/6] drm/amdkfd: GFP_NOIO while holding locks taken in MMU notifier

On Fri, Mar 23, 2018 at 10:32 PM, Felix Kuehling wrote: > When an MMU notifier runs in memory reclaim context, it can deadlock > trying to take locks that are already held in the thread causing the > memory reclaim. The solution is to avoid memory reclaim while holding >

Re: [PATCH 2/6] drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker threads

Adding Alex, Christian On Fri, May 11, 2018 at 10:36 AM, Oded Gabbay <oded.gab...@gmail.com> wrote: > Hi Felix, > The patch looks fine to me and I can ACK it, but I would prefer that > Alex or Christian will review it as well before pushing it. > Thanks, > Oded > > On

Re: [PATCH 3/6] drm/amdgpu: Avoid reclaim while holding locks taken in MMU notifier

Hi Felix, Same as patch 2. ACK but I want an extra review from amdgpu people. Thanks, Oded On Fri, Mar 23, 2018 at 10:32 PM, Felix Kuehling wrote: > When an MMU notifier runs in memory reclaim context, it can deadlock > trying to take locks that are already held in the

Re: [PATCH 2/6] drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker threads

Hi Felix, The patch looks fine to me and I can ACK it, but I would prefer that Alex or Christian will review it as well before pushing it. Thanks, Oded On Fri, Mar 23, 2018 at 10:32 PM, Felix Kuehling wrote: > This commit allows amdgpu_ttm_tt_get_user_pages to work in a

Re: New SPDX-License-Identifier requirement

I believe it should be : SPDX-License-Identifier: GPL-2.0 OR MIT But John probably knows best about this Oded On Tue, May 1, 2018 at 11:14 PM, Felix Kuehling wrote: > Hi, > > I'm getting a checkpatch warning with the latest amdkfd-next branch > (4.17-rc2) when adding a

[git pull] amdkfd fixes for 4.17 rc3/4

Hi Dave, A couple of small fixes for 4.17 rc3/4, nothing special: - fix amdkfd Kconfig to select MMU_NOTIFIER - allow clock retrieval in case GPU not present - fix return code from function - make function static (fix sparse warning) Thanks, Oded The following changes since commit

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

Thanks, but I took Randy's patch as it was earlier in my email queue. Oded On Thu, Apr 19, 2018 at 8:47 PM, Felix Kuehling wrote: > On 2018-04-19 06:56 AM, Anders Roxell wrote: >> On 28 March 2018 at 18:04, Christian König wrote: >>> Am

Re: [PATCH] drm/amdgpu: Always call kfd post reset after reset

On Wed, Apr 11, 2018 at 11:19 PM, Felix Kuehling wrote: > On 2018-04-11 03:47 PM, Shaoyun Liu wrote: >> Even reset failed, kfd post reset need to be called to make lock balance on >> kfd side >> >> Change-Id: I8b6ef29d7527915611be0b96a9cd039bc75bb0a9 >> Signed-off-by:

Re: [PATCH] drm/amdkfd: fix clock counter retrieval for node without GPU

args->gpu_clock_counter = > + dev->kfd2kgd->get_gpu_clock_counter(dev->kgd); > + else > + /* Node without GPU resource */ > + args->gpu_clock_counter = 0; > > /* No

Re: [PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

On Mon, Apr 2, 2018 at 9:02 PM, Felix Kuehling wrote: > Thanks for catching that. I'd use -ENODEV to match what is done a few > lines below for peer_pdd. With that fixed, this patch is Reviewed-by: > Felix Kuehling > > Regards, > Felix > > > On

Re: [PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

On Mon, Apr 2, 2018 at 9:03 PM, Felix Kuehling wrote: > This patch is Reviewed-by: Felix Kuehling > > > On 2018-03-29 10:25 PM, Wei Yongjun wrote: >> Fixes the following sparse warning: >> >> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6:

Re: [PATCH -next] drm/amdgpu: fix error return code in amdgpu_amdkfd_gpuvm_create_process_vm()

On Wed, Mar 28, 2018 at 4:20 PM, Wei Yongjun wrote: > Fix to return error code -ENOMEM from the eviction fence create fail > error handling case instead of 0, as done elsewhere in this function. > > Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions

Re: [PATCH 00/21] GFXv9/Vega10 support for KFD

Hi Felix, Just to let you know that I am currently on vacation and will be back home only on 4/21 so all patch reviews from my side will be done after that date. Thanks, Oded On Tue, 10 Apr 2018, 17:33 Felix Kuehling wrote: > This patch series adds support for GFXv9

[git pull] amdkfd next 4.17

/amdkfd: Populate DRM render device minor Oded Gabbay (1): drm/amdkfd: add missing include of mm.h drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 28 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 1 + drivers/gpu/drm

Re: [PATCH 4/4] drm/amdkfd: Use ordered workqueue to restore processes

return; > @@ -957,7 +979,7 @@ int kfd_resume_all_processes(void) > int ret = 0, idx = srcu_read_lock(_processes_srcu); > > hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) { > - if (!schedule_delayed_work(>restore_work, 0)) { >

[git pull] amdkfd fixes for 4.16 final

Hi Dave, Two small fixes for the final 4.16 release: - Programming VMID correctly for scratch memory with HWS - deallocating SDMA queues correctly in various situations Thanks, Oded The following changes since commit 5a9f698feb11b198f17b2acebbfe0e2716a3beed: drm/ast: Fixed 1280x800 Display

Re: [PATCH 00/20] Add KFD GPUVM support for dGPUs v4

On Mon, Mar 19, 2018 at 9:05 PM, Felix Kuehling wrote: > On 2018-03-19 12:39 PM, Christian König wrote: >> So coming back to this series once more. >> >> Patch #1, #3 are Reviewed-by: Christian König . >> >> Patch #2, #4 - #13 and #18-#19 are

Re: [PATCH] drm/amdkfd: fix uninitialized variable use

On Thu, Mar 15, 2018 at 6:49 PM, Arnd Bergmann wrote: > When CONFIG_ACPI is disabled, we never initialize the acpi_table > structure in kfd_create_crat_image_virtual: > > drivers/gpu/drm/amd/amdkfd/kfd_crat.c: In function > 'kfd_create_crat_image_virtual': >

[git pull] amdkfd next 4.17

memory access Oded Gabbay (1): dma-fence: add comment for WARN_ON in dma_fence_release() Yong Zhao (1): drm/amdgpu: Replace kgd_mem with amdgpu_bo for kernel pinned gtt mem MAINTAINERS|2 + drivers/dma-buf/dma-fence.c

Re: [PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

On Thu, Feb 8, 2018 at 11:33 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Thu, 8 Feb 2018 22:23:57 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using

Re: [PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

Hi Gustavo, The patch is queued for the merge window of kernel 4.17 (opens in about 7 weeks from now). Oded On Wed, Feb 14, 2018 at 11:30 PM, Gustavo A. R. Silva wrote: > Hi all, > > I was just wondering about the status of this patch. > > Thanks > -- > Gustavo > > > On

Re: [PATCH 17/25] uapi: Fix type used in ioctl parameter structures

32_t pad; > + __u64 tba_addr; /* to KFD */ > + __u64 tma_addr; /* to KFD */ > + __u32 gpu_id; /* to KFD */ > + __u32 pad; > }; > > #define AMDKFD_IOCTL_BASE 'K' > -- > 2.7.4 > This patch is: Reviewed-by: Oded Gabba

Re: [PATCH 16/25] drm/amdkfd: Implement KFD process eviction/restore

d_work *dwork; > + struct kfd_process *p; > + struct kfd_process_device *pdd; > + int ret = 0; > + > + dwork = to_delayed_work(work); > + > + /* Process termination destroys this worker thread. So during the > +* lifetime of this thread, kfd_proce

  1   2   3   >