linux-kernel - Re: [PATCH v3 0/5] clk: dt: bindings for mux, divider & gate clocks

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Aug 2013 21:14:48 -0700
From:	Mike Turquette <mturquette@...aro.org>
To:	Stephen Boyd <sboyd@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>
Cc:	linux-kernel@...r.kernel.org,
	Heiko Stübner <heiko@...ech.de>,
	devicetree-discuss@...ts.ozlabs.org, Tero Kristo <t-kristo@...com>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Matt Sealey <neko@...uhatsu.net>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 0/5] clk: dt: bindings for mux, divider & gate clocks

Quoting Stephen Boyd (2013-07-18 14:04:44)
> On 06/20/13 23:14, Mike Turquette wrote:
> > This series introduces binding definitions for common register-mapped
> > clock multiplexer, divider and gate IP blocks along with the
> > corresponding setup functions for matching DT data.  The bindings are
> > similar to the struct definitions but please don't hold that against the
> > binding: the struct definitions closely model the hardware register
> > layout.
> 
> I know there was some discussion about clock bindings and how they
> should and should not be done at Linaro Connect Europe last week. Can
> someone in that discussion reply to the mailing list with what came out
> of that? I only have second hand knowledge about the discussion so it
> would be good for me and others to know what was discussed. I'm
> especially curious because the arm soc update etherpad[1] says "DT
> describes what HW is (location, type, attributes), not how HW works
> (register descriptions, bitmasks, etc)." but these proposed generic
> clock bindings are describing registers and bitmasks.

Hi Stephen,

I just happened across a to-do list note telling me to respond to this
email. Better late than never.

The meeting you're referring to did not focus on clock provider bindings
as much as it focused on a pair of standard clock attributes that could
be referenced by clock consumers. They are "assigned-clock-parent" and
"assigned-clock-rate". The usage scribbled on the white board[1] was
something like:

mux: mux {
	clocks = <&clock-foo>, <&clock-bar>;
};

uart: uart {
	clocks = <&mux>;
	assigned-clock-parent = <1>;
};

In the example above assigned-clock-parent uses the index of the mux,
but I prefer the following:

uart: uart {
	clocks = <&mux>;
	assigned-clock-parent = <&clock-bar>;
};

This is a way to establish initial configuration from the consumer's
perspective. Similarly something can be done for the clock rate with
assigned-clock-rate.

With all of that said this is consumer-level stuff. We'll definitely
talk about the clock provider DT bindings at the ARM Summit, which is
what you discuss above.

Regards,
Mike

[1] https://plus.google.com/u/0/107457854652287465481/posts/cvRveAupUpa

> 
> [1] http://pad.linaro.org/p/LCE13_ARM_SOC_Tree_Consolidation_Update
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/