Re: [PATCH 0/3] clk: add duty cycle support

[Stephen Boyd]

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.