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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 455D5C32750 for ; Fri, 2 Aug 2019 17:17:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0871B20880 for ; Fri, 2 Aug 2019 17:17:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564766263; bh=5vmjMpiDWDoHbfIEjw2l5ptTIfiiyZTgBi7QK8QIoHM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=SOCpQ2MGP5KaLDCgQ9SOSMO9jeMZItWVgoIcVoOBS5oABV+QjShnJrMgCc0FRBpes WP7mSnCFBHQ9IFqliLYByDCT+HqwpqHiVXK90pM3NVmtB0UHnytbTystq++7ohZecb RjQ9ZdW3wAt85vOv2fcOeat2bau/t8wKBgLJ6Npg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391773AbfHBRRl (ORCPT ); Fri, 2 Aug 2019 13:17:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:41498 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391083AbfHBRRk (ORCPT ); Fri, 2 Aug 2019 13:17:40 -0400 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 629FB217D7; Fri, 2 Aug 2019 17:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564766259; bh=5vmjMpiDWDoHbfIEjw2l5ptTIfiiyZTgBi7QK8QIoHM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lhaum2PDzZjeWUO+WsAPOwKR/YgoXWAR0RXVBZYh5t5+PfmXONrVeQpGaqPVUFLNV zeDEVI0jHfexKJbsQD+EJtDab3k6iGED56EBhGxGJaIwBy9kSo1dYlZn9j/4qmkL4a R3PlUQKqZUXTeiEG8RYoleZ6v44K+IO5A8+pUoig= Received: by mail-qk1-f182.google.com with SMTP id w190so55352375qkc.6; Fri, 02 Aug 2019 10:17:39 -0700 (PDT) X-Gm-Message-State: APjAAAXdcNOmfNjVBrKvk75sviQKRvKpMDc5IAZ8y/ri16o9EpSbqGAf TH6iMs821OALuJoTsICRgLuy5MheW+8aYjebnw== X-Google-Smtp-Source: APXvYqxL5GHe5mkbUxAz7mbqxNvzn4pWJks7bPOqG/UgQKQwi7xLsLORGJlb/4eoiQbYIUPfkF/if0CjxqkRI+lgyvY= X-Received: by 2002:a37:a48e:: with SMTP id n136mr93644586qke.223.1564766258476; Fri, 02 Aug 2019 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <20190731154752.16557-1-nsaenzjulienne@suse.de> <20190731154752.16557-4-nsaenzjulienne@suse.de> In-Reply-To: <20190731154752.16557-4-nsaenzjulienne@suse.de> From: Rob Herring Date: Fri, 2 Aug 2019 11:17:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size To: Nicolas Saenz Julienne Cc: Catalin Marinas , Christoph Hellwig , wahrenst@gmx.net, Marc Zyngier , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Linux IOMMU , linux-mm@kvack.org, Frank Rowand , phill@raspberryi.org, Florian Fainelli , Will Deacon , "linux-kernel@vger.kernel.org" , Eric Anholt , Matthias Brugger , Andrew Morton , Marek Szyprowski , "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne wrote: > > Some SoCs might have multiple interconnects each with their own DMA > addressing limitations. This function parses the 'dma-ranges' on each of > them and tries to guess the maximum SoC wide DMA addressable memory > size. > > This is specially useful for arch code in order to properly setup CMA > and memory zones. We already have a way to setup CMA in reserved-memory, so why is this needed for that? I have doubts this can really be generic... > > Signed-off-by: Nicolas Saenz Julienne > --- > > drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/of_fdt.h | 2 ++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 9cdf14b9aaab..f2444c61a136 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void) > } > #endif > > +/** > + * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the > + * maximum common dmable memory size. > + * > + * Some devices might have multiple interconnects each with their own DMA > + * addressing limitations. For example the Raspberry Pi 4 has the following: > + * > + * soc { > + * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * v3dbus { > + * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * scb { > + * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>; > + * [...] > + * } > + * > + * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence > + * the function will write in 'data' a size of 0x3c000000. > + * > + * Note that the implementation assumes all interconnects have the same physical > + * memory view and that the mapping always start at the beginning of RAM. Not really a valid assumption for general code. > + */ > +int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname, > + int depth, void *data) Don't use the old fdt scanning interface with depth/data. It's not really needed now because you can just use libfdt calls. > +{ > + const char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u64 phys_addr, dma_addr, size; > + u64 *dma_zone_size = data; > + int dma_addr_cells; > + const __be32 *reg; > + const void *prop; > + int len; > + > + if (depth == 0) > + *dma_zone_size = 0; > + > + /* > + * We avoid pci host controllers as they have their own way of using > + * 'dma-ranges'. > + */ > + if (type && !strcmp(type, "pci")) > + return 0; > + > + reg = of_get_flat_dt_prop(node, "dma-ranges", &len); > + if (!reg) > + return 0; > + > + prop = of_get_flat_dt_prop(node, "#address-cells", NULL); > + if (prop) > + dma_addr_cells = be32_to_cpup(prop); > + else > + dma_addr_cells = 1; /* arm64's default addr_cell size */ Relying on the defaults has been a dtc error longer than arm64 has existed. If they are missing, just bail. > + > + if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells)) > + return 0; > + > + dma_addr = dt_mem_next_cell(dma_addr_cells, ®); > + phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®); > + size = dt_mem_next_cell(dt_root_size_cells, ®); > + > + if (!*dma_zone_size || *dma_zone_size > size) > + *dma_zone_size = size; > + > + return 0; > +} It's possible to have multiple levels of nodes and dma-ranges. You need to handle that case too. Doing that and handling differing address translations will be complicated. IMO, I'd just do: if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711")) dma_zone_size = XX; 2 lines of code is much easier to maintain than 10s of incomplete code and is clearer who needs this. Maybe if we have dozens of SoCs with this problem we should start parsing dma-ranges. Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size Date: Fri, 2 Aug 2019 11:17:26 -0600 Message-ID: References: <20190731154752.16557-1-nsaenzjulienne@suse.de> <20190731154752.16557-4-nsaenzjulienne@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190731154752.16557-4-nsaenzjulienne@suse.de> Sender: linux-kernel-owner@vger.kernel.org To: Nicolas Saenz Julienne Cc: Catalin Marinas , Christoph Hellwig , wahrenst@gmx.net, Marc Zyngier , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Linux IOMMU , linux-mm@kvack.org, Frank Rowand , phill@raspberryi.org, Florian Fainelli , Will Deacon , "linux-kernel@vger.kernel.org" , Eric Anholt , Matthias Brugger , Andrew Morton , Marek Szyprowski List-Id: devicetree@vger.kernel.org On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne wrote: > > Some SoCs might have multiple interconnects each with their own DMA > addressing limitations. This function parses the 'dma-ranges' on each of > them and tries to guess the maximum SoC wide DMA addressable memory > size. > > This is specially useful for arch code in order to properly setup CMA > and memory zones. We already have a way to setup CMA in reserved-memory, so why is this needed for that? I have doubts this can really be generic... > > Signed-off-by: Nicolas Saenz Julienne > --- > > drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/of_fdt.h | 2 ++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 9cdf14b9aaab..f2444c61a136 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void) > } > #endif > > +/** > + * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the > + * maximum common dmable memory size. > + * > + * Some devices might have multiple interconnects each with their own DMA > + * addressing limitations. For example the Raspberry Pi 4 has the following: > + * > + * soc { > + * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * v3dbus { > + * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * scb { > + * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>; > + * [...] > + * } > + * > + * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence > + * the function will write in 'data' a size of 0x3c000000. > + * > + * Note that the implementation assumes all interconnects have the same physical > + * memory view and that the mapping always start at the beginning of RAM. Not really a valid assumption for general code. > + */ > +int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname, > + int depth, void *data) Don't use the old fdt scanning interface with depth/data. It's not really needed now because you can just use libfdt calls. > +{ > + const char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u64 phys_addr, dma_addr, size; > + u64 *dma_zone_size = data; > + int dma_addr_cells; > + const __be32 *reg; > + const void *prop; > + int len; > + > + if (depth == 0) > + *dma_zone_size = 0; > + > + /* > + * We avoid pci host controllers as they have their own way of using > + * 'dma-ranges'. > + */ > + if (type && !strcmp(type, "pci")) > + return 0; > + > + reg = of_get_flat_dt_prop(node, "dma-ranges", &len); > + if (!reg) > + return 0; > + > + prop = of_get_flat_dt_prop(node, "#address-cells", NULL); > + if (prop) > + dma_addr_cells = be32_to_cpup(prop); > + else > + dma_addr_cells = 1; /* arm64's default addr_cell size */ Relying on the defaults has been a dtc error longer than arm64 has existed. If they are missing, just bail. > + > + if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells)) > + return 0; > + > + dma_addr = dt_mem_next_cell(dma_addr_cells, ®); > + phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®); > + size = dt_mem_next_cell(dt_root_size_cells, ®); > + > + if (!*dma_zone_size || *dma_zone_size > size) > + *dma_zone_size = size; > + > + return 0; > +} It's possible to have multiple levels of nodes and dma-ranges. You need to handle that case too. Doing that and handling differing address translations will be complicated. IMO, I'd just do: if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711")) dma_zone_size = XX; 2 lines of code is much easier to maintain than 10s of incomplete code and is clearer who needs this. Maybe if we have dozens of SoCs with this problem we should start parsing dma-ranges. Rob 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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 3FCC4C433FF for ; Fri, 2 Aug 2019 17:17:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E988820B7C for ; Fri, 2 Aug 2019 17:17:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lhaum2PD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E988820B7C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 834596B000D; Fri, 2 Aug 2019 13:17:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BFB36B000E; Fri, 2 Aug 2019 13:17:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6381D6B0010; Fri, 2 Aug 2019 13:17:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by kanga.kvack.org (Postfix) with ESMTP id 2F0886B000D for ; Fri, 2 Aug 2019 13:17:41 -0400 (EDT) Received: by mail-pg1-f199.google.com with SMTP id 8so42504088pgl.3 for ; Fri, 02 Aug 2019 10:17:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:mime-version:references :in-reply-to:from:date:message-id:subject:to:cc; bh=djjrE6lfphI+2uZtSPLUJz7QIApveAhJ1PmPLeRGB14=; b=rQJd9QLNL7UI3FP60ebZZ/z+zo1q1ccJK3ytvKFwYQeNz9fuHQwQJzLAqIg4BhputG 6CoE/F+MLCep4uEVa9v3wa9gQb1Fb87OzoEuvz6xiWLmkLb0iabO3p+/kZIqi5xKdoxE A4VjATKD8ZeC2JUThXtFY2kpHzylsqjOaKB7KQ1lQlvTYlg3kL9wr1I8Vtgpn5kU/K1n wKKnTOOacZdAdxhKIhVDCrtXQ1GEJ42realI0Eofy381MYBw8qNDz5z+9FcATvG1Qnaw z1UPeNk2iztKF2z1jQD9ValPO3BZxHjmPtBFzZKWO8FQ0GbaaZeqH8iOIf3nngjKOlmm TzsA== X-Gm-Message-State: APjAAAWLc6QlbW3H+d+leA8jHGqbx7cBhZN0034fOO0PZBiSrSfNriF6 e/DGZ6ByehpcjfD3crfyI08APDcMuZEIr4dAhqgsifWj/0Lq7tYuzjEOgKAjYIOY4wwIhlT/nTk H+TNDKM5D71rRl0mQrpjLF2q7WUf6U/5OWckSFPC2C/nv0rcs91GVm6aVhH3esk/xwQ== X-Received: by 2002:a17:902:f301:: with SMTP id gb1mr130182619plb.292.1564766260785; Fri, 02 Aug 2019 10:17:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqzvjHaWtdErdHd5p+2LJGJOKxPuN57naaxVHVF294RMczyI/xYsKAvWOZcs8GNETN+OIi7A X-Received: by 2002:a17:902:f301:: with SMTP id gb1mr130182541plb.292.1564766259918; Fri, 02 Aug 2019 10:17:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564766259; cv=none; d=google.com; s=arc-20160816; b=iXbEN9p+3BYqoySkfzANIt2IbwJ7lWWTYkfuRVMR9XJq23bcrNhpHhLBI8+GEu1nvV 7mgWhPrbsm3zqwJeeewkr+kw6ggvBZoAbOisSPIGZzglya6YFys473+UkwvwNroi0I++ HezdNQvCRiM7rWR8HCkY9duUi0Wbk1/GvKtto+vmPyfFU9RdLn7EAMNjjNtlDZn8TQJK 9wnAgP2LTCz4/u76GNiMnGf3rYuAQBD/RB3H4Lry2S0tfToYQNIVwXqiZOQFYjd8i+eI tY/NX8EJwpxMK7Vg9MuCkZBUJEdr0WGWhQYZCfccaeZOLlZY14mBdUflMwG+EgnpfC2h 4HQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=djjrE6lfphI+2uZtSPLUJz7QIApveAhJ1PmPLeRGB14=; b=yL8DYiMZS4ce4jOk8CPZKxjX8dmsrl7VcZd4RymJOLMWdn7cDwZUEbe4c4ckpPbBT1 Pd4g4atxbStB6s0cOtR0vXwvj8Wf1fiDCLFObBTyUGlNnnvOOErjGdl5eNJQAh9HkAYC VeEx780vQa52cIDLi9XA6I0FDGbL7y8sOJWgcLjAdSSXSU2Z6xXQtSWPMAbSAZLQTEiZ 6RLYoxTy0SNDPCulnHnfspahiIYcjo7d0NtGOaHNifaR/UCc/IFWZDMoUelDuW9bLX19 fn+BiptgLUSPQMWIcs+M2RQCKjK6liYEvLNMJz4c6e2kDwqrH4tP73PUJfy7KURzATtz d5Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lhaum2PD; spf=pass (google.com: domain of robh+dt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail.kernel.org (mail.kernel.org. [198.145.29.99]) by mx.google.com with ESMTPS id d37si34233702pla.288.2019.08.02.10.17.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 10:17:39 -0700 (PDT) Received-SPF: pass (google.com: domain of robh+dt@kernel.org designates 198.145.29.99 as permitted sender) client-ip=198.145.29.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lhaum2PD; spf=pass (google.com: domain of robh+dt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 64955217F4 for ; Fri, 2 Aug 2019 17:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564766259; bh=5vmjMpiDWDoHbfIEjw2l5ptTIfiiyZTgBi7QK8QIoHM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lhaum2PDzZjeWUO+WsAPOwKR/YgoXWAR0RXVBZYh5t5+PfmXONrVeQpGaqPVUFLNV zeDEVI0jHfexKJbsQD+EJtDab3k6iGED56EBhGxGJaIwBy9kSo1dYlZn9j/4qmkL4a R3PlUQKqZUXTeiEG8RYoleZ6v44K+IO5A8+pUoig= Received: by mail-qk1-f170.google.com with SMTP id m14so29663091qka.10 for ; Fri, 02 Aug 2019 10:17:39 -0700 (PDT) X-Received: by 2002:a37:a48e:: with SMTP id n136mr93644586qke.223.1564766258476; Fri, 02 Aug 2019 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <20190731154752.16557-1-nsaenzjulienne@suse.de> <20190731154752.16557-4-nsaenzjulienne@suse.de> In-Reply-To: <20190731154752.16557-4-nsaenzjulienne@suse.de> From: Rob Herring Date: Fri, 2 Aug 2019 11:17:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size To: Nicolas Saenz Julienne Cc: Catalin Marinas , Christoph Hellwig , wahrenst@gmx.net, Marc Zyngier , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Linux IOMMU , linux-mm@kvack.org, Frank Rowand , phill@raspberryi.org, Florian Fainelli , Will Deacon , "linux-kernel@vger.kernel.org" , Eric Anholt , Matthias Brugger , Andrew Morton , Marek Szyprowski , "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne wrote: > > Some SoCs might have multiple interconnects each with their own DMA > addressing limitations. This function parses the 'dma-ranges' on each of > them and tries to guess the maximum SoC wide DMA addressable memory > size. > > This is specially useful for arch code in order to properly setup CMA > and memory zones. We already have a way to setup CMA in reserved-memory, so why is this needed for that? I have doubts this can really be generic... > > Signed-off-by: Nicolas Saenz Julienne > --- > > drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/of_fdt.h | 2 ++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 9cdf14b9aaab..f2444c61a136 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void) > } > #endif > > +/** > + * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the > + * maximum common dmable memory size. > + * > + * Some devices might have multiple interconnects each with their own DMA > + * addressing limitations. For example the Raspberry Pi 4 has the following: > + * > + * soc { > + * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * v3dbus { > + * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * scb { > + * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>; > + * [...] > + * } > + * > + * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence > + * the function will write in 'data' a size of 0x3c000000. > + * > + * Note that the implementation assumes all interconnects have the same physical > + * memory view and that the mapping always start at the beginning of RAM. Not really a valid assumption for general code. > + */ > +int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname, > + int depth, void *data) Don't use the old fdt scanning interface with depth/data. It's not really needed now because you can just use libfdt calls. > +{ > + const char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u64 phys_addr, dma_addr, size; > + u64 *dma_zone_size = data; > + int dma_addr_cells; > + const __be32 *reg; > + const void *prop; > + int len; > + > + if (depth == 0) > + *dma_zone_size = 0; > + > + /* > + * We avoid pci host controllers as they have their own way of using > + * 'dma-ranges'. > + */ > + if (type && !strcmp(type, "pci")) > + return 0; > + > + reg = of_get_flat_dt_prop(node, "dma-ranges", &len); > + if (!reg) > + return 0; > + > + prop = of_get_flat_dt_prop(node, "#address-cells", NULL); > + if (prop) > + dma_addr_cells = be32_to_cpup(prop); > + else > + dma_addr_cells = 1; /* arm64's default addr_cell size */ Relying on the defaults has been a dtc error longer than arm64 has existed. If they are missing, just bail. > + > + if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells)) > + return 0; > + > + dma_addr = dt_mem_next_cell(dma_addr_cells, ®); > + phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®); > + size = dt_mem_next_cell(dt_root_size_cells, ®); > + > + if (!*dma_zone_size || *dma_zone_size > size) > + *dma_zone_size = size; > + > + return 0; > +} It's possible to have multiple levels of nodes and dma-ranges. You need to handle that case too. Doing that and handling differing address translations will be complicated. IMO, I'd just do: if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711")) dma_zone_size = XX; 2 lines of code is much easier to maintain than 10s of incomplete code and is clearer who needs this. Maybe if we have dozens of SoCs with this problem we should start parsing dma-ranges. Rob 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=-6.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 922B2C433FF for ; Fri, 2 Aug 2019 17:20:27 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (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 69B2E21773 for ; Fri, 2 Aug 2019 17:20:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lhaum2PD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69B2E21773 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 3C00D153D; Fri, 2 Aug 2019 17:20:27 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 411FD1498 for ; Fri, 2 Aug 2019 17:17:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C475A7ED for ; Fri, 2 Aug 2019 17:17:39 +0000 (UTC) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 67D71217F5 for ; Fri, 2 Aug 2019 17:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564766259; bh=5vmjMpiDWDoHbfIEjw2l5ptTIfiiyZTgBi7QK8QIoHM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lhaum2PDzZjeWUO+WsAPOwKR/YgoXWAR0RXVBZYh5t5+PfmXONrVeQpGaqPVUFLNV zeDEVI0jHfexKJbsQD+EJtDab3k6iGED56EBhGxGJaIwBy9kSo1dYlZn9j/4qmkL4a R3PlUQKqZUXTeiEG8RYoleZ6v44K+IO5A8+pUoig= Received: by mail-qk1-f181.google.com with SMTP id r4so55276846qkm.13 for ; Fri, 02 Aug 2019 10:17:39 -0700 (PDT) X-Gm-Message-State: APjAAAWR0Q+7Z4EcByE2M+rVs5hVr3vpLi50cjdt1sq8XvPVlAx2BjUv 8xXmAZKEGlRoaBQC4ePPePLuAr8Fj8G3QJD2Ag== X-Google-Smtp-Source: APXvYqxL5GHe5mkbUxAz7mbqxNvzn4pWJks7bPOqG/UgQKQwi7xLsLORGJlb/4eoiQbYIUPfkF/if0CjxqkRI+lgyvY= X-Received: by 2002:a37:a48e:: with SMTP id n136mr93644586qke.223.1564766258476; Fri, 02 Aug 2019 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <20190731154752.16557-1-nsaenzjulienne@suse.de> <20190731154752.16557-4-nsaenzjulienne@suse.de> In-Reply-To: <20190731154752.16557-4-nsaenzjulienne@suse.de> From: Rob Herring Date: Fri, 2 Aug 2019 11:17:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size To: Nicolas Saenz Julienne Cc: phill@raspberryi.org, devicetree@vger.kernel.org, "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" , Florian Fainelli , Frank Rowand , Eric Anholt , Marc Zyngier , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , linux-mm@kvack.org, Linux IOMMU , Matthias Brugger , wahrenst@gmx.net, Andrew Morton , Robin Murphy , Christoph Hellwig , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne wrote: > > Some SoCs might have multiple interconnects each with their own DMA > addressing limitations. This function parses the 'dma-ranges' on each of > them and tries to guess the maximum SoC wide DMA addressable memory > size. > > This is specially useful for arch code in order to properly setup CMA > and memory zones. We already have a way to setup CMA in reserved-memory, so why is this needed for that? I have doubts this can really be generic... > > Signed-off-by: Nicolas Saenz Julienne > --- > > drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/of_fdt.h | 2 ++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 9cdf14b9aaab..f2444c61a136 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void) > } > #endif > > +/** > + * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the > + * maximum common dmable memory size. > + * > + * Some devices might have multiple interconnects each with their own DMA > + * addressing limitations. For example the Raspberry Pi 4 has the following: > + * > + * soc { > + * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * v3dbus { > + * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * scb { > + * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>; > + * [...] > + * } > + * > + * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence > + * the function will write in 'data' a size of 0x3c000000. > + * > + * Note that the implementation assumes all interconnects have the same physical > + * memory view and that the mapping always start at the beginning of RAM. Not really a valid assumption for general code. > + */ > +int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname, > + int depth, void *data) Don't use the old fdt scanning interface with depth/data. It's not really needed now because you can just use libfdt calls. > +{ > + const char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u64 phys_addr, dma_addr, size; > + u64 *dma_zone_size = data; > + int dma_addr_cells; > + const __be32 *reg; > + const void *prop; > + int len; > + > + if (depth == 0) > + *dma_zone_size = 0; > + > + /* > + * We avoid pci host controllers as they have their own way of using > + * 'dma-ranges'. > + */ > + if (type && !strcmp(type, "pci")) > + return 0; > + > + reg = of_get_flat_dt_prop(node, "dma-ranges", &len); > + if (!reg) > + return 0; > + > + prop = of_get_flat_dt_prop(node, "#address-cells", NULL); > + if (prop) > + dma_addr_cells = be32_to_cpup(prop); > + else > + dma_addr_cells = 1; /* arm64's default addr_cell size */ Relying on the defaults has been a dtc error longer than arm64 has existed. If they are missing, just bail. > + > + if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells)) > + return 0; > + > + dma_addr = dt_mem_next_cell(dma_addr_cells, ®); > + phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®); > + size = dt_mem_next_cell(dt_root_size_cells, ®); > + > + if (!*dma_zone_size || *dma_zone_size > size) > + *dma_zone_size = size; > + > + return 0; > +} It's possible to have multiple levels of nodes and dma-ranges. You need to handle that case too. Doing that and handling differing address translations will be complicated. IMO, I'd just do: if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711")) dma_zone_size = XX; 2 lines of code is much easier to maintain than 10s of incomplete code and is clearer who needs this. Maybe if we have dozens of SoCs with this problem we should start parsing dma-ranges. Rob _______________________________________________ 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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C29A3C32750 for ; Fri, 2 Aug 2019 17:17:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.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 95C6720880 for ; Fri, 2 Aug 2019 17:17:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="upcDU+Lw"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lhaum2PD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95C6720880 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Xzar9Vt3jpuqBQUjPa9l2DVteCutsQJyklo332eXkVg=; b=upcDU+Lw2REoK5 auAJMRZkLegfpkS65/Y6duAZcTvFGcyBedlFTrGcp0JlWtZsODfwvJ7XIw4HcJrFM3Ma6iWiO/30+ a5hHJ5SpVNeLBydFtxT5x0p7dzoaBDcscdnVsb6407FEpeSmH4JwggTw6D9RoQxO3BvwdbhuJq0PR Tq7aw1W8dATCG+1YHRH4NOyXPF01IcfTiu62kf9IZOEwSD/41QF7CGiyvIKZZwIK6ZYh9aAxFrBxx aWoJt6bHJyaPjGRyadbYmiDdptGFoG8zPfLi7+aLk3ICNUIqkLjQwgA+4ogLBZ7C3O289Lga3PTnW olMz5mDh4yZ+MLGmbJrQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1htbBd-00011D-Py; Fri, 02 Aug 2019 17:17:49 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1htbBa-0000zm-1W; Fri, 02 Aug 2019 17:17:47 +0000 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7514821841; Fri, 2 Aug 2019 17:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1564766259; bh=5vmjMpiDWDoHbfIEjw2l5ptTIfiiyZTgBi7QK8QIoHM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lhaum2PDzZjeWUO+WsAPOwKR/YgoXWAR0RXVBZYh5t5+PfmXONrVeQpGaqPVUFLNV zeDEVI0jHfexKJbsQD+EJtDab3k6iGED56EBhGxGJaIwBy9kSo1dYlZn9j/4qmkL4a R3PlUQKqZUXTeiEG8RYoleZ6v44K+IO5A8+pUoig= Received: by mail-qk1-f180.google.com with SMTP id g18so55355901qkl.3; Fri, 02 Aug 2019 10:17:39 -0700 (PDT) X-Gm-Message-State: APjAAAUfpVZFlKpufmaoiK+bOafnk6wJw5IqY7M5fl6d0bg1MkDhmohY CaVR48cLoPuUliCQrA/SMxXbidhW9Ow+UTbrgQ== X-Google-Smtp-Source: APXvYqxL5GHe5mkbUxAz7mbqxNvzn4pWJks7bPOqG/UgQKQwi7xLsLORGJlb/4eoiQbYIUPfkF/if0CjxqkRI+lgyvY= X-Received: by 2002:a37:a48e:: with SMTP id n136mr93644586qke.223.1564766258476; Fri, 02 Aug 2019 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <20190731154752.16557-1-nsaenzjulienne@suse.de> <20190731154752.16557-4-nsaenzjulienne@suse.de> In-Reply-To: <20190731154752.16557-4-nsaenzjulienne@suse.de> From: Rob Herring Date: Fri, 2 Aug 2019 11:17:26 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size To: Nicolas Saenz Julienne X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190802_101746_136607_67CDF7FC X-CRM114-Status: GOOD ( 21.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: phill@raspberryi.org, devicetree@vger.kernel.org, "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" , Florian Fainelli , Frank Rowand , Eric Anholt , Marc Zyngier , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , linux-mm@kvack.org, Linux IOMMU , Matthias Brugger , wahrenst@gmx.net, Andrew Morton , Robin Murphy , Christoph Hellwig , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Marek Szyprowski Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne wrote: > > Some SoCs might have multiple interconnects each with their own DMA > addressing limitations. This function parses the 'dma-ranges' on each of > them and tries to guess the maximum SoC wide DMA addressable memory > size. > > This is specially useful for arch code in order to properly setup CMA > and memory zones. We already have a way to setup CMA in reserved-memory, so why is this needed for that? I have doubts this can really be generic... > > Signed-off-by: Nicolas Saenz Julienne > --- > > drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/of_fdt.h | 2 ++ > 2 files changed, 74 insertions(+) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 9cdf14b9aaab..f2444c61a136 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -953,6 +953,78 @@ int __init early_init_dt_scan_chosen_stdout(void) > } > #endif > > +/** > + * early_init_dt_dma_zone_size - Look at all 'dma-ranges' and provide the > + * maximum common dmable memory size. > + * > + * Some devices might have multiple interconnects each with their own DMA > + * addressing limitations. For example the Raspberry Pi 4 has the following: > + * > + * soc { > + * dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * v3dbus { > + * dma-ranges = <0x00000000 0x0 0x00000000 0x3c000000>; > + * [...] > + * } > + * > + * scb { > + * dma-ranges = <0x0 0x00000000 0x0 0x00000000 0xfc000000>; > + * [...] > + * } > + * > + * Here the area addressable by all devices is [0x00000000-0x3bffffff]. Hence > + * the function will write in 'data' a size of 0x3c000000. > + * > + * Note that the implementation assumes all interconnects have the same physical > + * memory view and that the mapping always start at the beginning of RAM. Not really a valid assumption for general code. > + */ > +int __init early_init_dt_dma_zone_size(unsigned long node, const char *uname, > + int depth, void *data) Don't use the old fdt scanning interface with depth/data. It's not really needed now because you can just use libfdt calls. > +{ > + const char *type = of_get_flat_dt_prop(node, "device_type", NULL); > + u64 phys_addr, dma_addr, size; > + u64 *dma_zone_size = data; > + int dma_addr_cells; > + const __be32 *reg; > + const void *prop; > + int len; > + > + if (depth == 0) > + *dma_zone_size = 0; > + > + /* > + * We avoid pci host controllers as they have their own way of using > + * 'dma-ranges'. > + */ > + if (type && !strcmp(type, "pci")) > + return 0; > + > + reg = of_get_flat_dt_prop(node, "dma-ranges", &len); > + if (!reg) > + return 0; > + > + prop = of_get_flat_dt_prop(node, "#address-cells", NULL); > + if (prop) > + dma_addr_cells = be32_to_cpup(prop); > + else > + dma_addr_cells = 1; /* arm64's default addr_cell size */ Relying on the defaults has been a dtc error longer than arm64 has existed. If they are missing, just bail. > + > + if (len < (dma_addr_cells + dt_root_addr_cells + dt_root_size_cells)) > + return 0; > + > + dma_addr = dt_mem_next_cell(dma_addr_cells, ®); > + phys_addr = dt_mem_next_cell(dt_root_addr_cells, ®); > + size = dt_mem_next_cell(dt_root_size_cells, ®); > + > + if (!*dma_zone_size || *dma_zone_size > size) > + *dma_zone_size = size; > + > + return 0; > +} It's possible to have multiple levels of nodes and dma-ranges. You need to handle that case too. Doing that and handling differing address translations will be complicated. IMO, I'd just do: if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711")) dma_zone_size = XX; 2 lines of code is much easier to maintain than 10s of incomplete code and is clearer who needs this. Maybe if we have dozens of SoCs with this problem we should start parsing dma-ranges. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel