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 7C293C001DE for ; Sat, 15 Jul 2023 12:36:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229809AbjGOMgT (ORCPT ); Sat, 15 Jul 2023 08:36:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjGOMgS (ORCPT ); Sat, 15 Jul 2023 08:36:18 -0400 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88CAC3A81 for ; Sat, 15 Jul 2023 05:36:17 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-cb4de3bd997so3554070276.1 for ; Sat, 15 Jul 2023 05:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689424575; x=1692016575; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dpJ+fMs1IOI6v0cEM4uyI8KOLiMJF74uY2KcNd4wMZA=; b=XRMoaDrV9xzJt4GcRI1SJzWMqAqfQA7QdP2W1NH2uC3lt3rejwhCKHSgpCRazRFdh7 mcXHP9x0UHQvwQJ2KjkqJ12ycfiTd9KUvfFGtDiEeqGTAzso0TyOCdJEe815KubpJZUi GlPWyDx82A66bpwH2qgE5RuFkAizPrWoOSDkNcoad4hKENo86O9rw6xEcPKqE6aQRK+F jXVGAT4HqggzQSS1YWQ6KNqN3Zr1pm4W6oqLX5kjDjjskgIjW1NTLjk9uvPBuXyMCQX6 zzGQoS9nmP57tFybZKXMH3ueVehgWX7mN5+kaJucRdKNp8qIdOKFc0zKimegh6MUQIcQ uoGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689424575; x=1692016575; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dpJ+fMs1IOI6v0cEM4uyI8KOLiMJF74uY2KcNd4wMZA=; b=a+BKq150sXPTX3CCrBKNOFBOE2ztWXbA+3wfLjWrXOK6ZCIIKMeh1Iix6PG+yUHSyr 4xiOodrURb1eiLUyfV7PJDXAnXcqF/ZIsynaRFBC4dr3DTrm5wu+jI9HcE+B7IxhmGM7 IEa6BhqHrXLC9XfIqGRzEgPwTHDRi8P9eiV3vsTkFBCsoyVjdbY27QmeQN67n4YpoBx0 jU+8+C6zzSX+703m8aJOA88BGADvAv8S5dFTTgjxa6nD1lPAJdimHvzBB0T4CQet3P/9 WSHgquf0+KNFDpsz+c1wLqrchx9ZNyx0hs/nSmWHE/9un6pOm7tACMEUcBu6fukdD27s 2jKg== X-Gm-Message-State: ABy/qLZO6OUfiai/WHLQXMTkY6ZpAYawkXYdNu0DbwemRFy9yHjMwk6G 5eZyXhtgLKK7048S27Sn3aMgJFiwNpak1Jb8Zqnw6g== X-Google-Smtp-Source: APBJJlGDF63mhRSyH4p9VTQc6rjgrJyCAVzT5nfkkrOuEPVRsn5X+Iw3TWaDpHP8YQbCm0sO287AOirXsFnAaHBT3r0= X-Received: by 2002:a0d:e649:0:b0:57a:15c0:2f5b with SMTP id p70-20020a0de649000000b0057a15c02f5bmr6283853ywe.8.1689424575647; Sat, 15 Jul 2023 05:36:15 -0700 (PDT) MIME-Version: 1.0 References: <20230607124628.157465-1-ulf.hansson@linaro.org> <20230607124628.157465-10-ulf.hansson@linaro.org> <20230614230044.GA3019052-robh@kernel.org> In-Reply-To: From: Ulf Hansson Date: Sat, 15 Jul 2023 14:35:38 +0200 Message-ID: Subject: Re: [PATCH 09/16] dt-bindings: firmware: arm,scmi: Extend bindings for protocol@13 To: Rob Herring Cc: Sudeep Holla , Cristian Marussi , Viresh Kumar , Nishanth Menon , Stephen Boyd , Nikunj Kela , Prasad Sodagudi , Alexandre Torgue , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Conor Dooley , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, 14 Jul 2023 at 19:15, Rob Herring wrote: > > On Thu, Jun 15, 2023 at 3:11=E2=80=AFAM Ulf Hansson wrote: > > > > On Thu, 15 Jun 2023 at 01:00, Rob Herring wrote: > > > > > > On Wed, Jun 07, 2023 at 02:46:21PM +0200, Ulf Hansson wrote: > > > > The protocol@13 node is describing the performance scaling option f= or the > > > > ARM SCMI interface, as a clock provider. This is unnecessary limiti= ng, as > > > > performance scaling is in many cases not limited to switching a clo= ck's > > > > frequency. > > > > > > > > Therefore, let's extend the binding so the interface can be modelle= d as a > > > > generic "performance domain" too. The common way to describe this, = is to > > > > use the "power-domain" bindings, so let's use that. > > > > > > What's wrong with the performance-domain binding? > > > > In my opinion I think the performance-domain binding is superfluous. > > We already have plenty of power-domains that do performance scaling > > too - and they stick with the power-domain binding, as it's > > sufficient. > > IMO, power-domains should be for power islands which can be power > gated. I know they are abused though. Of course, when things are > hidden in firmware, you don't really know. A power-domain could be > just a clock or a clock could be multiple physical clocks. I would also like to point out that it's perfectly possible that a power-domain can be a combination of a "power-island" and a performance-domain. In fact we have those cases already (Qcom, Tegra). > > > That said, I would rather follow the defacto standard that has been > > used for many years in the kernel. Do you have a preference that we > > should stick to? > > If power-domains are sufficient, then why do we have > performance-domains? We need clear rules for when to use what. Well, I think we invented the performance-domains bindings, especially with CPUs in mind. So far, that's the only use-case too (Mediatek, Apple). Even if I think the power-domains bindings would have worked fine for these cases too, maybe we should limit the performance-domains binding to be used for CPUs? Anyway, for the more generic use-case, I think the power-domains DT binding is better to stick with (it's what we have used for many years by now), as it provides us with the flexibility of hooking up an opp-table to the power-domain, allowing us to make the domain "performance-capable" too. Kind regards Uffe