Re: New subsystem for acceleration devices

On Sun, Aug 7, 2022 at 9:43 AM Oded Gabbay wrote: > > On Fri, Aug 5, 2022 at 3:22 AM Jason Gunthorpe wrote: > > > > On Thu, Aug 04, 2022 at 08:48:28PM +0300, Oded Gabbay wrote: > > > > > > The flip is true of DRM - DRM is pretty general. I bet I could > &

Re: New subsystem for acceleration devices

On Fri, Aug 5, 2022 at 6:03 AM Dave Airlie wrote: > > On Thu, 4 Aug 2022 at 17:44, Oded Gabbay wrote: > > > > On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie wrote: > > > > > > On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > > > > > >

Re: New subsystem for acceleration devices

On Fri, Aug 5, 2022 at 3:22 AM Jason Gunthorpe wrote: > > On Thu, Aug 04, 2022 at 08:48:28PM +0300, Oded Gabbay wrote: > > > > The flip is true of DRM - DRM is pretty general. I bet I could > > > implement an RDMA device under DRM - but that doesn't mean it should &g

Re: New subsystem for acceleration devices

On Thu, Aug 4, 2022 at 6:04 PM Jeffrey Hugo wrote: > > On 8/4/2022 6:00 AM, Tvrtko Ursulin wrote: > > > > On 04/08/2022 00:54, Dave Airlie wrote: > >> On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > >>> > >>> On Wed, Aug 3, 2022 at 10:04 PM Da

Re: New subsystem for acceleration devices

On Thu, Aug 4, 2022 at 5:50 PM Jason Gunthorpe wrote: > > On Thu, Aug 04, 2022 at 10:43:42AM +0300, Oded Gabbay wrote: > > > After all, memory management services, or common device chars handling > > I can get from other subsystems (e.g. rdma) as well. I'm sure I co

Re: New subsystem for acceleration devices

On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie wrote: > > On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > > > > On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: > > > > > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay wrote: > > > > > > &g

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: Habanalabs, Ask for the linux firmware code which loads by coprocesseor

On Tue, Dec 7, 2021 at 9:19 AM Cai Huoqing wrote: > > Hi Oded Gabbay and habanalabs folks. > > I'm insterested in this kind of AI acceralator. > > After scanning the driver code. > It seems that there are a linux firmware which is loaded by > coprocessor(an slave cpu

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

Re: Accelerator drivers going forward (was Re: Habanalabs Open-Source TPC LLVM compiler and SynapseAI Core library)

10, 2021 at 6:09 PM Daniel Vetter > > > wrote: > > > > > > > > On Fri, Sep 10, 2021 at 9:58 AM Greg Kroah-Hartman > > > > wrote: > > > > > On Fri, Sep 10, 2021 at 10:26:56AM +0300, Oded Gabbay wrote: > > > > >

[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

Re: [RFC] Make use of non-dynamic dmabuf in RDMA

On Wed, Aug 25, 2021 at 6:14 PM Christian König wrote: > > Am 25.08.21 um 16:47 schrieb Jason Gunthorpe: > > On Wed, Aug 25, 2021 at 03:51:14PM +0200, Christian König wrote: > >> Am 25.08.21 um 14:38 schrieb Jason Gunthorpe: > >>> On Wed, Aug 25, 2021 at 02:27:08PM +0200, Christian König wrote: >

[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

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

on physical addresses. Therefore, the user doesn't pass through the kernel driver to allocate memory there. As a result, only for GAUDI we receive from the user a device memory physical address (instead of a handle) and a size. Signed-off-by: Tomer Tayar Reviewed-by: Oded Gabbay Reviewed-by: Gal

[PATCH v3 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 a47a731e4527

Re: [PATCH v6 03/17] misc/habana: Stop using frame_vector helpers

aniel Vetter > Cc: Christoph Hellwig > Cc: Jason Gunthorpe > Cc: Andrew Morton > Cc: John Hubbard > Cc: Jérôme Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org &

Re: [PATCH v6 04/17] misc/habana: Use FOLL_LONGTERM for userptr

Cc: Dan Williams > Cc: linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: Oded Gabbay > Cc: Omer Shpigelman > Cc: Ofir Bitton > Cc: Tomer Tayar > Cc: Moti Haimovski > Cc: Da

Re: [PATCH v2 03/17] misc/habana: Stop using frame_vector helpers

On Sun, Oct 11, 2020 at 12:41 AM Daniel Vetter wrote: > > On Sat, Oct 10, 2020 at 11:32 PM Daniel Vetter wrote: > > > > On Sat, Oct 10, 2020 at 10:27 PM Oded Gabbay wrote: > > > > > > On Fri, Oct 9, 2020 at 10:59 AM Daniel Vetter > > > wrote:

Re: [PATCH v2 03/17] misc/habana: Stop using frame_vector helpers

on Gunthorpe > Cc: Andrew Morton > Cc: John Hubbard > Cc: Jérôme Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: Oded Gabbay

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

On Sat, Oct 3, 2020 at 2:31 AM Jason Gunthorpe wrote: > > On Fri, Oct 02, 2020 at 08:16:48PM +0200, Daniel Vetter wrote: > > On Fri, Oct 2, 2020 at 8:06 PM Jason Gunthorpe wrote: > > > On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote: > > > > For $reasons I've stumbled over this

Re: [PATCH 1/2] mm/frame-vec: Drop gup_flags from get_vaddr_frames()

> > Cc: Pawel Osciak > > Cc: Marek Szyprowski > > Cc: Tomasz Figa > > Cc: Andrew Morton > > Cc: Oded Gabbay > > Cc: Omer Shpigelman > > Cc: Tomer Tayar > > Cc: Greg Kroah-Hartman > > Cc: Pawel Piskorski > > Cc: linux-arm-ker...@lis

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter wrote: > > On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote: > > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter > > wrote: > > > > > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote: > > >

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote: > > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote: > > > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter > > > wrote: &

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

On Mon, May 11, 2020 at 12:36 PM Oded Gabbay wrote: > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote: > > > > It's the default. > Thanks for catching that. > > > > > Also so much for "we're not going to tell the graphics people how to > >

Re: [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

Signed-off-by: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Olof Johansson > Cc: Oded Gabbay > Cc: Sumit Semwal > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > --- > drivers/misc/habanalabs/command_submission.c | 1 - > 1 file changed, 1 del

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

[PATCH v2] MAINTAINERS: update amdkfd maintainer

I'm leaving the role of amdkfd maintainer. Therefore, update the relevant entry in the MAINTAINERS file with the name of the new maintainer. Good Luck! Signed-off-by: Oded Gabbay --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS

[PATCH 1/1] MAINTAINERS: update amdkfd maintainer

amdkfd is now being upstreamed together with the amdgpu driver. Therefore, update the maintainer entry for the driver with the name of the amdgpu driver maintainer. Signed-off-by: Oded Gabbay --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b

[PATCH 0/1] Officialy leaving role as amdkfd maintainer

time to work with you guys and I learned a lot from you and from other people in the drm community. I'm sure we will work again in the future :) Thanks, Oded Oded Gabbay (1): MAINTAINERS: update amdkfd maintainer MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

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

[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] [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: linux-next: build failure after merge of the drm tree

ject: [PATCH] drm/amdgpu: include pagemap.h for release_pages() > > Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD" > Cc: Felix Kuehling <felix.kuehl...@amd.com> > Cc: Oded Gabbay <oded.gab...@gmail.com> > Signed-off-by: Stephen Rothwell <s...@

[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: [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

[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] gpu/drm/amd/amdkfd: fix build, select MMU_NOTIFIER

led by default] >> ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:439:2: warning: (near >> initialization for 'kfd_process_mmu_notifier_ops') [enabled by default] >> ../drivers/gpu/drm/amd/amdkfd/kfd_process.c:534:2: error: implicit >> declaration of function 'mmu_notifier_register'

Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

Thanks, but already fixed in latest upstream tree Oded On Thu, Apr 5, 2018 at 7:26 AM, Dmitry V. Levin wrote: > Consistently use types provided by via > to fix the following linux/kfd_ioctl.h userspace compilation errors: > > /usr/include/linux/kfd_ioctl.h:266:2: error:

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: [RFC PATCH gabbayo] drm/amdkfd: kfd_dev_is_large_bar() can be static

On Tue, Mar 27, 2018 at 7:55 PM, kbuild test robot wrote: > > > Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management") > Signed-off-by: Fengguang Wu > --- > kfd_chardev.c |2 +- > 1 file changed, 1 insertion(+), 1

[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

[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] 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': >

Re: [PATCH] drm/amdkfd: add missing include of mm.h

Hi Dave, Could you please apply this directly to drm-next ? I don't have any pending pull requests at the moment and it seems redundant to send one for just a single patch. Thanks, Oded On Thu, Mar 15, 2018 at 10:10 AM, Oded Gabbay <oded.gab...@gmail.com> wrote: > This patch fixes ker

[PATCH] drm/amdkfd: add missing include of mm.h

This patch fixes kernel build in ARCH=frv Signed-off-by: Oded Gabbay <oded.gab...@gmail.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h

Re: [drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?

Hi, There is a missing #include at amdgpu_amdkfd.h I'll send a patch to Dave to apply to his drm-next tree to fix this. Thanks for catching this, Oded On Thu, Mar 15, 2018 at 4:50 AM, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip >

[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: [RFC PATCH gabbayo] drm/amdgpu: amdkfd_fence_ops can be static

On Mon, Feb 12, 2018 at 2:53 PM, kbuild test robot wrote: > > > Fixes: 447ed3ae9ceb ("drm/amdgpu: Add KFD eviction fence") > Signed-off-by: Fengguang Wu > --- > amdgpu_amdkfd_fence.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: kdg2kfd_probe failed

HI Sen, Those messages are expected and you can ignore them. In kernel 4.14 a couple of warning/error messages were added to amdkfd. If you use the amdgpu driver you will not see them but because you use radeon you are seeing them. In kernel 4.15 we removed support of amdkfd from radeon, so once

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] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry

On Sat, Jan 20, 2018 at 12:30 AM, Gustavo A. R. Silva wrote: > > Quoting Felix Kuehling : > >> Looks good. This change is Reviewed-by: Felix Kuehling >> >> > > Thanks Felix. > -- > Gustavo > Applied to -next Oded > > > >

Re: [PATCH] dma-fence: add comment for WARN_ON in dma_fence_release()

On Tue, Jan 30, 2018 at 12:33 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Mon, Jan 29, 2018 at 05:40:02PM +0200, Oded Gabbay wrote: >> In dma_fence_release() there is a WARN_ON which could be triggered by >> several cases of wrong dma-fence usage. This patch adds a comm

[PATCH] dma-fence: add comment for WARN_ON in dma_fence_release()

In dma_fence_release() there is a WARN_ON which could be triggered by several cases of wrong dma-fence usage. This patch adds a comment to explain two use-cases to help driver developers that use dma-fence and trigger that WARN_ON to better understand the reasons for it. Signed-off-by: Oded

<    1   2   3   4   5   6   7   8   9   10   >