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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E477C25B0E for ; Tue, 16 Aug 2022 11:41:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234956AbiHPLlx (ORCPT ); Tue, 16 Aug 2022 07:41:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234802AbiHPLlh (ORCPT ); Tue, 16 Aug 2022 07:41:37 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CB31BCC15 for ; Tue, 16 Aug 2022 04:11:24 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id r17so14423271lfm.11 for ; Tue, 16 Aug 2022 04:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=0cuU1bG6KFLMr6an740FWMa8MPaqg8PFLx685pJUkOY=; b=GYEkY3kBMOdN21wTqQAEDOg88pgX6jp9BtCRiEAUPFEC6zLl70PjISb/WBZMzz3c/E azAJ/UWONLB1jmDNlv9VZH2FA77IyeUK8jMU51+I/lXnmBeUB6KNCTR94t1sG0NrS9vt UnWaYBYdbffWDhISjUJXAUDWBwzwYGfsDdS/xntKp6At257goXRAUH5oiRfXMgJg5aFQ 6tS7afCAa6zoTnvIK4rB3RePeJNCayOSIY6uaJ0DqtXTt5vVGG0GC7gO5ngutEGaZMca 6W5ZMF8oiVXgcqcq9d4QDxrta+c6D//Ffad0mHN5wG4u8vy2kG54TuUk19KN2RewMM6+ CzTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=0cuU1bG6KFLMr6an740FWMa8MPaqg8PFLx685pJUkOY=; b=N3zkPdCWEhEhMuZiJahJn6S3Vy6LNP4c3d42PiM+qSkegdj5KKu2Q/ewmEhhSS4r4S wLRVg6+PGHqbsmbi2Quld0Aw+Rdn1aubW5vEt6H7WxZWVpekHs2YNFtYV5lOBlazj1QS Gk9nTuC96lUQYawzUU+j3gMyvvzBsPazAIaN1PzqLxci5BwzSCZlRoSFymgYGRzLOHC9 et7Y3gsbWGd7A3nFSsgUFkb589gN52aOo6cYHBISCrjxaGQLyEiTll6/Hd5uRTgQpgUU 4zLdaawZ2y4Z9Qvr32oTToT5k1eoDwbQ+xwA1sJYehiwSLfJNcFYGur80EM3OmXY35S6 fgWw== X-Gm-Message-State: ACgBeo0E+Fgom/Y7kWkw6sW+1Rq2UNQdU8cnMwfCCQrs79wVoqLRXXHb ISJo80NVrXk+nnBm5XKz1CSj6g== X-Google-Smtp-Source: AA6agR4jvAh3L22ickhZa14uDRFbhGMs9hDFABhJBvwWXmWM/n4NtsL5IflGqzOc8MYp3IFiSXYs5A== X-Received: by 2002:ac2:47f1:0:b0:48a:ea6e:b8fd with SMTP id b17-20020ac247f1000000b0048aea6eb8fdmr6589451lfp.26.1660648282335; Tue, 16 Aug 2022 04:11:22 -0700 (PDT) Received: from ?IPV6:2001:14bb:ae:539c:1782:dd68:b0c1:c1a4? (d15l54g8c71znbtrbzt-4.rev.dnainternet.fi. [2001:14bb:ae:539c:1782:dd68:b0c1:c1a4]) by smtp.gmail.com with ESMTPSA id u17-20020a056512041100b0047f7419de4asm1354065lfk.180.2022.08.16.04.11.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 04:11:21 -0700 (PDT) Message-ID: <29072f12-b9a3-9815-ad52-5c4f6b1634b3@linaro.org> Date: Tue, 16 Aug 2022 14:11:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH 06/12] riscv: dts: allwinner: Add the D1 SoC base devicetree Content-Language: en-US To: Andre Przywara Cc: =?UTF-8?Q?Jernej_=c5=a0krabec?= , Samuel Holland , Chen-Yu Tsai , linux-sunxi@lists.linux.dev, Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-riscv@lists.infradead.org, =?UTF-8?Q?Heiko_St=c3=bcbner?= , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski References: <20220815050815.22340-1-samuel@sholland.org> <5593349.DvuYhMxLoT@jernej-laptop> <3881930.ZaRXLXkqSa@diego> <2249129.ElGaqSPkdT@jernej-laptop> <20220816120050.07dc2416@donnerap.cambridge.arm.com> From: Krzysztof Kozlowski In-Reply-To: <20220816120050.07dc2416@donnerap.cambridge.arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 16/08/2022 14:00, Andre Przywara wrote: > On Tue, 16 Aug 2022 12:42:39 +0300 > Krzysztof Kozlowski wrote: > > Hi, > >> On 16/08/2022 12:25, Jernej Škrabec wrote: >>> Dne torek, 16. avgust 2022 ob 11:12:05 CEST je Heiko Stübner napisal(a): >>>> Am Dienstag, 16. August 2022, 09:49:58 CEST schrieb Jernej Škrabec: >>>>> Dne torek, 16. avgust 2022 ob 09:41:45 CEST je Krzysztof Kozlowski >>> napisal(a): >>>>>> On 15/08/2022 08:08, Samuel Holland wrote: >>>>>>> + >>>>>>> + de: display-engine { >>>>>>> + compatible = "allwinner,sun20i-d1-display-engine"; >>>>>>> + allwinner,pipelines = <&mixer0>, <&mixer1>; >>>>>>> + status = "disabled"; >>>>>>> + }; >>>>>>> + >>>>>>> + osc24M: osc24M-clk { >>>>>> >>>>>> lowercase >>>>>> >>>>>>> + compatible = "fixed-clock"; >>>>>>> + clock-frequency = <24000000>; >>>>>> >>>>>> This is a property of the board, not SoC. >>>>> >>>>> SoC needs 24 MHz oscillator for correct operation, so each and every board >>>>> has it. Having it here simplifies board DT files. >>>> >>>> I guess the oscillator is a separate component on each board, right? >>> >>> Correct. >>> >>>> And DT obvious is meant to describe the hardware - independently from >>>> implementation-specific choices. >>> >>> There is no choice in this case. 24 MHz crystal has to be present. >>> >>> FWIW, including crystal node in SoC specific DTSI is already common pattern in >>> Allwinner ARM SoC DTSI files. >>> >>>> >>>> Starting to discuss which exceptions to allow then might lead to even more >>>> exceptions. >>>> >>>> Also having to look for a board-component in the soc dtsi also is surprising >>>> if one gets to the party later on :-) . >>> >>> As I said, if one is accustomed to Allwinner ARM DT development, it would be >>> more surprising to include 24 MHz crystal node in each and every board DT. >> >> It's same everywhere. Allwinner, Exynos, iMX, Qualcomm. Everywhere this >> is a part of the board, so even if oscillator frequency is fixed (as in >> 99% of cases although some SoCs I think might just allow to implement >> one of few), still this is a property of the board. Because: >> 1. DTSI describes the SoC part, not board. >> 2. So the DTS developer is a bit more conscious about his design. > > 1) is certainly true, but indeed most platforms put the base > crystal oscillator in the SoC .dtsi: Yes. And once per week when I look at new DTS I need to repeat the same arguments. :) > I just sampled Rockchip (rk3399.dtsi, > rk356x.dtsi, rk3328.dtsi), Amlogic (meson-g12-common.dtsi), ActionSemi (s[79]00.dtsi), > Qualcomm (msm8916.dtsi, sm8450.dtsi, sc7180.dtsi), Freescale (imx8mm.dtsi, > imx8qxp.dtsi), Realtek (rtd129x.dtsi), Broadcom (bcm283x.dtsi), Mediatek > (mt8183.dtsi, mt8516.dtsi). The list probably goes on (I just stopped > here). > > I think one reason might be that this is so central to the whole SoC > operation, that it's already referenced multiple times in the base .dtsi. > And having a yet unresolved reference in the .dtsi looks dodgy. > > NVidia seems to omit a base oscillator (maybe it's implicit in their > binding design), Marvell doesn't use a fixed-clock (but still puts their > base clock in armada-37xx.dtsi). > > Exynos and Renesas put a *stub* fixed-clock in the .dtsi, and set the > frequency in the board .dts files. Would this be a compromise? This is exactly what I said before. The clock frequency is a property of the board. Feel free to keep the rest of the clock in the SoC DTSI to reduce duplication, but at minimum the clock should go to the board. Best regards, Krzysztof