LKML Archive on
help / color / mirror / Atom feed
From: Stephen Boyd <>
To: Jerome Brunet <>,
	Michael Turquette <>,
	Russell King <>
Cc: Jerome Brunet <>,,
Subject: Re: [PATCH 0/3] clk: add duty cycle support
Date: Mon, 16 Apr 2018 22:49:09 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Quoting Jerome Brunet (2018-04-16 10:57:40)
> This patchset adds the possibility to control the duty cycle ratio of a
> clock within the clock framework.
> This useful when the duty cycle ratio depends on another parameter
> controlled by the clock framework. For example, the duty cycle ratio may
> depends on the value of a divider (ratio = N / div).
> This is also useful if the related clock is part of large tree. In this
> case, using CCF to control the clock tree and the PWM framework for the
> duty cycle would be a nightmare for the provider and the consumer.

Can you please Cc the PWM maintainer on this patch series?

> A clock provider is not required to implement the operation to set and get
> the duty cycle. If it does not implement .get_duty_cycle(), the ratio is
> assumed to be 50%.
> This series also provides pass-through operations ready to be used for
> clock which don't resample the clock signal (such as gates and muxes).
> This is provided to make things easier for consumers. Clocks are usually
> made of several elements, like a composite clocks with a mux, a divider,
> and a gate. With the pass-through ops set on the gate, the consumer does
> not need to be aware that the duty cycle is actually controlled by the
> divider, it can continue to use the clock through the gate, as usual.  The
> simple propagation will stop at the first clock which resample the signal
> (such as a divider).
> Patch 2 and 3 add the pass-through ops to the generic gate and mux ops.  In
> this first version, it is unconditional, but maybe we should provide a flag
> to let people decide what is best for them ?
> The series has been developed to handled the sample clocks provided by
> audio clock controller of amlogic's A113 SoC. To support i2s modes, this
> clock need to have a 50% duty cycle ratio, while it should be just one
> pulse of the parent clock in dsp modes.

Cool. I've heard rumblings from some other SoC manufacturers that they
want duty cycle control via the clk framework but nothing came of it, so
thanks for picking this up.

> PS: Checkpatch complains heavily about the white space in the trace header
> file. I believe I have respected the style already used in this
> file. Please let me know if it should be done differently.

The trace file looks fine. Ignore checkpatch.

  parent reply	other threads:[~2018-04-17  5:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 17:57 [PATCH 0/3] clk: add duty cycle support Jerome Brunet
2018-04-16 17:57 ` [PATCH 1/3] " Jerome Brunet
2018-04-17  5:43   ` Stephen Boyd
2018-04-17  6:28     ` Jerome Brunet
2018-04-16 17:57 ` [PATCH 2/3] clk: gate: add duty cycle passthrough ops Jerome Brunet
2018-04-16 17:57 ` [PATCH 3/3] clk: mux: " Jerome Brunet
2018-04-17  5:49 ` Stephen Boyd [this message]
2018-04-17  6:30   ` [PATCH 0/3] clk: add duty cycle support Jerome Brunet

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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).