On 27 March 2014 15:00, Gautham R Shenoy wrote:
> As of now, I prefer this patch be based on code that is in the -next
> tree. I'll get rid of the per-core locking once the serialization
> patch of the core is accepted.
Okay, its pushed in -next now :)
On Thu, 2014-03-27 at 16:50 +0530, Gautham R Shenoy wrote:
>
> Well, in the scenarios that we're interested in, it is highly unlikely
> that CONFIG_PREMPT is set. Hence we'll default to
> raw_smp_processor_id() anyway. So, I think we can retain
> smp_processor_id().
We don't know that. Some peop
On 27 March 2014 16:50, Gautham R Shenoy wrote:
> (That said, in the future if we want to export additional
> information, say pertaining to the voltage, we will have to keep a
> separate array anyway :-) )
Lets handle that once it comes.
> However, as of now, I am wary about reusing a variable
On Thu, Mar 27, 2014 at 03:29:36PM +0530, Viresh Kumar wrote:
> On 27 March 2014 15:00, Gautham R Shenoy wrote:
> > As of now, I prefer this patch be based on code that is in the -next
> > tree. I'll get rid of the per-core locking once the serialization
> > patch of the core is accepted.
>
> Oka
On Thu, 2014-03-27 at 15:00 +0530, Gautham R Shenoy wrote:
> > > --- a/arch/powerpc/configs/pseries_le_defconfig
> > > +++ b/arch/powerpc/configs/pseries_le_defconfig
> > > @@ -350,3 +350,4 @@ CONFIG_CRYPTO_LZO=m
> > > # CONFIG_CRYPTO_ANSI_CPRNG is not set
> > > CONFIG_CRYPTO_DEV_NX=y
> > > CONF
On 27 March 2014 15:51, Srivatsa S. Bhat
wrote:
> smp_processor_id() maps to debug_smp_processor_id() only if
> CONFIG_DEBUG_PREEMPT is set. Otherwise, it is same as raw_smp_processor_id().
> So I think its best to keep it as it is.
That was the case in .configs and so suggested raw_* variant. Ke
On 27 March 2014 15:41, Vaidyanathan Srinivasan
wrote:
>> > Why do you need to get these from DT? And not find that yourself here
>> > instead?
> DT provides the values that we should use. Ideally these are the
> upper and lower limits of the PState table, however as per the
> platform spec, w
On 03/27/2014 03:29 PM, Viresh Kumar wrote:
> On 27 March 2014 15:00, Gautham R Shenoy wrote:
>> As of now, I prefer this patch be based on code that is in the -next
>> tree. I'll get rid of the per-core locking once the serialization
>> patch of the core is accepted.
>
[...]
+ pr_deb
* Gautham R Shenoy [2014-03-27 15:00:50]:
[snip]
> > > + u32 len_ids, len_freqs;
> > > +
> > > + power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
> > > + if (!power_mgt) {
> > > + pr_warn("power-mgt node not found\n");
> > > + return -ENODEV
On 27 March 2014 15:00, Gautham R Shenoy wrote:
> As of now, I prefer this patch be based on code that is in the -next
> tree. I'll get rid of the per-core locking once the serialization
> patch of the core is accepted.
Okay.. Then divide this patch into two parts, second one doing all
the serial
On Thu, Mar 27, 2014 at 12:09:53PM +0530, Viresh Kumar wrote:
> Cc'ing Rafael.
>
Thanks. It was a lapse on my part by not Cc'ing Rafael in the first
place.
> On 26 March 2014 22:25, Gautham R. Shenoy wrote:
> > From: Vaidyanathan Srinivasan
> >
> > Backend driver to dynamically set voltage and
Cc'ing Rafael.
On 26 March 2014 22:25, Gautham R. Shenoy wrote:
> From: Vaidyanathan Srinivasan
>
> Backend driver to dynamically set voltage and frequency on
> IBM POWER non-virtualized platforms. Power management SPRs
> are used to set the required PState.
>
> This driver works in conjunction
Hi Gautham,
> Backend driver to dynamically set voltage and frequency on
> IBM POWER non-virtualized platforms. Power management SPRs
> are used to set the required PState.
I tested this version on ppc64le, it still looks good. I'm already
a Signed-off-by on the patch, but feel free to add:
Te
From: Vaidyanathan Srinivasan
Backend driver to dynamically set voltage and frequency on
IBM POWER non-virtualized platforms. Power management SPRs
are used to set the required PState.
This driver works in conjunction with cpufreq governors
like 'ondemand' to provide a demand based frequency an
14 matches
Mail list logo
