Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2298077rwa; Mon, 22 Aug 2022 05:40:51 -0700 (PDT) X-Google-Smtp-Source: AA6agR5gAZXhryJG9q+oqWZYjT6aca/OmXV5MkPP8qyFyBwd/TduXEfxgP7lo7poP19YmlO9nAJ8 X-Received: by 2002:a05:6a00:1402:b0:536:bf1c:3d16 with SMTP id l2-20020a056a00140200b00536bf1c3d16mr2968397pfu.20.1661172050926; Mon, 22 Aug 2022 05:40:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661172050; cv=none; d=google.com; s=arc-20160816; b=cSz9dflodKUvxzWU2mfO/zhvvDVaXZtCSIdqKfO8qk420pIGon2NRkzubTVyHmTF2K H1Hlh1sbb4zx5837HmRARRT1vywrqW/0cLOg57NOCHiWppt1CBy7Lyxa11n+/aFwqgU8 khXwmNc3h1cC3ic4W2r9Rk3sMvEOrNTqY7/UMob//XclLRfX/muX+rd9K/IaAGHZ9WGE MlhjUR/46bL0xx0wh9hsRrZNtJ7FhjcsXYqreHW1CWTJeMa1q5mzmVjtdurqDphbMWFI 0HUz9y8iH7p2w5LLuFJNIs0pRrzF1Jt70bIKDmp3QTzX9ultrxQ89XsmGoaIRhyMLsCn QQKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=1ktvx/5SauqvUdPFBR/8rPj1UDxMqAJ4fKgITpejQjo=; b=inezxH8DucQAvcwZiwdqOUzgOif52DjYxtItb0cgzQLSEInDUOCtUr3aCjQle4Ogij Ps18prz+9E1IHs1V344JNLoehMZikZcxvBztSl3SJZbmxomKgTceiL37jp2yk3txRa48 5rcQ+83+cCxvAYXvrfmzwiBrXHEvMfzLO6kRsKE7e2oIMHbHVL5tCZoyePHNhgmYvroi zO5BPXpyTTHFpKgkvYsMNo4HwSCZ4j5IgbHhElJlZKkaNEy2kE4dK7fD2IQ7Xrdz/Zq1 SR6z4XeCCocVyHGKnU6QTCG2nhqoq2qeqYbYjBQuCHbZL425U1iC5FQDM+we1GK+RANt e6gQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p5-20020a63c145000000b00415d8740505si11771046pgi.499.2022.08.22.05.40.38; Mon, 22 Aug 2022 05:40:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234379AbiHVLrE convert rfc822-to-8bit (ORCPT + 99 others); Mon, 22 Aug 2022 07:47:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230131AbiHVLrD (ORCPT ); Mon, 22 Aug 2022 07:47:03 -0400 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B48B33E22; Mon, 22 Aug 2022 04:47:02 -0700 (PDT) Received: by mail-qt1-f176.google.com with SMTP id s11so7614479qtx.6; Mon, 22 Aug 2022 04:47:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=2XJZ/Imo2dVNd0H4SfuBgLAT9QYlxOPB6r7l1kGv5p8=; b=CUp9H9Z9MnEA00D52dA9uPlykWCdBmhiiZixbz6ua5096TApkwqpTOSBh8BcW6uVEe mF35ibcjm86XWXnSR59zZ+9XJ451/4s7d64i0pVZfPzzlhzoAY/ZTYAYjh2q6ZS9UR/r cnjusCMYjxxloV4lcjHmj/8ZJ1JZZ52omuuxXCyFxTKdLOJjs4A4RTBKxIHkoDtsbBtG Ozb72UR0W06LVBVcOwFNvJn+Df1Tq7lG37TXbE3GTdjTgLWD4+oDb6L9NAsPopyrdJ4g /C6kS15NKE2VwY6/C9TdW4gKbcfHMyP2Boa11q9n3nrm0gRpkqhTDDkw0j3g/xYqGOok Sp2w== X-Gm-Message-State: ACgBeo0w2rHgAnaTmi67xA6zuuBUmYD4ETGYwNj0z/a1KG+Esgx7wqLg tIcAumBlCs3lHSypwnhW4nwk5J61yJ1xdQ== X-Received: by 2002:a05:622a:591:b0:344:5946:8da5 with SMTP id c17-20020a05622a059100b0034459468da5mr14933246qtb.473.1661168820943; Mon, 22 Aug 2022 04:47:00 -0700 (PDT) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id o13-20020a05620a2a0d00b006bad7a2964fsm10505731qkp.78.2022.08.22.04.46.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Aug 2022 04:46:59 -0700 (PDT) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-3378303138bso244746567b3.9; Mon, 22 Aug 2022 04:46:59 -0700 (PDT) X-Received: by 2002:a25:1f02:0:b0:695:92f8:5a58 with SMTP id f2-20020a251f02000000b0069592f85a58mr6143444ybf.604.1661168819290; Mon, 22 Aug 2022 04:46:59 -0700 (PDT) MIME-Version: 1.0 References: <20220815050815.22340-1-samuel@sholland.org> <20220815050815.22340-7-samuel@sholland.org> <20220815141159.10edeba5@donnerap.cambridge.arm.com> <3cd9ed5b-8348-38ac-feb1-9a7da858cebc@microchip.com> <932aaefd-e2ca-ef26-bf30-e315fb271ec5@sholland.org> In-Reply-To: From: Geert Uytterhoeven Date: Mon, 22 Aug 2022 13:46:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 06/12] riscv: dts: allwinner: Add the D1 SoC base devicetree To: Conor Dooley Cc: uwu@icenowy.me, Samuel Holland , Andre Przywara , Chen-Yu Tsai , Jernej Skrabec , linux-sunxi@lists.linux.dev, Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-riscv , Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List , Krzysztof Kozlowski , "Lad, Prabhakar" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Conor, Andre, On Sun, Aug 21, 2022 at 12:07 PM wrote: > On 21/08/2022 07:45, Icenowy Zheng wrote: > > 在 2022-08-20星期六的 17:29 +0000,Conor.Dooley@microchip.com写道: > >> On 20/08/2022 18:24, Samuel Holland wrote: > >>> On 8/15/22 12:01 PM, Conor.Dooley@microchip.com wrote: > >>>> On 15/08/2022 14:11, Andre Przywara wrote: > >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless > >>>>> you know the content is safe > >>>>> > >>>>> On Mon, 15 Aug 2022 00:08:09 -0500 > >>>>> Samuel Holland wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> thanks for all the efforts in getting those SoC peripherals > >>>>> supported! > >>>>> > >>>>>> D1 is a SoC containing a single-core T-HEAD Xuantie C906 CPU, > >>>>>> as well as > >>>>>> one HiFi 4 DSP. The SoC is based on a design that > >>>>>> additionally contained > >>>>>> a pair of Cortex A7's. For that reason, some peripherals are > >>>>>> duplicated. > >>>>> > >>>>> So because of this, the Allwinner R528 and T113 SoCs would > >>>>> share almost > >>>>> everything in this file. Would it be useful to already split > >>>>> this DT up? > >>>>> To have a base .dtsi, basically this file without /cpus and > >>>>> /soc/plic, > >>>>> then have a RISC-V specific file with just those, including the > >>>>> base? > >>>>> There is precedence for this across-arch(-directories) sharing > >>>>> with the > >>>>> Raspberry Pi and Allwinner H3/H5 SoCs. > >>>> > >>>> For those playing along at home, one example is the arm64 > >>>> bananapi m2 > >>>> dts which looks like: > >>>>> /dts-v1/; > >>>>> #include "sun50i-h5.dtsi" > >>>>> #include "sun50i-h5-cpu-opp.dtsi" > >>>>> #include > >>>>> > >>>>> / { > >>>>> model = "Banana Pi BPI-M2-Plus v1.2 H5"; > >>>>> compatible = "bananapi,bpi-m2-plus-v1.2", > >>>>> "allwinner,sun50i-h5"; > >>>>> }; > >>>> > >>>> I think this is a pretty good idea, and putting in the modularity > >>>> up > >>>> front seems logical to me, so when the arm one does eventually > >>>> get > >>>> added it can be done by only touching a single arch. > >>> > >>> This is not feasible, due to the different #interrupt-cells. See > >>> https://lore.kernel.org/linux-riscv/CAMuHMdXHSMcrVOH+vcrdRRF+i2TkMcFisGxHMBPUEa8nTMFpzw@mail.gmail.com/ > >>> > >>> Even if we share some file across architectures, you still have to > >>> update files > >>> in both places to get the interrupts properties correct. > >>> > >>> I get the desire to deduplicate things, but we already deal with > >>> updating the > >>> same/similar nodes across several SoCs, so that is nothing new. I > >>> think it would > >>> be more confusing/complicated to have all of the interrupts > >>> properties > >>> overridden in a separate file. > >> > >> Yeah, should maybe have circled back after that conversation, would > >> have been > >> nice but if the DTC can't do it nicely then w/e. > > > > Well, maybe we can overuse the facility of C preprocessor? > > > > e.g. > > > > ``` > > // For ARM > > #define SOC_PERIPHERAL_IRQ(n) GIC_SPI n > > // For RISC-V > > #define SOC_PERIPHERAL_IRQ(n) n > > ``` > > > > Geert pointed out that this is not possible (at least on the Renesas > stuff) because the GIC interrupt numbers are not the same as the > PLIC's & the DTC is not able to handle the addition: > https://lore.kernel.org/linux-riscv/CAMuHMdXHSMcrVOH+vcrdRRF+i2TkMcFisGxHMBPUEa8nTMFpzw@mail.gmail.com/ Without the ability to do additions in DTC, we could e.g. list both interrupts in the macro, like: // For ARM #define SOC_PERIPHERAL_IRQ(na, nr) GIC_SPI na // For RISC-V #define SOC_PERIPHERAL_IRQ(na, nr) nr On Mon, Aug 22, 2022 at 12:52 PM Andre Przywara wrote: > There are interrupt-maps for that: > sun8i-r528.dtsi: > soc { > #interrupt-cells = <1>; > interrupt-map = <0 18 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, > <0 19 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, > .... > > sun20i-d1.dtsi: > soc { > #interrupt-cells = <1>; > interrupt-map = <0 18 &plic 18 IRQ_TYPE_LEVEL_HIGH>, > <0 19 &plic 19 IRQ_TYPE_LEVEL_HIGH>, > > then, in the shared .dtsi: > uart0: serial@2500000 { > compatible = "snps,dw-apb-uart"; > ... > interrupts = <18>; Nice! But it's gonna be a very large interrupt-map. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds