From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
Date: Mon, 13 Oct 2014 12:39:52 +0200 [thread overview]
Message-ID: <20141013103952.GW19438@lukather> (raw)
In-Reply-To: <CAGb2v65KDOmwHAgFT6Gx8mtKTGEEYfbx6UVhz74V15J1O4odjg@mail.gmail.com>
On Thu, Oct 09, 2014 at 11:16:50AM +0800, Chen-Yu Tsai wrote:
> On Sat, Sep 27, 2014 at 2:53 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Chen-Yu Tsai (2014-09-25 17:55:27)
> >> On Fri, Sep 26, 2014 at 8:25 AM, Mike Turquette <mturquette@linaro.org> wrote:
> >> > Quoting Maxime Ripard (2014-09-11 13:36:23)
> >> >> Hi Chen-Yu,
> >> >>
> >> >> On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote:
> >> >> > Hi everyone,
> >> >> >
> >> >> > This series unifies the mux and divider parts of the AHB1 clock found
> >> >> > on sun6i and sun8i, while also adding support for the pre-divider on
> >> >> > the PLL6 input.
> >> >> >
> >> >> > The rate calculation logic must factor in which parent it is using to
> >> >> > calculate the rate, to decide whether to use the pre-divider or not.
> >> >> > This is beyond the original factors clk design in sunxi. To avoid
> >> >> > feature bloat, this is implemented as a seperate composite clk.
> >> >> >
> >> >> > The new clock driver is registered with a separate OF_CLK_DECLARE.
> >> >> > This is done so that assigned-clocks* properties on the clk provider
> >> >> > node can actually work. The clock framework arranges the clock setup
> >> >> > order by checking whether all clock parents are available, by checking
> >> >> > the node matching OF_CLK_DECLARE.
> >> >> >
> >> >> > However, the sunxi clk driver is based on the root node compatible,
> >> >> > has no defined dependencies (parents), and is setup before the fixed-rate
> >> >> > clocks. Thus when the ahb1 clock is added, all parents have rate = 0.
> >> >> > There is no way to calculate the required clock factors to set a default
> >> >> > clock rate under these circumstances. This happens when we set the
> >> >> > defaults in the clock node (provider), rather than a clock consumer.
> >> >> >
> >> >> > I can think of 2 ways to solve the dependency issue, but neither is
> >> >> > pretty. One would be to move the root fixed-rate clocks into the sunxi
> >> >> > clk driver. The other would be separating all the clocks into individual
> >> >> > OF_CLK_DECLARE statements, which adds a lot of boilerplate code.
> >> >>
> >> >> I don't know what Mike thinks of this, but I'd prefer the second.
> >> >
> >> > I do not fully understand the problem. Ideally the clock driver should
> >> > have some way to fail with EPROBE_DEFER until the fixed-rate clocks are
> >> > registered. Those fixed-rate parents are enumerated in your dts, right?
> >> > Why isn't this enough?
> >>
> >> This is due to the way the sunxi clock driver is setup. The clock driver's
> >> OF_CLK_DECLARE matches against the "soc" node, not the individual clock
> >> nodes. When the setup function is called, it just registers all the
> >> supported clocks. There are no dependencies listed.
> >>
> >> Unfortunately, the fixed-factor clock is in the middle of the whole clock
> >> tree. The sunxi clock driver provides its parents _and_ its children.
> >> Naturally the clock framework then probes the fixed-factor clock after
> >> the sunxi ones. Any attempts to change the state of clocks under the
> >> unavailable fixed-factor clock, such as done by of_clk_set_defaults(),
> >> would get an incomplete clock, likely with no parents and parent_rate = 0.
> >> That is until of_clk_init() finishes and all clocks are properly hooked
> >> up.
> >>
> >> Anyway, this problem only occurred when I added clk-assigned-* defaults
> >> to the clock provider node, which is not the case anymore.
> >
> > Makes sense. I guess you could ignore the problem until you need to use
> > the assigned defaults.
>
> An update on this. Improper ordering of clock probing also affects
> sunxi's clock protection code.
>
> Currently we have 2 mechanisms for protecting clocks.
>
> a) A list of clock names in sunxi/clk-sunxi.c, fetched and enabled
> using clkdev.
> b) Enabling clocks right after they are registered. Used for separated
> clock drivers like sun5i-a13-mbus and sun8i-a23-mbus.
>
> One issue I ran across was when most of the clock tree is registered using
> independent CLK_OF_DECLAREs, as I'm doing for the A80, if the protected
> clocks list is handled before the clock tree is complete, the prepare
> and enable calls are not correctly propagated to the parents that arrive
> later on.
>
> This happens to the ahb*_sdram gates.
I guess that eventually, we should be able to remove a). For the time
being, maybe we can just move the clock protection code itself to a
later initcall?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141013/1d84f837/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Cc: Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Emilio Lopez <emilio-0Z03zUJReD5OxF6Tv1QG9Q@public.gmane.org>,
Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Dan Williams
<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linux-sunxi <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
Date: Mon, 13 Oct 2014 12:39:52 +0200 [thread overview]
Message-ID: <20141013103952.GW19438@lukather> (raw)
In-Reply-To: <CAGb2v65KDOmwHAgFT6Gx8mtKTGEEYfbx6UVhz74V15J1O4odjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4761 bytes --]
On Thu, Oct 09, 2014 at 11:16:50AM +0800, Chen-Yu Tsai wrote:
> On Sat, Sep 27, 2014 at 2:53 AM, Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > Quoting Chen-Yu Tsai (2014-09-25 17:55:27)
> >> On Fri, Sep 26, 2014 at 8:25 AM, Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> > Quoting Maxime Ripard (2014-09-11 13:36:23)
> >> >> Hi Chen-Yu,
> >> >>
> >> >> On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote:
> >> >> > Hi everyone,
> >> >> >
> >> >> > This series unifies the mux and divider parts of the AHB1 clock found
> >> >> > on sun6i and sun8i, while also adding support for the pre-divider on
> >> >> > the PLL6 input.
> >> >> >
> >> >> > The rate calculation logic must factor in which parent it is using to
> >> >> > calculate the rate, to decide whether to use the pre-divider or not.
> >> >> > This is beyond the original factors clk design in sunxi. To avoid
> >> >> > feature bloat, this is implemented as a seperate composite clk.
> >> >> >
> >> >> > The new clock driver is registered with a separate OF_CLK_DECLARE.
> >> >> > This is done so that assigned-clocks* properties on the clk provider
> >> >> > node can actually work. The clock framework arranges the clock setup
> >> >> > order by checking whether all clock parents are available, by checking
> >> >> > the node matching OF_CLK_DECLARE.
> >> >> >
> >> >> > However, the sunxi clk driver is based on the root node compatible,
> >> >> > has no defined dependencies (parents), and is setup before the fixed-rate
> >> >> > clocks. Thus when the ahb1 clock is added, all parents have rate = 0.
> >> >> > There is no way to calculate the required clock factors to set a default
> >> >> > clock rate under these circumstances. This happens when we set the
> >> >> > defaults in the clock node (provider), rather than a clock consumer.
> >> >> >
> >> >> > I can think of 2 ways to solve the dependency issue, but neither is
> >> >> > pretty. One would be to move the root fixed-rate clocks into the sunxi
> >> >> > clk driver. The other would be separating all the clocks into individual
> >> >> > OF_CLK_DECLARE statements, which adds a lot of boilerplate code.
> >> >>
> >> >> I don't know what Mike thinks of this, but I'd prefer the second.
> >> >
> >> > I do not fully understand the problem. Ideally the clock driver should
> >> > have some way to fail with EPROBE_DEFER until the fixed-rate clocks are
> >> > registered. Those fixed-rate parents are enumerated in your dts, right?
> >> > Why isn't this enough?
> >>
> >> This is due to the way the sunxi clock driver is setup. The clock driver's
> >> OF_CLK_DECLARE matches against the "soc" node, not the individual clock
> >> nodes. When the setup function is called, it just registers all the
> >> supported clocks. There are no dependencies listed.
> >>
> >> Unfortunately, the fixed-factor clock is in the middle of the whole clock
> >> tree. The sunxi clock driver provides its parents _and_ its children.
> >> Naturally the clock framework then probes the fixed-factor clock after
> >> the sunxi ones. Any attempts to change the state of clocks under the
> >> unavailable fixed-factor clock, such as done by of_clk_set_defaults(),
> >> would get an incomplete clock, likely with no parents and parent_rate = 0.
> >> That is until of_clk_init() finishes and all clocks are properly hooked
> >> up.
> >>
> >> Anyway, this problem only occurred when I added clk-assigned-* defaults
> >> to the clock provider node, which is not the case anymore.
> >
> > Makes sense. I guess you could ignore the problem until you need to use
> > the assigned defaults.
>
> An update on this. Improper ordering of clock probing also affects
> sunxi's clock protection code.
>
> Currently we have 2 mechanisms for protecting clocks.
>
> a) A list of clock names in sunxi/clk-sunxi.c, fetched and enabled
> using clkdev.
> b) Enabling clocks right after they are registered. Used for separated
> clock drivers like sun5i-a13-mbus and sun8i-a23-mbus.
>
> One issue I ran across was when most of the clock tree is registered using
> independent CLK_OF_DECLAREs, as I'm doing for the A80, if the protected
> clocks list is handled before the clock tree is complete, the prepare
> and enable calls are not correctly propagated to the parents that arrive
> later on.
>
> This happens to the ahb*_sdram gates.
I guess that eventually, we should be able to remove a). For the time
being, maybe we can just move the clock protection code itself to a
later initcall?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-10-13 10:39 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-06 10:47 [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-06 10:47 ` [PATCH 1/7] clk: sunxi: Add post clk divider for factor clocks Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-11 20:36 ` Maxime Ripard
2014-09-11 20:36 ` Maxime Ripard
2014-09-13 14:43 ` Emilio López
2014-09-13 14:43 ` Emilio López
2014-09-16 8:11 ` [linux-sunxi] " Chen-Yu Tsai
2014-09-16 8:11 ` Chen-Yu Tsai
2014-09-16 15:57 ` Maxime Ripard
2014-09-16 15:57 ` Maxime Ripard
2014-09-24 15:35 ` Chen-Yu Tsai
2014-09-24 15:35 ` Chen-Yu Tsai
2014-09-27 7:07 ` Maxime Ripard
2014-09-27 7:07 ` Maxime Ripard
2014-09-27 7:23 ` Chen-Yu Tsai
2014-09-27 7:23 ` Chen-Yu Tsai
2014-09-06 10:47 ` [PATCH 2/7] clk: sunxi: Fix PLL6 calculation on sun6i Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-11 20:38 ` Maxime Ripard
2014-09-11 20:38 ` Maxime Ripard
2014-09-06 10:47 ` [PATCH 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-11 21:02 ` Maxime Ripard
2014-09-11 21:02 ` Maxime Ripard
2014-09-12 3:16 ` Chen-Yu Tsai
2014-09-12 3:16 ` Chen-Yu Tsai
2014-09-13 10:26 ` Maxime Ripard
2014-09-13 10:26 ` Maxime Ripard
2014-09-25 23:03 ` Mike Turquette
2014-09-25 23:03 ` Mike Turquette
2014-09-26 8:28 ` Maxime Ripard
2014-09-26 8:28 ` Maxime Ripard
2014-09-06 10:47 ` [PATCH 4/7] ARM: dts: sun8i: Unify ahb1 clock nodes Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-06 10:47 ` [PATCH 5/7] ARM: dts: sun6i: " Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-06 10:47 ` [PATCH 6/7] ARM: dts: sun6i: Add required ahb1 clock parent and rates for dma controller Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-11 21:15 ` Maxime Ripard
2014-09-11 21:15 ` Maxime Ripard
2014-09-12 2:10 ` Chen-Yu Tsai
2014-09-12 2:10 ` Chen-Yu Tsai
2014-09-16 15:48 ` Maxime Ripard
2014-09-16 15:48 ` Maxime Ripard
2014-09-16 16:01 ` Chen-Yu Tsai
2014-09-16 16:01 ` Chen-Yu Tsai
2014-09-20 9:59 ` Maxime Ripard
2014-09-20 9:59 ` Maxime Ripard
2014-09-21 8:31 ` Chen-Yu Tsai
2014-09-21 8:31 ` Chen-Yu Tsai
2014-09-25 13:41 ` Maxime Ripard
2014-09-25 13:41 ` Maxime Ripard
2014-09-06 10:47 ` [PATCH 7/7] dmaengine: sun6i: Remove obsolete clk muxing code Chen-Yu Tsai
2014-09-06 10:47 ` Chen-Yu Tsai
2014-09-11 21:16 ` Maxime Ripard
2014-09-11 21:16 ` Maxime Ripard
2014-09-24 5:10 ` Vinod Koul
2014-09-24 5:10 ` Vinod Koul
2014-09-11 20:36 ` [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation Maxime Ripard
2014-09-11 20:36 ` Maxime Ripard
2014-09-26 0:25 ` Mike Turquette
2014-09-26 0:25 ` Mike Turquette
2014-09-26 0:55 ` Chen-Yu Tsai
2014-09-26 0:55 ` Chen-Yu Tsai
2014-09-26 18:53 ` Mike Turquette
2014-09-26 18:53 ` Mike Turquette
2014-10-09 3:16 ` Chen-Yu Tsai
2014-10-09 3:16 ` Chen-Yu Tsai
2014-10-13 10:39 ` Maxime Ripard [this message]
2014-10-13 10:39 ` Maxime Ripard
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=20141013103952.GW19438@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.