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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1523946602.2601.78.camel@baylibre.com>
Date:   Tue, 17 Apr 2018 08:30:02 +0200
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Russell King <linux@...linux.org.uk>
Cc:     linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] clk: add duty cycle support

On Mon, 2018-04-16 at 22:49 -0700, Stephen Boyd wrote:
> 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?
Sure. I'll see him of the v2.

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