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
> &
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:
> > > >
> >
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
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
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
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
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
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:
> >> &
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
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
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
-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
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
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
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
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
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
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
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:
> > >
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:
> > > >
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
> &
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
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
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
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:
> > > > >
-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
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
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
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:
>
-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
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
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
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
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
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
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,
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
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
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
-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
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:
> >
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
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
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:
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
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
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
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:
> >
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:
> > > >
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
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:
> > > >
> > >
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
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
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
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
&
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
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:
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
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
> > 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
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:
> > >
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:
&
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
> >
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
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
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
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
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
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
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
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
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 .
>
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
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
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...@
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
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
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
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
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
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'
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:
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
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:
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
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
/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
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
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':
>
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
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
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
>
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
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
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(-)
>
>
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
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
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
>
>
>
>
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
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
401 - 500 of 1120 matches
Mail list logo