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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED 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 AEF6AC433DB for ; Fri, 26 Mar 2021 21:16:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7EC4A61954 for ; Fri, 26 Mar 2021 21:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230372AbhCZVQV (ORCPT ); Fri, 26 Mar 2021 17:16:21 -0400 Received: from sibelius.xs4all.nl ([83.163.83.176]:62722 "EHLO sibelius.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230107AbhCZVQQ (ORCPT ); Fri, 26 Mar 2021 17:16:16 -0400 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 71729a6f; Fri, 26 Mar 2021 22:16:14 +0100 (CET) Date: Fri, 26 Mar 2021 22:16:14 +0100 (CET) From: Mark Kettenis To: Arnd Bergmann Cc: sven@svenpeter.dev, robin.murphy@arm.com, robh@kernel.org, iommu@lists.linux-foundation.org, joro@8bytes.org, will@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: (message from Arnd Bergmann on Fri, 26 Mar 2021 20:59:58 +0100) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> <20210323205346.GA1283560@robh.at.kernel.org> <43685c67-6d9c-4e72-b320-0462c2273bf0@www.fastmail.com> <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com> <45faaadd-eda7-464f-96ff-7324f566669e@www.fastmail.com> Message-ID: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Arnd Bergmann > Date: Fri, 26 Mar 2021 20:59:58 +0100 > > On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote: > > 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 direct cnnection from > > > > the DART to the individual devices in the devicetree. The "iommus" > > > > property makes a connection in the opposite direction. > > > > > > What still seems unclear is whether these addressing limitations are a > > > property of the DART input interface, the device output interface, or > > > the interconnect between them. Although the observable end result > > > appears more or less the same either way, they are conceptually > > > different things which we have different abstractions to deal with. > > > > I'm not really sure if there is any way for us to figure out where these > > limitation comes from though. > > My first guess was that this is done to partition the available address > address space in a way that allows one physical IOTLB to handle > multiple devices that each have their own page table for a subset > of the address space, as was done on old PowerPC IOMMUs. > However, the ranges you list don't really support that model. > > > I've done some more experiments and looked at all DART nodes in Apple's Device > > Tree though. It seems that most (if not all) masters only connect 32 address > > lines even though the iommu can handle a much larger address space. I'll therefore > > remove the code to handle the full space for v2 since it's essentially dead > > code that can't be tested anyway. > > > > > > There are some exceptions though: > > > > There are the PCIe DARTs which have a different limitation which could be > > encoded as 'dma-ranges' in the pci bus node: > > > > name base size > > dart-apcie1: 00100000 3fe00000 > > dart-apcie2: 00100000 3fe00000 > > dart-apcie0: 00100000 3fe00000 > > dart-apciec0: 00004000 7fffc000 > > dart-apciec1: 80000000 7fffc000 > > This looks like they are reserving some address space in the beginning > and/or the end, and for apciec0, the address space is partitioned into > two equal-sized regions. > > > Then there are also these display controller DARTs. If we wanted to use dma-ranges > > we could just put them in a single sub bus: > > > > name base size > > dart-disp0: 00000000 fc000000 > > dart-dcp: 00000000 fc000000 > > dart-dispext0: 00000000 fc000000 > > dart-dcpext: 00000000 fc000000 > > > > > > And finally we have these strange ones which might eventually each require > > another awkward sub-bus if we want to stick to the dma-ranges property. > > > > name base size > > dart-aop: 00030000 ffffffff ("always-on processor") > > dart-pmp: 00000000 bff00000 (no idea yet) > > Here I also see a "pio-vm-size" property: > > dart-pmp { > pio-vm-base = <0xc0000000>; > pio-vm-size = <0x40000000>; > vm-size = <0xbff00000>; > ... > }; > > Which seems to give 3GB of address space to the normal iotlb, > plus the last 1GB to something else. The vm-base property is also > missing rather than zero, but that could just be part of their syntax > instead of a real difference. Yes. It seems like "vm-base" is omitted when it is 0, and "vm-size" is omitted when the end of the window is at 0xffffffff. > > Could it be that there are > > > dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor) > > Same here: > dart-sio { > vm-base = <0x0>; > vm-size = <0xfc000000>; > pio-vm-base = <0xfd000000>; > pio-vm-size = <0x2000000>; > pio-granularity = <0x1000000>; > } > > There are clearly two distinct ranges that split up the 4GB space again, > with a small hole of 16MB (==pio-granularity) at the end of each range. > > The "pio" name might indicate that this is a range of addresses that > can be programmed to point at I/O registers in another device, rather > than pointing to RAM. > > Arnd > 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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED,URIBL_RED 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 DE2E9C433DB for ; Fri, 26 Mar 2021 21:16:26 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 7655561A24 for ; Fri, 26 Mar 2021 21:16:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7655561A24 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 smtp2.osuosl.org (Postfix) with ESMTP id 35DBD4060F; Fri, 26 Mar 2021 21:16:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pMIFpHCJ0Ln; Fri, 26 Mar 2021 21:16:25 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp2.osuosl.org (Postfix) with ESMTP id 1E1F740245; Fri, 26 Mar 2021 21:16:25 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id EB7E4C000C; Fri, 26 Mar 2021 21:16:24 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 056DFC000A for ; Fri, 26 Mar 2021 21:16:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id D6C454060F for ; Fri, 26 Mar 2021 21:16:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dREVivZRyTpW for ; Fri, 26 Mar 2021 21:16:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) by smtp2.osuosl.org (Postfix) with ESMTPS id BE2A640245 for ; Fri, 26 Mar 2021 21:16:17 +0000 (UTC) Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 71729a6f; Fri, 26 Mar 2021 22:16:14 +0100 (CET) Date: Fri, 26 Mar 2021 22:16:14 +0100 (CET) From: Mark Kettenis To: Arnd Bergmann In-Reply-To: (message from Arnd Bergmann on Fri, 26 Mar 2021 20:59:58 +0100) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> <20210323205346.GA1283560@robh.at.kernel.org> <43685c67-6d9c-4e72-b320-0462c2273bf0@www.fastmail.com> <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com> <45faaadd-eda7-464f-96ff-7324f566669e@www.fastmail.com> Message-ID: Cc: robh@kernel.org, sven@svenpeter.dev, devicetree@vger.kernel.org, will@kernel.org, marcan@marcan.st, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.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" > From: Arnd Bergmann > Date: Fri, 26 Mar 2021 20:59:58 +0100 > > On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote: > > 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 direct cnnection from > > > > the DART to the individual devices in the devicetree. The "iommus" > > > > property makes a connection in the opposite direction. > > > > > > What still seems unclear is whether these addressing limitations are a > > > property of the DART input interface, the device output interface, or > > > the interconnect between them. Although the observable end result > > > appears more or less the same either way, they are conceptually > > > different things which we have different abstractions to deal with. > > > > I'm not really sure if there is any way for us to figure out where these > > limitation comes from though. > > My first guess was that this is done to partition the available address > address space in a way that allows one physical IOTLB to handle > multiple devices that each have their own page table for a subset > of the address space, as was done on old PowerPC IOMMUs. > However, the ranges you list don't really support that model. > > > I've done some more experiments and looked at all DART nodes in Apple's Device > > Tree though. It seems that most (if not all) masters only connect 32 address > > lines even though the iommu can handle a much larger address space. I'll therefore > > remove the code to handle the full space for v2 since it's essentially dead > > code that can't be tested anyway. > > > > > > There are some exceptions though: > > > > There are the PCIe DARTs which have a different limitation which could be > > encoded as 'dma-ranges' in the pci bus node: > > > > name base size > > dart-apcie1: 00100000 3fe00000 > > dart-apcie2: 00100000 3fe00000 > > dart-apcie0: 00100000 3fe00000 > > dart-apciec0: 00004000 7fffc000 > > dart-apciec1: 80000000 7fffc000 > > This looks like they are reserving some address space in the beginning > and/or the end, and for apciec0, the address space is partitioned into > two equal-sized regions. > > > Then there are also these display controller DARTs. If we wanted to use dma-ranges > > we could just put them in a single sub bus: > > > > name base size > > dart-disp0: 00000000 fc000000 > > dart-dcp: 00000000 fc000000 > > dart-dispext0: 00000000 fc000000 > > dart-dcpext: 00000000 fc000000 > > > > > > And finally we have these strange ones which might eventually each require > > another awkward sub-bus if we want to stick to the dma-ranges property. > > > > name base size > > dart-aop: 00030000 ffffffff ("always-on processor") > > dart-pmp: 00000000 bff00000 (no idea yet) > > Here I also see a "pio-vm-size" property: > > dart-pmp { > pio-vm-base = <0xc0000000>; > pio-vm-size = <0x40000000>; > vm-size = <0xbff00000>; > ... > }; > > Which seems to give 3GB of address space to the normal iotlb, > plus the last 1GB to something else. The vm-base property is also > missing rather than zero, but that could just be part of their syntax > instead of a real difference. Yes. It seems like "vm-base" is omitted when it is 0, and "vm-size" is omitted when the end of the window is at 0xffffffff. > > Could it be that there are > > > dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor) > > Same here: > dart-sio { > vm-base = <0x0>; > vm-size = <0xfc000000>; > pio-vm-base = <0xfd000000>; > pio-vm-size = <0x2000000>; > pio-granularity = <0x1000000>; > } > > There are clearly two distinct ranges that split up the 4GB space again, > with a small hole of 16MB (==pio-granularity) at the end of each range. > > The "pio" name might indicate that this is a range of addresses that > can be programmed to point at I/O registers in another device, rather > than pointing to RAM. > > Arnd > _______________________________________________ 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,URIBL_BLOCKED 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 76684C433C1 for ; Fri, 26 Mar 2021 21:17:57 +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 18FE461954 for ; Fri, 26 Mar 2021 21:17:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18FE461954 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=0C4y9P29kReepDD8F9vOF58Q0xrbNhXBjLtnivmjIcU=; b=cVQ9vTBeikH6IS6JYAVgMwYf7W mGcSXCaNgfchxv5p95/nAR5Ccuj5KMLDW+sw3eGN81jZSmsYfI+NOTnXVvIds6oNZhtiv0hmclNgd yjye7384SgMoQQbz01wCsl6+whF3Vws1zu5vJNAGRolD9kpuXKUGr2Z6hypnJPCX+OcIq7yOtZj2x O9OSw/vT4+/oKXurhsK5l0luF3JrpihV/73n6Kn69Iej68h88GLHiMaYFaB3AaNjGtArQkQlB4+yL B5yAYYg0MD04EujCc9BngyMCkN5bAywNzquxG+8idRBaoDdfv0sDHoc2vjdtyEBi+6e+4yuPP4N9B HOYHV17Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lPtod-004McQ-La; Fri, 26 Mar 2021 21:16:23 +0000 Received: from sibelius.xs4all.nl ([83.163.83.176]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lPtoV-004Mba-Du for linux-arm-kernel@lists.infradead.org; Fri, 26 Mar 2021 21:16:17 +0000 Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 71729a6f; Fri, 26 Mar 2021 22:16:14 +0100 (CET) Date: Fri, 26 Mar 2021 22:16:14 +0100 (CET) From: Mark Kettenis To: Arnd Bergmann Cc: sven@svenpeter.dev, robin.murphy@arm.com, robh@kernel.org, iommu@lists.linux-foundation.org, joro@8bytes.org, will@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: (message from Arnd Bergmann on Fri, 26 Mar 2021 20:59:58 +0100) Subject: Re: [PATCH 0/3] Apple M1 DART IOMMU driver References: <20210320151903.60759-1-sven@svenpeter.dev> <20210323205346.GA1283560@robh.at.kernel.org> <43685c67-6d9c-4e72-b320-0462c2273bf0@www.fastmail.com> <9f06872d-f0ec-43c3-9b53-d144337100b3@www.fastmail.com> <45faaadd-eda7-464f-96ff-7324f566669e@www.fastmail.com> Message-ID: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210326_211615_701425_249438BB X-CRM114-Status: GOOD ( 38.09 ) 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 > From: Arnd Bergmann > Date: Fri, 26 Mar 2021 20:59:58 +0100 > > On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote: > > 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 direct cnnection from > > > > the DART to the individual devices in the devicetree. The "iommus" > > > > property makes a connection in the opposite direction. > > > > > > What still seems unclear is whether these addressing limitations are a > > > property of the DART input interface, the device output interface, or > > > the interconnect between them. Although the observable end result > > > appears more or less the same either way, they are conceptually > > > different things which we have different abstractions to deal with. > > > > I'm not really sure if there is any way for us to figure out where these > > limitation comes from though. > > My first guess was that this is done to partition the available address > address space in a way that allows one physical IOTLB to handle > multiple devices that each have their own page table for a subset > of the address space, as was done on old PowerPC IOMMUs. > However, the ranges you list don't really support that model. > > > I've done some more experiments and looked at all DART nodes in Apple's Device > > Tree though. It seems that most (if not all) masters only connect 32 address > > lines even though the iommu can handle a much larger address space. I'll therefore > > remove the code to handle the full space for v2 since it's essentially dead > > code that can't be tested anyway. > > > > > > There are some exceptions though: > > > > There are the PCIe DARTs which have a different limitation which could be > > encoded as 'dma-ranges' in the pci bus node: > > > > name base size > > dart-apcie1: 00100000 3fe00000 > > dart-apcie2: 00100000 3fe00000 > > dart-apcie0: 00100000 3fe00000 > > dart-apciec0: 00004000 7fffc000 > > dart-apciec1: 80000000 7fffc000 > > This looks like they are reserving some address space in the beginning > and/or the end, and for apciec0, the address space is partitioned into > two equal-sized regions. > > > Then there are also these display controller DARTs. If we wanted to use dma-ranges > > we could just put them in a single sub bus: > > > > name base size > > dart-disp0: 00000000 fc000000 > > dart-dcp: 00000000 fc000000 > > dart-dispext0: 00000000 fc000000 > > dart-dcpext: 00000000 fc000000 > > > > > > And finally we have these strange ones which might eventually each require > > another awkward sub-bus if we want to stick to the dma-ranges property. > > > > name base size > > dart-aop: 00030000 ffffffff ("always-on processor") > > dart-pmp: 00000000 bff00000 (no idea yet) > > Here I also see a "pio-vm-size" property: > > dart-pmp { > pio-vm-base = <0xc0000000>; > pio-vm-size = <0x40000000>; > vm-size = <0xbff00000>; > ... > }; > > Which seems to give 3GB of address space to the normal iotlb, > plus the last 1GB to something else. The vm-base property is also > missing rather than zero, but that could just be part of their syntax > instead of a real difference. Yes. It seems like "vm-base" is omitted when it is 0, and "vm-size" is omitted when the end of the window is at 0xffffffff. > > Could it be that there are > > > dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor) > > Same here: > dart-sio { > vm-base = <0x0>; > vm-size = <0xfc000000>; > pio-vm-base = <0xfd000000>; > pio-vm-size = <0x2000000>; > pio-granularity = <0x1000000>; > } > > There are clearly two distinct ranges that split up the 4GB space again, > with a small hole of 16MB (==pio-granularity) at the end of each range. > > The "pio" name might indicate that this is a range of addresses that > can be programmed to point at I/O registers in another device, rather > than pointing to RAM. > > Arnd > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel