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

2021-09-12 Thread Oded Gabbay
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 v6 1/2] habanalabs: define uAPI to export FD for DMA-BUF

2021-09-12 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-09-12 Thread Oded Gabbay
ance doesn't allow p2p. Signed-off-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/m

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

2021-09-14 Thread Oded Gabbay
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 apprecia

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

2021-09-15 Thread Oded Gabbay
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 use

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

2021-09-16 Thread Oded Gabbay
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

2021-09-16 Thread Oded Gabbay
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

2021-09-18 Thread Oded Gabbay
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

2021-09-23 Thread Oded Gabbay
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

2021-09-28 Thread Oded Gabbay
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 1/2] habanalabs: define uAPI to export FD for DMA-BUF

2021-09-28 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-09-28 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-09-30 Thread Oded Gabbay
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

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

2021-10-03 Thread Oded Gabbay
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 s

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

2021-10-03 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-10-03 Thread Oded Gabbay
ance doesn't allow p2p. Signed-off-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&#x

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

2021-10-07 Thread Oded Gabbay
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 w

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

2021-06-21 Thread Oded Gabbay
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 have

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

2021-06-21 Thread Oded Gabbay
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: [Linaro-mm-sig] [PATCH v3 1/2] habanalabs: define uAPI to export FD for DMA-BUF

2021-06-22 Thread Oded Gabbay
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 > >> through the

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

2021-06-22 Thread Oded Gabbay
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

2021-06-22 Thread Oded Gabbay
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

2021-06-22 Thread Oded Gabbay
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

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

2021-06-22 Thread Oded Gabbay
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

2021-06-22 Thread Oded Gabbay
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 th

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

2021-06-23 Thread Oded Gabbay
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

2021-06-23 Thread Oded Gabbay
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 reduces

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

2021-06-23 Thread Oded Gabbay
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

2021-06-23 Thread Oded Gabbay
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: > > >

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

2021-07-05 Thread Oded Gabbay
on a bare-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 Tome

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

2021-07-05 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-07-05 Thread Oded Gabbay
low p2p. Signed-off-by: Tomer 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 u

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

2021-07-06 Thread Oded Gabbay
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

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

2021-07-06 Thread Oded Gabbay
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: [Linaro-mm-sig] [PATCH v4 0/2] Add p2p via dmabuf to habanalabs

2021-07-06 Thread Oded Gabbay
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 go

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

2021-07-06 Thread Oded Gabbay
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: [PATCH v4 2/2] habanalabs: add support for dma-buf exporter

2021-07-06 Thread Oded Gabbay
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

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

2021-07-11 Thread Oded Gabbay
fixes 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 Gabb

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

2021-07-11 Thread Oded Gabbay
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 2/2] habanalabs: add support for dma-buf exporter

2021-07-11 Thread Oded Gabbay
ance doesn't allow p2p. Signed-off-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

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

2022-12-24 Thread Oded Gabbay
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

2022-06-18 Thread Oded Gabbay
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 sys

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

2022-06-19 Thread Oded Gabbay
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: > >> > O

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

2022-06-20 Thread Oded Gabbay
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, Jun 17, 2022 at 8:20 PM Sierra

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

2018-10-03 Thread Oded Gabbay
q->properties.is_active = true; > retval = mqd_mgr->load_mqd(mqd_mgr, q->mqd, q->pipe, > - q->queue, &q->properties, > - q->process->mm); > +

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

2018-07-26 Thread Oded Gabbay
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 . >

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

2018-07-28 Thread Oded Gabbay
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 0/6] Raven support for KFD v2

2018-07-28 Thread Oded Gabbay
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 1/2] drm/amd: Add CU-masking ioctl definition to kfd_ioctl.h

2018-07-28 Thread Oded Gabbay
_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 2/2] drm/amdkfd: Add CU-masking ioctl to KFD

2018-07-28 Thread Oded Gabbay
++ b/drivers/gpu/drm/amd/amdkfd/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; >

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

2018-07-28 Thread Oded Gabbay
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 ex

[git pull] amdkfd next 4.19

2018-07-28 Thread Oded Gabbay
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 6/6] drm/amdkfd: Enable Raven for KFD

2018-07-30 Thread Oded Gabbay
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. > > > > Si

Re: Possible use_mm() mis-uses

2018-08-22 Thread Oded Gabbay
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: Possible use_mm() mis-uses

2018-08-22 Thread Oded Gabbay
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: KFD co-maintainership and branch model

2018-08-22 Thread Oded Gabbay
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 se

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

2019-08-06 Thread Oded Gabbay
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 MA

Re: Change queue/pipe split between amdkfd and amdgpu

2017-02-08 Thread Oded Gabbay
On Wed, Feb 8, 2017 at 6:23 PM, Andres Rodriguez wrote: > Hey Felix, > > Thanks for the pointer to the ROCm mqd commit. I like that the workarounds > are easy to spot. I'll add that to a new patch series I'm working on for > some bug-fixes for perf being lower on pipes other than pipe 0. > > I hav

Re: Change queue/pipe split between amdkfd and amdgpu

2017-02-09 Thread Oded Gabbay
we should merge this patch-set. Oded On Wed, Feb 8, 2017 at 9:47 PM, Andres Rodriguez wrote: > Thank you Oded. > > - Andres > > > On 2017-02-08 02:32 PM, Oded Gabbay wrote: >> >> On Wed, Feb 8, 2017 at 6:23 PM, Andres Rodriguez >> wrote: >>> >&g

Re: Change queue/pipe split between amdkfd and amdgpu

2017-02-10 Thread Oded Gabbay
lid queue enabled by amdgpu: %d\n", i); > break; > } > > John/Felix, > > Any chance I could borrow a carrizo/kaveri for a few days? Or maybe you > could help me run some final tests on this patch series? > > - Andres >

Re: Change queue/pipe split between amdkfd and amdgpu

2017-02-10 Thread Oded Gabbay
t; Where can I find a repo with kfdtest? > > I tried looking here bit couldn't find it: > > https://cgit.freedesktop.org/~gabbayo/ > > -Andres > > > > On 2017-02-10 05:35 AM, Oded Gabbay wrote: >> >> So the warning in dmesg is gone of course, but the test

Re: [PATCH 01/21] drm/amdgpu: refactor MQD/HQD initialization

2017-03-03 Thread Oded Gabbay
Hi Andres, A little suggestion, if I may. Could you please send future versions of this patch-set with [PATCH vX], where X is the version number ? That would help (at least me) to track the evolution of this patch-set quicker. And another thing, if you haven't done it so far (because I didn't chec

Re: [PATCH 09/17] drm/amdgpu: take ownership of per-pipe configuration v2

2017-04-15 Thread Oded Gabbay
On Fri, Apr 14, 2017 at 12:35 AM, Andres Rodriguez wrote: > Make amdgpu the owner of all per-pipe state of the HQDs. > > This change will allow us to split the queues between kfd and amdgpu > with a queue granularity instead of pipe granularity. > > This patch fixes kfd allocating an HDP_EOP regio

Re: [PATCH 09/17] drm/amdgpu: take ownership of per-pipe configuration v2

2017-04-15 Thread Oded Gabbay
take some time. Oded On Sun, Apr 16, 2017 at 3:12 AM, Andres Rodriguez wrote: > Hey Oded, > > I've had problems with 4.12-wip on its own. Just wanted to confirm if > you picked up this fix for a bug in drm-next: > "drm: Fix get_property logic fumble" > > Regards,

Re: [PATCH 09/17] drm/amdgpu: take ownership of per-pipe configuration v2

2017-04-18 Thread Oded Gabbay
ted patch with 2 bugs fixed: > > 1. the offset into the HPD bo was incorrect > 2. the compute_pipe_init function had an mec/me mismatch, so registers were > being set for the wrong ME > > Regards, > Andres > > On 2017-04-16 01:25 AM, Oded Gabbay wrote: >> >>

