From: "Théo Lebrun" <theo.lebrun@bootlin.com>
To: "Stephen Boyd" <sboyd@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Rob Herring" <robh@kernel.org>
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Vladimir Kondratiev" <vladimir.kondratiev@mobileye.com>,
"Grégory Clement" <gregory.clement@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Tawfik Bayouk" <tawfik.bayouk@mobileye.com>
Subject: Re: [PATCH v5 4/4] clk: eyeq: add driver
Date: Tue, 29 Oct 2024 10:04:48 +0100 [thread overview]
Message-ID: <D5864C0GXLOD.2R2G7Y8CA3T6B@bootlin.com> (raw)
In-Reply-To: <39b99c310a307d97955ec6f9335c0439.sboyd@kernel.org>
On Mon Oct 28, 2024 at 11:52 PM CET, Stephen Boyd wrote:
> Quoting Théo Lebrun (2024-10-24 05:50:16)
> > The bug is elsewhere: we do get valid clocks from PL011. Both clk_get()
> > calls give proper pointers.
> >
> > The issue is that we are using `compatible = "fixed-factor-clock"`
> > clocks in the middle, and those don't wait for their parents to be
> > active.
> >
> > Simplified clock graph is: pll-per -> occ-periph.
> > pll-per is register by our driver. occ-periph looks like:
> >
> > occ_periph: occ-periph {
> > compatible = "fixed-factor-clock";
> > clocks = <&olb EQ5C_PLL_PER>;
> > #clock-cells = <0>;
> > clock-div = <16>;
> > clock-mult = <1>;
> > };
>
> Why is this fixed factor clk registered from DT vs. from the driver that
> registers pll-per? Is it useful to describe it in DT because the factor
> can change? Where does it physically exist? In the SoC?
Those are internal SoC clocks, yes. No reason for them to change from
one board to another. Adding them from the driver makes the most sense,
I'll patch that up.
> > Sequence is:
> > - eqc_early_init(): it registers a clock provider that will return
> > EPROBE_DEFER for our pll-per.
> > - _of_fixed_factor_clk_setup(): it registers occ-periph, even though
> > its parent is EPROBE_DEFER. clk_core_populate_parent_map() runs all
> > fine without complaining; logical as it doesn't query the clk_hw for
> > its parent, it only stores indexes.
> > - amba_get_enable_pclk(): it does a clk_get() which works because
> > occ-periph exists.
> >
> > Maybe __clk_register() should check the clk_hw for each parent: if any
> > is an EPROBE_DEFER then it should EPROBE_DEFER itself? That looks like
> > a rather big behavioral change.
> >
> > The other solution is to keep as-is: provide all clocks consumed by
> > fixed-factor-clocks at of_clk_init() stage.
>
> Another solution is to register the fixed factor clk from the pll-per
> clk provider.
>
> And yet another solution is to return EPROBE_DEFER for orphaned clks. We
> have everything in place for that but we ran into trouble with consumers
> wanting to get orphaned clks in their probe or during assigned-clocks
> handling.
No suprise this kind of edge-case behavior can cause trouble.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2024-10-29 9:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 13:49 [PATCH v5 0/4] Add Mobileye EyeQ clock support Théo Lebrun
2024-10-07 13:49 ` [PATCH v5 1/4] Revert "dt-bindings: clock: mobileye,eyeq5-clk: add bindings" Théo Lebrun
2024-10-17 18:52 ` Stephen Boyd
2024-10-07 13:49 ` [PATCH v5 2/4] dt-bindings: clock: add Mobileye EyeQ6L/EyeQ6H clock indexes Théo Lebrun
2024-10-17 18:52 ` Stephen Boyd
2024-10-07 13:49 ` [PATCH v5 3/4] clk: divider: Introduce CLK_DIVIDER_EVEN_INTEGERS flag Théo Lebrun
2024-10-17 18:52 ` Stephen Boyd
2024-10-07 13:49 ` [PATCH v5 4/4] clk: eyeq: add driver Théo Lebrun
2024-10-17 18:48 ` Stephen Boyd
2024-10-23 11:08 ` Théo Lebrun
2024-10-23 22:12 ` Stephen Boyd
2024-10-24 12:50 ` Théo Lebrun
2024-10-28 22:52 ` Stephen Boyd
2024-10-29 9:04 ` Théo Lebrun [this message]
2024-10-15 8:50 ` [PATCH v5 0/4] Add Mobileye EyeQ clock support Théo Lebrun
2024-10-17 18:42 ` 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=D5864C0GXLOD.2R2G7Y8CA3T6B@bootlin.com \
--to=theo.lebrun@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=tawfik.bayouk@mobileye.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.kondratiev@mobileye.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
Powered by JetHome