dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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

  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).