Re: [PATCH] Improve pipe split between amdgpu and amdkfd v4

2017-04-26 Thread Oded Gabbay
also gone over your code and it seems fine. So, this patch-set is: Acked-by: Oded Gabbay > On 2017-04-21 04:02 PM, Andres Rodriguez wrote: >> >> V4 updates: >> * Rebased onto latest 4.12-wip (ba16d6c), since I got test reports that >> the >>patch series f

Re: [PATCH 1/4] amdkfd: Tidy up kfd_generate_gpu_id() uint64_t bitshift unpack

2016-09-05 Thread Oded Gabbay
ts(local_mem_size); > + buf[6] = upper_32_bits(local_mem_size); > > for (i = 0, hashout = 0; i < 7; i++) > hashout ^= hash_32(buf[i], KFD_GPU_ID_HASH_WIDTH); > -- > 2.7.4 > > ___ > amd-gfx maili

Re: [PATCH 3/4] amdkfd: Add some missing memset zero'ing in queue init func

2016-09-05 Thread Oded Gabbay
> amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx With the above comment, 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: [PATCH 4/4] amdkfd: Fix possible dangling ptr in kfd_dbgmgr_destroy()

2016-09-05 Thread Oded Gabbay
On Sat, Sep 3, 2016 at 5:49 AM, Edward O'Callaghan wrote: > Signed-off-by: Edward O'Callaghan > --- > drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.c > b/drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.c > index 56d6

Re: [PATCH 1/7] amdkfd: Tidy up kfd_generate_gpu_id() uint64_t bitshift unpack

2016-09-10 Thread Oded Gabbay
On Sat, Sep 10, 2016 at 4:31 AM, Edward O'Callaghan wrote: > Dereference the one time and unpack the lower and upper 32bit > portions with the proper kernel helper macros. > > Signed-off-by: Edward O'Callaghan > Reviewed-by: Oded Gabbay > --- > drivers/gpu/dr

Re: [PATCH 3/7] amdkfd: Add some missing memset zero'ing in queue init func

2016-09-10 Thread Oded Gabbay
On Sat, Sep 10, 2016 at 4:31 AM, Edward O'Callaghan wrote: > Signed-off-by: Edward O'Callaghan > Reviewed-by: Oded Gabbay > --- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdkfd/

Re: [PATCH 4/7] drm/amdkfd: Make kfd_lookup_process_by_pasid() well defined

2016-09-10 Thread Oded Gabbay
On Sat, Sep 10, 2016 at 4:31 AM, Edward O'Callaghan wrote: > Ensure we return a NULL on the fail branch so that the call > site may BUG_ON() it. > > Signed-off-by: Edward O'Callaghan > --- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > >

Re: [PATCH 5/7] drm/amdkfd: Remove duplicate pqm_uninit()

2016-09-10 Thread Oded Gabbay
On Sat, Sep 10, 2016 at 4:31 AM, Edward O'Callaghan wrote: > pqm_uninit() will be called in kfd_process_notifier_release(), which > is when the process exits. Calling it in kfd_unbind_process_from_device() > is duplicate and in fact incorrect, because pqm should not be > uninitalized as long as th

Re: [PATCH 6/7] drm/amdkfd: Reuse function to find a process through pasid

2016-09-11 Thread Oded Gabbay
* We don't call amd_iommu_unbind_pasid() here > +* because the IOMMU called us. > +*/ > + pdd->bound = false; > > - srcu_read_unlock(&kfd_processes_srcu, idx); > + mutex_unlock(&p->mutex); > } > > struct kfd_proce

Re: [PATCH 7/7] drm/amdkfd: Fix possible infinite loop

