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 C8C41C4332F for ; Fri, 8 Apr 2022 03:14:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233929AbiDHDQs (ORCPT ); Thu, 7 Apr 2022 23:16:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233907AbiDHDQq (ORCPT ); Thu, 7 Apr 2022 23:16:46 -0400 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4330B185459; Thu, 7 Apr 2022 20:14:41 -0700 (PDT) X-UUID: 8eb52f8929ae4418ac0f0202cfdff902-20220408 X-UUID: 8eb52f8929ae4418ac0f0202cfdff902-20220408 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 491764811; Fri, 08 Apr 2022 11:14:34 +0800 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 11:14:33 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 11:14:33 +0800 Message-ID: Subject: Re: [PATCH 1/4] dt-bindings: cpufreq: mediatek: transform cpufreq-mediatek into yaml From: Rex-BC Chen To: Krzysztof Kozlowski , Jia-Wei Chang , Krzysztof Kozlowski , "Rafael J . Wysocki" , Viresh Kumar , Rob Herring , Liam Girdwood , Mark Brown , Matthias Brugger CC: , , , , , , , , , , , Jia-Wei Chang Date: Fri, 8 Apr 2022 11:14:33 +0800 In-Reply-To: <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> References: <20220307122151.11666-1-jia-wei.chang@mediatek.com> <20220307122151.11666-2-jia-wei.chang@mediatek.com> <2cf526d400c011b5172ba4fc2c3f03b4a4f371dc.camel@mediatek.com> <96a823a2-f3b6-9fb7-c9d6-f1315f6056fd@kernel.org> <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-04-01 at 18:32 +0200, Krzysztof Kozlowski wrote: > On 01/04/2022 15:26, Jia-Wei Chang wrote: > > On Thu, 2022-03-24 at 11:33 +0100, Krzysztof Kozlowski wrote: > > > On 24/03/2022 10:38, Jia-Wei Chang wrote: > > > > > > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..584946eb3790 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > @@ -0,0 +1,131 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/schemas/cpufreq/cpufreq-mediatek.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2NdpChkMA$ > > > > > > > > > > > > +$schema: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2O8T_oxCQ$ > > > > > > > > > > > > + > > > > > > +title: Mediatek CPUFREQ driver Device Tree Bindings > > > > > > > > > > Please remove "driver Device Tree Bindings" because the title > > > > > should > > > > > describe the hardware. Therefore it could be something like > > > > > "Mediatek > > > > > SoC CPU frequency and voltage scaling". > > > > > > > > Thanks for your suggestion of title. > > > > Or should I use the origin title "Binding for MediaTek's > > > > CPUFreq > > > > driver"? > > > > > > Mediatek CPUFREQ > > > or > > > Mediatek CPU frequency scaling > > > > Ok, I will choose one of it. > > > > > > > > > > > > > > > > > > > How is it related to cpufreq-mediatek-hw.yaml? The > > > > > names/title > > > > > look > > > > > unfortunately too similar. > > > > > > > > No, mediatek-cpufreq is performing in kernel driver rather than > > > > on > > > > hardware. > > > > On the other hand, mediatek-cpufreq-hw is performing on > > > > hardware. > > > > That's why "hw" is present in its name. > > > > > > Unfortunately, I do not get it. The bindings are only about > > > hardware, > > > so > > > how bindings could be about CPU frequency scaling not in > > > hardware? > > > > Sorry, let me correct my statements. > > > > For mediatek-cpufreq here, the required hardware are clock and > > regulator which have to be under control of mediatek-cpufreq. > > That's > > the reason why it needs bindings. > > > > mediatek-cpufreq scales up and down voltage and frequency via > > kernel > > framework of clock and regulator, however, mediatek-cpufreq-hw > > delegate > > the voltage and frequency control to a hardware agent instead. > > OK, that makes sense, thanks for explanation. > > > > > > > > > > > > > > > > > > > > In general this does not look like proper bindings (see also > > > > > below > > > > > lack > > > > > of compatible). Bindings describe the hardware, so what is > > > > > exactly > > > > > the > > > > > hardware here? > > > > > > > > Except for SoC, there's no requirement of hardware binding for > > > > mediatek-cpufreq. > > > > mediatek-cpufreq recognizes the compatible of Mediatek SoC > > > > while > > > > probing. > > > > > > What is the hardware here? If there is no requirement for > > > bindings > > > for > > > mediate-cpufreq, why do we have this patch here? > > > > Sorry, that's my mistake. > > Clock and regulator are required hardware for mediatek-cpufreq. > > > > > > > > > > > > > > > > > > > > + > > > > > > +maintainers: > > > > > > + - Jia-Wei Chang > > > > > > + > > > > > > +description: | > > > > > > + CPUFREQ is used for scaling clock frequency of CPUs. > > > > > > + The module cooperates with CCI DEVFREQ to manage > > > > > > frequency > > > > > > for > > > > > > some Mediatek > > > > > > + SoCs. > > > > > > + > > > > > > +properties: > > > > > > > > > > How is this schema going to be applied? I don't see here > > > > > select > > > > > neither > > > > > compatible. > > > > > > > > As mentioned above, only compatible of SoC is required for > > > > mediatek- > > > > cpufreq. > > > > > > It does not answer my questions. How the schema is going to be > > > applied? > > > > Currently, we do use compatible of SoC to probe mediatek-cpufreq. > > Probing and binding to compatible is correct, but there is no > compatible > here, so the schema is a no-op. Does nothing. > > > If the better way is using clock and regulator opp, do you have a > > suggestion to approach that? > > I mean I can't find a good example from other vendors trying to do > > that > > way. Or maybe I miss something? > > One other way (proper) is to use cpufreq-dt and existing bindings. I > understand that maybe you need some specific bindings here, but I > fail > to see how they would work. IOW, you don't have the compatible, no > select, so nothing can use these bindings. Also bindings do not refer > to > any specific hardware, like SoC model. > > It's good that you try to convert existing bindings to DT schema, but > with that they should be probably fixed/updated to match proper > bindings. > > Best regards, > Krzysztof > Hello Krzysztof, Thanks for your suggestion. I have discussed with Jia-wei internally. We want to push next version because we finish to prepare the driver parts. For binding part, we want to cancel the transformation to yaml first and only add the mediatek cci property for cpufreq series in next version. I will help Jia-wei to push next version. If you have any suggestion, we can discuss in the next version (v2) of this series. Thanks for your big support! BRs, Rex 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 DD868C433EF for ; Fri, 8 Apr 2022 03:22:44 +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:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5kCTRrSS46j2peeyAmt8fXzY6hx0N+1av0nKfvZYKWM=; b=GAM6exYpU8T9ln rK3tfMbdQGplyrg7g0hkJe8LGKtETzQWX2Dyoyh6Kw8jXN2z4or4KX7GKgkxSRcAIaRfN6DKSfTxc 37zbTi4grPjMXYG9jGoQUvtI7t45c5VQwZoI3lI70H7GDJRajUBh+B+s2nb3GSp8GnqNzr1SvDidD iufM4qoQ0ORrcIT479Luu78hYubjMy5lT7LBjYmdOZxGiyVqVdOPypHjXPdGLpkzn4M+v+m6E1HAJ FyibhRmFgm58aK4lkAgs8LnVkd5GAXaUMfJ4Z6r/V8/WBILm8SSH8ei6IIjwzWuAYfjY+XM8/QbZ+ gUVhm9xYrLM1yvCAo+nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncfCo-00ElVk-Am; Fri, 08 Apr 2022 03:22:38 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncfCk-00ElV0-Sc; Fri, 08 Apr 2022 03:22:36 +0000 X-UUID: c8b86ecb39b64c30bcaad42edb0f4bb2-20220407 X-UUID: c8b86ecb39b64c30bcaad42edb0f4bb2-20220407 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 590347565; Thu, 07 Apr 2022 20:22:27 -0700 Received: from mtkmbs07n1.mediatek.inc (172.21.101.16) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 Apr 2022 20:14:35 -0700 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 11:14:33 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 11:14:33 +0800 Message-ID: Subject: Re: [PATCH 1/4] dt-bindings: cpufreq: mediatek: transform cpufreq-mediatek into yaml From: Rex-BC Chen To: Krzysztof Kozlowski , Jia-Wei Chang , Krzysztof Kozlowski , "Rafael J . Wysocki" , Viresh Kumar , "Rob Herring" , Liam Girdwood , Mark Brown , Matthias Brugger CC: , , , , , , , , , , , Jia-Wei Chang Date: Fri, 8 Apr 2022 11:14:33 +0800 In-Reply-To: <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> References: <20220307122151.11666-1-jia-wei.chang@mediatek.com> <20220307122151.11666-2-jia-wei.chang@mediatek.com> <2cf526d400c011b5172ba4fc2c3f03b4a4f371dc.camel@mediatek.com> <96a823a2-f3b6-9fb7-c9d6-f1315f6056fd@kernel.org> <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_202234_968304_26CC0906 X-CRM114-Status: GOOD ( 52.35 ) X-BeenThere: linux-mediatek@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-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Fri, 2022-04-01 at 18:32 +0200, Krzysztof Kozlowski wrote: > On 01/04/2022 15:26, Jia-Wei Chang wrote: > > On Thu, 2022-03-24 at 11:33 +0100, Krzysztof Kozlowski wrote: > > > On 24/03/2022 10:38, Jia-Wei Chang wrote: > > > > > > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..584946eb3790 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > @@ -0,0 +1,131 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/schemas/cpufreq/cpufreq-mediatek.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2NdpChkMA$ > > > > > > > > > > > > +$schema: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2O8T_oxCQ$ > > > > > > > > > > > > + > > > > > > +title: Mediatek CPUFREQ driver Device Tree Bindings > > > > > > > > > > Please remove "driver Device Tree Bindings" because the title > > > > > should > > > > > describe the hardware. Therefore it could be something like > > > > > "Mediatek > > > > > SoC CPU frequency and voltage scaling". > > > > > > > > Thanks for your suggestion of title. > > > > Or should I use the origin title "Binding for MediaTek's > > > > CPUFreq > > > > driver"? > > > > > > Mediatek CPUFREQ > > > or > > > Mediatek CPU frequency scaling > > > > Ok, I will choose one of it. > > > > > > > > > > > > > > > > > > > How is it related to cpufreq-mediatek-hw.yaml? The > > > > > names/title > > > > > look > > > > > unfortunately too similar. > > > > > > > > No, mediatek-cpufreq is performing in kernel driver rather than > > > > on > > > > hardware. > > > > On the other hand, mediatek-cpufreq-hw is performing on > > > > hardware. > > > > That's why "hw" is present in its name. > > > > > > Unfortunately, I do not get it. The bindings are only about > > > hardware, > > > so > > > how bindings could be about CPU frequency scaling not in > > > hardware? > > > > Sorry, let me correct my statements. > > > > For mediatek-cpufreq here, the required hardware are clock and > > regulator which have to be under control of mediatek-cpufreq. > > That's > > the reason why it needs bindings. > > > > mediatek-cpufreq scales up and down voltage and frequency via > > kernel > > framework of clock and regulator, however, mediatek-cpufreq-hw > > delegate > > the voltage and frequency control to a hardware agent instead. > > OK, that makes sense, thanks for explanation. > > > > > > > > > > > > > > > > > > > > In general this does not look like proper bindings (see also > > > > > below > > > > > lack > > > > > of compatible). Bindings describe the hardware, so what is > > > > > exactly > > > > > the > > > > > hardware here? > > > > > > > > Except for SoC, there's no requirement of hardware binding for > > > > mediatek-cpufreq. > > > > mediatek-cpufreq recognizes the compatible of Mediatek SoC > > > > while > > > > probing. > > > > > > What is the hardware here? If there is no requirement for > > > bindings > > > for > > > mediate-cpufreq, why do we have this patch here? > > > > Sorry, that's my mistake. > > Clock and regulator are required hardware for mediatek-cpufreq. > > > > > > > > > > > > > > > > > > > > + > > > > > > +maintainers: > > > > > > + - Jia-Wei Chang > > > > > > + > > > > > > +description: | > > > > > > + CPUFREQ is used for scaling clock frequency of CPUs. > > > > > > + The module cooperates with CCI DEVFREQ to manage > > > > > > frequency > > > > > > for > > > > > > some Mediatek > > > > > > + SoCs. > > > > > > + > > > > > > +properties: > > > > > > > > > > How is this schema going to be applied? I don't see here > > > > > select > > > > > neither > > > > > compatible. > > > > > > > > As mentioned above, only compatible of SoC is required for > > > > mediatek- > > > > cpufreq. > > > > > > It does not answer my questions. How the schema is going to be > > > applied? > > > > Currently, we do use compatible of SoC to probe mediatek-cpufreq. > > Probing and binding to compatible is correct, but there is no > compatible > here, so the schema is a no-op. Does nothing. > > > If the better way is using clock and regulator opp, do you have a > > suggestion to approach that? > > I mean I can't find a good example from other vendors trying to do > > that > > way. Or maybe I miss something? > > One other way (proper) is to use cpufreq-dt and existing bindings. I > understand that maybe you need some specific bindings here, but I > fail > to see how they would work. IOW, you don't have the compatible, no > select, so nothing can use these bindings. Also bindings do not refer > to > any specific hardware, like SoC model. > > It's good that you try to convert existing bindings to DT schema, but > with that they should be probably fixed/updated to match proper > bindings. > > Best regards, > Krzysztof > Hello Krzysztof, Thanks for your suggestion. I have discussed with Jia-wei internally. We want to push next version because we finish to prepare the driver parts. For binding part, we want to cancel the transformation to yaml first and only add the mediatek cci property for cpufreq series in next version. I will help Jia-wei to push next version. If you have any suggestion, we can discuss in the next version (v2) of this series. Thanks for your big support! BRs, Rex _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 94288C433F5 for ; Fri, 8 Apr 2022 03:24:06 +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:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fFZfsVyMncNGT0748Dn26PEZ/MQpca1a7VqkZOvxVtE=; b=H+gBGquerhay+C vU7IGgjjZpYLSTADnyd+4hgj1PW2vlbjSrU0jtskCjO8vzYiGSQMaZNGwTvuvbd8gqLjvYD+l7rzS pQw9nwbue96sBBNS8rq863ky3uS4/hyHRoNHzkXUQsrkFsrUH/afNbG/8WNX3Bvs8n346CNnHBOxA unC5aH35E5YA114nHsrycBr03rFKiMMHSCHU8X9bY6TmgcZtcy5LgQZ/jVD1vQuJSLS6tIkKpH6km dIygiqK/APXtItvEYRXBkSsikjq+4hTzSwHw5AMmkMv/ArRphs4SUo/tagTNFr5FcUzgorwU87OM6 JFmma4A8W4bANY2TUv8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncfCp-00ElVs-NY; Fri, 08 Apr 2022 03:22:39 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncfCk-00ElV0-Sc; Fri, 08 Apr 2022 03:22:36 +0000 X-UUID: c8b86ecb39b64c30bcaad42edb0f4bb2-20220407 X-UUID: c8b86ecb39b64c30bcaad42edb0f4bb2-20220407 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 590347565; Thu, 07 Apr 2022 20:22:27 -0700 Received: from mtkmbs07n1.mediatek.inc (172.21.101.16) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 Apr 2022 20:14:35 -0700 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 8 Apr 2022 11:14:33 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 8 Apr 2022 11:14:33 +0800 Message-ID: Subject: Re: [PATCH 1/4] dt-bindings: cpufreq: mediatek: transform cpufreq-mediatek into yaml From: Rex-BC Chen To: Krzysztof Kozlowski , Jia-Wei Chang , Krzysztof Kozlowski , "Rafael J . Wysocki" , Viresh Kumar , "Rob Herring" , Liam Girdwood , Mark Brown , Matthias Brugger CC: , , , , , , , , , , , Jia-Wei Chang Date: Fri, 8 Apr 2022 11:14:33 +0800 In-Reply-To: <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> References: <20220307122151.11666-1-jia-wei.chang@mediatek.com> <20220307122151.11666-2-jia-wei.chang@mediatek.com> <2cf526d400c011b5172ba4fc2c3f03b4a4f371dc.camel@mediatek.com> <96a823a2-f3b6-9fb7-c9d6-f1315f6056fd@kernel.org> <56c5870e-bc41-39be-6b53-785396d8812b@linaro.org> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220407_202234_968304_26CC0906 X-CRM114-Status: GOOD ( 52.35 ) 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 Fri, 2022-04-01 at 18:32 +0200, Krzysztof Kozlowski wrote: > On 01/04/2022 15:26, Jia-Wei Chang wrote: > > On Thu, 2022-03-24 at 11:33 +0100, Krzysztof Kozlowski wrote: > > > On 24/03/2022 10:38, Jia-Wei Chang wrote: > > > > > > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > new file mode 100644 > > > > > > index 000000000000..584946eb3790 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq- > > > > > > mediatek.yaml > > > > > > @@ -0,0 +1,131 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/schemas/cpufreq/cpufreq-mediatek.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2NdpChkMA$ > > > > > > > > > > > > +$schema: > > > > > > > > > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!xbKG4TgD0MRpMLyGJVBZEGpZFrNOclrcxOCx_APKo5Nmg8nF2x5PcBdE0unvL2O8T_oxCQ$ > > > > > > > > > > > > + > > > > > > +title: Mediatek CPUFREQ driver Device Tree Bindings > > > > > > > > > > Please remove "driver Device Tree Bindings" because the title > > > > > should > > > > > describe the hardware. Therefore it could be something like > > > > > "Mediatek > > > > > SoC CPU frequency and voltage scaling". > > > > > > > > Thanks for your suggestion of title. > > > > Or should I use the origin title "Binding for MediaTek's > > > > CPUFreq > > > > driver"? > > > > > > Mediatek CPUFREQ > > > or > > > Mediatek CPU frequency scaling > > > > Ok, I will choose one of it. > > > > > > > > > > > > > > > > > > > How is it related to cpufreq-mediatek-hw.yaml? The > > > > > names/title > > > > > look > > > > > unfortunately too similar. > > > > > > > > No, mediatek-cpufreq is performing in kernel driver rather than > > > > on > > > > hardware. > > > > On the other hand, mediatek-cpufreq-hw is performing on > > > > hardware. > > > > That's why "hw" is present in its name. > > > > > > Unfortunately, I do not get it. The bindings are only about > > > hardware, > > > so > > > how bindings could be about CPU frequency scaling not in > > > hardware? > > > > Sorry, let me correct my statements. > > > > For mediatek-cpufreq here, the required hardware are clock and > > regulator which have to be under control of mediatek-cpufreq. > > That's > > the reason why it needs bindings. > > > > mediatek-cpufreq scales up and down voltage and frequency via > > kernel > > framework of clock and regulator, however, mediatek-cpufreq-hw > > delegate > > the voltage and frequency control to a hardware agent instead. > > OK, that makes sense, thanks for explanation. > > > > > > > > > > > > > > > > > > > > In general this does not look like proper bindings (see also > > > > > below > > > > > lack > > > > > of compatible). Bindings describe the hardware, so what is > > > > > exactly > > > > > the > > > > > hardware here? > > > > > > > > Except for SoC, there's no requirement of hardware binding for > > > > mediatek-cpufreq. > > > > mediatek-cpufreq recognizes the compatible of Mediatek SoC > > > > while > > > > probing. > > > > > > What is the hardware here? If there is no requirement for > > > bindings > > > for > > > mediate-cpufreq, why do we have this patch here? > > > > Sorry, that's my mistake. > > Clock and regulator are required hardware for mediatek-cpufreq. > > > > > > > > > > > > > > > > > > > > + > > > > > > +maintainers: > > > > > > + - Jia-Wei Chang > > > > > > + > > > > > > +description: | > > > > > > + CPUFREQ is used for scaling clock frequency of CPUs. > > > > > > + The module cooperates with CCI DEVFREQ to manage > > > > > > frequency > > > > > > for > > > > > > some Mediatek > > > > > > + SoCs. > > > > > > + > > > > > > +properties: > > > > > > > > > > How is this schema going to be applied? I don't see here > > > > > select > > > > > neither > > > > > compatible. > > > > > > > > As mentioned above, only compatible of SoC is required for > > > > mediatek- > > > > cpufreq. > > > > > > It does not answer my questions. How the schema is going to be > > > applied? > > > > Currently, we do use compatible of SoC to probe mediatek-cpufreq. > > Probing and binding to compatible is correct, but there is no > compatible > here, so the schema is a no-op. Does nothing. > > > If the better way is using clock and regulator opp, do you have a > > suggestion to approach that? > > I mean I can't find a good example from other vendors trying to do > > that > > way. Or maybe I miss something? > > One other way (proper) is to use cpufreq-dt and existing bindings. I > understand that maybe you need some specific bindings here, but I > fail > to see how they would work. IOW, you don't have the compatible, no > select, so nothing can use these bindings. Also bindings do not refer > to > any specific hardware, like SoC model. > > It's good that you try to convert existing bindings to DT schema, but > with that they should be probably fixed/updated to match proper > bindings. > > Best regards, > Krzysztof > Hello Krzysztof, Thanks for your suggestion. I have discussed with Jia-wei internally. We want to push next version because we finish to prepare the driver parts. For binding part, we want to cancel the transformation to yaml first and only add the mediatek cci property for cpufreq series in next version. I will help Jia-wei to push next version. If you have any suggestion, we can discuss in the next version (v2) of this series. Thanks for your big support! BRs, Rex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel