Re: [PATCH 1/1] clk: Add notifier support in clk_prepare/clk_unprepare

On Thu, Mar 28, 2013 at 11:01:09PM +0100, Mike Turquette wrote: > Quoting Colin Cross (2013-03-21 17:06:25) > > On Thu, Mar 21, 2013 at 3:36 PM, Mike Turquette > > wrote: > > > To my knowledge, devfreq performs one task: implements an algorithm > > > (typically one that loops/polls) and applies t

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

On Fri, Mar 15, 2013 at 06:22:47AM +0100, Stephen Warren wrote: > On 03/14/2013 07:20 PM, Bill Huang wrote: > > On Fri, 2013-03-15 at 01:54 +0800, Stephen Warren wrote: > >> On 03/14/2013 03:28 AM, Bill Huang wrote: > >>> On Thu, 2013-03-14 at 17:21 +0800, Peter De

Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare

On Thu, Mar 14, 2013 at 03:15:11AM +0100, Bill Huang wrote: > I don't think deferring will work either, considering the usage of DVFS, > device voltage is tightly coupled with frequency, when clock rate is > about to increase, we have to boost voltage first and we can lower the > voltage after the

Re: [PATCH V3 0/4] cpuidle : multiple drivers support

ed on ARM Dual Cortex-A9 U8500 (aka Snowball) > > > > V1 tested on Tegra3 and Vexpress TC2 > > V3 tested on TC2, hence, on the whole series > > Tested-by: Lorenzo Pieralisi > V3 tested on Tegra3, so: Tested-by: Peter De Schrijver ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/4][V2] cpuidle : multiple drivers support

On Thu, Oct 25, 2012 at 10:29:43PM +0200, Rafael J. Wysocki wrote: > On Thursday, October 25, 2012 04:49:33 PM Peter De Schrijver wrote: > > On Fri, Oct 19, 2012 at 12:10:45PM +0200, Daniel Lezcano wrote: > > > The discussion about having different cpus on the system with > &g

Re: [PATCH 0/4][V2] cpuidle : multiple drivers support

On Fri, Oct 19, 2012 at 12:10:45PM +0200, Daniel Lezcano wrote: > The discussion about having different cpus on the system with > different latencies bring us to a first attemp by adding a > pointer in the cpuidle_device to the states array. > > But as Rafael suggested, it would make more sense to

Re: [PATCH 4/4] cpuidle - support multiple drivers

> >> > >> eg. > >> cpu0: acpi_idle > >> cpu1: acpi_idle > >> > > > > Is this allowed? I thought sysfs files can output only 1 line of data? > > Ah yeah :) > > Does it make sense to put the following files: > > /sys/devices/system/cpu/cpu0/cpuidle/driver > => acpi_idle > /sys/devices/system/cpu

Re: [PATCH 0/4] cpuidle - support multiple drivers at a time

FIG_CPU_IDLE_MULTIPLE_DRIVERS. > > Tested on Core2 Duo T9500 with acpi_idle [and intel_idle] > Tested on ARM Dual Cortex-A9 U8500 (aka Snowball) > Tested on Cardhu (Tegra30). Besides the possibly problem with the sysfs format: Acked-by: Peter De Schrijver Cheers, Peter.

Re: [PATCH 4/4] cpuidle - support multiple drivers

On Tue, Sep 25, 2012 at 12:43:54AM +0200, Daniel Lezcano wrote: > With the tegra3 and the big.LITTLE [1] new architectures, several cpus > with different characteristics (latencies and states) can co-exists on the > system. > > The cpuidle framework has the limitation of handling only identical cp

Re: [PATCH 0/6] cpuidle : per cpu latencies

> > It is similar with Tegra3. > In our case CPU0 has different latencies for 1 C state compared to the other CPUs > I think Peter and Lorenzo already wrote a driver based on this approach. > Peter, Lorenzo any comments ? > Yes. My implementation doesn't provide a state table in the cpuidle d

Re: [PATCH 0/5][RFC] Use per cpuidle_device states

On Mon, Sep 03, 2012 at 01:05:11PM +0200, Peter De Schrijver wrote: > On Fri, Aug 31, 2012 at 11:19:15PM +0200, Daniel Lezcano wrote: > > On 07/27/2012 01:28 PM, Peter De Schrijver wrote: > > > On Wed, Jul 25, 2012 at 12:45:57PM +0200, Daniel Lezcano wrote: &

Re: [PATCH 3/5][RFC] cpuidle : add a pointer for cpuidle_state in the cpuidle_device

On Wed, Jul 25, 2012 at 12:46:00PM +0200, Daniel Lezcano wrote: > This patch adds a pointer to the cpuidle_state array in the cpuidle_device > structure. When the cpuidle_device is initialized, the pointer is assigned > from the driver's cpuidle states array. > > Signed-off-by: Daniel Lezcano > -

Re: [PATCH 5/5][RFC] cpuidle : add cpuidle_register_states function

On Wed, Jul 25, 2012 at 12:46:02PM +0200, Daniel Lezcano wrote: > The tegra3 and big.LITTLE architecture have different cpu latencies. > This API allows to specify a different cpu latency for a specific cpu. > > With the previous patches, we use the per cpuidle device states pointer, > this functi

Re: [PATCH 0/5][RFC] Use per cpuidle_device states

On Fri, Aug 31, 2012 at 11:19:15PM +0200, Daniel Lezcano wrote: > On 07/27/2012 01:28 PM, Peter De Schrijver wrote: > > On Wed, Jul 25, 2012 at 12:45:57PM +0200, Daniel Lezcano wrote: > >> Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab, > >> cpuidle: Si

Re: [PATCH 0/5][RFC] Use per cpuidle_device states

On Wed, Jul 25, 2012 at 12:45:57PM +0200, Daniel Lezcano wrote: > Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab, > cpuidle: Single/Global registration of idle states > > we have a single registration for the cpuidle states which makes > sense. But now two new architectures are comi

Re: cpuidle future and improvements

On Mon, Jun 18, 2012 at 02:35:42PM +0200, Daniel Lezcano wrote: > On 06/18/2012 01:54 PM, Deepthi Dharwar wrote: > > On 06/18/2012 02:10 PM, Daniel Lezcano wrote: > > > >> > >> Dear all, > >> > >> A few weeks ago, Peter De Schrijver proposed a