public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Sasha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	arnd-r2nGTMty4D4@public.gmane.org,
	Tomasz Figa <tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Daniel Kurtz <djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Subject: Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver
Date: Thu, 17 Dec 2015 11:12:39 +0800	[thread overview]
Message-ID: <1450321959.22854.141.camel@mhfsdcap03> (raw)
In-Reply-To: <56715D8D.3050102-5wv7dgnIgG8@public.gmane.org>

On Wed, 2015-12-16 at 12:48 +0000, Robin Murphy wrote:
> On 16/12/15 05:59, Yong Wu wrote:
> > On Tue, 2015-12-15 at 12:37 +0000, Robin Murphy wrote:
> >> On 15/12/15 03:28, Yong Wu wrote:
> >>> On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> >>>> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
[...]
> > Following your comment above, I test as below. Then the flows seems meet
> > the "best case" that the iommu core will help create default DMA domain.
> >
> > @@ -664,19 +636,41 @@ static int mtk_iommu_probe(struct platform_device
> > *pdev)
> > for (i = 0; i < larb_nr; i++) {
> > 		struct device_node *larbnode;
> > 		struct platform_device *plarbdev;
> >
> > 		larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
> > 		if (!larbnode)
> > 			return -EINVAL;
> >
> >                  plarbdev = of_find_device_by_node(larbnode);
> >                  of_node_put(larbnode);
> > -               if (!plarbdev)
> > -                       return -EPROBE_DEFER;
> > +               if (!plarbdev) {
> > +                       plarbdev = of_platform_device_create(larbnode,
> > NULL, platform_bus_type.dev_root);
> > +                       if (IS_ERR(pdev))
> > +                               return -EPROBE_DEFER;
> > +               }
> > }
> >
> > I only add of_platform_device_create for the SMI local arbiter devices
> > here.
> >
> > This is a big improvement for us. If this is ok, I will send a quick
> > next version for this.
> 
> In my opinion it's reasonable - we need the whole "IOMMU" to be ready, 

  Thanks.

> so if we already have to short-cut the creation of the M4U part it only 
> seems fair to do the same for the SMI part. That said, would it work to 
> just unconditionally poke the larbs in mtk_iommu_init_fn() before you 
> poke the M4U itself? It would be nice to keep all that stuff together in 
> the same place.

    mtk_iommu_init_fn don't have the larb's "struct device_node". So I
cann't create its platform_device directly.

    I have tried 2 method:
   a) add a mtk_smi_larb_init_fn in the SMI patch.

static int mtk_smi_larb_init_fn(struct device_node *np)
{
	struct platform_device *pdev;

	pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);

	return IS_ERR(pdev) ? PTR_ERR(pdev) :  0;
}
IOMMU_OF_DECLARE(mtk_smi_larb, "mediatek,mt8173-smi-larb",
mtk_smi_larb_init_fn);

   This don't work. It will run after mtk_iommu_init_fn. then the larb's
platform_device also don't exist while m4u's probe.

  b) Copy the code below to mtk_iommu_init_fn.

   for (i = 0; i < larb_nr; i++) {
      xxx
      plarbdev = of_platform_device_create(larbnode,
                      NULL, platform_bus_type.dev_root);
   }

   It works. But then there are 2 same code of parsing the SMI local
arbiter(one is in mtk_iommu_init_fn, the other is in mtk_iommu_init_fn).
It looks not good. I think that the one I wrote in the previous mail is
better, It only add 3 lines, What's your opinion?

