Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Matthew Brost" <matthew.brost@intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Kasireddy Vivek" <vivek.kasireddy@intel.com>,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [RFC PATCH 1/2] dma-buf: Add support for private interconnects
Date: Thu, 25 Sep 2025 17:48:36 +0200	[thread overview]
Message-ID: <2e518022d743762fc0c5bde8c0918ee47a18b0aa.camel@linux.intel.com> (raw)
In-Reply-To: <20250925130849.12021-2-thomas.hellstrom@linux.intel.com>

On Thu, 2025-09-25 at 15:08 +0200, Thomas Hellström wrote:
> Add a function to the dma_buf_attach_ops to indicate whether the
> connection is a private interconnect. If so the function returns
> the address to an interconnect-defined structure that can be
> used for further negotiating.
> 
> Also add a field to the dma_buf_attachment that indicates whether
> a private interconnect is used by the attachment.
> 
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
>  include/linux/dma-buf.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d58e329ac0e7..e7191edb2125 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -475,6 +475,19 @@ struct dma_buf_attach_ops {
>  	 * point to the new location of the DMA-buf.
>  	 */
>  	void (*move_notify)(struct dma_buf_attachment *attach);
> +
> +	/**
> +	 * @supports_interconnect: [optional] - Does the driver
> support a local interconnect?
> +	 *
> +	 * Does the importer support a private interconnect? The
> interconnect is
> +	 * identified using a unique address defined by the exporter
> and declared
> +	 * in a protocol header.

Actually we'd probably want to use something like a

struct dma_buf_interconnect {
	const char *name;
};

Here, and for globally known interconnects have them
instantiated somewhere common since there could be multiple exporters.

>  (RFC: Should this be a struct instead).
> +	 *
> +	 * Return: A pointer to the interconnect-private attach_ops
> structure if supported,
> +	 * %NULL otherwise.
> +	 */
> +	const void *(*supports_interconnect)(struct
> dma_buf_attachment *attach,
> +					     const void
> *interconnect);

And similarly for stricter type-checking the return value could be a
struct dma_buf_interconnect_attach_ops {
};

which is subclassed for each interconnect-private attach ops.

>  };
>  
>  /**
> @@ -484,6 +497,7 @@ struct dma_buf_attach_ops {
>   * @node: list of dma_buf_attachment, protected by dma_resv lock of
> the dmabuf.
>   * @peer2peer: true if the importer can handle peer resources
> without pages.
>   * @priv: exporter specific attachment data.
> + * @interconnect: Private interconnect to use if any, NULL
> otherwise.
>   * @importer_ops: importer operations for this attachment, if
> provided
>   * dma_buf_map/unmap_attachment() must be called with the dma_resv
> lock held.
>   * @importer_priv: importer specific attachment data.
> @@ -503,6 +517,7 @@ struct dma_buf_attachment {
>  	struct list_head node;
>  	bool peer2peer;
>  	const struct dma_buf_attach_ops *importer_ops;
> +	const void *interconnect;

const struct dma_buf_interconnect *interconnect;

>  	void *importer_priv;
>  	void *priv;
>  };

/Thomas


  reply	other threads:[~2025-09-25 15:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25 13:08 [RFC PATCH 0/2] dma-buf private interconnect POC Thomas Hellström
2025-09-25 13:08 ` [RFC PATCH 1/2] dma-buf: Add support for private interconnects Thomas Hellström
2025-09-25 15:48   ` Thomas Hellström [this message]
2025-09-25 16:40     ` Matthew Brost
2025-09-25 13:08 ` [RFC PATCH 2/2] drm/xe/dma-buf: Add generic interconnect support framework Thomas Hellström
2025-09-25 13:14 ` ✗ CI.checkpatch: warning for dma-buf private interconnect POC Patchwork
2025-09-25 13:16 ` ✓ CI.KUnit: success " Patchwork
2025-09-25 13:33 ` ✗ CI.checksparse: warning " Patchwork
2025-09-25 13:56 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-09-25 18:03 ` ✗ Xe.CI.Full: " Patchwork

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=2e518022d743762fc0c5bde8c0918ee47a18b0aa.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.brost@intel.com \
    --cc=vivek.kasireddy@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox