From: Mike Turquette <mturquette@linaro.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH v2 09/10] clk: shmobile: div6: support selectable-input clocks
Date: Wed, 03 Sep 2014 14:56:59 +0000 [thread overview]
Message-ID: <20140903145659.11368.60628@quantum> (raw)
In-Reply-To: <1409649186-1046-10-git-send-email-ulrich.hecht+renesas@gmail.com>
Quoting Geert Uytterhoeven (2014-09-03 02:03:06)
> Hi Ulrich, Mike,
>
> On Wed, Sep 3, 2014 at 9:48 AM, Ulrich Hecht
> <ulrich.hecht+renesas@gmail.com> wrote:
> > On Wed, Sep 3, 2014 at 12:45 AM, Mike Turquette <mturquette@linaro.org> wrote:
> >> Quoting Ulrich Hecht (2014-09-02 02:13:05)
> >>> From: Ulrich Hecht <ulrich.hecht@gmail.com>
> >>>
> >>> Support for setting the parent at initialization time based on the current
> >>> hardware configuration in DIV6 clocks with selectable parents as found in
> >>> the r8a73a4, r8a7740, sh73a0, and other SoCs.
> >>>
> >>> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> >>> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>
> >> I still have the same question about switching parents at run-time as I
> >> did in the last posting[0]. Is there a use case for modeling this clocks
> >> as proper muxes and switching parents dynamically?
> >
> > I have no idea, frankly. Laurent, can you comment on that?
>
> Technically, it seems to be possible to switch parents at run-time.
Cool. You just need to know if switching parents is glitchless or not.
If switching is glitchless then you have nothing to worry about. If not
then you might need to set the CLK_SET_PARENT_GATE flag.
>
> Of course, if we do that, we need a way to set up the parents.
> It's my understanding this is done explicitly (through clk_set_parent()),
> or implicitly (through clk_set_rate() and propagation). Is that correct?
Correct.
> The default would still be read from the hardware, like is done now, right?
This is done in __clk_init_parent(). This reads the hardware for mux
clocks (which MUST implement the .get_parent callback) and updates the
clock framework bookkeeping to use the correct parent at clock
registration-time.
Regards,
Mike
>
> It seems we only configure rates explicitly for audio and video.
> For most drivers, we just use the rates as dictated by following the flow
> from the main crystal(s) through the clock topology and the divisors
> present within.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
next prev parent reply other threads:[~2014-09-03 14:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 9:13 [PATCH v2 09/10] clk: shmobile: div6: support selectable-input clocks Ulrich Hecht
2014-09-02 22:45 ` Mike Turquette
2014-09-03 7:48 ` Ulrich Hecht
2014-09-03 9:03 ` Geert Uytterhoeven
2014-09-03 14:56 ` Mike Turquette [this message]
2014-09-09 22:08 ` Laurent Pinchart
2014-09-09 22:12 ` Laurent Pinchart
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=20140903145659.11368.60628@quantum \
--to=mturquette@linaro.org \
--cc=linux-sh@vger.kernel.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 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).