All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: "Guido Günther" <agx@sigxcpu.org>
Cc: etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	patchwork-lst@pengutronix.de, kernel@pengutronix.de,
	Russell King <linux+etnaviv@armlinux.org.uk>
Subject: Re: [PATCH v3 7/8] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get
Date: Thu, 15 Aug 2019 11:06:38 +0200	[thread overview]
Message-ID: <1565859998.2641.27.camel@pengutronix.de> (raw)
In-Reply-To: <20190814095955.GA16514@bogon.m.sigxcpu.org>

Am Mittwoch, den 14.08.2019, 11:59 +0200 schrieb Guido Günther:
> Hi,
> On Fri, Aug 09, 2019 at 02:04:23PM +0200, Lucas Stach wrote:
> > In preparation to having a context per process, etnaviv_gem_mapping_get
> > should not use the current GPU context, but needs to be told which
> > context to use.
> > 
> > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > > Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gem.c        | 22 ++++++++++++--------
> >  drivers/gpu/drm/etnaviv/etnaviv_gem.h        |  3 ++-
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  3 ++-
> >  3 files changed, 17 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > index 0ccc3c4dffc4..04c8170f76cd 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > @@ -248,7 +248,8 @@ void etnaviv_gem_mapping_unreference(struct etnaviv_vram_mapping *mapping)
> >  }
> >  
> >  struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> > > > -	struct drm_gem_object *obj, struct etnaviv_gpu *gpu)
> > > > +	struct drm_gem_object *obj, struct etnaviv_gpu *gpu,
> > > > +	struct etnaviv_iommu_context *mmu_context)
> >  {
> > > >  	struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
> > > >  	struct etnaviv_vram_mapping *mapping;
> > @@ -256,7 +257,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> > > >  	int ret = 0;
> >  
> > > >  	mutex_lock(&etnaviv_obj->lock);
> > > > -	mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, gpu->mmu_context);
> > > > +	mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, mmu_context);
> > > >  	if (mapping) {
> > > >  		/*
> > > >  		 * Holding the object lock prevents the use count changing
> > @@ -265,12 +266,12 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> > > >  		 * the MMU owns this mapping to close this race.
> > > >  		 */
> > > >  		if (mapping->use == 0) {
> > > > -			mutex_lock(&gpu->mmu_context->lock);
> > > > -			if (mapping->context == gpu->mmu_context)
> > > > +			mutex_lock(&mmu_context->lock);
> > > > +			if (mapping->context == mmu_context)
> > > >  				mapping->use += 1;
> > > >  			else
> > > >  				mapping = NULL;
> > > > -			mutex_unlock(&gpu->mmu_context->lock);
> > > > +			mutex_unlock(&mmu_context->lock);
> > > >  			if (mapping)
> > > >  				goto out;
> > > >  		} else {
> > @@ -303,11 +304,12 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> > > >  		list_del(&mapping->obj_node);
> > > >  	}
> >  
> > > > -	mapping->context = gpu->mmu_context;
> > > > +	etnaviv_iommu_context_get(mmu_context);
> > > > +	mapping->context = mmu_context;
> > > >  	mapping->use = 1;
> >  
> > > > -	ret = etnaviv_iommu_map_gem(gpu->mmu_context, etnaviv_obj,
> > > > -				    gpu->memory_base, mapping);
> > > > +	ret = etnaviv_iommu_map_gem(mmu_context, etnaviv_obj, gpu->memory_base,
> > > > +				    mapping);
> > > >  	if (ret < 0)
> >  		kfree(mapping);
> 
> Does this error path need a etnaviv_iommu_context_put()?

Good catch! Thanks, I'll fix this.

Regards,
Lucas
> 
> apart from that
> 
> > Reviewed-by: Guido Günther <agx@sigxcpu.org> 
> 
>  -- Guido

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-08-15  9:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-09 12:04 [PATCH v3 1/8] drm/etnaviv: simplify unbind checks Lucas Stach
2019-08-09 12:04 ` [PATCH v3 2/8] drm/etnaviv: split out cmdbuf mapping into address space Lucas Stach
2019-08-09 12:04 ` [PATCH v3 3/8] drm/etnaviv: share a single cmdbuf suballoc region across all GPUs Lucas Stach
2019-08-13 14:01   ` Guido Günther
2019-08-09 12:04 ` [PATCH v3 4/8] drm/etnaviv: replace MMU flush marker with flush sequence Lucas Stach
2019-08-09 12:16   ` Philipp Zabel
2019-08-13 18:20   ` Guido Günther
2019-08-09 12:04 ` [PATCH v3 5/8] drm/etnaviv: rework MMU handling Lucas Stach
2019-08-13 15:27   ` Guido Günther
2019-08-09 12:04 ` [PATCH v3 6/8] drm/etnaviv: split out starting of FE idle loop Lucas Stach
2019-08-13 14:21   ` Guido Günther
2019-08-09 12:04 ` [PATCH v3 7/8] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get Lucas Stach
2019-08-14  9:59   ` Guido Günther
2019-08-15  9:06     ` Lucas Stach [this message]
2019-08-09 12:04 ` [PATCH v3 8/8] drm/etnaviv: implement per-process address spaces on MMUv2 Lucas Stach
2019-08-09 12:25   ` Philipp Zabel
2019-08-09 13:45   ` Lucas Stach
2019-08-14 10:00   ` 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=1565859998.2641.27.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=agx@sigxcpu.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=kernel@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 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.