> >>>>> +static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> >>>>> +{
> >>>>> +	struct mtk_iommu_data *data;
> >>>>> +	struct mtk_iommu_client_priv *priv;
> >>>>> +
> >>>>> +	priv = dev->archdata.iommu;
> >>>>> +	if (!priv)
> >>>>> +		return ERR_PTR(-ENODEV);
> >>>>> +
> >>>>> +	/* All the client devices are in the same m4u iommu-group */
> >>>>> +	data = dev_get_drvdata(priv->m4udev);
> >>>>> +	if (!data->m4u_group) {
> >>>>> +		data->m4u_group = iommu_group_alloc();
> >>>>> +		if (IS_ERR(data->m4u_group))
> >>>>> +			dev_err(dev, "Failed to allocate M4U IOMMU group\n");
> >>>>> +	}
> >>>>> +	return data->m4u_group;
> >>>>> +}
> >>
> >> As long as this works as expected, then AFAICS you shouldn't have to
> >> have *any* special-case behaviour or tracking of domains at all.
> >
> > We only need one iommu-group, one iommu domain here.
> >
> > What's the special-case behavior, how can we track of domains.
> > Could you help give me a example?
> 
> The beauty of it is that you don't need to. If you guarantee all of an 
> IOMMU's client devices are in the same group, you know you've only got 
> one thing which can be attached to that IOMMU's domains. Therefore, you 
> can freely allow as many domains as you like to *exist*, because there 
> can never be more than one *active* at any given time - the core code 
> enforces that the group is detached from one domain before being 
> attached to another, and the driver's attach and detach calls just 
> become responsible for switching the given domain's page table in and 
> out of the actual hardware. I think it's pretty neat.

It seems that mtk-iommu can not detach/attach dynamically. the iommu
core don't support iommu_detach_device/iommu_attach_device whose
iommu-group have many devices.(Normally there is only one device in a
iommu-group). 

So currently we only iommu_attach_device while probe, it will never
attach/detach again.

All our multimedia modules are in the m4u'domain and share m4u's
pagetable, They won't change pagetable.

> 
> Robin.

  parent reply	other threads:[~2015-12-17  3:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08  9:49 [PATCH v6 0/5] MT8173 IOMMU SUPPORT Yong Wu
2015-12-08  9:49 ` [PATCH v6 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU Yong Wu
     [not found]   ` <1449568153-15643-2-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-12-09  3:33     ` Rob Herring
2015-12-09  6:55       ` Yong Wu
2015-12-08  9:49 ` [PATCH v6 2/5] dt-bindings: mediatek: Add smi dts binding Yong Wu
     [not found]   ` <1449568153-15643-3-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-12-09  3:35     ` Rob Herring
2015-12-08  9:49 ` [PATCH v6 3/5] memory: mediatek: Add SMI driver Yong Wu
     [not found]   ` <1449568153-15643-4-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-12-11  7:22     ` Yong Wu
2015-12-14 18:18   ` Matthias Brugger
     [not found]     ` <24171857.0SPpBlzoZl-FL1YVkE3Js+HtQ08XqlRiA@public.gmane.org>
2015-12-15  2:38       ` Yong Wu
2015-12-15  5:45         ` Daniel Kurtz
     [not found]           ` <CAGS+omDTt646fH3p7kA+EHkR93xGX0APu1sOEjY7MCzQfpO8DA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-16  6:00             ` Yong Wu
2015-12-08  9:49 ` [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver Yong Wu
2015-12-08 10:32   ` kbuild test robot
     [not found]   ` <1449568153-15643-5-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-12-14 14:16     ` Joerg Roedel
     [not found]       ` <20151214141656.GG18805-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2015-12-15  3:28         ` Yong Wu
2015-12-15 12:37           ` Robin Murphy
     [not found]             ` <5670098E.40601-5wv7dgnIgG8@public.gmane.org>
2015-12-16  5:59               ` Yong Wu
2015-12-16 12:48                 ` Robin Murphy
     [not found]                   ` <56715D8D.3050102-5wv7dgnIgG8@public.gmane.org>
2015-12-17  3:12                     ` Yong Wu [this message]
2015-12-16 15:15               ` Joerg Roedel
2015-12-14 18:19     ` Matthias Brugger
     [not found]       ` <566F0821.4080507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-15  2:40         ` Yong Wu
     [not found] ` <1449568153-15643-1-git-send-email-yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-12-08  9:49   ` [PATCH v6 5/5] dts: mt8173: Add iommu/smi nodes for mt8173 Yong Wu

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=1450321959.22854.141.camel@mhfsdcap03 \
    --to=yong.wu-nus5lvnupcjwk0htik3j/w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=djkurtz-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    --cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=tfiga-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox