linux-kernel - Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

Open Source and information security mailing list archives

Date:	Mon, 17 Oct 2011 18:53:03 +0800
From:	Richard Zhao <richard.zhao@...aro.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	<jeremy.kerr@...onical.com>, <paul@...an.com>,
	<linaro-dev@...ts.linaro.org>, <linus.walleij@...ricsson.com>,
	<patches@...aro.org>, <shawn.guo@...escale.com>,
	Sascha Hauer <s.hauer@...gutronix.de>, <magnus.damm@...il.com>,
	<linux-kernel@...r.kernel.org>, <eric.miao@...aro.org>,
	<grant.likely@...retlab.ca>, <dsaxena@...aro.org>,
	<amit.kucheria@...aro.org>, <skannan@...cinc.com>,
	<linux@....linux.org.uk>, <arnd.bergmann@...aro.org>,
	<sboyd@...inc.com>, <tglx@...utronix.de>,
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...com>
Subject: Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure

On Mon, Oct 17, 2011 at 10:20:28AM +0100, Mark Brown wrote:
> On Mon, Oct 17, 2011 at 04:48:52PM +0800, Richard Zhao wrote:
> 
> > For example, devices that possible access to on-chip RAM, depend on OCRAM clock. 
> > On imx53, VPU depends on OCRAM clock, even when VPU does not use OCRAM.
> 
> So if the VPU depends on OCRAM the VPU should be enabling the OCRAM
> clock.  The function of a given clock isn't terribly relevant, and
> certainly grouping clocks together doesn't seem to be the obvious
> solution from what you've said
VPU don't know OCRAM clk, it's SoC specific. I know it's clock function
replationship. But it's the only better place to refect the dependency 
in clock tree. Another dependency example, from SoC bus topology, some bus
clk always depends on bus switch/hub.
> - if the driver doesn't know about the
> clock it seems like the core ought to be enabling it transparently
> rather than gluing it together with some other random clock.
If you mean clk core here, then we need things like below:
struct clk_hw {
	struct clk *clk;
	struct dependency {
		struct clk_hw *clks;
		int count;
	};
};
Though Mike does not like to add things in clk_hw, but it's the only place
to put common things of clk drivers.

Thanks
Richard
> 
> Either way the point here is that individual drivers shouldn't be hand
> coding this stuff, it should be being handled by core code.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

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