From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EA6EC433E0 for ; Sun, 21 Mar 2021 16:01:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E5B0161930 for ; Sun, 21 Mar 2021 16:01:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230039AbhCUQBE (ORCPT ); Sun, 21 Mar 2021 12:01:04 -0400 Received: from sibelius.xs4all.nl ([83.163.83.176]:51001 "EHLO sibelius.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229840AbhCUQA6 (ORCPT ); Sun, 21 Mar 2021 12:00:58 -0400 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 94fcbf52; Sun, 21 Mar 2021 17:00:50 +0100 (CET) Date: Sun, 21 Mar 2021 17:00:50 +0100 (CET) From: Mark Kettenis To: Sven Peter Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, robh+dt@kernel.org, arnd@kernel.org, marcan@marcan.st, 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 In-Reply-To: <20210320151903.60759-1-sven@svenpeter.dev> (message from Sven Peter on Sat, 20 Mar 2021 15:19:33 +0000) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> Message-ID: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Date: Sat, 20 Mar 2021 15:19:33 +0000 > From: Sven Peter > > 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. > Configuring this iommu is mandatory if these peripherals require DMA access. > > This patchset implements initial support for this iommu. The hardware itself > uses a pagetable format that's very similar to the one already implement in > io-pgtable.c. There are some minor modifications, namely some details of the > PTE format and that there are always three pagetable levels, which I've > implement as a new format variant. > > I have mainly tested this with the USB controller in device mode which is > compatible with Linux's dwc3 driver. Some custom PHY initialization (which is > not yet ready or fully understood) is required though to bring up the ports, > see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the same > setup you will probably need that branch for now and add the nodes from > the DT binding specification example to your device tree. > > Even though each DART instances could support up to 16 devices usually only > a single device is actually connected. Different devices generally just use > an entirely separate DART instance with a seperate MMIO range, IRQ, etc. > > 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 DART instance. > > This means that we might need to support devices attached to two iommus > simultaneously and just create the same iova mappings. Currently this only > seems to be required for USB according to Apple's Device Tree. > > I see two options for this and would like to get feedback before > I implement either one: > > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell > to identify the DART and the second one to identify the master. > The DART DT node would then also take two register ranges that would > correspond to the two DARTs. Both instances use the same IRQ and the > same clocks according to Apple's device tree and my experiments. > This would keep a single device node and the DART driver would then > simply map iovas in both DARTs if required. > > 2) Keep #iommu-cells as-is but support > iommus = <&usb_dart1a 1>, <&usb_dart1b 0>; > instead. > This would then require two devices nodes for the two DART instances and > some housekeeping in the DART driver to support mapping iovas in both > DARTs. > I believe omap-iommu.c supports this setup but I will have to read > more code to understand the details there and figure out how to implement > this in a sane way. > > I currently prefer the first option but I don't understand enough details of > the iommu system to actually make an informed decision. > I'm obviously also open to more options :-) Hi Sven, 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. 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. Cheers, Mark [1] Documentation/devicetree/bindings/pci/pci-iommu.txt From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AA6AC433E0 for ; Sun, 21 Mar 2021 19:38:51 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 330FD6192C for ; Sun, 21 Mar 2021 19:38:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 330FD6192C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E25E7605AC; Sun, 21 Mar 2021 19:38:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUkh6KNSEW7W; Sun, 21 Mar 2021 19:38:48 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTP id 7D73D60586; Sun, 21 Mar 2021 19:38:48 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C394C000A; Sun, 21 Mar 2021 19:38:48 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 36538C0001 for ; Sun, 21 Mar 2021 16:07:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 15B1D403D8 for ; Sun, 21 Mar 2021 16:07:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zyrrVz2CNJ1 for ; Sun, 21 Mar 2021 16:07:35 +0000 (UTC) X-Greylist: delayed 00:06:38 by SQLgrey-1.8.0 Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) by smtp4.osuosl.org (Postfix) with ESMTPS id B5D2C403D0 for ; Sun, 21 Mar 2021 16:07:33 +0000 (UTC) Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 94fcbf52; Sun, 21 Mar 2021 17:00:50 +0100 (CET) Date: Sun, 21 Mar 2021 17:00:50 +0100 (CET) From: Mark Kettenis To: Sven Peter In-Reply-To: <20210320151903.60759-1-sven@svenpeter.dev> (message from Sven Peter on Sat, 20 Mar 2021 15:19:33 +0000) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> Message-ID: X-Mailman-Approved-At: Sun, 21 Mar 2021 19:38:46 +0000 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 X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" > Date: Sat, 20 Mar 2021 15:19:33 +0000 > From: Sven Peter > > 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. > Configuring this iommu is mandatory if these peripherals require DMA access. > > This patchset implements initial support for this iommu. The hardware itself > uses a pagetable format that's very similar to the one already implement in > io-pgtable.c. There are some minor modifications, namely some details of the > PTE format and that there are always three pagetable levels, which I've > implement as a new format variant. > > I have mainly tested this with the USB controller in device mode which is > compatible with Linux's dwc3 driver. Some custom PHY initialization (which is > not yet ready or fully understood) is required though to bring up the ports, > see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the same > setup you will probably need that branch for now and add the nodes from > the DT binding specification example to your device tree. > > Even though each DART instances could support up to 16 devices usually only > a single device is actually connected. Different devices generally just use > an entirely separate DART instance with a seperate MMIO range, IRQ, etc. > > 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 DART instance. > > This means that we might need to support devices attached to two iommus > simultaneously and just create the same iova mappings. Currently this only > seems to be required for USB according to Apple's Device Tree. > > I see two options for this and would like to get feedback before > I implement either one: > > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell > to identify the DART and the second one to identify the master. > The DART DT node would then also take two register ranges that would > correspond to the two DARTs. Both instances use the same IRQ and the > same clocks according to Apple's device tree and my experiments. > This would keep a single device node and the DART driver would then > simply map iovas in both DARTs if required. > > 2) Keep #iommu-cells as-is but support > iommus = <&usb_dart1a 1>, <&usb_dart1b 0>; > instead. > This would then require two devices nodes for the two DART instances and > some housekeeping in the DART driver to support mapping iovas in both > DARTs. > I believe omap-iommu.c supports this setup but I will have to read > more code to understand the details there and figure out how to implement > this in a sane way. > > I currently prefer the first option but I don't understand enough details of > the iommu system to actually make an informed decision. > I'm obviously also open to more options :-) Hi Sven, 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. 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. Cheers, Mark [1] Documentation/devicetree/bindings/pci/pci-iommu.txt _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88F23C433C1 for ; Sun, 21 Mar 2021 16:03:15 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 184886192D for ; Sun, 21 Mar 2021 16:03:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 184886192D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:MIME-Version:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:Subject:In-Reply-To:Cc:To:From :Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SzW9ECIu75UjARs6XvjpiE0mnXWBgJJP+UceITRh+Wo=; b=JCdEzQ+d2ut773wo9H4coueIKQ lo+fn6DjXYoaDDEFERVyzMmjuzOFC+tLScoH0vJkP7hiqzzYrSO853FdLzVpTuiYx4y52aiZyqxvY PfYQFFTF0h/LWaKKSuLRH46z4gAh8yK0skUQ42uBgMYZz4L5LrlAYtQb6JcQTv/YiAxaPdt0W16Ba n4UYf0s7Id1oHOjntiMeJ98d2GUMw3a0uueMgc48BEmCwF6V/iCfd1PelwB8+h6pQjJKBO4QB5w+k jTDN7h3vheFkJavsEd/v3HgRD5jJVsYUO1YC41qUIiSg8V7a3qsC+xlplwE1UhhYlxYG8lL5is6Bw dz26ltZw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lO0Vt-00A7VF-2b; Sun, 21 Mar 2021 16:01:13 +0000 Received: from sibelius.xs4all.nl ([83.163.83.176]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lO0VY-00A7UR-KH for linux-arm-kernel@lists.infradead.org; Sun, 21 Mar 2021 16:00:56 +0000 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 94fcbf52; Sun, 21 Mar 2021 17:00:50 +0100 (CET) Date: Sun, 21 Mar 2021 17:00:50 +0100 (CET) From: Mark Kettenis To: Sven Peter Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, robh+dt@kernel.org, arnd@kernel.org, marcan@marcan.st, 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 In-Reply-To: <20210320151903.60759-1-sven@svenpeter.dev> (message from Sven Peter on Sat, 20 Mar 2021 15:19:33 +0000) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> Message-ID: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210321_160054_686395_0EFDE4F2 X-CRM114-Status: GOOD ( 36.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > Date: Sat, 20 Mar 2021 15:19:33 +0000 > From: Sven Peter > > 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. > Configuring this iommu is mandatory if these peripherals require DMA access. > > This patchset implements initial support for this iommu. The hardware itself > uses a pagetable format that's very similar to the one already implement in > io-pgtable.c. There are some minor modifications, namely some details of the > PTE format and that there are always three pagetable levels, which I've > implement as a new format variant. > > I have mainly tested this with the USB controller in device mode which is > compatible with Linux's dwc3 driver. Some custom PHY initialization (which is > not yet ready or fully understood) is required though to bring up the ports, > see e.g. my patches to our m1n1 bootloader [3,4]. If you want to test the same > setup you will probably need that branch for now and add the nodes from > the DT binding specification example to your device tree. > > Even though each DART instances could support up to 16 devices usually only > a single device is actually connected. Different devices generally just use > an entirely separate DART instance with a seperate MMIO range, IRQ, etc. > > 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 DART instance. > > This means that we might need to support devices attached to two iommus > simultaneously and just create the same iova mappings. Currently this only > seems to be required for USB according to Apple's Device Tree. > > I see two options for this and would like to get feedback before > I implement either one: > > 1) Change #iommu-cells = <1>; to #iommu-cells = <2>; and use the first cell > to identify the DART and the second one to identify the master. > The DART DT node would then also take two register ranges that would > correspond to the two DARTs. Both instances use the same IRQ and the > same clocks according to Apple's device tree and my experiments. > This would keep a single device node and the DART driver would then > simply map iovas in both DARTs if required. > > 2) Keep #iommu-cells as-is but support > iommus = <&usb_dart1a 1>, <&usb_dart1b 0>; > instead. > This would then require two devices nodes for the two DART instances and > some housekeeping in the DART driver to support mapping iovas in both > DARTs. > I believe omap-iommu.c supports this setup but I will have to read > more code to understand the details there and figure out how to implement > this in a sane way. > > I currently prefer the first option but I don't understand enough details of > the iommu system to actually make an informed decision. > I'm obviously also open to more options :-) Hi Sven, 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. 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. Cheers, Mark [1] Documentation/devicetree/bindings/pci/pci-iommu.txt _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel