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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F12BC433EF for ; Tue, 14 Sep 2021 13:25:45 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4968D606A5 for ; Tue, 14 Sep 2021 13:25:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4968D606A5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/VZ2i813ESgGba7XeEJLcBihN3kH35ulLXt5/X8vgu0=; b=d+gDgRDdF4KNSY1mUr9g8Gw3vb m7K63i5lisxKoqTpAPpy7Yz5avvIsbzQt2XcaFcB7/A1c1gYpNe2EFoRJlCB6bq5Fzv5oR6Z8OxJd IKja6qS/dVcjQG8q2AbU3PjcnZ0qgtpudtvgI9RiBRH9UEHUI7aFLS4ZkEX5UJHzfy8au1lcyPXpQ HPx+X5cAPXaBP05yTK1b69CQCCYt1BKnwk3nUj8EfJmBFRM+EpYUa5R3OhBgRFfVocUTRDcR4uaxo l4eRLiiXUzHTuuY5qHkBDtHfBcKCF8IRvR6L3g/o88vaHfBnkpOH4hSZWmBDahgjU7iqwDuLfwl/R g7rqIHKQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQ8P1-005riS-0h; Tue, 14 Sep 2021 13:23:11 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQ8Ov-005rhb-Di for linux-arm-kernel@lists.infradead.org; Tue, 14 Sep 2021 13:23:07 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQ8Or-0007cz-Dv; Tue, 14 Sep 2021 15:23:01 +0200 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1mQ8Oo-0006RL-Ia; Tue, 14 Sep 2021 15:22:58 +0200 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1mQ8Oo-00077e-GZ; Tue, 14 Sep 2021 15:22:58 +0200 Date: Tue, 14 Sep 2021 15:22:56 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Stephen Boyd Cc: alexandre.belloni@bootlin.com, Michael Turquette , Ludovic.Desroches@microchip.com, lee.jones@linaro.org, linux-clk@vger.kernel.org, linux-rtc@vger.kernel.org, Russell King , o.rempel@pengutronix.de, andy.shevchenko@gmail.com, aardelean@deviqon.com, linux-pwm@vger.kernel.org, Arnd Bergmann , broonie@kernel.org, Jonathan.Cameron@huawei.com, linux-arm-kernel@lists.infradead.org, a.zummo@towertech.it, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, wsa@kernel.org, thierry.reding@gmail.com, kernel@pengutronix.de, akpm@linux-foundation.org, torvalds@linux-foundation.org, Claudiu.Beznea@microchip.com Subject: Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks] Message-ID: <20210914132256.5ucytcfmk3sjn2vi@pengutronix.de> References: <20210728202547.7uvfwflpruku7yps@pengutronix.de> <20210728204033.GF22278@shell.armlinux.org.uk> <162771727997.714452.2303764341103276867@swboyd.mtv.corp.google.com> <20210731120004.i3affxw7upl5y4c5@pengutronix.de> <20210802094810.GJ22278@shell.armlinux.org.uk> <20210802152755.ibisunvibmwhiyry@pengutronix.de> <20210802163824.GK22278@shell.armlinux.org.uk> <162797831443.714452.3551045763456936564@swboyd.mtv.corp.google.com> <20210803104012.wf2buscbukxufesl@pengutronix.de> <162820957661.19113.17221558053361108175@swboyd.mtv.corp.google.com> MIME-Version: 1.0 In-Reply-To: <162820957661.19113.17221558053361108175@swboyd.mtv.corp.google.com> X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210914_062305_515668_15C11E83 X-CRM114-Status: GOOD ( 41.90 ) 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: multipart/mixed; boundary="===============4363668728147539637==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4363668728147539637== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mggb23vxwlpcjl6t" Content-Disposition: inline --mggb23vxwlpcjl6t Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 05, 2021 at 05:26:16PM -0700, Stephen Boyd wrote: > Quoting Uwe Kleine-K=F6nig (2021-08-03 03:40:12) > > On Tue, Aug 03, 2021 at 01:11:54AM -0700, Stephen Boyd wrote: > > >=20 > > > Maybe this series would be more compelling if those various drivers t= hat > > > are hand rolling the devm action were converted to the consolidated > > > official devm function. The truth is it's already happening in various > > > subsystems so consolidating that logic into one place would be a win > > > code size wise and very hard to ignore. > > >=20 > > > Doing > > >=20 > > > $ git grep devm_add_action | grep clk > > >=20 > > > seems to catch quite a few of them. Will do. =20 > > Another upside is that grepping for these drivers with a potential for > > further improvement become easier to grep for as > > devm_clk_get_{prepared,enabled} is a much better hint :-) >=20 > Sorry, but that's a pretty weak argument. I'd think grepping for the > absence of pm_ops in drivers would be the same hint. To be honest: Yes, it's a weak argument, but grepping for drivers without pm_ops is a tad more complicated and yields a different set of drivers. For example take the i2c-imx driver (drivers/i2c/busses/i2c-imx.c) which has a pm_ops but still can make use of devm_clk_get_enabled. > > The changes to these drivers probably won't go through a clk tree, so > > adding these patches before adding devm_clk_get_enabled() would only > > help for the warm and cozy feeling that it is right to do so, correct? >=20 > It isn't to feel warm and cozy. It's to demonstrate the need for > consolidating code. Converting the i2c and spi drivers to use this is > actively damaging the cause though. Those driver frameworks are more > likely to encourage proper power management around bus transfers, so > converting them to use the devm API moves them away from power > management, not closer to it. Well I think one could disagree here. Today these drivers are not power efficient as they just enable the clock in their probe routine and keep it on even though it might not be needed. My patch still is beneficial as it simplifies the drivers without making them worse. Agreed, this isn't the best optimisation to the drivers (assuming it is possible to disable the clocks while the device isn't in use). > This proves why this topic is always contentious. It's too easy to > blindly convert drivers to get the clk and leave it enabled forever and > then they never use power management. The janitors win and nobody else. If the janitors win and nobody else looses anything, this is fine for me. And if in the future someone turns up who cares enough to improve the converted drivers to a more efficient clock usage, they will probably not stop their efforts just because then the driver uses devm_clk_get_enabled. > Is there some way to avoid that trap? Maybe through some combination of > a device PM function that indicates the driver has no runtime PM > callbacks (pm_runtime_no_callbacks() perhaps?) and > devm_clk_get_enabled() checking for that and returning the clk only when > that call has been made (i.e. pm_runtime_has_no_callbacks())? This > approach would fail to catch the case where system wide suspend/resume > could turn the clk off but the driver doesn't do it. I'm not sure how > much we care about that case though. >=20 > > As my focus is limited to (mostly) drivers/pwm and I already have quite > > some other patch quests on my list: >=20 > Don't we all? :) Might be. The patches in your queue are however not a reason to drop my efforts to make my queue shorter :-P Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --mggb23vxwlpcjl6t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmFAoiwACgkQwfwUeK3K 7An7Fgf+Ia8CaycjOR7ZZLxYVuGNx+XLrBQeXwl1H3567k8tcNg55hObDzgVPo1w cB9RPS5f36SEEa4ixbzMsRINVfkngTTL2zyTKgniKoy4eD0Nb0qYNKuAxRmb87yt bURm19Q+4J/gdUkTzEVqYIYcXPQJlWzEPKaGHBNlZ55stXnT1IUf5FmoPWK7FWxM 1FTzxg3khSQXc/UosMbVBY9slM4JAskBAfXk7oRasoVbuaEJldG+Gr4jDn78Cras mJHAT/hsDtRmum9dl8U2NdLXtHoEy3xg6MARQO/K50Kqixg8dIdOpajV8ynvsJFj 3RYCJRrVGp7yeeS9SRw1w6IdNbkBHg== =z44f -----END PGP SIGNATURE----- --mggb23vxwlpcjl6t-- --===============4363668728147539637== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4363668728147539637==--