From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24D1A2FAF for ; Wed, 18 Aug 2021 16:40:03 +0000 (UTC) Received: by mail-wr1-f53.google.com with SMTP id k29so4478306wrd.7 for ; Wed, 18 Aug 2021 09:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ha7pIRXhU7lIgKM6iZl7/5MXUfps49I8x1mGTn2G/w8=; b=KvVZzPhz+mK5fc19evqC4zyHudK/Odr/0pbefoznRNp9+QKXFauQFrMCz9+7+IMGv+ kBT6xIsXhtq4ROP1l6VWMA1dx1IYRqoR75xcdzZFFPyfOiUMhKKD1oCXTTLp3UteLJI0 L1p/xE+6HgyXVTV1kzxgRHAfm/J+keZB2K5OqIUrX6OpC1HCNNxLJQnh8tkT/+0q/ii5 wuWWneKMJAslsJCiQgTPjQEbhCM9ftXItQUKZ1kJ3H3EefS1r51+P5QEa/YMyrKiVhxc YfLhIihi1NKlPy13BlEamnLWcm0cvz9w708YrmMGl3JFy2/Yf6hzosfO1z0+Y2J9yfi4 f6oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ha7pIRXhU7lIgKM6iZl7/5MXUfps49I8x1mGTn2G/w8=; b=KTeKoRxIoCNSQNb+GTGmBIQb8K7MKlwAWyXK8+Jw/3mUX2JFdj/BTSC93DiYcEpBjm hd10uAzvXoHWcwu/4Cs+YoFCsrhNnLrv9BoMyJPUP8lSbQ5u7rwJJSNysd5/YLyz9f1j ARqajlz2GxDNGHzwog7zyH55+/Gndk30DDuVPiMDGE7jNdsHvrJYIg/yPlRK3kFbaPq3 3DKstOf+ieGy+k96g36Ovh7Ko7AvnjYCDUCcP0PtflYQh3yDJljRP3hQ/PaTI3cjslCZ xlGBU3IMLbWLM0V+yFCXhCFlYvzvKfQ2xflb6DEaUXYqhZJm5dVE7atAoQdVR52B5SKu TbbQ== X-Gm-Message-State: AOAM530TdOpT9KZmn480X5x/yee0uMhzfxQdRyX7dnfB5yrmXD6DNcVd 2R8B5ELGzbCl4dE7JzWB6sg= X-Google-Smtp-Source: ABdhPJzWuDpzbJgtrsE3+I2RnhODHoXt0n5NIf7WHBWuFXM7MOXZc9rKkOXOo8zH1v4Xrx93tidQmg== X-Received: by 2002:adf:f704:: with SMTP id r4mr12119842wrp.389.1629304801463; Wed, 18 Aug 2021 09:40:01 -0700 (PDT) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id g35sm6122212wmp.9.2021.08.18.09.40.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 09:40:00 -0700 (PDT) Date: Wed, 18 Aug 2021 18:39:59 +0200 From: Thierry Reding To: Dmitry Osipenko Cc: Jonathan Hunter , Ulf Hansson , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Mark Brown , Lee Jones , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Nishanth Menon , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Adrian Hunter , Mauro Carvalho Chehab , Rob Herring , Michael Turquette , linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node Message-ID: References: <20210817012754.8710-1-digetx@gmail.com> <20210817012754.8710-7-digetx@gmail.com> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eFtPHN6cNJIzUPRB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.1.1 (e2a89abc) (2021-07-12) --eFtPHN6cNJIzUPRB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2021 at 06:05:11PM +0300, Dmitry Osipenko wrote: > 18.08.2021 16:59, Thierry Reding =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Tue, Aug 17, 2021 at 04:27:26AM +0300, Dmitry Osipenko wrote: > >> Document tegra-clocks sub-node which describes Tegra SoC clocks that > >> require a higher voltage of the core power domain in order to operate > >> properly on a higher clock rates. Each node contains a phandle to OPP > >> table and power domain. > >> > >> The root PLLs and system clocks don't have any specific device dedicat= ed > >> to them, clock controller is in charge of managing power for them. > >> > >> Signed-off-by: Dmitry Osipenko > >> --- > >> .../bindings/clock/nvidia,tegra20-car.yaml | 51 +++++++++++++++++++ > >> 1 file changed, 51 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-ca= r.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> index 459d2a525393..7f5cd27e4ce0 100644 > >> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> @@ -42,6 +42,48 @@ properties: > >> "#reset-cells": > >> const: 1 > >> =20 > >> + tegra-clocks: > >> + description: child nodes are the output clocks from the CAR > >> + type: object > >> + > >> + patternProperties: > >> + "^[a-z]+[0-9]+$": > >> + type: object > >> + properties: > >> + compatible: > >> + allOf: > >> + - items: > >> + - enum: > >> + - nvidia,tegra20-sclk > >> + - nvidia,tegra30-sclk > >> + - nvidia,tegra30-pllc > >> + - nvidia,tegra30-plle > >> + - nvidia,tegra30-pllm > >> + - const: nvidia,tegra-clock > >> + > >> + operating-points-v2: > >> + $ref: /schemas/types.yaml#/definitions/phandle > >> + description: > >> + Phandle to OPP table that contains frequencies, voltage= s and > >> + opp-supported-hw property, which is a bitfield indicati= ng > >> + SoC process or speedo ID mask. > >> + > >> + clocks: > >> + items: > >> + - description: node's clock > >> + > >> + power-domains: > >> + maxItems: 1 > >> + description: phandle to the core SoC power domain > >> + > >> + required: > >> + - compatible > >> + - operating-points-v2 > >> + - clocks > >> + - power-domains > >> + > >> + additionalProperties: false > >> + > >> required: > >> - compatible > >> - reg > >> @@ -59,6 +101,15 @@ examples: > >> reg =3D <0x60006000 0x1000>; > >> #clock-cells =3D <1>; > >> #reset-cells =3D <1>; > >> + > >> + tegra-clocks { > >> + sclk { > >> + compatible =3D "nvidia,tegra20-sclk", "nvidia,tegra-c= lock"; > >> + operating-points-v2 =3D <&opp_table>; > >> + clocks =3D <&tegra_car TEGRA20_CLK_SCLK>; > >> + power-domains =3D <&domain>; > >> + }; > >> + }; > >=20 > > I wonder if it'd be better to match on the name of the node rather than > > add an artificial compatible string. We usually use the compatible > > string to match a device, but here you're really trying to add > > information about a resource provided by the CAR controller. > >=20 > > We do similar things for example in PMIC bindings where the individual > > regulators are represented in the device tree via nodes named after the > > regulator. > >=20 > > You could then also leave out the clocks property, which is weird as it > > is because it's basically a self-reference. But you don't really need > > the reference here in the first place because the CAR is already the > > parent of SCLK. >=20 > We don't have a platform device for CaR. I don't see how it's going to > work. We need to create a platform device for each RPM-capable clock > because that's how RPM works. The compatible string is required for > instantiating OF-devices from a node, otherwise we will have to > re-invent the OF core. I think we do have a platform device for CAR. It's just not bound against by the driver because these clock drivers are "special". But =66rom other parts of the series you're already trying to fix that, at least partially. But it doesn't seem right to create a platform device for each RPM- capable clock. Why do they need to be devices? They aren't, so why pretend? Is it that some API that we want to use here requires the struct device? > > Also, I don't think the tegra- prefix is necessary here. The parent node > > is already identified as Tegra via the compatible string. > >=20 > > In the case of CAR, I'd imagine something like: > >=20 > > clocks { > > sclk { > > operating-points-v2 =3D <&opp_table>; > > power-domains =3D <&domain>; > > }; > > }; > >=20 > > Now you've only got the bare minimum in here that you actually add. All > > the other data that you used to have is simply derived from the parent. >=20 > 'clocks' is already a generic keyword in DT. It's probably not okay to > redefine it. "clocks" is not a generic keyword. It's the name of a property and given that we're talking about the clock provider here, it doesn't need a clocks property of its own, so it should be fine to use that for the node. Thierry --eFtPHN6cNJIzUPRB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmEdN9wACgkQ3SOs138+ s6FSERAAi00u9umOi2kRPzgNx22NK4zXmCFm25TyZE0+c/u4y+m5z3W7btG7C5qF JedyqJ/SAA8aKttuEimSsNOiMDcQiGRpWQDR3uiv5wwk2u/0T3bdam6E3I9gBCFI 1i50Q2BISzTsiYKEu/2HTdwk8RKHZ8WRuddyc/+BjGtgto1RS975yZr/Ou1B7prp QSZCsIy9Y2ZEdVLkdnXNYauYiUqeNbigF9O/cD1bkfYfHEjS71jRMmqR05Di7Les 11yc/jftF4N2o1+nh3ziQUV5EPmEt0Q+KtphSA1FuncuwMYrcL1tpI26P2ma25zP o+MqXTst7xl3iM5HQtJqGiteFX4Z7ZF9W66DsKOoKc/C9yx+gBOJBk/7WAq9CYHK EmR0lun02aVE9/jdpWhDIiTioP6NKudMKSF8prZJVc1gnLnjfhzKWNDzqJknwB1Z Pq0sUtE25GZjmidSWpOuzi8vQtUmJB+kQsHqeKtD1kM/nV4eF5428ar+LqFp1QKi +6AS6oH/23bgFGMBvlQMSmuoNz09nZlLW2AUdPxXA3PL/Ga7c+EJlTtS8L5/L0Ik zZ5NiDwI/wgedxo8GiUTA9TaSpzFtFL3abt3+5cOXihde+0lhyLeAMYMZi4R/UDv yTBta0D48QPXz7t8EHc4D7qMDA+Igs/jGuNrNlX6k76CY+V8lXU= =wpRa -----END PGP SIGNATURE----- --eFtPHN6cNJIzUPRB-- 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=-12.2 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 9C172C4338F for ; Wed, 18 Aug 2021 16:41:01 +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 6191861075 for ; Wed, 18 Aug 2021 16:41:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6191861075 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LoxDjktGrTsJMMtmg+yZFcL9TRtmuNTgVz51vWda3wQ=; b=Xq7zTUkXhll+iBfT0lgP2AqQct bFu27hMkT5gEGwMwUvzS4IeE9VSzrrkYOUr/8yQtSa/fjV+LsikWjPjMPsVbeSxmQc9CpmEDqbZLj zZ2avhU7jxst7+cIW4NQw1/aOsR9b0u0K9yMOHcITrHVn0QLGeVr1yrYsGJobp+Qupmj/sLBai0Jv 9yMg+ui3JRrPNYCXXhDtVME89P5giTGoduxTOgOn/ZXaD1QuRJBHS3oHrxB7kVlGMCdcKcpVv4rJ6 i6fIGQW9x2uNAuovWUpoeVlfIGEOK/9wcSWV3M2EfxGBA1+Su1Y8IxpwLssJKysBOqWmcouGyTwTa bcVL4L6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGObm-006CQj-GE; Wed, 18 Aug 2021 16:40:06 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGObk-006CQ5-16 for linux-mtd@lists.infradead.org; Wed, 18 Aug 2021 16:40:05 +0000 Received: by mail-wr1-x42b.google.com with SMTP id k8so4507954wrn.3 for ; Wed, 18 Aug 2021 09:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ha7pIRXhU7lIgKM6iZl7/5MXUfps49I8x1mGTn2G/w8=; b=KvVZzPhz+mK5fc19evqC4zyHudK/Odr/0pbefoznRNp9+QKXFauQFrMCz9+7+IMGv+ kBT6xIsXhtq4ROP1l6VWMA1dx1IYRqoR75xcdzZFFPyfOiUMhKKD1oCXTTLp3UteLJI0 L1p/xE+6HgyXVTV1kzxgRHAfm/J+keZB2K5OqIUrX6OpC1HCNNxLJQnh8tkT/+0q/ii5 wuWWneKMJAslsJCiQgTPjQEbhCM9ftXItQUKZ1kJ3H3EefS1r51+P5QEa/YMyrKiVhxc YfLhIihi1NKlPy13BlEamnLWcm0cvz9w708YrmMGl3JFy2/Yf6hzosfO1z0+Y2J9yfi4 f6oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ha7pIRXhU7lIgKM6iZl7/5MXUfps49I8x1mGTn2G/w8=; b=mHExFL+vXlsPZoG8TFs+gywHpYKG3HWyapaGt5+QPAUQUE3JY6+rFs98oV4hmYeyGF yOrxr84Y7Cg9dLZhmO+8FjoGpc5QifcWK4DfhJdXP9prdxTHUBrhcqo5Cp17/+HuZVvP 8mzOaPP2267bN5BJJtq1GFEVF967uqmGxXw6REPZWZfXGVSV7GnFKAsaCP60XC5eNG/6 KOVHdIk6Hca7AOV2g/cIZBkYFUA8QI4EMbXjpR1qf01GTF9lABi+JGHaK/7f8p6z5cWg eIB/U5213zIxmU2RhNZ69xVJyNgYAisI70BYWTe994AOoEcnV4J9j93dmsNbY3RI+BoI m6pg== X-Gm-Message-State: AOAM533WYxOegwTFP0IzAMzmWKTjQBejjPKqO+ylqS9hdPwlBPt73Eu/ 6USvKmjOmEFS9si3kT9JOuU= X-Google-Smtp-Source: ABdhPJzWuDpzbJgtrsE3+I2RnhODHoXt0n5NIf7WHBWuFXM7MOXZc9rKkOXOo8zH1v4Xrx93tidQmg== X-Received: by 2002:adf:f704:: with SMTP id r4mr12119842wrp.389.1629304801463; Wed, 18 Aug 2021 09:40:01 -0700 (PDT) Received: from localhost ([217.111.27.204]) by smtp.gmail.com with ESMTPSA id g35sm6122212wmp.9.2021.08.18.09.40.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Aug 2021 09:40:00 -0700 (PDT) Date: Wed, 18 Aug 2021 18:39:59 +0200 From: Thierry Reding To: Dmitry Osipenko Cc: Jonathan Hunter , Ulf Hansson , Viresh Kumar , Stephen Boyd , Peter De Schrijver , Mikko Perttunen , Peter Chen , Mark Brown , Lee Jones , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Nishanth Menon , Vignesh Raghavendra , Richard Weinberger , Miquel Raynal , Lucas Stach , Stefan Agner , Adrian Hunter , Mauro Carvalho Chehab , Rob Herring , Michael Turquette , linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node Message-ID: References: <20210817012754.8710-1-digetx@gmail.com> <20210817012754.8710-7-digetx@gmail.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.1.1 (e2a89abc) (2021-07-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210818_094004_118699_919588A2 X-CRM114-Status: GOOD ( 43.85 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8159034100311612382==" Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org --===============8159034100311612382== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eFtPHN6cNJIzUPRB" Content-Disposition: inline --eFtPHN6cNJIzUPRB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2021 at 06:05:11PM +0300, Dmitry Osipenko wrote: > 18.08.2021 16:59, Thierry Reding =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Tue, Aug 17, 2021 at 04:27:26AM +0300, Dmitry Osipenko wrote: > >> Document tegra-clocks sub-node which describes Tegra SoC clocks that > >> require a higher voltage of the core power domain in order to operate > >> properly on a higher clock rates. Each node contains a phandle to OPP > >> table and power domain. > >> > >> The root PLLs and system clocks don't have any specific device dedicat= ed > >> to them, clock controller is in charge of managing power for them. > >> > >> Signed-off-by: Dmitry Osipenko > >> --- > >> .../bindings/clock/nvidia,tegra20-car.yaml | 51 +++++++++++++++++++ > >> 1 file changed, 51 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-ca= r.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> index 459d2a525393..7f5cd27e4ce0 100644 > >> --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml > >> @@ -42,6 +42,48 @@ properties: > >> "#reset-cells": > >> const: 1 > >> =20 > >> + tegra-clocks: > >> + description: child nodes are the output clocks from the CAR > >> + type: object > >> + > >> + patternProperties: > >> + "^[a-z]+[0-9]+$": > >> + type: object > >> + properties: > >> + compatible: > >> + allOf: > >> + - items: > >> + - enum: > >> + - nvidia,tegra20-sclk > >> + - nvidia,tegra30-sclk > >> + - nvidia,tegra30-pllc > >> + - nvidia,tegra30-plle > >> + - nvidia,tegra30-pllm > >> + - const: nvidia,tegra-clock > >> + > >> + operating-points-v2: > >> + $ref: /schemas/types.yaml#/definitions/phandle > >> + description: > >> + Phandle to OPP table that contains frequencies, voltage= s and > >> + opp-supported-hw property, which is a bitfield indicati= ng > >> + SoC process or speedo ID mask. > >> + > >> + clocks: > >> + items: > >> + - description: node's clock > >> + > >> + power-domains: > >> + maxItems: 1 > >> + description: phandle to the core SoC power domain > >> + > >> + required: > >> + - compatible > >> + - operating-points-v2 > >> + - clocks > >> + - power-domains > >> + > >> + additionalProperties: false > >> + > >> required: > >> - compatible > >> - reg > >> @@ -59,6 +101,15 @@ examples: > >> reg =3D <0x60006000 0x1000>; > >> #clock-cells =3D <1>; > >> #reset-cells =3D <1>; > >> + > >> + tegra-clocks { > >> + sclk { > >> + compatible =3D "nvidia,tegra20-sclk", "nvidia,tegra-c= lock"; > >> + operating-points-v2 =3D <&opp_table>; > >> + clocks =3D <&tegra_car TEGRA20_CLK_SCLK>; > >> + power-domains =3D <&domain>; > >> + }; > >> + }; > >=20 > > I wonder if it'd be better to match on the name of the node rather than > > add an artificial compatible string. We usually use the compatible > > string to match a device, but here you're really trying to add > > information about a resource provided by the CAR controller. > >=20 > > We do similar things for example in PMIC bindings where the individual > > regulators are represented in the device tree via nodes named after the > > regulator. > >=20 > > You could then also leave out the clocks property, which is weird as it > > is because it's basically a self-reference. But you don't really need > > the reference here in the first place because the CAR is already the > > parent of SCLK. >=20 > We don't have a platform device for CaR. I don't see how it's going to > work. We need to create a platform device for each RPM-capable clock > because that's how RPM works. The compatible string is required for > instantiating OF-devices from a node, otherwise we will have to > re-invent the OF core. I think we do have a platform device for CAR. It's just not bound against by the driver because these clock drivers are "special". But =66rom other parts of the series you're already trying to fix that, at least partially. But it doesn't seem right to create a platform device for each RPM- capable clock. Why do they need to be devices? They aren't, so why pretend? Is it that some API that we want to use here requires the struct device? > > Also, I don't think the tegra- prefix is necessary here. The parent node > > is already identified as Tegra via the compatible string. > >=20 > > In the case of CAR, I'd imagine something like: > >=20 > > clocks { > > sclk { > > operating-points-v2 =3D <&opp_table>; > > power-domains =3D <&domain>; > > }; > > }; > >=20 > > Now you've only got the bare minimum in here that you actually add. All > > the other data that you used to have is simply derived from the parent. >=20 > 'clocks' is already a generic keyword in DT. It's probably not okay to > redefine it. "clocks" is not a generic keyword. It's the name of a property and given that we're talking about the clock provider here, it doesn't need a clocks property of its own, so it should be fine to use that for the node. Thierry --eFtPHN6cNJIzUPRB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmEdN9wACgkQ3SOs138+ s6FSERAAi00u9umOi2kRPzgNx22NK4zXmCFm25TyZE0+c/u4y+m5z3W7btG7C5qF JedyqJ/SAA8aKttuEimSsNOiMDcQiGRpWQDR3uiv5wwk2u/0T3bdam6E3I9gBCFI 1i50Q2BISzTsiYKEu/2HTdwk8RKHZ8WRuddyc/+BjGtgto1RS975yZr/Ou1B7prp QSZCsIy9Y2ZEdVLkdnXNYauYiUqeNbigF9O/cD1bkfYfHEjS71jRMmqR05Di7Les 11yc/jftF4N2o1+nh3ziQUV5EPmEt0Q+KtphSA1FuncuwMYrcL1tpI26P2ma25zP o+MqXTst7xl3iM5HQtJqGiteFX4Z7ZF9W66DsKOoKc/C9yx+gBOJBk/7WAq9CYHK EmR0lun02aVE9/jdpWhDIiTioP6NKudMKSF8prZJVc1gnLnjfhzKWNDzqJknwB1Z Pq0sUtE25GZjmidSWpOuzi8vQtUmJB+kQsHqeKtD1kM/nV4eF5428ar+LqFp1QKi +6AS6oH/23bgFGMBvlQMSmuoNz09nZlLW2AUdPxXA3PL/Ga7c+EJlTtS8L5/L0Ik zZ5NiDwI/wgedxo8GiUTA9TaSpzFtFL3abt3+5cOXihde+0lhyLeAMYMZi4R/UDv yTBta0D48QPXz7t8EHc4D7qMDA+Igs/jGuNrNlX6k76CY+V8lXU= =wpRa -----END PGP SIGNATURE----- --eFtPHN6cNJIzUPRB-- --===============8159034100311612382== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ --===============8159034100311612382==--