2016-09-11 Thread Oded Gabbay
utimeout; > > m = get_sdma_mqd(mqd); > sdma_base_addr = get_sdma_base_addr(m); > @@ -396,7 +397,7 @@ static int kgd_hqd_sdma_destroy(struct kgd_dev *kgd, void > *mqd, > temp = RREG32(sdma_base_addr + mmSDMA0_

Re: [PATCH 2/7] radeonkfd/amdkfd: Implement get_local_mem_info()

2016-09-11 Thread Oded Gabbay
On Sat, Sep 10, 2016 at 4:31 AM, Edward O'Callaghan wrote: > Signed-off-by: Edward O'Callaghan Please give a little explanation why this new function is needed. In addition, I don't think "radeonkfd/amdkfd: .." is good as we never used this kind of title before. Let's just use "drm/amdkfd: ..."

Re: drm/amdkfd: Misc patchset lineup for drm-next-4.9

2016-09-18 Thread Oded Gabbay
opertices' by reference > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx All patches in the series are Reviewed-by: Oded Gabbay I added them to my -next tree

Re: [PATCH 2/2] drm/amdkfd: Decode bit fields in 'cik_ih_ring_entry' directly

2016-09-27 Thread Oded Gabbay
Christian is correct. That is not portable to other architectures Oded On Tue, Sep 27, 2016 at 3:52 PM, Christian König wrote: > NAK, don't use bitfields to decode hardware values. They aren't portable. > > Regards, > Christian. > > > Am 27.09.2016 um 14:47 schrieb Edward O'Callaghan: >> >> Sign

Re: [PATCH 1/2] drm/amdkfd: Use kfd_vm_info struct to carry consts state

2016-09-30 Thread Oded Gabbay
heck if there is over subscription */ > if ((sched_policy == > KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION) && > - ((dev->dqm->processes_count >= VMID_PER_DEVICE) || > + ((dev->dqm->processes_count >= dev->vm_info.vmid_num_kfd) || > (dev->dqm->queue_count >= PIPE_PER_ME_CP_SCHEDULING * > QUEUES_PER_PIPE))) { > pr_err("kfd: over-subscription is not allowed in > radeon_kfd.sched_policy == 1\n"); > retval = -EPERM; > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx With the above comment fixed, 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: [PATCH 0/8] Retry page fault handling for Vega10

2017-09-11 Thread Oded Gabbay
On Mon, Sep 11, 2017 at 10:29 PM, Deucher, Alexander wrote: >> -Original Message- >> From: Kuehling, Felix >> Sent: Wednesday, September 06, 2017 5:54 PM >> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander; Oded Gabbay; >> Koenig, Christian >>

Re: [PATCH 2/8] drm/amdgpu: Add PASID management

2017-09-16 Thread Oded Gabbay
ck_in_mhz: Retrieves maximum GPU clock in MHz > * > + * @alloc_pasid: Allocate a PASID > + * @free_pasid: Free a PASID > + * > * @program_sh_mem_settings: A function that should initiate the memory > * properties such as main aperture memory type (cache / non cached) and > * secondary aperture base address, size and memory type. > @@ -160,6 +163,9 @@ struct kfd2kgd_calls { > > uint32_t (*get_max_engine_clock_in_mhz)(struct kgd_dev *kgd); > > + int (*alloc_pasid)(unsigned int bits); > + void (*free_pasid)(unsigned int pasid); > + > /* Register access functions */ > void (*program_sh_mem_settings)(struct kgd_dev *kgd, uint32_t vmid, > uint32_t sh_mem_config, uint32_t sh_mem_ape1_base, > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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: [PATCH 3/8] drm/radeon: Add PASID manager for KFD

2017-09-16 Thread Oded Gabbay
return (struct radeon_device *)kgd; > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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: [PATCH 5/8] drm/amdkfd: Use PASID manager from KGD

2017-09-16 Thread Oded Gabbay
i++; > + } > + > + if (!kfd2kgd) > + return false; > + } > > - mutex_unlock(&pasid_mutex); > + r = kfd2kgd->alloc_pasid(pasid_bits); > > - return found; > + return r > 0 ? r : 0; > } > > void kfd_pasid_free

Re: [PATCH 4/8] drm/amdkfd: Separate doorbell allocation from PASID

2017-09-16 Thread Oded Gabbay
gt;mutex); > > @@ -288,6 +289,9 @@ static struct kfd_process *create_process(const struct > task_struct *thread) > if (process->pasid == 0) > goto err_alloc_pasid; > > + if (kfd_alloc_process_doorbells(process) < 0) > +

Re: [PATCH 11/11] drm/amdkfd: Set /dev/kfd permissions to 0666 by default

2017-09-17 Thread Oded Gabbay
On Sat, Sep 16, 2017 at 2:43 AM, Felix Kuehling wrote: > From: Andres Rodriguez > > Set the default permissions of /dev/kfd to be more than just root > accessible 600. > I don't think that's acceptable. You need to use udev rules file for that. Oded > Signed-off-by: Andres Rodriguez > Reviewed

Re: [PATCH 07/11] drm/amdkfd: Reuse CHIP_* from amdgpu

2017-09-17 Thread Oded Gabbay
On Sat, Sep 16, 2017 at 2:42 AM, Felix Kuehling wrote: > From: Yong Zhao > > There are already CHIP_* definitions under amd_shared.h file on amdgpu > side, so KFD should reuse them rather than defining new ones. > > Using enum for asic type requires default cases on switch statements > to prevent

Re: [PATCH 01/11] drm/amdkfd: Reorganize kfd resume code

2017-09-17 Thread Oded Gabbay
iommu_invalid_ppr_cb); > + > + err = kfd->dqm->ops.start(kfd->dqm); > + if (err) { > + dev_err(kfd_device, > + "Error starting queue manager for device %x:%x\n", > + kfd->pdev->vendor, kfd->pdev->device); > + goto dqm_start_error; > } > > - return 0; > + return err; > + > +dqm_start_error: > + amd_iommu_free_device(kfd->pdev); > + > + return err; > } > > /* This is called directly from KGD at ISR. */ > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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: [PATCH 02/11] drm/amdkfd: Fix suspend/resume issue on Carrizo

