LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Stephen Boyd <sboyd@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	<alexandre.belloni@bootlin.com>,
	Michael Turquette <mturquette@baylibre.com>,
	<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 <arnd@arndb.de>,
	<broonie@kernel.org>, <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>
Subject: Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks]
Date: Mon, 2 Aug 2021 10:36:38 +0100	[thread overview]
Message-ID: <20210802103638.00000448@Huawei.com> (raw)
In-Reply-To: <20210731120004.i3affxw7upl5y4c5@pengutronix.de>

On Sat, 31 Jul 2021 14:00:04 +0200
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:

> Hi Russell, hi Stephen,
> 
> On Sat, Jul 31, 2021 at 12:41:19AM -0700, Stephen Boyd wrote:
> > 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) ?  
> 
> I wasn't really aware that Russell has the clk API hat (or that this
> separate hat actually exists and this isn't purely a CCF topic). I
> assume I only did
> 
> 	$ scripts/get_maintainer.pl -f drivers/clk/clk-devres.c
> 
> which is where the current and new code implementing devm_clk_get et al
> lives.
> 
> @Russell: What is your position here, do you like the approach of
> devm_clk_get_enabled? I can send a new pull request in your direction if
> you like it and are willing to take it.
> 
> > +1 This patch doesn't fall under CCF maintainer.  
> 
> Given that CCF is the only implementer of devm_clk_get at least an Ack
> from your side would still be good I guess?
> 
> > 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 found a patch set adding devm variants of clk_enable (e.g.
> https://lore.kernel.org/patchwork/patch/755667/) but this approach is
> different as it also contains clk_get which IMHO makes more sense 
> The discussion considered wrapping get+enable at one point, but I didn't
> find a followup.
> 
> > 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".  
> 
> This doesn't sound like a hardware property and so I don't think this
> belongs into DT and I would be surprised if the dt maintainers would be
> willing to accept an idea with this semantic.

Agreed. It's not unheard of to have a driver start out just enabing
clock at probe and dropping it at remove. When the driver gets more
sophisticated it will then manage the clock more frequently.
Whilst that's often tied to runtime_pm I'm not sure it always is.

Given the mess that would be involved in having a property that we
need to later ignore for particular drivers, I'd keep this management
explicit in the driver. This series makes that trivial to do for these
easy cases.

Jonathan

> 
> > 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).  
> 
> clk pm domain sounds good, but introducing devm_clk_get_enabled() is
> much easier and converting to it can be done without dt changes and more
> or less mechanically. So I consider the cost-usage-value of
> devm_clk_get_enabled() much better.
> 
> Best regards
> Uwe
> 


  reply	other threads:[~2021-08-02  9:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210510174142.986250-1-u.kleine-koenig@pengutronix.de>
     [not found] ` <20210609202123.u5rmw7al4x3rrvun@pengutronix.de>
     [not found]   ` <20210625171434.3xusxpxjprcdqa47@pengutronix.de>
     [not found]     ` <20210705080144.zfbzkm7l3gmnh6st@pengutronix.de>
     [not found]       ` <20210722060654.nudpdtemosi64nlb@pengutronix.de>
     [not found]         ` <YPkg0wtYIoHKpTUW@kunai>
     [not found]           ` <20210722081817.2tsjzof4gvldq6ka@pengutronix.de>
     [not found]             ` <YPlfcbkxiBmB+vw1@kunai>
     [not found]               ` <CAHp75VfC=s12Unw3+Cn0ag71mM5i90=Jbwj4nYwB5cPKiUTRSA@mail.gmail.com>
2021-07-23  9:13                 ` [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks Uwe Kleine-König
2021-07-26  9:18                   ` Claudiu.Beznea
2021-07-26  9:52                     ` Andy Shevchenko
2021-07-26 12:32                       ` Wolfram Sang
2021-07-26 13:28                         ` Andy Shevchenko
2021-07-26 17:40                           ` Wolfram Sang
2021-07-28 20:25                     ` About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks] Uwe Kleine-König
2021-07-28 20:40                       ` Russell King (Oracle)
2021-07-31  7:41                         ` Stephen Boyd
2021-07-31  8:07                           ` Andy Shevchenko
2021-07-31 12:00                           ` Uwe Kleine-König
2021-08-02  9:36                             ` Jonathan Cameron [this message]
2021-08-02  9:48                             ` Russell King (Oracle)
2021-08-02 15:27                               ` Uwe Kleine-König
2021-08-02 16:38                                 ` Russell King (Oracle)
2021-08-02 17:13                                   ` Andy Shevchenko
2021-08-02 20:28                                     ` Russell King (Oracle)
2021-08-03  8:11                                   ` Stephen Boyd
2021-08-03 10:40                                     ` Uwe Kleine-König
2021-08-06  0:26                                       ` Stephen Boyd
2021-09-14 13:22                                         ` Uwe Kleine-König
2021-09-14 13:52                                           ` Mark Brown
2021-08-03  7:44                               ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210802103638.00000448@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Claudiu.Beznea@microchip.com \
    --cc=Ludovic.Desroches@microchip.com \
    --cc=a.zummo@towertech.it \
    --cc=aardelean@deviqon.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mturquette@baylibre.com \
    --cc=o.rempel@pengutronix.de \
    --cc=sboyd@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wsa@kernel.org \
    --subject='Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks]' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).