linux-kernel - Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20161103182834.GR25787@tuxbot>
Date:   Thu, 3 Nov 2016 11:28:34 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     Georgi Djakov <georgi.djakov@...aro.org>, mturquette@...libre.com,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver

On Wed 02 Nov 15:55 PDT 2016, Stephen Boyd wrote:

> On 11/02, Bjorn Andersson wrote:
> > On Thu 27 Oct 18:54 PDT 2016, Stephen Boyd wrote:
> > 
> > > On 10/19, Georgi Djakov wrote:
> > > > Add a driver for the A53 Clock Controller. It is a hardware block that
> > > > implements a combined mux and half integer divider functionality. It can
> > > > choose between a fixed-rate clock or the dedicated A53 PLL. The source
> > > > and the divider can be set both at the same time.
> > > > 
> > > > This is required for enabling CPU frequency scaling on platforms like
> > > > MSM8916.
> > > > 
> > > 
> > > Please Cc DT reviewers.
> > > 
> > > > Signed-off-by: Georgi Djakov <georgi.djakov@...aro.org>
> > > > ---
> > > >  .../devicetree/bindings/clock/qcom,a53cc.txt       |  22 +++
> > > >  drivers/clk/qcom/Kconfig                           |   8 ++
> > > >  drivers/clk/qcom/Makefile                          |   1 +
> > > >  drivers/clk/qcom/a53cc.c                           | 155 +++++++++++++++++++++
> > > >  4 files changed, 186 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > >  create mode 100644 drivers/clk/qcom/a53cc.c
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > > new file mode 100644
> > > > index 000000000000..a025f062f177
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
> > > > @@ -0,0 +1,22 @@
> > > > +Qualcomm A53 CPU Clock Controller Binding
> > > > +------------------------------------------------
> > > > +The A53 CPU Clock Controller is hardware, which provides a combined
> > > > +mux and divider functionality for the CPU clocks. It can choose between
> > > > +a fixed rate clock and the dedicated A53 PLL.
> > > > +
> > > > +Required properties :
> > > > +- compatible : shall contain:
> > > > +
> > > > +			"qcom,a53cc"
> > > > +
> > > > +- reg : shall contain base register location and length
> > > > +	of the APCS region
> > > > +- #clock-cells : shall contain 1
> > > > +
> > > > +Example:
> > > > +
> > > > +	apcs: syscon@...1000 {
> > > > +		compatible = "qcom,a53cc", "syscon";
> > > 
> > > Why is it a syscon? Is that part used?
> > > 
> > 
> > I use the register at offset 8 for interrupting the other subsystems, so
> > this must be available as something I can poke.
> > 
> > Which makes me think that this should be described as a "simple-mfd" and
> > "syscon" with the a53cc node as a child - grabbing the regmap of the
> > syscon parent, rather then ioremapping the same region again.
> > 
> 
> That's sort of a question for DT reviewers. The register space
> certainly seems like a free for all with a tilt toward power
> management of the CPU, similar to how this was done on Krait
> based designs.
> 

Right. But this kind of mashup blocks was the reason why simple-mfd was
put in place.

> I wonder why we didn't make up some provider/consumer binding for
> the "kicking" feature used by SMD/RPM code. Then this could be a
> clock provider and a "kick" provider (haha #kick-cells) and the
> usage of syscon/regmap wouldn't be mandatory.
> 

I did consider doing that, but had enough dependencies to put in place
as it was.

I'm in favour of us inventing a kicker API and it's found outside out
use cases as well (e.g. virtio/rpmsg).

Regards,
Bjorn