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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 C559CC4338F for ; Tue, 3 Aug 2021 08:13:27 +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 8F51F60F35 for ; Tue, 3 Aug 2021 08:13:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8F51F60F35 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Message-ID:Date:To:Cc:From:Subject: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Lp/dU8VAhYm6hyYYmNwFOVi2mJJBxKEqns3j11teoXI=; b=xq3vT0oO8zM0qo sld2FNtF1XgkIOP1LfVZRoghlLtkCmlL21d2dORgYRw+ytpROYMRWHRHqNDlkp9zi/+COPe4d3+WU /wOJMHC58/JfYsOTTiVilL8QIPV+c/thUdjTywdzpkuZSobvKLAyDypIfpWI6Uhu/5x6fL3M2IHCK lugG97Zu0ikOKGmuncS+NStL7K8l2L3hNajQgsSj9cVX6F1dzTSM6oF6vwatMezX0x3kkl+jyIzZf n6XkwSNvLB3vm/wOoOFf3yVzqp/+iv40hOWDkki6YLmIJYpNjvgt0j4JhuG5XTA+Ig8rCswmjPFh7 LBiOMweE+mcWwVTfgxQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mApWp-001Zdw-Ug; Tue, 03 Aug 2021 08:12:00 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mApWm-001ZdT-0R for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 08:11:57 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id A474260F35; Tue, 3 Aug 2021 08:11:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627978315; bh=msnR5QzQeo3Lq11b0UAkCf4kr/ykeiduGDAXCY8iwbw=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=urCAC6Ev+tDAWmhFVuc36aGNlm/4q0CA0aQhxRhVjrC378XcgxLT+2NauPR+ev4nB kSQTcqx6GV8p+sXmGA8LLjetdmJoxKzbw98++UBcURojbIMG+9Mm0XL/gx1SzH7btB BfR06oa72KvsgXu+mKJxPz8EVem7/dkkHl36SBPSPGwDf9dXoauMDbP1KXYzVgIIfB SciCzuPQcywiGCqSlKJeMhom/PvMoFAndKcz6gAZe4BYC7ozau3zU++5NR6L+FlLDP n7EemAaNmXuEQ8uuNcrWYenWr142vQwlhSF9EjbSj3rx3hXSQ+T7/YlDJlBVD12B42 BuFVGL3BLEpQg== MIME-Version: 1.0 In-Reply-To: <20210802163824.GK22278@shell.armlinux.org.uk> References: <20210723091331.wl33wtcvvnejuhau@pengutronix.de> <06e799be-b7c0-5b93-8586-678a449d2239@microchip.com> <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> Subject: Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks] From: Stephen Boyd Cc: alexandre.belloni@bootlin.com, Michael Turquette , thierry.reding@gmail.com, lee.jones@linaro.org, linux-clk@vger.kernel.org, linux-rtc@vger.kernel.org, Ludovic.Desroches@microchip.com, 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, kernel@pengutronix.de, akpm@linux-foundation.org, torvalds@linux-foundation.org, Claudiu.Beznea@microchip.com To: Russell King (Oracle) , Date: Tue, 03 Aug 2021 01:11:54 -0700 Message-ID: <162797831443.714452.3551045763456936564@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210803_011156_125677_5308AE90 X-CRM114-Status: GOOD ( 24.82 ) 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 Quoting Russell King (Oracle) (2021-08-02 09:38:24) > On Mon, Aug 02, 2021 at 05:27:55PM +0200, Uwe Kleine-Konig wrote: > > Hello Russell, > > > > On Mon, Aug 02, 2021 at 10:48:10AM +0100, Russell King (Oracle) wrote: > > > > There have been several different approaches to wrapping things up, > > > but here's a question: should we make it easier to do the lazy thing > > > (get+enable) or should we make it easier to be power efficient? > > > Shouldn't we be encouraging people to write power efficient drivers? > > > > Yeah, sounds compelling, but I wonder if that's of practical importance. > > How many driver authors do you expect to lure into making a better > > driver just because devm_clk_get_prepared() doesn't exist? In contrast: > > How many drivers become simpler with devm_clk_get_prepared() and so > > it becomes easier to maintain them and easier to spot bugs? > > In the absence of devm_clk_get_prepared(), is it better that several > > frameworks (or drivers) open code it? > > It probably depends on where you stand on power management and power > efficiency issues. Personally, I would like to see more effort put > into drivers to make them more power efficient, and I believe in the > coming years, power efficiency is going to become a big issue. > I agree we should put more effort into power efficiency in the kernel. I've occasionally heard from driver writers that they never will turn the clk off even in low power modes though. They feel like it's a nuisance to have to do anything with the clk framework in their driver. When I say "why not use runtime PM?" I get told that they're not turning the clk off because it needs to be on all the time, so using runtime PM makes the driver more complicated, not less, and adds no value. I think some touchscreens are this way, and watchdogs too. Looking at the drivers being converted in this series I suspect RTC is one of those sorts of devices as well. But SPI and I2C most likely could benefit from using runtime PM and so those ones don't feel appropriate to convert. Maybe this series would be more compelling if those various drivers that 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. Doing $ git grep devm_add_action | grep clk seems to catch quite a few of them. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel