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 AA20CC83F2E for ; Thu, 31 Aug 2023 16:28:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245325AbjHaQ2u (ORCPT ); Thu, 31 Aug 2023 12:28:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346832AbjHaQ2t (ORCPT ); Thu, 31 Aug 2023 12:28:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C903110C8; Thu, 31 Aug 2023 09:28:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4E0296423E; Thu, 31 Aug 2023 16:28:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9F3DC433BA; Thu, 31 Aug 2023 16:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693499318; bh=2Ww9Q0u01Ue+C8XQjrYkRHwNmgFGRGEhWZl6ghxXldA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YQ7DVYv1EQJjy14V0lYUk3VQ8WGwCK6l3oPzoE/loFFS/jMB6h9bpmbRLEiKwzGgw QRXySJsQqdhXraaq1cuL4QnN7EapEqVNq3vcLLgUxJQhtxFiHK0lNYpbX8gavTHYWF kMqv/uPNizTJBvLdOmr2g4pcp2tLBiFnJu9xzcxpzfSHMwkPYODJME9nwiEQ54Ctpa KAEzzyPSR8eUemdjm2tFnl0fX26jzYr6FADPg+D5aSkSSv49ziZu+McTBvzwgfX5P4 iM2Fdl6/RZqqCJFiwH4lqIkzaxIzU1Piz/QKUldlPrpTZaXF5Cua47KJD7uhZ6TqId HonvaYww0XrUA== Received: (nullmailer pid 2392965 invoked by uid 1000); Thu, 31 Aug 2023 16:28:35 -0000 Date: Thu, 31 Aug 2023 11:28:35 -0500 From: Rob Herring To: Ulf Hansson Cc: Konrad Dybcio , Krzysztof Kozlowski , AngeloGioacchino Del Regno , Andy Gross , Bjorn Andersson , Viresh Kumar , Nishanth Menon , Stephen Boyd , Niklas Cassel , Liam Girdwood , Mark Brown , Conor Dooley , "Rafael J. Wysocki" , Viresh Kumar , Robert Marko , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, Jeffrey Hugo , Marijn Suijten , AngeloGioacchino Del Regno Subject: Re: [PATCH v14 3/9] dt-bindings: soc: qcom: cpr3: Add bindings for CPR3 driver Message-ID: <20230831162835.GA2390385-robh@kernel.org> References: <20230217-topic-cpr3h-v14-0-9fd23241493d@linaro.org> <20230217-topic-cpr3h-v14-3-9fd23241493d@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Aug 29, 2023 at 01:01:44PM +0200, Ulf Hansson wrote: > On Mon, 28 Aug 2023 at 13:42, Konrad Dybcio wrote: > > > > From: AngeloGioacchino Del Regno > > > > Add the bindings for the CPR3 driver to the documentation. > > > > Signed-off-by: AngeloGioacchino Del Regno > > [Konrad: Make binding check pass; update AGdR's email] > > Tested-by: Jeffrey Hugo > > Signed-off-by: Konrad Dybcio > > --- > > .../devicetree/bindings/soc/qcom/qcom,cpr3.yaml | 286 +++++++++++++++++++++ > > 1 file changed, 286 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml > > new file mode 100644 > > index 000000000000..acf2e294866b > > [...] > > > + > > +examples: > > + - | > > + #include > > + #include > > + > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + cpu@0 { > > + compatible = "qcom,kryo280"; > > + device_type = "cpu"; > > + reg = <0x0 0x0>; > > + operating-points-v2 = <&cpu0_opp_table>; > > + power-domains = <&apc_cprh 0>; > > + power-domain-names = "cprh"; > > Rather than using a Qcom specific power-domain-name, perhaps a common > power-domain-name for cpus, that can be used for "the performance > domain" would be a good idea here? > > I have suggested using "perf" for the SCMI performance domain [1], > perhaps that description should be extended to cover this and other > performance domains too? Better yet, nothing. There's no value to -names when there is only 1 entry. Rob