Linux-Clk Archive on lore.kernel.org
 help / color / Atom feed
From: Jonny Hall <jonny.hall@boxcast.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: linux-clk@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>
Subject: Re: Informing common clock framework driver of externally-derived base clock frequency
Date: Fri, 4 Jan 2019 16:29:07 -0500
Message-ID: <CAP_wsPa5qsuUhDNXWe55612xY-ppytj+jX4+5s-bFxn5BURoTg@mail.gmail.com> (raw)
In-Reply-To: <32a08ee4-3989-3785-88d6-7d215147eba3@samsung.com>

On Fri, Jan 4, 2019 at 4:30 AM Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
>
> Hi,
>
> Cc: CCF maintainers
>
> On 1/4/19 03:35, Jonny Hall wrote:
> [...]
>
> > ... However, in my application, the input frequency of
> > the si5342 is not known in advance, is derived from an external
> > source, and can change during runtime. The si5342 will need to be
> > (re)configured during operation with the frequency of this root clock
> > source in order to properly lock onto it and generate the correct
> > output frequencies -- it cannot independently determine the input
> > frequency, only "locked" / "unlocked" state.  The application software
> > (other drivers and usermode application code) will know the input
> > clock rate.  I've though of a couple ways to do this:
> >
> > -Implement the root clock source as an "imaginary" divider where the
> > set_rate call actually configures the input dividers of the si5342.
> > This approach seems to abuse the common clock framework, as I'm not
> > actually *setting* the rate, I'm *informing* the driver of a rate that
> > was determined independently.
>
> It sounds like registering a clk notifier on the si5342 root source clock
> might be a way to go, wouldn't that work for you?
> For an example you could have a look at drivers/clk/sunxi-ng/ccu_mux.c.
>
> --
> Regards,
> Sylwester

Maybe my understanding is incorrect, but to me it looks like a
notifier (callback registered with clk_notifier_register) is actually
the opposite case -- this method would be used by a clock consumer
that wants to be notified by the common clock framework that a clock
rate has changed (I, as an endpoint, want to know when my clock
source, which is controlled by CCF drivers, changes rate).  The use
case I'm looking for is when a clock chip needs to be notified by
*something else* that something in the system has changed (I, as a
clock chip, need to be informed by other parts of the system what my
input clock rate is).

To add a bit of clarity to the scenario -- in my use case, the si5342
is generating video pixel clocks for video outputs from the system.
The inputs of the si5342 are other video pixel clocks, from video
inputs to the system.  The parts of the system that are aware of the
input clock rates are things like HDMI subsystem drivers and usermode
application code.  I need a way to connect these
"parts-that-are-aware-of-the-clock-rate" to my si5342 driver so it can
properly configure that portion of the si5342 -- preferably within the
common clock framework, because on the output side of the si5342, our
video output drivers already work with the CCF.

It looks like some similar chips use recalc_rate as their function to
configure input dividers -- but there appears to be no way to call
recalc_rate through the clk.h API -- it looks like recalc_rate is only
used for keeping track of things internal to the CCF.

Thanks,
  -Jonny

  reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190104023702epcas4p4e6b225121db059cb6ed167581c303e92@epcas4p4.samsung.com>
2019-01-04  2:35 ` Jonny Hall
2019-01-04  9:30   ` Sylwester Nawrocki
2019-01-04 21:29     ` Jonny Hall [this message]
2019-01-09 14:22       ` Sylwester Nawrocki
2019-01-29 22:26         ` Stephen Boyd

Reply instructions:

You may reply publically 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=CAP_wsPa5qsuUhDNXWe55612xY-ppytj+jX4+5s-bFxn5BURoTg@mail.gmail.com \
    --to=jonny.hall@boxcast.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=s.nawrocki@samsung.com \
    --cc=sboyd@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

Linux-Clk Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-clk/0 linux-clk/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-clk linux-clk/ https://lore.kernel.org/linux-clk \
		linux-clk@vger.kernel.org linux-clk@archiver.kernel.org
	public-inbox-index linux-clk


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-clk


AGPL code for this site: git clone https://public-inbox.org/ public-inbox