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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 9D533C4338F for ; Sat, 31 Jul 2021 07:41:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A67860F35 for ; Sat, 31 Jul 2021 07:41:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232365AbhGaHla (ORCPT ); Sat, 31 Jul 2021 03:41:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:36210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230196AbhGaHl1 (ORCPT ); Sat, 31 Jul 2021 03:41:27 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3148A60EE6; Sat, 31 Jul 2021 07:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627717281; bh=Hv1Kjt0wM3IMrL51Qq27kQRTwgyaY1whymskpzTrLBg=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Mfe/v8Uz7KZzXezwTwjXNOUR+12p4qzmq6509mWK4HR6HXGPAgYYHOsPNIDypMN4W dptRTFmjMlRcoslggxxB3pGQBj0x6UrIzpyRhgK0eHShF1H4ayZFJwSjbVOjohBESi S7z2KmeryQRXtF7eCeDb2EWvnztkdGkPMUlZcvNgWKzC+b7h/pDhgVb1avCQX29DcW jD3PhoYFAFhcJd+plY+0d1jbLOvWrCoQRpOp8y4dhHXeVVhAQXt6M5qmuAJacc37Fb htU5NUsNIGPVW4EzuZd3O1Ri4wdN/qcx17MjnStx1zor6X+sjRKLhzQ7jQZ84kkJOU +DAteW7woUfZA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20210728204033.GF22278@shell.armlinux.org.uk> References: <20210625171434.3xusxpxjprcdqa47@pengutronix.de> <20210722060654.nudpdtemosi64nlb@pengutronix.de> <20210722081817.2tsjzof4gvldq6ka@pengutronix.de> <20210723091331.wl33wtcvvnejuhau@pengutronix.de> <06e799be-b7c0-5b93-8586-678a449d2239@microchip.com> <20210728202547.7uvfwflpruku7yps@pengutronix.de> <20210728204033.GF22278@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: Michael Turquette , Claudiu.Beznea@microchip.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, 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-spi@vger.kernel.org, wsa@kernel.org, kernel@pengutronix.de, akpm@linux-foundation.org, torvalds@linux-foundation.org To: Russell King (Oracle) , Date: Sat, 31 Jul 2021 00:41:19 -0700 Message-ID: <162771727997.714452.2303764341103276867@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Russell King (Oracle) (2021-07-28 13:40:34) > > I adapted the Subject in the hope to catch Stephen's and Michael's > > attention. My impression is that this thread isn't on their radar yet, > > but the topic here seems important enough to get a matching Subject. The thread is on my radar but... >=20 > Have you thought about sending your pull request to the clk API > maintainer (iow, me) ? >=20 +1 This patch doesn't fall under CCF maintainer. $ ./scripts/get_maintainer.pl -f include/linux/clk.h Russell King (maintainer:CLK API) linux-clk@vger.kernel.org (open list:CLK API) linux-kernel@vger.kernel.org (open list) Finally, this sort of patch has been discussed for years and I didn't see any mention of those previous attempts in the patch series. Has something changed since that time? I think we've got a bunch of hand rolled devm things in the meantime but not much else.=20 I still wonder if it would be better if we had some sort of DT binding that said "turn this clk on when the driver probes this device and keep it on until the driver is unbound". That would probably work well for quite a few drivers that don't want to ever call clk_get() or clk_prepare_enable() and could tie into the assigned-clock-rates property in a way that let us keep the platform details out of the drivers. We could also go one step further and make a clk pm domain when this new property is present and then have the clk be enabled based on runtime PM of the device (and if runtime PM is disabled then just enable it at driver probe time). 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, URIBL_BLOCKED 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 CE552C4338F for ; Sat, 31 Jul 2021 07:43:16 +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 7893260F35 for ; Sat, 31 Jul 2021 07:43:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7893260F35 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=k908CeQtx5oCfDqt82GqYDJO8Hkk8wvLKQB4CE5E9Cc=; b=PbkM5wyNT4m9DW 7zeFd2rmbEJ+cKgjIl9HLwR/5opCIrjOuQ0/wSMKm8CP0rBDikJM/qcx/d8wHt2/lXsaAJcY1dV8a XKShQxXQmukJVWspdZbbCQZ82cSUhCscNkBTlfT+cprRtGj8D3am7G780wzkxX/R6z7SLiCNZj4Gn ZWKxLDT2D3SsogATqiR5OL692hmIOfcgVMnzrHMSLxcv3DCMKlFXrkEA1wOkvXlo2Fglt39q0sO+k EZiBkztsrYCq/6SU71Gfe4pyMFU6k8F7eAyisq1V/yDsyTUUu3g1qTMG1oBZvQk1cW9DearBww/tf InU8dmV5MZQDR0J5iS4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9jcb-00BC20-70; Sat, 31 Jul 2021 07:41:25 +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 1m9jcX-00BC1L-Jz for linux-arm-kernel@lists.infradead.org; Sat, 31 Jul 2021 07:41:22 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3148A60EE6; Sat, 31 Jul 2021 07:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627717281; bh=Hv1Kjt0wM3IMrL51Qq27kQRTwgyaY1whymskpzTrLBg=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Mfe/v8Uz7KZzXezwTwjXNOUR+12p4qzmq6509mWK4HR6HXGPAgYYHOsPNIDypMN4W dptRTFmjMlRcoslggxxB3pGQBj0x6UrIzpyRhgK0eHShF1H4ayZFJwSjbVOjohBESi S7z2KmeryQRXtF7eCeDb2EWvnztkdGkPMUlZcvNgWKzC+b7h/pDhgVb1avCQX29DcW jD3PhoYFAFhcJd+plY+0d1jbLOvWrCoQRpOp8y4dhHXeVVhAQXt6M5qmuAJacc37Fb htU5NUsNIGPVW4EzuZd3O1Ri4wdN/qcx17MjnStx1zor6X+sjRKLhzQ7jQZ84kkJOU +DAteW7woUfZA== MIME-Version: 1.0 In-Reply-To: <20210728204033.GF22278@shell.armlinux.org.uk> References: <20210625171434.3xusxpxjprcdqa47@pengutronix.de> <20210722060654.nudpdtemosi64nlb@pengutronix.de> <20210722081817.2tsjzof4gvldq6ka@pengutronix.de> <20210723091331.wl33wtcvvnejuhau@pengutronix.de> <06e799be-b7c0-5b93-8586-678a449d2239@microchip.com> <20210728202547.7uvfwflpruku7yps@pengutronix.de> <20210728204033.GF22278@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: Michael Turquette , Claudiu.Beznea@microchip.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, 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-spi@vger.kernel.org, wsa@kernel.org, kernel@pengutronix.de, akpm@linux-foundation.org, torvalds@linux-foundation.org To: Russell King (Oracle) , Date: Sat, 31 Jul 2021 00:41:19 -0700 Message-ID: <162771727997.714452.2303764341103276867@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-20210731_004121_715014_C90E207F X-CRM114-Status: GOOD ( 14.86 ) 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-07-28 13:40:34) > > I adapted the Subject in the hope to catch Stephen's and Michael's > > attention. My impression is that this thread isn't on their radar yet, > > but the topic here seems important enough to get a matching Subject. The thread is on my radar but... > > Have you thought about sending your pull request to the clk API > maintainer (iow, me) ? > +1 This patch doesn't fall under CCF maintainer. $ ./scripts/get_maintainer.pl -f include/linux/clk.h Russell King (maintainer:CLK API) linux-clk@vger.kernel.org (open list:CLK API) linux-kernel@vger.kernel.org (open list) Finally, this sort of patch has been discussed for years and I didn't see any mention of those previous attempts in the patch series. Has something changed since that time? I think we've got a bunch of hand rolled devm things in the meantime but not much else. I still wonder if it would be better if we had some sort of DT binding that said "turn this clk on when the driver probes this device and keep it on until the driver is unbound". That would probably work well for quite a few drivers that don't want to ever call clk_get() or clk_prepare_enable() and could tie into the assigned-clock-rates property in a way that let us keep the platform details out of the drivers. We could also go one step further and make a clk pm domain when this new property is present and then have the clk be enabled based on runtime PM of the device (and if runtime PM is disabled then just enable it at driver probe time). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel