From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
bskeggs@redhat.com, Liam.Howlett@oracle.com,
matthew.brost@intel.com, alexdeucher@gmail.com,
ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org,
jason@jlekstrand.net, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH drm-next v3 04/15] drm: manager to keep track of GPUs VA mappings
Date: Fri, 28 Apr 2023 12:18:13 +0200 [thread overview]
Message-ID: <20230428121813.309ea609@collabora.com> (raw)
In-Reply-To: <20230404012741.116502-5-dakr@redhat.com>
On Tue, 4 Apr 2023 03:27:30 +0200
Danilo Krummrich <dakr@redhat.com> wrote:
> +struct drm_gpuva_manager {
> + /**
> + * @name: the name of the DRM GPU VA space
> + */
> + const char *name;
> +
> + /**
> + * @mm_start: start of the VA space
> + */
> + u64 mm_start;
> +
> + /**
> + * @mm_range: length of the VA space
> + */
> + u64 mm_range;
> +
> + /**
> + * @mtree: the &maple_tree to track GPU VA mappings
> + */
> + struct maple_tree mtree;
> +
> + /**
> + * @kernel_alloc_node:
> + *
> + * &drm_gpuva representing the address space cutout reserved for
> + * the kernel
> + */
> + struct drm_gpuva kernel_alloc_node;
> +
> + /**
> + * @ops: &drm_gpuva_fn_ops providing the split/merge steps to drivers
> + */
> + struct drm_gpuva_fn_ops *ops;
Any reason for not making that a const object (same goes for all the
functions being passed a drm_gpuva_fn_ops)?
> +};
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: matthew.brost@intel.com, willy@infradead.org, daniel@ffwll.ch,
dri-devel@lists.freedesktop.org, corbet@lwn.net,
nouveau@lists.freedesktop.org, ogabbay@kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
mripard@kernel.org, linux-mm@kvack.org, alexdeucher@gmail.com,
bskeggs@redhat.com, Liam.Howlett@oracle.com,
Dave Airlie <airlied@redhat.com>,
bagasdotme@gmail.com, christian.koenig@amd.com,
jason@jlekstrand.net
Subject: Re: [Nouveau] [PATCH drm-next v3 04/15] drm: manager to keep track of GPUs VA mappings
Date: Fri, 28 Apr 2023 12:18:13 +0200 [thread overview]
Message-ID: <20230428121813.309ea609@collabora.com> (raw)
In-Reply-To: <20230404012741.116502-5-dakr@redhat.com>
On Tue, 4 Apr 2023 03:27:30 +0200
Danilo Krummrich <dakr@redhat.com> wrote:
> +struct drm_gpuva_manager {
> + /**
> + * @name: the name of the DRM GPU VA space
> + */
> + const char *name;
> +
> + /**
> + * @mm_start: start of the VA space
> + */
> + u64 mm_start;
> +
> + /**
> + * @mm_range: length of the VA space
> + */
> + u64 mm_range;
> +
> + /**
> + * @mtree: the &maple_tree to track GPU VA mappings
> + */
> + struct maple_tree mtree;
> +
> + /**
> + * @kernel_alloc_node:
> + *
> + * &drm_gpuva representing the address space cutout reserved for
> + * the kernel
> + */
> + struct drm_gpuva kernel_alloc_node;
> +
> + /**
> + * @ops: &drm_gpuva_fn_ops providing the split/merge steps to drivers
> + */
> + struct drm_gpuva_fn_ops *ops;
Any reason for not making that a const object (same goes for all the
functions being passed a drm_gpuva_fn_ops)?
> +};
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: matthew.brost@intel.com, willy@infradead.org,
dri-devel@lists.freedesktop.org, corbet@lwn.net,
nouveau@lists.freedesktop.org, ogabbay@kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, bskeggs@redhat.com, tzimmermann@suse.de,
Liam.Howlett@oracle.com, Dave Airlie <airlied@redhat.com>,
bagasdotme@gmail.com, christian.koenig@amd.com,
jason@jlekstrand.net
Subject: Re: [PATCH drm-next v3 04/15] drm: manager to keep track of GPUs VA mappings
Date: Fri, 28 Apr 2023 12:18:13 +0200 [thread overview]
Message-ID: <20230428121813.309ea609@collabora.com> (raw)
In-Reply-To: <20230404012741.116502-5-dakr@redhat.com>
On Tue, 4 Apr 2023 03:27:30 +0200
Danilo Krummrich <dakr@redhat.com> wrote:
> +struct drm_gpuva_manager {
> + /**
> + * @name: the name of the DRM GPU VA space
> + */
> + const char *name;
> +
> + /**
> + * @mm_start: start of the VA space
> + */
> + u64 mm_start;
> +
> + /**
> + * @mm_range: length of the VA space
> + */
> + u64 mm_range;
> +
> + /**
> + * @mtree: the &maple_tree to track GPU VA mappings
> + */
> + struct maple_tree mtree;
> +
> + /**
> + * @kernel_alloc_node:
> + *
> + * &drm_gpuva representing the address space cutout reserved for
> + * the kernel
> + */
> + struct drm_gpuva kernel_alloc_node;
> +
> + /**
> + * @ops: &drm_gpuva_fn_ops providing the split/merge steps to drivers
> + */
> + struct drm_gpuva_fn_ops *ops;
Any reason for not making that a const object (same goes for all the
functions being passed a drm_gpuva_fn_ops)?
> +};
next prev parent reply other threads:[~2023-04-28 10:18 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 1:27 [PATCH drm-next v3 00/15] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 01/15] drm: execution context for GEM buffers v3 Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 02/15] drm_exec: fix double dma_resv unlock Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 03/15] maple_tree: split up MA_STATE() macro Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 04/15] drm: manager to keep track of GPUs VA mappings Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 5:29 ` kernel test robot
2023-04-04 5:29 ` kernel test robot
2023-04-04 5:29 ` [Nouveau] " kernel test robot
2023-04-21 10:46 ` Boris Brezillon
2023-04-21 10:46 ` Boris Brezillon
2023-04-21 10:46 ` [Nouveau] " Boris Brezillon
2023-04-28 10:18 ` Boris Brezillon [this message]
2023-04-28 10:18 ` Boris Brezillon
2023-04-28 10:18 ` [Nouveau] " Boris Brezillon
2023-04-04 1:27 ` [PATCH drm-next v3 05/15] drm: debugfs: provide infrastructure to dump a DRM GPU VA space Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 4:05 ` kernel test robot
2023-04-04 4:05 ` kernel test robot
2023-04-04 4:05 ` [Nouveau] " kernel test robot
2023-04-04 8:36 ` kernel test robot
2023-04-04 8:36 ` kernel test robot
2023-04-04 8:36 ` [Nouveau] " kernel test robot
2023-04-04 1:27 ` [PATCH drm-next v3 06/15] drm/nouveau: new VM_BIND uapi interfaces Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 07/15] drm/nouveau: get vmm via nouveau_cli_vmm() Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 08/15] drm/nouveau: bo: initialize GEM GPU VA interface Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 09/15] drm/nouveau: move usercopy helpers to nouveau_drv.h Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 10/15] drm/nouveau: fence: separate fence alloc and emit Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 7:55 ` kernel test robot
2023-04-04 7:55 ` kernel test robot
2023-04-04 7:55 ` [Nouveau] " kernel test robot
2023-04-04 1:27 ` [PATCH drm-next v3 11/15] drm/nouveau: fence: fail to emit when fence context is killed Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 12/15] drm/nouveau: chan: provide nouveau_channel_kill() Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 13/15] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 5:50 ` kernel test robot
2023-04-04 5:50 ` kernel test robot
2023-04-04 5:50 ` [Nouveau] " kernel test robot
2023-04-04 1:27 ` [PATCH drm-next v3 14/15] drm/nouveau: implement new VM_BIND uAPI Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
2023-04-04 1:27 ` [PATCH drm-next v3 15/15] drm/nouveau: debugfs: implement DRM GPU VA debugfs Danilo Krummrich
2023-04-04 1:27 ` Danilo Krummrich
2023-04-04 1:27 ` [Nouveau] " Danilo Krummrich
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=20230428121813.309ea609@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Liam.Howlett@oracle.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=alexdeucher@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dakr@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ogabbay@kernel.org \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.org \
/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.