From: Philipp Zabel <p.zabel@pengutronix.de>
To: Lucas Stach <l.stach@pengutronix.de>, etnaviv@lists.freedesktop.org
Cc: Russell King <linux+etnaviv@armlinux.org.uk>,
dri-devel@lists.freedesktop.org, kernel@pengutronix.de,
patchwork-lst@pengutronix.de
Subject: Re: [PATCH v2 5/8] drm/etnaviv: rework MMU handling
Date: Mon, 29 Jul 2019 17:35:11 +0200 [thread overview]
Message-ID: <1564414511.7633.9.camel@pengutronix.de> (raw)
In-Reply-To: <20190705171727.27501-5-l.stach@pengutronix.de>
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> This reworks the MMU handling to make it possible to have multiple MMU contexts.
> A context is basically one instance of GPU page tables. Currently we have one
> set of page tables per GPU, which isn't all that clever, as it has the
> following two consequences:
>
> 1. All GPU clients (aka processes) are sharing the same pagetables, which means
> there is no isolation between clients, but only between GPU assigned memory
> spaces and the rest of the system. Better than nothing, but also not great.
>
> 2. Clients operating on the same set of buffers with different etnaviv GPU
> cores, e.g. a workload using both the 2D and 3D GPU, need to map the used
> buffers into the pagetable sets of each used GPU.
>
> This patch reworks all the MMU handling to introduce the abstraction of the
> MMU context. A context can be shared across different GPU cores, as long as
> they have compatible MMU implementations, which is the case for all systems
> with Vivante GPUs seen in the wild.
>
> As MMUv1 is not able to change pagetables on the fly, without a
> "stop the world" operation, which stops GPU, changes pagetables via CPU
> interaction, restarts GPU, the implementation introduces a shared context on
> MMUv1, which is returned whenever there is a request for a new context.
>
> This patch assigns a MMU context to each GPU, so on MMUv2 systems there is
> still one set of pagetables per GPU, but due to the shared context MMUv1
> systems see a change in behavior as now a single pagetable set is used
> across all GPU cores.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +-
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 8 +-
> drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 6 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 4 +-
> drivers/gpu/drm/etnaviv/etnaviv_dump.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 14 +-
> drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 151 ++++++------
> drivers/gpu/drm/etnaviv/etnaviv_iommu.h | 20 --
> drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 264 +++++++++------------
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 264 +++++++++++++--------
> drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 88 +++++--
> 14 files changed, 441 insertions(+), 413 deletions(-)
> delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.h
>
[...]
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -223,12 +223,12 @@ int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset)
>
> static struct etnaviv_vram_mapping *
> etnaviv_gem_get_vram_mapping(struct etnaviv_gem_object *obj,
> - struct etnaviv_iommu *mmu)
> + struct etnaviv_iommu_context *context)
> {
> struct etnaviv_vram_mapping *mapping;
>
> list_for_each_entry(mapping, &obj->vram_list, obj_node) {
> - if (mapping->mmu == mmu)
> + if (mapping->context == context)
> return mapping;
> }
>
> @@ -266,7 +266,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> */
> if (mapping->use == 0) {
> mutex_lock(&gpu->mmu->lock);
> - if (mapping->mmu == gpu->mmu)
> + if (mapping->context == gpu->mmu)
Is there a reason that mmu parameters and mapping->mmu are renamed to
context, but gpu->mmu is not?
Could be renamed to gpu->mmu_context for consistency.
[...]
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 7b396ac5dba5..a53fecd17fa9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
[...]
> @@ -1684,11 +1690,11 @@ static void etnaviv_gpu_unbind(struct device *dev, struct device *master,
> if (gpu->initialized) {
> etnaviv_cmdbuf_free(&gpu->buffer);
> etnaviv_cmdbuf_suballoc_unmap(gpu->mmu, &gpu->cmdbuf_mapping);
> - etnaviv_iommu_destroy(gpu->mmu);
> + etnaviv_iommu_context_put(gpu->mmu);
> + etnaviv_iommu_global_fini(gpu);
> gpu->initialized = false;
> }
>
> -
This should be fixed in a previous patch.
[...]
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 3348d9962177..cf49f0e2e1cb 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
[...]
> @@ -391,21 +369,107 @@ void etnaviv_iommu_put_suballoc_va(struct etnaviv_iommu *mmu,
>
> mapping->use = 0;
>
> - if (mmu->version == ETNAVIV_IOMMU_V1)
> + if (context->global->version == ETNAVIV_IOMMU_V1)
> return;
>
> - mutex_lock(&mmu->lock);
> - etnaviv_domain_unmap(mmu->domain, node->start, node->size);
> + mutex_lock(&context->lock);
> + etnaviv_context_unmap(context, node->start, node->size);
> drm_mm_remove_node(node);
> - mutex_unlock(&mmu->lock);
> + mutex_unlock(&context->lock);
> +}
> +
> +size_t etnaviv_iommu_dump_size(struct etnaviv_iommu_context *context)
> +{
> + return context->global->ops->dump_size(context);
> }
>
> -size_t etnaviv_iommu_dump_size(struct etnaviv_iommu *iommu)
> +void etnaviv_iommu_dump(struct etnaviv_iommu_context *context, void *buf)
> {
> - return iommu->domain->ops->dump_size(iommu->domain);
> + context->global->ops->dump(context, buf);
> }
>
> -void etnaviv_iommu_dump(struct etnaviv_iommu *iommu, void *buf)
> +extern const struct etnaviv_iommu_ops etnaviv_iommuv1_ops;
> +extern const struct etnaviv_iommu_ops etnaviv_iommuv2_ops;
These should be moved into a header that is also included where the ops
are defined.
Apart from this,
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-07-29 15:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 17:17 [PATCH v2 1/8] drm/etnaviv: simplify unbind checks Lucas Stach
2019-07-05 17:17 ` [PATCH v2 2/8] drm/etnaviv: split out cmdbuf mapping into address space Lucas Stach
2019-07-24 13:51 ` Philipp Zabel
2019-08-02 13:39 ` Guido Günther
2019-08-02 14:21 ` Philipp Zabel
2019-08-02 18:23 ` Guido Günther
2019-08-02 18:40 ` Guido Günther
2019-08-08 10:26 ` Guido Günther
2019-08-09 9:17 ` Lucas Stach
2019-08-09 9:28 ` Guido Günther
2019-07-05 17:17 ` [PATCH v2 3/8] drm/etnaviv: share a single cmdbuf suballoc region across all GPUs Lucas Stach
2019-07-24 15:37 ` Philipp Zabel
2019-07-05 17:17 ` [PATCH v2 4/8] drm/etnaviv: replace MMU flush marker with flush sequence Lucas Stach
2019-07-24 15:45 ` Philipp Zabel
2019-08-13 15:27 ` Guido Günther
2019-07-05 17:17 ` [PATCH v2 5/8] drm/etnaviv: rework MMU handling Lucas Stach
2019-07-29 15:35 ` Philipp Zabel [this message]
2019-07-05 17:17 ` [PATCH v2 6/8] drm/etnaviv: split out starting of FE idle loop Lucas Stach
2019-07-29 15:36 ` Philipp Zabel
2019-07-05 17:17 ` [PATCH v2 7/8] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get Lucas Stach
2019-07-29 15:38 ` Philipp Zabel
2019-07-05 17:17 ` [PATCH v2 8/8] drm/etnaviv: implement per-process address spaces on MMUv2 Lucas Stach
2019-07-30 9:44 ` Philipp Zabel
2019-07-24 12:11 ` [PATCH v2 1/8] drm/etnaviv: simplify unbind checks Philipp Zabel
2019-08-02 8:14 ` Guido Günther
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=1564414511.7633.9.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=patchwork-lst@pengutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).