[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100917120702.GB4322@rakim.wolfsonmicro.main>
Date: Fri, 17 Sep 2010 13:07:02 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: 'Kukjin Kim' <kgene.kim@...sung.com>,
'Jeongbae Seo' <jeongbae.seo@...sung.com>,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
'Changhwan Youn' <chaos.youn@...sung.com>,
linux-arm-kernel@...ts.infradead.org, lrg@...mlogic.co.uk
Subject: Re: [PATCH] regulator: Add support samsung power domain
On Fri, Sep 17, 2010 at 01:45:36PM +0200, Marek Szyprowski wrote:
> The approach with merging power domains with clocks have some disadvantages.
> In some cases the clock gating and power gating should be distinguished.
This is not what I suggested. I suggested using runtime PM instead of
the regulator API to manage blocks.
> Just assume an IP like a video codec. It has it's own internal state machine.
> It gets reset when the ip is power gated, but it is preserved during clock
> gating. The driver might want to do a clock gating when it is waiting for a
> new frame to decode, but should do power gating only when the device has
There's nothing stopping the drivers enabling and disabling the clocks
for themselves while they're active, all the rumtime PM stuff I've seen
for this does is ensure that the clocks are enabled and disabled when
the device is enabled and disabled. This matches what you're saying
above - clearly, if the device is power gated there's no need to provide
a clock for it - and with aggressive runtime PM it's pretty much exactly
what a lot of devices end up needing.
> been closed. Having a set of fake clocks just for power gating imho doesn't
> look good.
Who said use the clock API?
--
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