2017-09-17 Thread Oded Gabbay
the paths in the code in order to understand it. > + mutex_unlock(&p->mutex); > + > + if (temp_bound == PDD_BOUND) > + amd_iommu_unbind_pasid(dev->pdev, temp_pasid); > + } > + > + srcu_read_unlock(&kfd_processes_srcu, idx); > +} > + > +void kfd_process_iommu_unbind_callback(struct kfd_dev *dev, unsigned int > pasid) > { > struct kfd_process *p; > struct kfd_process_device *pdd; > @@ -432,15 +500,6 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, > unsigned int pasid) > pdd->reset_wavefronts = false; > } > > - /* > -* Just mark pdd as unbound, because we still need it > -* to call amd_iommu_unbind_pasid() in when the > -* process exits. > -* We don't call amd_iommu_unbind_pasid() here > -* because the IOMMU called us. > -*/ > - pdd->bound = false; > - > mutex_unlock(&p->mutex); > } > > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx With the above minor comments fixed, 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: [PATCH 04/11] drm/amdkfd: Adjust dequeue latencies and timeouts

2017-09-17 Thread Oded Gabbay
rm/amd/amdkfd/kfd_priv.h > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h > @@ -673,11 +673,8 @@ int amdkfd_fence_wait_timeout(unsigned int *fence_addr, > > /* Packet Manager */ > > -#define KFD_HIQ_TIMEOUT (500) > - > #define KFD_FENCE_COMP

Re: [PATCH 05/11] drm/amdkfd: Fix incorrect destroy_mqd parameter

2017-09-17 Thread Oded Gabbay
__ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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: [PATCH 08/11] drm/amdkfd: Drop _nocpsch suffix from shared functions

2017-09-17 Thread Oded Gabbay
dqm->ops.uninitialize = uninitialize_nocpsch; > + dqm->ops.uninitialize = uninitialize; > dqm->ops.set_cache_memory_policy = set_cache_memory_policy; > break; > default: > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx 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: [PATCH 06/11] drm/amdkfd: Use VMID bitmap from KGD

2017-09-17 Thread Oded Gabbay
rocess_queue_manager *pqm, > case KFD_QUEUE_TYPE_COMPUTE: > /* check if there is over subscription */ > if ((sched_policy == > KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION) && > - ((dev->dqm->processes_count >= VMID

Re: [PATCH 09/11] drm/amdkfd: Fix kernel-queue wrapping bugs

2017-09-17 Thread Oded Gabbay
On Sat, Sep 16, 2017 at 2:43 AM, Felix Kuehling wrote: > From: Yong Zhao > > Avoid intermediate negative numbers when doing calculations with a mix > of signed and unsigned variables where implicit conversions can lead > to unexpected results. > > When kernel queue buffer wraps around to 0, we ne

Re: [PATCH 10/11] drm/amdkfd: Print event limit messages only once per process

2017-09-17 Thread Oded Gabbay
> struct list_head signal_event_pages; > u32 next_nonsignal_event_id; > size_t signal_event_count; > + bool signal_event_limit_reached; > }; > > /** > -- > 2.7.4 > > _______ > amd-gfx mailing list > am

Re: [PATCH] drm/amdkfd: check for null dev to avoid a null pointer dereference

2017-09-17 Thread Oded Gabbay
On Fri, Sep 8, 2017 at 5:13 PM, Colin King wrote: > From: Colin Ian King > > The call to kfd_device_by_id can potentially return null, so check that > dev is null and return with -EINVAL to avoid a null pointer dereference. > > Detected by CoverityScan CID#1454629 ("Dereference null return value"

Re: KFD event handling questions

2017-09-24 Thread Oded Gabbay
bugger. 4096 is good enough and > the new debug trap handler will use events from that pool. > > Thanks > Hari > > > > -Original Message- > From: Kuehling, Felix > Sent: Thursday, September 21, 2017 9:36 PM > To: amd-gfx@lists.freedesktop.org; Oded Gabbay

Re: [PATCH 03/10] drm/amdkfd: Rectify the jiffies calculation error with milliseconds v2

2017-09-24 Thread Oded Gabbay
t_timeout(unsigned int *fence_addr, > unsigned int fence_value, > - unsigned long timeout); > + unsigned int timeout_ms); > > /* Packet Manager */ > > -- > 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: [PATCH 07/10] drm/amdkfd: Reuse CHIP_* from amdgpu v2

2017-09-24 Thread Oded Gabbay
@ -112,11 +114,6 @@ enum cache_policy { > cache_policy_noncoherent > }; > > -enum asic_family_type { > - CHIP_KAVERI = 0, > - CHIP_CARRIZO > -}; > - > struct kfd_event_interrupt_class { > bool (*interrupt_isr)(struct kfd_dev *dev, >

Re: [PATCH 09/10] drm/amdkfd: Fix kernel-queue wrapping bugs

2017-09-24 Thread Oded Gabbay
= rptr) { > + *buffer_ptr = NULL; > + return -ENOMEM; > + } > + /* fill nops, roll back and start at position 0 */ > while (wptr > 0) { > queue_address[wptr] = kq->nop_packet; >

Re: [PATCH 00/10] KFD fixes v2

2017-09-24 Thread Oded Gabbay
On Thu, Sep 21, 2017 at 1:10 AM, Felix Kuehling wrote: > Small self-contained KFD fixes that don't introduce any new > functionality or features. These may be suitable to include in > drm-fixes for 4.14. > Thanks! I added patches 5, 9 and 10 to my -fixes tree and I will send them shortly to Dave

  1   2   3   4   >