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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0D43AECDFA1 for ; Tue, 25 Oct 2022 23:13:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FS5RejUFl39rcvxuSDsd3iH75eHmAxIUYoQf5mhWcco=; b=XNIceiL5jLXDad Uh71SvEF54GnxokKgZjviqWHS3CBY92vj75r7SQzmRZNPXOk8o3R5994QfEqahQ4B+K+9z13/fbrK ztu2HHo0pqkz1X1uAHAhLaqZQ1yl4K0yacU+rms6KJ90Zb7KGtbmZNlJClON+Scts19ZahsGR5cJ+ s80GrsemxYTH9DcF5chq2cBCtIFIMnsKr45AbhoF6NnnKxkRhEonIOXVJhe0XPYKXvpv2ifNjf82i MLi3OA+4aDBsobBYnrt+M/zkb9th4QXzAZ8Kvo9OSzLm34GiwhiyljTY+xTgbXCdaIYLxjK0880Da 4MSEAucq4WrHj0aOKz8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1onT6C-007WQV-S3; Tue, 25 Oct 2022 23:12:44 +0000 Received: from mail-ot1-f54.google.com ([209.85.210.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1onT69-007WOV-Cn for linux-arm-kernel@lists.infradead.org; Tue, 25 Oct 2022 23:12:42 +0000 Received: by mail-ot1-f54.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso799907otr.9 for ; Tue, 25 Oct 2022 16:12:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RRrEEf9YiRUt4v0hkZPiB4Bxt9hmfog8mLXW/+6+K/E=; b=H4RAQTzlNclXc4ugTP7OWESdYQ2P7NZyZZbjqDs2HR3+I4iHr7qFgJLOww+g20IUEO 5ex+bY5KwAgCGkWPiexFWwgEbbJxH9SYvzX/EyzNKMWvDPUiXzF9obRXcfCWYCAGyVLC 5PM5jJOB3r2zqnhonCtEsOfp38/RdVQbSMSk+r6KRQ+p8jvIx0Tbs7OHIGY6WTxsSHqh Nuvn+jHhhUEpCO14K6SJuRz47cNDqHuVUWDSEBRS5UIETg0JpOxY27u3tO2DasBSiuxd nmk1aArAeaDCt/EwU71qc74NzdJrK92d4neUgElwC6ugYlAKtC+c2Zk3QFjwN+TpTuCS IeTw== X-Gm-Message-State: ACrzQf34+xBs6LZjj7sVdbeqAe1SyHsHUBBjKWGkhSSuSGz4BvQhJ6gO aSEA0BqoWxCNuyhA5qmGFg== X-Google-Smtp-Source: AMsMyM5n2yXaqLQhmHmFtxDIVMg/fe7mrUK1FKIQs9kPsJaabo0UCR9ubpWxzWKxK/TfoFcL1ifXvg== X-Received: by 2002:a05:6830:4487:b0:661:dba8:cc61 with SMTP id r7-20020a056830448700b00661dba8cc61mr20275561otv.256.1666739556607; Tue, 25 Oct 2022 16:12:36 -0700 (PDT) Received: from robh_at_kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id 187-20020a4a06c4000000b00480e77f90f9sm1613263ooj.41.2022.10.25.16.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 16:12:35 -0700 (PDT) Received: (nullmailer pid 3429121 invoked by uid 1000); Tue, 25 Oct 2022 23:12:36 -0000 Date: Tue, 25 Oct 2022 18:12:36 -0500 From: Rob Herring To: Hector Martin Cc: Krzysztof Kozlowski , "Rafael J. Wysocki" , Viresh Kumar , Matthias Brugger , Sven Peter , Alyssa Rosenzweig , Krzysztof Kozlowski , Stephen Boyd , Ulf Hansson , Marc Zyngier , Mark Kettenis , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/5] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq Message-ID: <20221025231236.GA3416036-robh@kernel.org> References: <20221024043925.25379-1-marcan@marcan.st> <20221024043925.25379-3-marcan@marcan.st> <5c3126fb-8fdb-5163-95a8-136a4a7ee2ce@linaro.org> <97d3d6d4-b19c-a194-de41-f17e65bf3eb6@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <97d3d6d4-b19c-a194-de41-f17e65bf3eb6@marcan.st> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221025_161241_457715_2ECDEC15 X-CRM114-Status: GOOD ( 26.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 26, 2022 at 02:22:40AM +0900, Hector Martin wrote: > On 26/10/2022 01.01, Krzysztof Kozlowski wrote: > > On 24/10/2022 00:39, Hector Martin wrote: > >> This binding represents the cpufreq/DVFS hardware present in Apple SoCs. > >> The hardware has an independent controller per CPU cluster, and we > >> represent them as unique nodes in order to accurately describe the > >> hardware. The driver is responsible for binding them as a single cpufreq > >> device (in the Linux cpufreq model). > >> > >> Signed-off-by: Hector Martin > >> --- > >> .../cpufreq/apple,cluster-cpufreq.yaml | 119 ++++++++++++++++++ > >> 1 file changed, 119 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> > >> diff --git a/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> new file mode 100644 > >> index 000000000000..b11452f91468 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/cpufreq/apple,cluster-cpufreq.yaml > >> @@ -0,0 +1,119 @@ > >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/cpufreq/apple,cluster-cpufreq.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Apple SoC cluster cpufreq device > > > > Few nits, in general looks fine to me. > > > >> + > >> +maintainers: > >> + - Hector Martin > >> + > >> +description: | > >> + Apple SoCs (e.g. M1) have a per-cpu-cluster DVFS controller that is part of > >> + the cluster management register block. This binding uses the standard > >> + operating-points-v2 table to define the CPU performance states, with the > >> + opp-level property specifying the hardware p-state index for that level. > >> + > >> +properties: > >> + compatible: > >> + oneOf: > >> + - items: > >> + - const: apple,t8103-cluster-cpufreq > >> + - const: apple,cluster-cpufreq > >> + - items: > >> + - const: apple,t6000-cluster-cpufreq > >> + - const: apple,t8103-cluster-cpufreq > >> + - const: apple,cluster-cpufreq > >> + - items: > >> + - const: apple,t8112-cluster-cpufreq > > > > With the first one (t8103) - it's an enum. > > This is deliberate. t6000 is compatible with t8103, but t8112 is not > (though all are compatible with what the generic apple,cluster-cpufreq > compatible implies). What does compatible mean here? IOW, what can a client do with 'apple,cluster-cpufreq' alone? It's one thing for self-contained blocks to remain unchanged from chip to chip, but things like this tend to change frequently. It looks like for 4 chips we have 3 different versions. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel