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 17469C3F6B0 for ; Sat, 6 Aug 2022 04:43:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237074AbiHFEnp (ORCPT ); Sat, 6 Aug 2022 00:43:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238132AbiHFEno (ORCPT ); Sat, 6 Aug 2022 00:43:44 -0400 Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EA14619035 for ; Fri, 5 Aug 2022 21:43:42 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id br15-20020a056830390f00b0061c9d73b8bdso3127447otb.6 for ; Fri, 05 Aug 2022 21:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Adh7Ypb7Bmy8isKMWTtzZFcBEH2hcOgccGX/JYLxyhY=; b=mQeR4p1ccfIZ2MF5ic3XoUcUw/s801es0iQrTJrc4FpnuGfRga+icLZfmBSFme8g9k bpgSx0fyeb8OEqbepbAz1HAgLt7QmAzg59AWyacvS3IFmTUSFOvHsKL80JQBTVFq0cMh LyWNdo1BNB/0j/onufu0Xzfuv+2fh4TPFURE6DsEvDrqb7kGO0vNuLWSv/VBvaq98RQx nzi5nJ2qiEGnvkEHHTwcesHOPQHue8Te3mkdJkl77/AjeKtLYoz6tTQitWwuNK7xrGUY /X4M+x7bFEUuHqYXEvAKc3xv906cO3aPoCRNzHtLkIqRwHeZp3Y40uxMBBL0SvhOCvvy Sn3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Adh7Ypb7Bmy8isKMWTtzZFcBEH2hcOgccGX/JYLxyhY=; b=nGUQ32KScQ/EcNFJK3cRjN7MmH7f8oz1PJzFIUimv76PKVhj+73eI0R4MSer9VaZie VIzStkks9Y9nW7yQOYuG+4uHSccBB2B3No7rHVWcl/KQl2WBCW06xCYEgvdGlISDoMfu J20QWP92VDgLkkszXx6qUMiDo8JmsmObY3CfbLpmEmhJbQ3qE5B7MKpTZVPCgFGtw4YN s0iBudYpE/BUn2bPI3iuEvai2ALG5KsvZPC16bYjke7u/ktBCtHMLYVHZd5vYZKuX8R7 0HInDWi46sNIbiF/XxEuUN7EnVherMguWJGyT8tPC5/4K3msV2x5U5FFgmlAI+mmBUQr p/iA== X-Gm-Message-State: ACgBeo1O9YwQe3FmdF2TsgznnKgJdCDQ2baD5kdbq/g8TxEuauw0RBot moSpq9frYKDhB+YiA8laWZkdIrkOQSX0kzoguD7Vsg== X-Google-Smtp-Source: AA6agR6yN3NgCkx/0jTPKa2ceXVArj9zjAtwy/GrlCnfLxfYblJodTc+tCUKfsv3lexjGrx+5CLOEM/ujyn/JnxrEGs= X-Received: by 2002:a05:6830:3985:b0:636:aa59:ea1 with SMTP id bs5-20020a056830398500b00636aa590ea1mr2429045otb.44.1659761021916; Fri, 05 Aug 2022 21:43:41 -0700 (PDT) MIME-Version: 1.0 References: <20220805074935.1158098-1-jun.nie@linaro.org> In-Reply-To: From: Jun Nie Date: Sat, 6 Aug 2022 12:43:44 +0800 Message-ID: Subject: Re: [PATCH 0/4] Support dynamic voltage frequency scaling inside clock controller To: Stephan Gerhold Cc: abel.vesa@linaro.org, bjorn.andersson@linaro.org, mturquette@baylibre.com, sboyd@kernel.org, agross@kernel.org, shawn.guo@linaro.org, bryan.odonoghue@linaro.org, linux-clk@vger.kernel.org, linux-arm-msm@vger.kernel.org, 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 Stephan Gerhold =E4=BA=8E2022=E5=B9=B48=E6=9C=885=E6= =97=A5=E5=91=A8=E4=BA=94 17:32=E5=86=99=E9=81=93=EF=BC=9A > > On Fri, Aug 05, 2022 at 03:49:31PM +0800, Jun Nie wrote: > > Support dynamic voltage frequency scaling inside clock controller with > > changes in clock framework. And added msm8916 as the first SoC to > > support this feature. > > > > As far as I understand it was decided to handle this on the consumer > driver side in mainline, together with OPP tables and "required-opps" in > the device tree. If you look at e.g. sc7180.dtsi you can see that this > is heavily used there. Also see e.g. [1] for some links to related > discussions. > > For MSM8916 at least the SDHCI and DSI driver should support this > already. Some other older drivers (e.g. QUP, USB) would need some change > similar to [2] (just like they still need changes for interconnects). > > I'm not entirely sure why it was decided to not do this as part of the > clock core (maybe someone can explain or link a relevant mailing list > post?), but we should try to keep it consistent in any case. :) > > Thanks, > Stephan Hi Stephan, Thanks for the reminder! My work in clk framework was done 2 years ago actu= ally. I guess it is just before the decision to use consumer side opps for this, because I did not see any solution at the time. I think the consumer side required-opps is better than my solution. Because clock is infrastructure to initialize other devices in most cases. If clock device depends on power domains, we have to initialize the power domain first. So adjustme= nt in initialization sequence of many devices is needed sometimes. The consumer s= ide operation avoid such inconvenience. So let's forget this patch set. Regards, Jun > > [1]: https://lore.kernel.org/linux-arm-msm/20200910162610.GA7008@gerhold.= net/ > [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c= ommit/?id=3D0472f8d3c054a0ff58122fc9d2dbf84f197a284f