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 1EC50C433F5 for ; Sat, 2 Apr 2022 11:41:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241562AbiDBLn2 (ORCPT ); Sat, 2 Apr 2022 07:43:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241431AbiDBLn1 (ORCPT ); Sat, 2 Apr 2022 07:43:27 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62A3A1AC434 for ; Sat, 2 Apr 2022 04:41:35 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id u16so7655567wru.4 for ; Sat, 02 Apr 2022 04:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=AvR1umnn7W1R+x4WzthY5v4HXESOD96tHh9j731yuyI=; b=Gb6gnH4BnPj01KZH7A4kXWQ8hmeq0ZH581OTlA9kouF5HlC/q7ghy/f13YADvbS+Jo hYeV0Lhen1057rY1ps9eXglxGWRJ+9oRLY9DfDek3HIVk4IYUe2lnyyslvpf2g1JYS7t I4dI75ExLKdFIlfv/0VN0wWhqI5a6PD4KNZzo2syvpF2dSYiOlo/0DCazPjtPcQdhRpT efWFjuBh+6qwnv9V7aXGZTJ+KvtHs3Oh6OMeLBrDsxPMfrOHqeuZr1GZda1mEBn8rk1D v97fMdC6ZSOKulNYUi/cNy4CqgI9CqL6iEE+owkBtFoodtinaSJk5F/iI8hsr4SePWhE jLHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AvR1umnn7W1R+x4WzthY5v4HXESOD96tHh9j731yuyI=; b=VqsJAWPFw3/hohY89GbZjbY+DkVlu73Nj90vTyvjgjzChb2PvhfLz+jgtwqIb7uYrB kml2qzhqnIcHzrXWZW0wBUG9PFTrhY3ljEjb94t5VdrBpGuauGw+htkRnPs7n3EA/Hz4 w/HWtzN07oYbhQz9zrbhGCsGTC2HwAggiR/NJGqCrIs4Q+WaRg0rs0kzySjp1LePf3NI 70s8qhxA88F/TTTakABl8Y16N7EkCnTt64LDBunMsWck5BkFdyRzX9jbcyE1/guaAG/R AvogpksiSRgJCyZf78SqHDIsGmJoK7rEJfeXwZh7bXpG64gDOcfSgI4vqom1LU8ZYxt8 3SRg== X-Gm-Message-State: AOAM530r4TjptNH9aczcuFH3MWiMJi1wOP1/rNWUwWqunJXzycuQXyXM qyZE5BNom/H5ocKFMBwoUAh1bQ== X-Google-Smtp-Source: ABdhPJyW+SkwDs4JCR2UYWWgiflNxMZWrZjRmhyqzN/fVy0Es0dbeHwx6imdXZmBlennZaTR9okHog== X-Received: by 2002:adf:f881:0:b0:203:f9b1:a6ab with SMTP id u1-20020adff881000000b00203f9b1a6abmr10755817wrp.410.1648899693983; Sat, 02 Apr 2022 04:41:33 -0700 (PDT) Received: from [192.168.0.171] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.gmail.com with ESMTPSA id m63-20020a1c2642000000b0038e5fa06b50sm1932105wmm.31.2022.04.02.04.41.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Apr 2022 04:41:32 -0700 (PDT) Message-ID: Date: Sat, 2 Apr 2022 13:41:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v3 1/2] dt-bindings: clock: convert rockchip,rk3188-cru.txt to YAML Content-Language: en-US To: =?UTF-8?Q?Heiko_St=c3=bcbner?= , Johan Jonker , zhangqing@rock-chips.com, Stephen Boyd Cc: robh+dt@kernel.org, krzk+dt@kernel.org, mturquette@baylibre.com, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <20220329111323.3569-1-jbx6244@gmail.com> <20220331225134.7A0A9C340ED@smtp.kernel.org> <3107512.vfdyTQepKt@diego> From: Krzysztof Kozlowski In-Reply-To: <3107512.vfdyTQepKt@diego> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 01/04/2022 09:55, Heiko Stübner wrote: > Hi Stephen, > > Am Freitag, 1. April 2022, 00:51:32 CEST schrieb Stephen Boyd: >> Quoting Johan Jonker (2022-03-29 04:13:22) >>> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml >>> new file mode 100644 >>> index 000000000..ddd7e46af >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml >>> @@ -0,0 +1,78 @@ >>> +# SPDX-License-Identifier: GPL-2.0 >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/clock/rockchip,rk3188-cru.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Rockchip RK3188/RK3066 Clock and Reset Unit (CRU) >>> + >>> +maintainers: >>> + - Elaine Zhang >>> + - Heiko Stuebner >>> + >>> +description: | >>> + The RK3188/RK3066 clock controller generates and supplies clocks to various >>> + controllers within the SoC and also implements a reset controller for SoC >>> + peripherals. >>> + Each clock is assigned an identifier and client nodes can use this identifier >>> + to specify the clock which they consume. All available clocks are defined as >>> + preprocessor macros in the dt-bindings/clock/rk3188-cru.h and >>> + dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources. >>> + Similar macros exist for the reset sources in these files. >>> + There are several clocks that are generated outside the SoC. It is expected >>> + that they are defined using standard clock bindings with following >>> + clock-output-names: >>> + - "xin24m" - crystal input - required >>> + - "xin32k" - RTC clock - optional >>> + - "xin27m" - 27mhz crystal input on RK3066 - optional >>> + - "ext_hsadc" - external HSADC clock - optional >>> + - "ext_cif0" - external camera clock - optional >>> + - "ext_rmii" - external RMII clock - optional >>> + - "ext_jtag" - external JTAG clock - optional >> >> I'd expect all these clks here to be inputs to this node. > > The optional clocks are all part of a circular dependency. > > So for example xin32k normally is generated by the pmic and fed > back into the system, so to get xin32k, we need the pmic to probe, > which needs i2c, which in turn already needs the clock controller. Are you sure that xin32k (RTC) clock should be input to the clock controller? I would expect it is the input to the SoC RTC block, so there is no circular dependency. Best regards, Krzysztof