From: Stephen Boyd <sboyd@kernel.org>
To: Michael Turquette <mturquette@baylibre.com>,
Santosh Shilimkar <ssantosh@kernel.org>,
Tero Kristo <t-kristo@ti.com>,
linux-clk <linux-clk@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] clk: keystone: changes for 5.3 v2
Date: Tue, 25 Jun 2019 11:55:28 -0700 [thread overview]
Message-ID: <20190625185529.ACAF52085A@mail.kernel.org> (raw)
In-Reply-To: <2ba035cc-2381-ce36-3b7d-f5027ef9ef40@ti.com>
Quoting Tero Kristo (2019-06-25 03:33:50)
> On 25/06/2019 04:17, Stephen Boyd wrote:
> > Quoting Tero Kristo (2019-06-12 04:56:15)
> >> Hi Stephen, Mike, Santosh,
> >>
> >> Here's a 2nd take of the pull request for the clock changes for keystone
> >> SoC for 5.3. The only change compared to the v1 is to add the required
> >> drivers/firmware change in. This avoids the nasty dependency between the
> >> pull requests between the clock driver and firmware driver.
> >>
> >> -Tero
> >
> > Thanks. Pulled into clk-next. I guess we should increase the size of the
> > number of parents that can exist to be more than a u8? We're close to
> > getting there with the new way of specifying clk parents, so maybe we
> > should expand it to an unsigned int, but then we may need to optimize
> > finding parents when searching through all the parents of a clk.
>
> For now, this is not an issue with TI SoC:s at least, I think we only
> have like 64 parents at max for muxes.
Ok. It doesn't sound like a priority then.
>
> > Also, there isn't any quantification of how much better it is to scan DT
> > for all the clks that are used and only register those ones. It would be
> > nice to understand how much better it is to do that sort of scan vs.
> > just populating all clks at boot time.
>
> I haven't done measurements lately, but it provides pretty drastic
> improvement. On am65x for example, it cuts the scan time from bit more
> than 1 second to couple of hundred milliseconds. I don't have
> measurements for the new j721e SoC, but I would believe the improvement
> is even more with that one.
Cool. Thanks for the numbers.
>
> > It may be useful to make the code
> > generic because NXP folks also want to populate clks from DT so maybe we
> > should provide this from the core framework somehow to ask providers to
> > register a particular clk or not. I haven't thought about it at all, but
> > it may come up that we totally rewrite this code in the future to be
> > shared outside of the TI clk driver.
>
> It might also be worth thinking whether some sort of lazy clock probe
> would be possible... now we register everything at one go, but would it
> be possible to only register / reparent clocks once they are actually
> requested by some driver?
Sure. Ideally the optimization isn't vendor driver specific.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-06-25 18:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 11:56 [GIT PULL] clk: keystone: changes for 5.3 v2 Tero Kristo
2019-06-25 1:17 ` Stephen Boyd
2019-06-25 10:33 ` Tero Kristo
2019-06-25 18:55 ` Stephen Boyd [this message]
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=20190625185529.ACAF52085A@mail.kernel.org \
--to=sboyd@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).