iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Sven Peter via iommu <iommu@lists.linux-foundation.org>
To: "Mark Kettenis" <mark.kettenis@xs4all.nl>
Cc: arnd@kernel.org, devicetree@vger.kernel.org, will@kernel.org,
	marcan@marcan.st, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	maz@kernel.org, mohamed.mediouni@caramail.com,
	robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org,
	stan@corellium.com
Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver
Date: Sun, 21 Mar 2021 18:28:59 +0100	[thread overview]
Message-ID: <9b2a6b19-9751-4459-af99-7ab3e20b6106@www.fastmail.com> (raw)
In-Reply-To: <c1bcc0609e920bc6@bloch.sibelius.xs4all.nl>



Hi Mark,

Sorry for the spam if you get this message twice. This is pretty embarrassing
but I've just switched mail providers after ProtonMail messed up yesterday and
it looks like my new one defaulted to sending HTML messages even though I only
typed plaintext. This shouldn't have happened in the first place but it
certainly shouldn't happen again now :-(

> On 21. Mar 2021, at 17:00, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> I don't think the first option is going to work for PCIe.  PCIe
> devices will have to use "iommu-map" properties to map PCI devices to
> the right iommu, and the currently implementation seems to assume that
> #iommu-cells = <1>.  The devictree binding[1] doesn't explicitly state
> that it relies on #iommu-cells = <1>, but it isn't clear how the
> rid-base to iommu-base mapping mechanism would work when that isn't
> the case.
> 
> Now the PCIe DARTs are simpler and seem to have only one "instance"
> per DART.  So if we keep #iommu-cells = <1> for those, you'd still be
> fine using the first approach.

Good point, I guess that only leaves option two for now then.
Having some DARTs use cells = <1> and others <2> sounds confusing to me.


> 
> As I mentioned before, not all DARTs support the full 32-bit aperture.
> In particular the PCIe DARTs support a smaller address-space.  It is
> not clear whether this is a restriction of the PCIe host controller or
> the DART, but the Apple Device Tree has "vm-base" and "vm-size"
> properties that encode the base address and size of the aperture.
> These single-cell properties which is probably why for the USB DARTs
> only "vm-base" is given; since "vm-base" is 0, a 32-bit number
> wouldn't be able to encode the full aperture size.  We could make them
> 64-bit numbers in the Linux device tree though and always be explicit
> about the size.  Older Sun SPARC machines used a single "virtual-dma"
> property to encode the aperture.  We could do someting similar.  You
> would use this property to initialize domain->geometry.aperture_start
> and domain->geometry.aperture_end in diff 3/3 of this series.
> 
> I think it would make sense to include this in this series, as this
> would make adding support for PCIe very easy, and PCIe gives you
> aupport for network (both wired and wireless) and the type-A USB ports
> on the mini.



Agreed, I'd ideally like to converge on a device tree binding
that won't have to change in the near future.

I've tried to use an address space larger than 32bit and that seems to
work for parts of the dwc3 controller but breaks for the xhci parts because
the upper lines don't seem to be connected there (e.g. if xhci tries to
use <0x1 0xffff0000> I get a fault for <0 0xffff0000>).

Looking at other iommu drivers I have found the following two similar
bindings:

qcom uses a ranges property with a 64bit address and 32 bit size [1]

  apps_iommu: iommu@1e20000 {
      ...
      ranges = <0 0x1e20000 0x40000>;
      ...
  };

and tegra seems to support a dma-window property with 32bit address
and size [2]

  smmu {
          [...]
          dma-window = <0 0x40000000>;    /* IOVA start & length */
          [...]
  };

I believe there already is of_get_dma_window to handle parsing this
in the common iommu code [3] but I can't find any place using it.
It's a little bit more complex that we need since it allows to specify the
number of cells for both the address and the size but it should allow us to
express all possible configurations:

  usb_dart {
      [ ... ]
      #dma-address-cells = <1>;
      #dma-size-cells = <2>;
      dma-window = <0 0x1 0x0>;
      [ ... ]
  };
  pcie_dart {
      [ ... ]
      #dma-address-cells = <1>;
      #dma-size-cells = <1>;
      dma-window = <0x100000 0x3fe00000>;
      [ ... ]
  };

where #dma-address-cells and #dma-size-cells default to
#address-cells and #size-cells respectively if I understand
the code correctly. That way we could also just always use
a 64bit address and size in the DT, e.g.

  pcie_dart {
      [ ... ]
      dma-window = <0 0x100000 0 0x3fe00000>;
      [ ... ]
  };


Best,

Sven


[1] Documentation/devicetree/bindings/iommu/qcom,iommu.txt
[2] Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt
[3] drivers/iommu/of_iommu.c
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  parent reply	other threads:[~2021-03-21 17:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 15:19 [PATCH 0/3] Apple M1 DART IOMMU driver Sven Peter via iommu
2021-03-20 15:19 ` [PATCH 1/3] iommu: io-pgtable: add DART pagetable format Sven Peter via iommu
2021-03-24 16:37   ` Robin Murphy
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 via iommu
2021-03-22  0:15   ` Rob Herring
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 17:22   ` Sven Peter via iommu
2021-03-21 18:35     ` Mark Kettenis
2021-03-22 22:17       ` Sven Peter via iommu
2021-03-23 20:00         ` Mark Kettenis
2021-03-23 21:03           ` Sven Peter via iommu
2021-03-21 17:28   ` Sven Peter via iommu [this message]
2021-03-23 20:53   ` Rob Herring
2021-03-23 22:33     ` Mark Kettenis
2021-03-25  7:53     ` Sven Peter via iommu
2021-03-25 11:50       ` Robin Murphy
2021-03-25 20:49         ` Sven Peter via iommu
2021-03-27 15:33         ` Sven Peter via iommu
2021-03-25 21:41       ` Arnd Bergmann
2021-03-26 15:59         ` Mark Kettenis
2021-03-26 16:09           ` Arnd Bergmann
2021-03-26 16:10           ` Sven Peter via iommu
2021-03-26 16:38             ` Arnd Bergmann
2021-03-26 17:06               ` Sven Peter via iommu
2021-03-26 17:26               ` Mark Kettenis
2021-03-26 17:34                 ` Robin Murphy
2021-03-26 17:51                   ` Sven Peter via iommu
2021-03-26 19:59                     ` Arnd Bergmann
2021-03-26 21:16                       ` Mark Kettenis
2021-03-27 15:30                       ` Sven Peter via iommu
2021-03-26 20:03                 ` Arnd Bergmann
2021-03-26 21:13                   ` Mark Kettenis
2021-03-24 15:29 ` Robin Murphy
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=9b2a6b19-9751-4459-af99-7ab3e20b6106@www.fastmail.com \
    --to=iommu@lists.linux-foundation.org \
    --cc=arnd@kernel.org \
    --cc=devicetree@vger.kernel.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+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stan@corellium.com \
    --cc=sven@svenpeter.dev \
    --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 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).