On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> This is the v3 of the consolidated patchset consisting
> patches for enabling cpufreq on IBM POWERNV platforms
> along with some enhancements.
This is the first time I saw them. Looks like you never Cc'd linux-pm list.
Also, would be bet
Hi Viresh,
On Fri, Mar 21, 2014 at 01:16:03PM +0530, Viresh Kumar wrote:
> On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
> wrote:
> > This is the v3 of the consolidated patchset consisting
> > patches for enabling cpufreq on IBM POWERNV platforms
> > along with some enhancements.
>
> This i
Hi Geoff,
> Do you have these in a git branch somewhere so I can merge and test
> them?
No, sorry, I don't have a public git repo. Let me see how I can fix
that, it might be useful for future patchsets.
Thanks,
C.
___
Linuxppc-dev mailing list
L
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: Vaidyanathan Srinivasan
Hi Vaidy,
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 4b029c0..4ba1632 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -48,6 +48,7 @@ config CPU_FRE
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: "Srivatsa S. Bhat"
>
> On POWER systems, the CPU frequency is controlled at a core-level and
> hence we need to serialize so that only one of the threads in the core
> switches the core's frequency at a time.
Probably you don't ne
On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
wrote:
> From: "Gautham R. Shenoy"
>
> Create a driver attribute named cpuinfo_nominal_freq which
> creates a sysfs read-only file named cpuinfo_nominal_freq. Export
> the frequency corresponding to the nominal_pstate through this
> interface.
>
From: Scott Wood [mailto:scottw...@freescale.com]
> On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
> > I tried to work out what the 'twi, isync' instructions were for (in
> > in_le32()).
> > The best I could come up with was to ensure a synchronous bus-fault.
> > But bus faults are probabl
On Thu, Mar 20, 2014 at 5:41 PM, Gautham R. Shenoy
wrote:
> From: "Gautham R. Shenoy"
>
> The current frequency of a cpu is reported through the sysfs file
> cpuinfo_cur_freq. This requires the driver to implement a
> "->get(unsigned int cpu)" method which will return the current
> operating freq
Hi Geoff,
>> Do you have these in a git branch somewhere so I can merge and test
>> them?
>
> No, sorry, I don't have a public git repo. Let me see how I can fix
> that, it might be useful for future patchsets.
Please try that :
git pull git://github.com/legoater/linux.git zimage
Th
On Fri, Mar 21, 2014 at 02:17:28PM +0530, Viresh Kumar wrote:
> > +static ssize_t show_cpuinfo_nominal_freq(struct cpufreq_policy *policy,
> > + char *buf)
> > +{
> > + int nominal_freq;
> > + nominal_freq =
> > pstate_id_to_freq(powernv_pstate_inf
On 03/21/2014 02:12 PM, Viresh Kumar wrote:
> On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
> wrote:
>> From: "Srivatsa S. Bhat"
>>
>> On POWER systems, the CPU frequency is controlled at a core-level and
>> hence we need to serialize so that only one of the threads in the core
>> switches t
On 21 March 2014 15:25, Gautham R Shenoy wrote:
> Probably the use of ATTR_RO(cpuinfo_nominal_freq) and renaming
> show_cpuinfo_nominal_freq to cpuinfo_nominal_freq_show() would be even
> better. What do you think ?
+1
___
Linuxppc-dev mailing list
Linu
Hi Viresh,
On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
> On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
> wrote:
> > From: Vaidyanathan Srinivasan
>
> Hi Vaidy,
>
> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> > index 4b029c0..4ba1632 100644
> > ---
On 21 March 2014 16:13, Gautham R Shenoy wrote:
> On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
>> > + pr_debug("PState id %d freq %d MHz\n", id, freq);
>> > + powernv_freqs[i].driver_data = i;
>>
>> I don't think you are using this field at all and thi
On Fri, Mar 21, 2014 at 03:01:29PM +0530, Viresh Kumar wrote:
> On Thu, Mar 20, 2014 at 5:41 PM, Gautham R. Shenoy
> wrote:
> > From: "Gautham R. Shenoy"
> >
> > The current frequency of a cpu is reported through the sysfs file
> > cpuinfo_cur_freq. This requires the driver to implement a
> > "->
To specify spi flash layouts by "mtdparts=..." in cmdline, we must
give mtd_info a fixed name,because the cmdlinepart's parser will
match the name of mtd_info given in cmdline.
Now, if use DT, the mtd_info's name will be spi->dev->name. It
consists of spi_master->bus_num, and the spi_master->bus_nu
On 03/21/2014 04:24 PM, Viresh Kumar wrote:
> On 21 March 2014 16:13, Gautham R Shenoy wrote:
>> On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
>
+ pr_debug("PState id %d freq %d MHz\n", id, freq);
+ powernv_freqs[i].driver_data = i;
>>>
[...]
On 03/21/2014 02:11 PM, Viresh Kumar wrote:
> On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
> wrote:
>> From: Vaidyanathan Srinivasan
>
> Hi Vaidy,
>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index 4b029c0..4ba1632 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b
On 21 March 2014 16:34, Gautham R Shenoy wrote:
> Heh! Well, that wasn't the reason why this was sent out as a separate
> patch, but never mind. Though I don't understand why it would be
> difficult to review the patch though.
Because the initial driver wasn't complete earlier. There were 2-3 pat
On 21 March 2014 17:15, Srivatsa S. Bhat
wrote:
>> I think you have Srivatsa there who has seen lots of cpufreq code and
>> could have helped you a lot :)
>>
>
> :-)
I was waiting for your reply here :)
> I have followed the locking and synchronization aspects of cpufreq
> closely, but unfortuna
From: Viresh Kumar
> On 21 March 2014 16:34, Gautham R Shenoy wrote:
> > Heh! Well, that wasn't the reason why this was sent out as a separate
> > patch, but never mind. Though I don't understand why it would be
> > difficult to review the patch though.
>
> Because the initial driver wasn't com
Hi Anshuman,
On 21/03/14 03:44, Anshuman Khandual wrote:
> On 03/10/2014 04:42 PM, Sudeep Holla wrote:
>> Hi Anshuman,
>>
>> On 07/03/14 06:14, Anshuman Khandual wrote:
>>> On 03/07/2014 09:36 AM, Anshuman Khandual wrote:
On 02/19/2014 09:36 PM, Sudeep Holla wrote:
> From: Sudeep Holla
>
On Fri, Mar 21, 2014 at 12:01:07PM +, David Laight wrote:
> From: Viresh Kumar
>
> > On 21 March 2014 16:34, Gautham R Shenoy wrote:
> > > Heh! Well, that wasn't the reason why this was sent out as a separate
> > > patch, but never mind. Though I don't understand why it would be
> > > diffic
On 21 March 2014 17:31, David Laight wrote:
>> *(int *)ret_freq = freq;
>
> Because it is very likely to be wrong.
> In general casts of pointers to integer types are dangerous.
Where are we converting pointers to integers? We are doing a
cast from 'void * ' to 'int *' and then using indirection
On Fri, Mar 21, 2014 at 05:15:34PM +0530, Viresh Kumar wrote:
> On 21 March 2014 16:34, Gautham R Shenoy wrote:
> > Heh! Well, that wasn't the reason why this was sent out as a separate
> > patch, but never mind. Though I don't understand why it would be
> > difficult to review the patch though.
>
On 21 March 2014 18:34, Gautham R Shenoy wrote:
> Consider the case when pmspr = 0x00fe;
>
> We are interested in extracting the value 'fe'. And ensure that when
> we store this value into an int, we get the sign extension right.
>
> So the following doesn't work:
>
>pstate_id = (p
Hi Viresh,
On Fri, Mar 21, 2014 at 04:24:27PM +0530, Viresh Kumar wrote:
> On 21 March 2014 16:13, Gautham R Shenoy wrote:
> > On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
>
> >> > + pr_debug("PState id %d freq %d MHz\n", id, freq);
> >> > + powernv_f
On 21 March 2014 18:53, Gautham R Shenoy wrote:
> Ok, I had based my code on linus's git tree. I checked the 'pm-cpufreq'
Always check his bleeding-edge or linux-next branch.
> branch of Rafael's 'linux-pm' tree and freq_table.c contains the
> following code snippet in show_available_frequencies
On Fri, Mar 21, 2014 at 06:42:50PM +0530, Viresh Kumar wrote:
> On 21 March 2014 18:34, Gautham R Shenoy wrote:
> > Consider the case when pmspr = 0x00fe;
> >
> > We are interested in extracting the value 'fe'. And ensure that when
> > we store this value into an int, we get the sign e
* Gautham R Shenoy [2014-03-21 16:13:17]:
> Hi Viresh,
>
> On Fri, Mar 21, 2014 at 02:11:32PM +0530, Viresh Kumar wrote:
> > On Thu, Mar 20, 2014 at 5:40 PM, Gautham R. Shenoy
> > wrote:
> > > From: Vaidyanathan Srinivasan
> >
> > Hi Vaidy,
> >
Hi Viresh,
Thanks for the detailed review.
>
On Fri, Mar 21, 2014 at 04:24:27PM +0530, Viresh Kumar wrote:
> >> > +static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
> >> > +{
> >> > + int base, i;
> >> > +
> >> > + base = cpu_first_thread_sibling(policy->cpu);
> >> > +
> >> > + for (i = 0; i < threads_per_co
From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> On 21 March 2014 17:31, David Laight wrote:
> >> *(int *)ret_freq = freq;
> >
> > Because it is very likely to be wrong.
> > In general casts of pointers to integer types are dangerous.
>
> Where are we converting pointers to integers? We are
Hi Cédric,
On Thu, 2014-03-20 at 16:09 +0100, Cédric Le Goater wrote:
> The following patchset adds support for 64bit little endian boot
> wrapper. It is based on original code from Andrew Tauferner.
I tested this on PS3 (64 bit BE) and found no regression.
Tested by: Geoff Levand
__
On Fri, 2014-03-21 at 19:16 +0800, Hou Zhiqiang wrote:
> @@ -1009,8 +1012,17 @@ static int m25p_probe(struct spi_device *spi)
>
> if (data && data->name)
> flash->mtd.name = data->name;
> - else
> - flash->mtd.name = dev_name(&spi->dev);
> + else{
Whitespa
On 03/21/2014 06:28 PM, Geoff Levand wrote:
> Hi Cédric,
>
> On Thu, 2014-03-20 at 16:09 +0100, Cédric Le Goater wrote:
>> The following patchset adds support for 64bit little endian boot
>> wrapper. It is based on original code from Andrew Tauferner.
>
> I tested this on PS3 (64 bit BE) and fo
On 14/03/19, Eric Paris wrote:
> For all arches which support audit implement syscall_get_arch()
> They are all pretty easy and straight forward, stolen from how the call
> to audit_syscall_entry() determines the arch.
>
> Signed-off-by: Eric Paris
> Cc: linux-i...@vger.kernel.org
> Cc: microblaz
On 14/03/19, Eric Paris wrote:
> We have a function where the arch can be queried, syscall_get_arch().
> So rather than have every single piece of arch specific code use and/or
> duplicate syscall_get_arch(), just have the audit code use the
> syscall_get_arch() code.
>
> Signed-off-by: Eric Paris
On Fri, 2014-03-21 at 09:21 +, David Laight wrote:
> From: Scott Wood [mailto:scottw...@freescale.com]
> > On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
> > > I tried to work out what the 'twi, isync' instructions were for (in
> > > in_le32()).
> > > The best I could come up with was
On Fri, 2014-03-21 at 16:34 +0530, Gautham R Shenoy wrote:
> > >
> > > +/*
> > > + * Computes the current frequency on this cpu
> > > + * and stores the result in *ret_freq.
> > > + */
> > > +static void powernv_read_cpu_freq(void *ret_freq)
> > > +{
> > > + unsigned long pmspr_val;
> > > +
From 9ad9432dab2bf4d1c8e6ff9201e88d5ae9f3994a Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Wed, 19 Mar 2014 20:24:22 -0500
Subject: [PATCH 1/1] perf: Add 'merge-recursive' callchain option
Powerpc saves the link register (LR) with each sample to help resolve
callchains for programs i
> > So reverting and applying v3 3/4 and 4/4 patches works for me.
>
> Ok, I verified that the above endds up resulting in the same tree as
> the minimal patch I sent out, modulo (a) some comments and (b) an
> #ifdef CONFIG_SMP in futex_get_mm() that doesn't really matter.
>
> So I committed the
On Sat, 2014-03-22 at 07:57 +0530, Srikar Dronamraju wrote:
> > > So reverting and applying v3 3/4 and 4/4 patches works for me.
> >
> > Ok, I verified that the above endds up resulting in the same tree as
> > the minimal patch I sent out, modulo (a) some comments and (b) an
> > #ifdef CONFIG_SMP
On 21 March 2014 20:18, Vaidyanathan Srinivasan
wrote:
> Yeah, I had the driver written using driver_data to store pstates.
> Gautham found the bug that we are missing one PState when we match the
> ID with CPUFREQ_BOOST_FREQ!
I see..
> We did not know that you have taken care of those issues.
On 21 March 2014 20:24, Gautham R Shenoy wrote:
> Ok, I guess the right thing to do at this point is call
>
>cpufreq_table_validate_and_show(policy, powernv_freqs);
>
> Will fix the code to take care of this.
Yes.
___
Linuxppc-dev mailing list
Linux
44 matches
Mail list logo
