> On 25. Apr 2022, at 10:56, Yang Yingliang wrote:
>
> It will cause null-ptr-deref in resource_size(), if platform_get_resource()
> returns NULL, move calling resource_size() after devm_ioremap_resource() that
> will check 'res' to avoid null-ptr-deref.
> And use
On Thu, Apr 14, 2022, at 14:42, Robin Murphy wrote:
> Stop calling bus_set_iommu() since it's now unnecessary, and simplify
> the probe failure path accordingly.
>
> Signed-off-by: Robin Murphy
Tested-by: Sven Peter
Reviewed-by: Sven Peter
Can't wait until that saga is completed :)
Sven
It's the same people anyway.
Signed-off-by: Sven Peter
---
MAINTAINERS | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index fd768d43e048..5af879de869c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1375,14 +1375,6 @@ L:
The M1 Pro/Max SoCs come with a new variant of DART which supports a
larger physical address space with a slightly different PTE format.
Pass through the correct paddr address space size to the io-pgtable code
which will take care of the rest.
Signed-off-by: Sven Peter
---
The M1 Max/Pro SoCs come with a new DART variant that is incompatible with
the previous one. Add a new compatible for those.
Signed-off-by: Sven Peter
---
Documentation/devicetree/bindings/iommu/apple,dart.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The DARTs present in the M1 Pro/Max SoC support a 42bit physical address
space by shifting the paddr and extending its mask inside the PTE.
Signed-off-by: Sven Peter
---
drivers/iommu/io-pgtable-arm.c | 30 +-
include/linux/io-pgtable.h | 2 ++
2 files changed,
DART allows to only expose a subpage to the device. While this is an
optional feature on the M1 DARTs the new ones present on the Pro/Max
models require this field in every PTE.
Signed-off-by: Sven Peter
---
drivers/iommu/io-pgtable-arm.c | 10 ++
1 file changed, 10 insertions(+)
diff
Hi,
This is a fairly brief series to add support for the DARTs present in the
M1 Pro/Max. They have two differences that make them incompatible with
those in the M1:
- the physical addresses are shifted left by 4 bits and and have 2 more
bits inside the PTE entries
- the subpage
t;>> Lu Baolu wrote:
>>>>>
>>>>> On 10/20/21 10:22 PM, Marc Zyngier wrote:
>>>>>> On Wed, 20 Oct 2021 06:21:44 +0100,
>>>>>> Lu Baolu wrote:
>>>>>>>
>>>>>>> On 2021/10/20 0:37, Sve
On Wed, Oct 20, 2021, at 07:21, Lu Baolu wrote:
> On 2021/10/20 0:37, Sven Peter via iommu wrote:
>> The iova allocator is capable of handling any granularity which is a power
>> of two. Remove the much stronger condition that the granularity must be
>> smaller or equal
Now that the dma-iommu API supports IOMMU granules which are larger than
the CPU page size and that the kernel no longer runs into a BUG_ON when
devices are attached to a domain with such a granule there's no need to
force bypass mode anymore.
Signed-off-by: Sven Peter
---
__IOMMU_DOMAIN_LP (large pages) indicates that a domain can handle
conditions where PAGE_SIZE might be smaller than the IOMMU page size.
Always allow attaching trusted devices to such domains and set the flag for
IOMMU_DOMAIN_DMA, which can now handle these situations.
Note that untrusted devices
The iova allocator is capable of handling any granularity which is a power
of two. Remove the much stronger condition that the granularity must be
smaller or equal to the CPU page size from a BUG_ON there.
Instead, check this condition during __iommu_attach_device and fail
gracefully.
Noncontiguous allocations must be made up of individual blocks
in a way that allows those blocks to be mapped contiguously in IOVA space.
For IOMMU page sizes larger than the CPU page size this can be done
by allocating all individual blocks from pools with
order >= get_order(iovad->granule). Some
Add support to iommu_dma_map_sg's impedance matching to also align
sg_lists correctly when the IOMMU granule is larger than PAGE_SIZE.
Co-developed-by: Robin Murphy
Signed-off-by: Robin Murphy
Signed-off-by: Sven Peter
---
drivers/iommu/dma-iommu.c | 25 -
1 file
While this function *probably* works correctly without any changes for
granule > PAGE_SIZE I don't have any code to actually test it and cannot
reason about how the function is supposed to work.
Disable it instead until we run into a use case where it's required.
Signed-off-by: Sven Peter
---
Hi,
RFC:
https://lore.kernel.org/linux-iommu/20210806155523.50429-1-s...@svenpeter.dev/
v2:
https://lore.kernel.org/linux-iommu/20210828153642.19396-1-s...@svenpeter.dev/
Time to revive this series:
v2 -> v3:
- Dropped support for untrusted devices since swiotlb currently does not
DART has an additional global register to control which streams are
isolated. This register is a bit redundant since DART_TCR can already
be used to control isolation and is usually initialized to DART_STREAM_ALL
by the time we get control. Some DARTs (namely the one used for the audio
controller)
On Wed, Oct 13, 2021, at 08:34, Wan Jiabing wrote:
> Fix following coccicheck warning:
> drivers/iommu/apple-dart.c:704:20-27: WARNING opportunity for kmemdup
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/iommu/apple-dart.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Looks
sid2groups keeps track of which stream id combinations belong to a
iommu_group to assign those correctly to devices.
When a iommu_group is freed a stale pointer will however remain in
sid2groups. This prevents devices with the same stream id combination
to ever be attached again (see below).
Fix
apple_dart_tlb_flush_{all,walk} expect to get a struct apple_dart_domain
but instead get a struct iommu_domain right now. This breaks those two
functions and can lead to kernel panics like the one below.
DART can only invalidate the entire TLB and apple_dart_iotlb_sync will
already flush
On Fri, Sep 3, 2021, at 17:45, Robin Murphy wrote:
> On 2021-09-03 16:16, Sven Peter wrote:
> >
> >
> > On Thu, Sep 2, 2021, at 21:42, Robin Murphy wrote:
> >> On 2021-09-02 19:19, Sven Peter wrote:
> >>>
> >>>
> >>> On Wed, Sep 1, 2021, at 23:10, Alyssa Rosenzweig wrote:
> > My biggest
On Thu, Sep 2, 2021, at 21:42, Robin Murphy wrote:
> On 2021-09-02 19:19, Sven Peter wrote:
> >
> >
> > On Wed, Sep 1, 2021, at 23:10, Alyssa Rosenzweig wrote:
> >>> My biggest issue is that I do not understand how this function is supposed
> >>> to be used correctly. It would work fine as-is
On Wed, Sep 1, 2021, at 23:10, Alyssa Rosenzweig wrote:
> > My biggest issue is that I do not understand how this function is supposed
> > to be used correctly. It would work fine as-is if it only ever gets passed
> > buffers
> > allocated by the coherent API but there's not way to check or
On Tue, Aug 31, 2021, at 23:39, Alyssa Rosenzweig wrote:
> > + if ((1 << __ffs(domain->pgsize_bitmap)) > PAGE_SIZE) {
>
> Not a fan of this construction. Could you assign `(1 <<
> __ffs(domain->pgsize_bitmap))` to an appropriately named temporary (e.g
> min_io_pgsize) so it's clearer what's
On Tue, Aug 31, 2021, at 23:30, Alyssa Rosenzweig wrote:
> I use this function for cross-device sharing on the M1 display driver.
> Arguably this is unsafe but it works on 16k kernels and if you want to
> test the function on 4k, you know where my code is.
>
My biggest issue is that I do not
and ofc shortly after submitting this series I realized this doesn't quite work
yet:
swiotlb_tbl_map_single can return a 16KB buffer that's only aligned to a 4KB
boundary.
v3 will need at least another change to ensure that the result will be aligned
to
a 16KB boundary as well.
Sven
On
Now that the dma-iommu API supports IOMMU granules which are larger than
the CPU page size and that the kernel no longer runs into a BUG_ON when
devices are attached to a domain with such a granule there's no need to
force bypass mode anymore.
Signed-off-by: Sven Peter
---
__IOMMU_DOMAIN_LP (large pages) indicates that a domain can handle
conditions where PAGE_SIZE might be smaller than the IOMMU page size.
Always allow attaching devices to such domains and set the flag for
IOMMU_DOMAIN_DMA, which can now handle these situations.
Signed-off-by: Sven Peter
---
The iova allocator is capable of handling any granularity which is a power
of two. Remove the much stronger condition that the granularity must be
smaller or equal to the CPU page size from a BUG_ON there.
Instead, check this condition during __iommu_attach_device and fail
gracefully.
Add support to iommu_dma_map_sg's impedance matching to also align
sg_lists correctly when the IOMMU granule is larger than PAGE_SIZE.
Co-developed-by: Robin Murphy
Signed-off-by: Robin Murphy
Signed-off-by: Sven Peter
---
drivers/iommu/dma-iommu.c | 18 ++
1 file changed, 10
Noncontiguous allocations must be made up of individual blocks
in a way that allows those blocks to be mapped contiguously in IOVA space.
For IOMMU page sizes larger than the CPU page size this can be done
by allocating all individual blocks from pools with
order >= get_order(iovad->granule). Some
Pretend that iommu_dma_get_sgtable is not implemented when
granule > PAGE_SIZE since I can neither test this function right now
nor do I fully understand how it is used.
Signed-off-by: Sven Peter
---
drivers/iommu/dma-iommu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Up until now PAGE_SIZE was always a multiple of iovad->granule
such that adjacent pages were never exposed to untrusted devices
due to allocations done as part of the coherent DMA API.
With PAGE_SIZE < iovad->granule however all these allocations
must also be aligned to iovad->granule.
If swiotlb is enabled we should never try to create any mappings that
would expose more memory than requested to the device.
WARN_ON and refuse those mappings just in case.
Signed-off-by: Sven Peter
---
drivers/iommu/dma-iommu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
RFC Patch:
https://lore.kernel.org/linux-iommu/20210806155523.50429-1-s...@svenpeter.dev/
Hi,
After a very helpful discussion with Robin Murphy on the RFC, here's v2 that is
slowly
starting to look sane.
I've been running this code for two weeks now and mainly tested it with usb
storage
On Wed, Aug 18, 2021, at 17:13, Robin Murphy wrote:
> Sven - I've prepared the follow-up patches already[1], so consider
> yourself off the hook (I see no point in trying to fix the nominal DART
> cookie bugs between now and then) :)
>
Great, thanks for taking care of that! :)
Just tested
On Thu, Aug 12, 2021, at 13:29, Joerg Roedel wrote:
> Hi Sven,
>
> On Tue, Aug 10, 2021 at 08:09:53AM +0200, Sven Peter wrote:
> > This happens because apple/dart is missing the "Optimizing
> > iommu_[map/unmap] performance"
> > series which is already in the core branch [1].
> > The same
On Tue, Aug 10, 2021, at 11:51, Robin Murphy wrote:
> On 2021-08-09 21:45, Sven Peter wrote:
> >
> >
> > On Mon, Aug 9, 2021, at 19:41, Robin Murphy wrote:
> >> On 2021-08-07 12:47, Sven Peter via iommu wrote:
> >>>
> >>>
> >>>
Good catch, thanks!
Acked-by: Sven Peter
Sven
On Tue, Aug 10, 2021, at 15:47, Geert Uytterhoeven wrote:
> The Apple DART (Device Address Resolution Table) IOMMU is only present
> on Apple ARM SoCs like the M1. Hence add a dependency on ARCH_APPLE, to
> prevent asking the user about this
Hi Joerg,
This happens because apple/dart is missing the "Optimizing iommu_[map/unmap]
performance"
series which is already in the core branch [1].
The same commit works fine in iommu/next since that branch merges both
iommu/core and
apple/dart.
Thanks,
Sven
[1]
On Mon, Aug 9, 2021, at 19:41, Robin Murphy wrote:
> On 2021-08-07 12:47, Sven Peter via iommu wrote:
> >
> >
> > On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
> >> On 2021-08-06 16:55, Sven Peter via iommu wrote:
> >>> @@ -1006,6 +1019,31 @@
Hi,
On Mon, Aug 9, 2021, at 20:37, Robin Murphy wrote:
> On 2021-08-07 09:41, Sven Peter wrote:
> > Hi,
> >
> > Thanks a lot for quick reply!
> >
> > On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
> >> On 2021-08-06 16:55, Sven Peter via iommu
On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
> On 2021-08-06 16:55, Sven Peter via iommu wrote:
> > @@ -1006,6 +1019,31 @@ static int iommu_dma_map_sg(struct device *dev,
> > struct scatterlist *sg,
> > if (dev_is_untrusted(dev))
> > return i
Hi,
Thanks a lot for quick reply!
On Fri, Aug 6, 2021, at 20:04, Robin Murphy wrote:
> On 2021-08-06 16:55, Sven Peter via iommu wrote:
> > DMA IOMMU domains can support hardware where the IOMMU page size is
> > larger than the CPU page size.
> > Alignments need to be done
Hi,
On the Apple M1 there's this slightly annoying situation where the DART IOMMU
has a hard-wired page size of 16KB. Additionally, the DARTs for some hardware
(USB A ports, WiFi, Ethernet, Thunderbolt PCIe) cannot be switched to bypass
mode and it's also not easily possible to program a software
__IOMMU_DOMAIN_LARGE_PAGES indicates that a domain can handle
conditions where PAGE_SIZE might be smaller than the IOMMU page size.
Always allow attaching devices to such domains and set the flag for
IOMMU_DOMAIN_DMA, which can now handle these situations.
Signed-off-by: Sven Peter
---
DMA IOMMU domains can support hardware where the IOMMU page size is
larger than the CPU page size.
Alignments need to be done with respect to both PAGE_SIZE and
iovad->granule. Additionally, the sg list optimization to use a single
IOVA allocation cannot be used in those cases since the physical
The iova allocator is capable of handling any granularity which is a power
of two. Remove the much stronger condition that the granularity must be
smaller or equal to the CPU page size from a BUG_ON there.
Instead, check this condition during __iommu_attach_device and fail
gracefully.
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Tested-by: Alyssa Rosenzweig
Signed-off-by: Sven Peter
---
MAINTAINERS| 1 +
drivers/iommu/Kconfig | 14 +
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Reviewed-by: Alexander Graf
Reviewed-by: Alyssa
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Reviewed-by: Rob Herring
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Sven Peter
---
.../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
MAINTAINERS
Hi,
This is v5 of my Apple M1 DART IOMMU driver series as a follow up to the
previous
versions [1][2][3][7].
Short summary: this series adds support for the iommu found in Apple's new M1
SoC which is required to use DMA on most peripherals like the display
controller,
the USB ports or the
On Mon, Jul 19, 2021, at 20:15, Robin Murphy wrote:
> On 2021-07-15 17:41, Sven Peter via iommu wrote:
> [...]
> >>> + u64 sw_bypass_cpu_start;
> >>> + u64 sw_bypass_dma_start;
> >>> + u64 sw_bypass_len;
> >>> +
> >>> + struct
Hi,
Awesome, thanks a lot for the detailed review!
On Wed, Jul 14, 2021, at 01:23, Robin Murphy wrote:
> ^^ Nit: the subsystem style for the subject format should be
> "iommu/dart: Add..." - similarly on patch #1, which I just realised I
> missed (sorry!)
Sure!
>
> On 2021-06-27 15:34,
Hi,
On Tue, Jul 13, 2021, at 21:17, Robin Murphy wrote:
> On 2021-06-27 15:34, Sven Peter wrote:
> > Apple's DART iommu uses a pagetable format that shares some
> > similarities with the ones already implemented by io-pgtable.c.
> > Add a new format variant to support the required differences
> >
Hi,
On Wed, Jun 30, 2021, at 15:49, Alyssa Rosenzweig wrote:
> Looks really good! Just a few minor comments. With them addressed,
>
> Reviewed-by: Alyssa Rosenzweig
Thanks!
>
> > + Say Y here if you are using an Apple SoC with a DART IOMMU.
>
> Nit: Do we need to spell out "with
On Mon, Jun 28, 2021, at 12:54, Alexander Graf wrote:
>
>
> On 27.06.21 16:34, Sven Peter wrote:
> >
> > Apple's DART iommu uses a pagetable format that shares some
> > similarities with the ones already implemented by io-pgtable.c.
> > Add a new format variant to support the required
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Signed-off-by: Sven Peter
---
MAINTAINERS |1 +
drivers/iommu/Kconfig| 15 +
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Reviewed-by: Rob Herring
Signed-off-by: Sven Peter
---
.../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
MAINTAINERS | 6 ++
2 files changed, 87
Hi,
This is v4 of my Apple M1 DART IOMMU driver series as a follow up to the
previous
versions [1][2][3].
Short summary: this series adds support for the iommu found in Apple's new M1
SoC which is required to use DMA on most peripherals like the display
controller,
the USB ports or the
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Signed-off-by: Sven Peter
---
Hi,
On Thu, Jun 10, 2021, at 18:52, Rob Herring wrote:
> On Thu, Jun 03, 2021 at 10:50:02AM +0200, Sven Peter wrote:
> > +
> > +examples:
> > + - |+
> > +dart1: iommu@82f8 {
> > + compatible = "apple,t8103-dart";
> > + reg = <0x82f8 0x4000>;
> > + interrupts = <1 781
Hi Rouven,
On Sat, Jun 5, 2021, at 13:50, Rouven Czerwinski wrote:
> Hi Sven,
>
> just a small comment, see inline.
>
> On Thu, 2021-06-03 at 10:50 +0200, Sven Peter wrote:
> > +
> > +/* must be called with held dart_domain->lock */
>
> You can remove this comment, include lockdep.h and…
>
>
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Signed-off-by: Sven Peter
---
MAINTAINERS | 1 +
drivers/iommu/Kconfig| 15 +
drivers/iommu/Makefile
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Signed-off-by: Sven Peter
---
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Signed-off-by: Sven Peter
---
.../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
MAINTAINERS | 6 ++
2 files changed, 87 insertions(+)
create mode
Hi,
This is v3 of my Apple M1 DART IOMMU driver series as a follow up to the
original
two versions [1][2].
Short summary: this series adds support for the iommu found in Apple's new M1
SoC which is required to use DMA on most peripherals. So far this code has been
tested with dwc3 in host and
Hi,
I just ran into the exact same issue while working on the M1 DART IOMMU driver
and it was fixed by this commit. Thanks!
Would be great if this could be picked up.
Tested-by: Sven Peter
Best,
Sven
On Mon, Sep 14, 2020, at 09:23, Srinath Mannam via iommu wrote:
> Fix IOVA reserve
On Sun, Apr 4, 2021, at 17:26, Julia Lawall wrote:
> From: kernel test robot
>
> Function apple_dart_attach_stream called on line 519 inside
> lock on line 509 but uses GFP_KERNEL
Thanks! Fixed for v3.
Best,
Sven
___
iommu mailing list
On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
[...]
> >
> > +static struct io_pgtable *
> > +apple_dart_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> > +{
> > + struct arm_lpae_io_pgtable *data;
> > +
> > + if
On Wed, Apr 7, 2021, at 12:42, Will Deacon wrote:
> On Sun, Mar 28, 2021 at 09:40:09AM +0200, Sven Peter wrote:
> > Apple's new SoCs use iommus for almost all peripherals. These Device
> > Address Resolution Tables must be setup before these peripherals can
> > act as DMA masters.
> >
> >
On Sun, Mar 28, 2021, at 10:16, Arnd Bergmann wrote:
> On Sun, Mar 28, 2021 at 9:40 AM Sven Peter wrote:
>
> I noticed only one detail here:
>
> > + - |+
> > +dart2a: dart2a@82f0 {
> > + compatible = "apple,t8103-dart";
> > + reg = <0x82f0 0x4000>;
> > +
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Signed-off-by: Sven Peter
---
MAINTAINERS | 1 +
drivers/iommu/Kconfig| 14 +
drivers/iommu/Makefile
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Signed-off-by: Sven Peter
---
.../devicetree/bindings/iommu/apple,dart.yaml | 81 +++
MAINTAINERS | 6 ++
2 files changed, 87 insertions(+)
create mode
Hi,
Here's v2 of my Apple M1 DART IOMMU driver series as a follow up to the original
version [1].
Short summary: this series adds support for the iommu found in Apple's new M1
SoC which is required to use DMA on most peripherals. So far this code has been
tested with dwc3 in host and device mode
Apple's DART iommu uses a pagetable format that shares some
similarities with the ones already implemented by io-pgtable.c.
Add a new format variant to support the required differences
so that we don't have to duplicate the pagetable handling code.
Signed-off-by: Sven Peter
---
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
On Fri, Mar 26, 2021, at 20:59, Arnd Bergmann wrote:
> On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote:
> > dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM
> > co-processor)
>
> Same here:
> dart-sio {
>vm-base = <0x0>;
>vm-size = <0xfc00>;
>
On Fri, Mar 26, 2021, at 18:34, Robin Murphy wrote:
> On 2021-03-26 17:26, Mark Kettenis wrote:
> >
> > Anyway, from my viewpoint having the information about the IOVA
> > address space sit on the devices makes little sense. This information
> > is needed by the DART driver, and there is no
On Fri, Mar 26, 2021, at 17:38, Arnd Bergmann wrote:
> On Fri, Mar 26, 2021 at 5:10 PM Sven Peter wrote:
> > On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > > Some of the DARTs provide a bypass facility. That code make using the
> > > standard "dma-ranges" property tricky. That
On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> Some of the DARTs provide a bypass facility. That code make using the
> standard "dma-ranges" property tricky. That property would need to
> contain the bypass address range. But that would mean that if the
> DART driver needs to look at
On Thu, Mar 25, 2021, at 12:50, Robin Murphy wrote:
> On 2021-03-25 07:53, Sven Peter wrote:
> >
> >
> > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> >> On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> >>>
> >>> As I mentioned before, not all DARTs support the full
Hi Robin,
Thanks for the review!
On Wed, Mar 24, 2021, at 17:37, Robin Murphy wrote:
> On 2021-03-20 15:19, Sven Peter wrote:
> > Apple's DART iommu uses a pagetable format that's very similar to the ones
> > already implemented by io-pgtable.c.
> > Add a new format variant to support the
Hi Robin,
On Wed, Mar 24, 2021, at 16:29, Robin Murphy wrote:
> On 2021-03-20 15:19, Sven Peter wrote:
> >
> > I have just noticed today though that at least the USB DWC3 controller in
> > host
> > mode uses *two* darts at the same time. I'm not sure yet which parts seem to
> > require which
On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> On Sun, Mar 21, 2021 at 05:00:50PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 20 Mar 2021 15:19:33 +
> > > From: Sven Peter
> > > I have just noticed today though that at least the USB DWC3 controller in
> > > host
> > > mode uses
Hi Mark,
On Tue, Mar 23, 2021, at 21:00, Mark Kettenis wrote:
> The problem with both #1 and #2 is that you end up with two references
> to (effectively) different iommu's in the dwc3 device node. I don't
> see how that is compatible with the idea of using a single translation
> table for both
Hi Mark,
On Sun, Mar 21, 2021, at 19:35, Mark Kettenis wrote:
>
> Guess we do need to understand a little bit better how the USB DART
> actually works. My hypothesis (based on our discussion on #asahi) is
> that the XHCI host controller and the peripheral controller of the
> DWC3 block use
Hi Rob,
On Mon, Mar 22, 2021, at 01:15, Rob Herring wrote:
>
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is
Hi Mark,
> On 21. Mar 2021, at 17:00, Mark Kettenis 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>.
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
Hi,
After Hector's initial work [1] to bring up Linux on Apple's M1 it's time to
bring up more devices. Most peripherals connected to the SoC are behind a iommu
which Apple calls "Device Address Resolution Table", or DART for short [2].
Unfortunately, it only shares the name with PowerPC's DART.
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be setup before these peripherals can
act as DMA masters.
Signed-off-by: Sven Peter
---
MAINTAINERS | 1 +
drivers/iommu/Kconfig| 13 +
drivers/iommu/Makefile
Apple's DART iommu uses a pagetable format that's very similar to the ones
already implemented by io-pgtable.c.
Add a new format variant to support the required differences.
Signed-off-by: Sven Peter
---
drivers/iommu/Kconfig | 13 +++
drivers/iommu/io-pgtable-arm.c | 70
DART (Device Address Resolution Table) is the iommu found on Apple
ARM SoCs such as the M1.
Signed-off-by: Sven Peter
---
.../bindings/iommu/apple,t8103-dart.yaml | 82 +++
MAINTAINERS | 6 ++
2 files changed, 88 insertions(+)
create mode
95 matches
Mail list logo
