All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sven Peter" <sven@svenpeter.dev>
To: "Robin Murphy" <robin.murphy@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>
Cc: iommu@lists.linux-foundation.org, joro@8bytes.org,
	"Will Deacon" <will@kernel.org>,
	"Arnd Bergmann" <arnd@kernel.org>,
	"Hector Martin" <marcan@marcan.st>,
	"Marc Zyngier" <maz@kernel.org>,
	mohamed.mediouni@caramail.com, stan@corellium.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Sat, 27 Mar 2021 16:33:29 +0100	[thread overview]
Message-ID: <26c9b3cc-a04f-444d-ada4-0c9bc99684e5@www.fastmail.com> (raw)
In-Reply-To: <33b3ce35-c42f-331a-79a2-e38917d588ef@arm.com>

Hi Robin,


On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
> On 2021-03-25 07:53, Sven Peter wrote:
> > The iommu binding documentation [1] mentions that
> > 
> >      The device tree node of the IOMMU device's parent bus must contain a valid
> >      "dma-ranges" property that describes how the physical address space of the
> >      IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> >      1:1 mapping from IOMMU to memory.
> > 
> > which, if I understand this correctly, means that the 'dma-ranges' for the
> > parent bus of the iommu should be empty since the DART hardware can see the
> > full physical address space with a 1:1 mapping.
> > 
> > 
> > The documentation also mentions that
> > 
> >       When an "iommus" property is specified in a device tree node, the IOMMU
> >       will be used for address translation. If a "dma-ranges" property exists
> >       in the device's parent node it will be ignored.
> > 
> > which means that specifying a 'dma-ranges' in the parent bus of any devices
> > that use the iommu will just be ignored.
> 
> I think that's just wrong and wants updating (or at least clarifying). 
> The high-level view now is that we use "dma-ranges" to describe 
> limitations imposed by a bridge or interconnect segment, and that can 
> certainly happen upstream of an IOMMU. As it happens, I've just recently 
> sent a patch for precisely that case[1].
> 
> I guess what it might have been trying to say is that "dma-ranges" 
> *does* become irrelevant in terms of constraining what physical memory 
> is usable for DMA, but that shouldn't imply that its meaning doesn't 
> just shift to a different purpose.

Should I add a patch to clarify this paragraph for v2 or submit a separate
one-off patch? I'm not entirely sure about the process here but I could add
a Suggested-by: to the commit if that's fine with you.



Best,

Sven

WARNING: multiple messages have this Message-ID (diff)
From: Sven Peter via iommu <iommu@lists.linux-foundation.org>
To: "Robin Murphy" <robin.murphy@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>
Cc: Arnd Bergmann <arnd@kernel.org>,
	devicetree@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Hector Martin <marcan@marcan.st>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	mohamed.mediouni@caramail.com, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, stan@corellium.com
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Sat, 27 Mar 2021 16:33:29 +0100	[thread overview]
Message-ID: <26c9b3cc-a04f-444d-ada4-0c9bc99684e5@www.fastmail.com> (raw)
In-Reply-To: <33b3ce35-c42f-331a-79a2-e38917d588ef@arm.com>

Hi Robin,


On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
> On 2021-03-25 07:53, Sven Peter wrote:
> > The iommu binding documentation [1] mentions that
> > 
> >      The device tree node of the IOMMU device's parent bus must contain a valid
> >      "dma-ranges" property that describes how the physical address space of the
> >      IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> >      1:1 mapping from IOMMU to memory.
> > 
> > which, if I understand this correctly, means that the 'dma-ranges' for the
> > parent bus of the iommu should be empty since the DART hardware can see the
> > full physical address space with a 1:1 mapping.
> > 
> > 
> > The documentation also mentions that
> > 
> >       When an "iommus" property is specified in a device tree node, the IOMMU
> >       will be used for address translation. If a "dma-ranges" property exists
> >       in the device's parent node it will be ignored.
> > 
> > which means that specifying a 'dma-ranges' in the parent bus of any devices
> > that use the iommu will just be ignored.
> 
> I think that's just wrong and wants updating (or at least clarifying). 
> The high-level view now is that we use "dma-ranges" to describe 
> limitations imposed by a bridge or interconnect segment, and that can 
> certainly happen upstream of an IOMMU. As it happens, I've just recently 
> sent a patch for precisely that case[1].
> 
> I guess what it might have been trying to say is that "dma-ranges" 
> *does* become irrelevant in terms of constraining what physical memory 
> is usable for DMA, but that shouldn't imply that its meaning doesn't 
> just shift to a different purpose.

Should I add a patch to clarify this paragraph for v2 or submit a separate
one-off patch? I'm not entirely sure about the process here but I could add
a Suggested-by: to the commit if that's fine with you.



Best,

Sven
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: "Sven Peter" <sven@svenpeter.dev>
To: "Robin Murphy" <robin.murphy@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>
Cc: iommu@lists.linux-foundation.org, joro@8bytes.org,
	"Will Deacon" <will@kernel.org>,
	"Arnd Bergmann" <arnd@kernel.org>,
	"Hector Martin" <marcan@marcan.st>,
	"Marc Zyngier" <maz@kernel.org>,
	mohamed.mediouni@caramail.com, stan@corellium.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Sat, 27 Mar 2021 16:33:29 +0100	[thread overview]
Message-ID: <26c9b3cc-a04f-444d-ada4-0c9bc99684e5@www.fastmail.com> (raw)
In-Reply-To: <33b3ce35-c42f-331a-79a2-e38917d588ef@arm.com>

Hi Robin,


On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
> On 2021-03-25 07:53, Sven Peter wrote:
> > The iommu binding documentation [1] mentions that
> > 
> >      The device tree node of the IOMMU device's parent bus must contain a valid
> >      "dma-ranges" property that describes how the physical address space of the
> >      IOMMU maps to memory. An empty "dma-ranges" property means that there is a
> >      1:1 mapping from IOMMU to memory.
> > 
> > which, if I understand this correctly, means that the 'dma-ranges' for the
> > parent bus of the iommu should be empty since the DART hardware can see the
> > full physical address space with a 1:1 mapping.
> > 
> > 
> > The documentation also mentions that
> > 
> >       When an "iommus" property is specified in a device tree node, the IOMMU
> >       will be used for address translation. If a "dma-ranges" property exists
> >       in the device's parent node it will be ignored.
> > 
> > which means that specifying a 'dma-ranges' in the parent bus of any devices
> > that use the iommu will just be ignored.
> 
> I think that's just wrong and wants updating (or at least clarifying). 
> The high-level view now is that we use "dma-ranges" to describe 
> limitations imposed by a bridge or interconnect segment, and that can 
> certainly happen upstream of an IOMMU. As it happens, I've just recently 
> sent a patch for precisely that case[1].
> 
> I guess what it might have been trying to say is that "dma-ranges" 
> *does* become irrelevant in terms of constraining what physical memory 
> is usable for DMA, but that shouldn't imply that its meaning doesn't 
> just shift to a different purpose.

Should I add a patch to clarify this paragraph for v2 or submit a separate
one-off patch? I'm not entirely sure about the process here but I could add
a Suggested-by: to the commit if that's fine with you.



Best,

Sven

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-03-27 15:35 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 15:19 [PATCH 0/3] Apple M1 DART IOMMU driver Sven Peter
2021-03-20 15:19 ` Sven Peter
2021-03-20 15:19 ` Sven Peter via iommu
2021-03-20 15:19 ` [PATCH 1/3] iommu: io-pgtable: add DART pagetable format Sven Peter
2021-03-20 15:19   ` Sven Peter
2021-03-20 15:19   ` Sven Peter via iommu
2021-03-24 16:37   ` Robin Murphy
2021-03-24 16:37     ` Robin Murphy
2021-03-24 16:37     ` Robin Murphy
2021-03-25 20:47     ` Sven Peter
2021-03-25 20:47       ` Sven Peter
2021-03-25 20:47       ` Sven Peter via iommu
2021-03-20 15:20 ` [PATCH 2/3] dt-bindings: iommu: add DART iommu bindings Sven Peter
2021-03-20 15:20   ` Sven Peter
2021-03-20 15:20   ` Sven Peter via iommu
2021-03-22  0:15   ` Rob Herring
2021-03-22  0:15     ` Rob Herring
2021-03-22  0:15     ` Rob Herring
2021-03-22 18:16     ` Sven Peter
2021-03-22 18:16       ` Sven Peter
2021-03-22 18:16       ` Sven Peter via iommu
2021-03-21 16:00 ` [PATCH 0/3] Apple M1 DART IOMMU driver Mark Kettenis
2021-03-21 16:00   ` Mark Kettenis
2021-03-21 16:00   ` Mark Kettenis
2021-03-21 17:22   ` Sven Peter via iommu
2021-03-21 18:35     ` Mark Kettenis
2021-03-21 18:35       ` Mark Kettenis
2021-03-21 18:35       ` Mark Kettenis
2021-03-22 22:17       ` Sven Peter
2021-03-22 22:17         ` Sven Peter
2021-03-22 22:17         ` Sven Peter via iommu
2021-03-23 20:00         ` Mark Kettenis
2021-03-23 20:00           ` Mark Kettenis
2021-03-23 20:00           ` Mark Kettenis
2021-03-23 21:03           ` Sven Peter
2021-03-23 21:03             ` Sven Peter
2021-03-23 21:03             ` Sven Peter via iommu
2021-03-21 17:28   ` Sven Peter
2021-03-21 17:28     ` Sven Peter
2021-03-21 17:28     ` Sven Peter via iommu
2021-03-23 20:53   ` Rob Herring
2021-03-23 20:53     ` Rob Herring
2021-03-23 20:53     ` Rob Herring
2021-03-23 22:33     ` Mark Kettenis
2021-03-23 22:33       ` Mark Kettenis
2021-03-23 22:33       ` Mark Kettenis
2021-03-25  7:53     ` Sven Peter
2021-03-25  7:53       ` Sven Peter
2021-03-25  7:53       ` Sven Peter via iommu
2021-03-25 11:50       ` Robin Murphy
2021-03-25 11:50         ` Robin Murphy
2021-03-25 11:50         ` Robin Murphy
2021-03-25 20:49         ` Sven Peter
2021-03-25 20:49           ` Sven Peter
2021-03-25 20:49           ` Sven Peter via iommu
2021-03-27 15:33         ` Sven Peter [this message]
2021-03-27 15:33           ` Sven Peter
2021-03-27 15:33           ` Sven Peter via iommu
2021-03-25 21:41       ` Arnd Bergmann
2021-03-25 21:41         ` Arnd Bergmann
2021-03-25 21:41         ` Arnd Bergmann
2021-03-26 15:59         ` Mark Kettenis
2021-03-26 15:59           ` Mark Kettenis
2021-03-26 15:59           ` Mark Kettenis
2021-03-26 16:09           ` Arnd Bergmann
2021-03-26 16:09             ` Arnd Bergmann
2021-03-26 16:09             ` Arnd Bergmann
2021-03-26 16:10           ` Sven Peter
2021-03-26 16:10             ` Sven Peter
2021-03-26 16:10             ` Sven Peter via iommu
2021-03-26 16:38             ` Arnd Bergmann
2021-03-26 16:38               ` Arnd Bergmann
2021-03-26 16:38               ` Arnd Bergmann
2021-03-26 17:06               ` Sven Peter
2021-03-26 17:06                 ` Sven Peter
2021-03-26 17:06                 ` Sven Peter via iommu
2021-03-26 17:26               ` Mark Kettenis
2021-03-26 17:26                 ` Mark Kettenis
2021-03-26 17:26                 ` Mark Kettenis
2021-03-26 17:34                 ` Robin Murphy
2021-03-26 17:34                   ` Robin Murphy
2021-03-26 17:34                   ` Robin Murphy
2021-03-26 17:51                   ` Sven Peter
2021-03-26 17:51                     ` Sven Peter
2021-03-26 17:51                     ` Sven Peter via iommu
2021-03-26 19:59                     ` Arnd Bergmann
2021-03-26 19:59                       ` Arnd Bergmann
2021-03-26 19:59                       ` Arnd Bergmann
2021-03-26 21:16                       ` Mark Kettenis
2021-03-26 21:16                         ` Mark Kettenis
2021-03-26 21:16                         ` Mark Kettenis
2021-03-27 15:30                       ` Sven Peter
2021-03-27 15:30                         ` Sven Peter
2021-03-27 15:30                         ` Sven Peter via iommu
2021-03-26 20:03                 ` Arnd Bergmann
2021-03-26 20:03                   ` Arnd Bergmann
2021-03-26 20:03                   ` Arnd Bergmann
2021-03-26 21:13                   ` Mark Kettenis
2021-03-26 21:13                     ` Mark Kettenis
2021-03-26 21:13                     ` Mark Kettenis
2021-03-24 15:29 ` Robin Murphy
2021-03-24 15:29   ` Robin Murphy
2021-03-24 15:29   ` Robin Murphy
2021-03-25  7:58   ` Sven Peter
2021-03-25  7:58     ` Sven Peter
2021-03-25  7:58     ` Sven Peter via iommu

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=26c9b3cc-a04f-444d-ada4-0c9bc99684e5@www.fastmail.com \
    --to=sven@svenpeter.dev \
    --cc=arnd@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.kettenis@xs4all.nl \
    --cc=maz@kernel.org \
    --cc=mohamed.mediouni@caramail.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stan@corellium.com \
    --cc=will@kernel.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.