All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Oded Gabbay <oded.gabbay@gmail.com>
Cc: linux-kernel@vger.kernel.org, SW_Drivers@habana.ai,
	Ofir Bitton <obitton@habana.ai>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH 1/3] habanalabs: implement dma-fence mechanism
Date: Mon, 13 Jul 2020 17:57:52 +0200	[thread overview]
Message-ID: <20200713155752.GC267581@kroah.com> (raw)
In-Reply-To: <20200713155424.24721-1-oded.gabbay@gmail.com>

On Mon, Jul 13, 2020 at 06:54:22PM +0300, Oded Gabbay wrote:
> From: Ofir Bitton <obitton@habana.ai>
> 
> Instead of using standard dma-fence mechanism designed for GPU's, we
> introduce our own implementation based on the former one. This
> implementation is much more sparse than the original, contains only
> mandatory functionality required by the driver.

Sad you can't use the in-kernel code for this, I really don't understand
what's wrong with using it as-is.

Daniel, why do we need/want duplicate code floating around in the tree
like this?

Copying code leads to errors, here's some documentation ones:

> --- /dev/null
> +++ b/drivers/misc/habanalabs/hl_dma_fence.c
> @@ -0,0 +1,338 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Fence mechanism for dma-buf and to allow for asynchronous dma access

Is that what this still does?

> + *
> + * Copyright (C) 2012 Canonical Ltd
> + * Copyright (C) 2012 Texas Instruments
> + *
> + * Authors:
> + * Rob Clark <robdclark@gmail.com>
> + * Maarten Lankhorst <maarten.lankhorst@canonical.com>
> + *
> + * The dma_fence module is a copy of dma-fence at drivers/dma-buf.

"The hl_dma_fence" module...

And is it a stand-alone module?  Or just a single file?

> + * This was done due to an explicit request by GPU developers who asked not
> + * to use the dma-buf module because we aren't part of DRM subsystem.

Why is dma-buf only for use for DRM?

If it is, should the symbol namespace be set to that to catch users that
want to use it for their own code?

> + * This copy was stripped from all extra features that habanalabs driver
> + * doesn't use, including the uapi interface dma-buf exposes.
> + * In addition, we removed the callbacks because the only usage is from inside
> + * habanalabs driver
> + */
> +
> +#include "hl_dma_fence.h"
> +#include "habanalabs.h"
> +#include <linux/slab.h>
> +#include <linux/export.h>
> +#include <linux/atomic.h>
> +#include <linux/sched/signal.h>
> +
> +/**
> + * DOC: DMA fences overview
> + *
> + * DMA fences, represented by &struct hl_dma_fence, are the kernel internal
> + * synchronization primitive for DMA operations like GPU rendering, video
> + * encoding/decoding, or displaying buffers on a screen.

I don't think this is correct anymore, right?  :(

> --- /dev/null
> +++ b/drivers/misc/habanalabs/hl_dma_fence.h
> @@ -0,0 +1,148 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Fence mechanism for dma-buf to allow for asynchronous dma access
> + *
> + * Copyright (C) 2012 Canonical Ltd
> + * Copyright (C) 2012 Texas Instruments
> + *
> + * Authors:
> + * Rob Clark <robdclark@gmail.com>
> + * Maarten Lankhorst <maarten.lankhorst@canonical.com>
> + *
> + * The dma_fence module is a copy of dma-fence at drivers/dma-buf.

Same comments here for the .h file.

thanks,

greg k-h

  parent reply	other threads:[~2020-07-13 15:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 15:54 [PATCH 1/3] habanalabs: implement dma-fence mechanism Oded Gabbay
2020-07-13 15:54 ` [PATCH 2/3] habanalabs: create common folder Oded Gabbay
2020-07-15 10:56   ` Omer Shpigelman
2020-07-13 15:54 ` [PATCH 3/3] habanalabs: update hl_boot_if.h from firmware Oded Gabbay
2020-07-15 10:58   ` Omer Shpigelman
2020-07-13 15:57 ` Greg Kroah-Hartman [this message]
2020-07-13 18:34   ` [PATCH 1/3] habanalabs: implement dma-fence mechanism Daniel Vetter
2020-07-13 19:03     ` Jason Gunthorpe
2020-07-13 19:08       ` Daniel Vetter
2020-07-14  6:36         ` Greg Kroah-Hartman
2020-07-14 12:07           ` Ofir Bitton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200713155752.GC267581@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=SW_Drivers@habana.ai \
    --cc=daniel.vetter@ffwll.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=obitton@habana.ai \
    --cc=oded.gabbay@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.