[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111017092028.GA3042@opensource.wolfsonmicro.com>
Date: Mon, 17 Oct 2011 10:20:28 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Richard Zhao <richard.zhao@...aro.org>
Cc: Sascha Hauer <s.hauer@...gutronix.de>,
linux-arm-kernel@...ts.infradead.org, paul@...an.com,
linaro-dev@...ts.linaro.org, linus.walleij@...ricsson.com,
patches@...aro.org, magnus.damm@...il.com,
linux-kernel@...r.kernel.org, eric.miao@...aro.org,
grant.likely@...retlab.ca, arnd.bergmann@...aro.org,
dsaxena@...aro.org, tglx@...utronix.de, amit.kucheria@...aro.org,
linux@....linux.org.uk, skannan@...cinc.com,
Mike Turquette <mturquette@...com>, jeremy.kerr@...onical.com,
shawn.guo@...escale.com, sboyd@...inc.com
Subject: Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
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 - 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.
Either way the point here is that individual drivers shouldn't be hand
coding this stuff, it should be being handled by core code.
--
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/
Powered by blists - more mailing lists