On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
> I don't have board right now to take the snapshot, but it would be
> like:
>
> $ tree /sys/devices/system/cpu/cpu0/cpufreq/
> /sys/devices/system/cpu/cpu0/cpufreq/
> ├── affected_cpus
> ├── bios_limit
> ├── cpb
> ├── cpuinfo_cur_freq
On Tue, Feb 05, 2013 at 05:54:57PM +0530, Viresh Kumar wrote:q
> This indication isn't enough. On a single image solution, we need to
> identify the system which needs support for multiple policies and i
> still feel we need that variable type indication :)
If the image is going to run also on sys
On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
> That's not completely true. There lies cpufreq directory in cpu/cpu*/
> too, where we have per policy stuff in cpu/cpu*/, like policy tunables
> and stats. And the same is true for governor too.
$ tree /sys/devices/system/cpu/cpu0/cpu
On Tue, Feb 05, 2013 at 03:17:21PM +0530, Viresh Kumar wrote:
> > multiple policies support in cpufreq should be optional and
> > selectable in Kconfig so that systems which don't need that, don't
> > have to see or use it. It is yet another feature which doesn't apply
> > universally so we make su
On Mon, Feb 04, 2013 at 07:51:33PM +0530, Viresh Kumar wrote:
> We correlate things with cpus rather than policies and so the current
> directory structure of cpu/cpu*/cpufreq/*** is the best suited ones.
Ok, show me the details of that layout. How is that going to look?
One thing I've come to re
On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
> not talking about governor tunables but policy tunables. Things like
> scaling_[min]max_freq are policy tunables.
No, on x86 those are the P-states frequencies.
On Tue, Feb 05, 2013 at 04:13:23PM +0530, Viresh Kumar wrote:
> There isn't lot of code that we have to keep inside the macro you
> suggest. Its just an if else (with single line block), which would
> give the parent kobject. Nothing else.
>
> I didn't wanted to create a macro for just that. For me
On Tue, Feb 05, 2013 at 04:42:23PM +0530, Viresh Kumar wrote:
> Tricky part is the name of this routine: add_additional_sysfs_entries().
Now you're just being silly - this is just an example how to do it. If
you want me to do it for ya, you need to send me your monthly salary.
> And so, keeping t
On Mon, Feb 04, 2013 at 05:54:18PM +0530, Viresh Kumar wrote:
> One important point i would like to highlight is: governors directory
> would be present in cpu/cpu*/cpufreq/ now instead of cpu/cpufreq/.
Uh, hold on, isn't this breaking a bunch of userspace with this move?
Also, on all those other
On Tue, Feb 05, 2013 at 06:38:07PM +, Charles Garcia-Tobin wrote:
> Later. Whatever you'd like to call it, but essentially a set of cpus,
> as linux understands them, that are logically related by the fact that
> you'd like to be able to use the same tuning policy and same governor
> across all
On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote:
> That's why i am highlighting it again and again. :)
Ah, see, someone caught up with it :).
> What i believe is, the place where this directory was present earlier
> (cpu/cpufreq/) wasn't the right place. Everything else was in
> cpu
On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
> > I think this is cleaner but whatever - I don't care that much. My
> > only strong concern is that this thing should be a Kconfig option and
> > optional for arches where it doesn't apply.
>
> Your concern is: we don't want to fix us
On Tue, Feb 05, 2013 at 11:29:04AM +, Charles Garcia-Tobin wrote:
> Actually shooting myself in the foot here, Krait is not such a great
> example because although you can use difference between frequencies
> you are less likely to use different tunables (not inconceivable
> but unlikely). The
On Tue, Feb 05, 2013 at 04:56:03PM +0530, Viresh Kumar wrote:
> Just some kind of indication from platform driver is required about
> how/where it wants its governor directory to be present.
The indication is this:
config CPUFREQ_PLATFORM_DRIVER_X
...
select CPUFREQ_MULTIPLE_POLIC
On Wednesday, February 06, 2013 03:45:58 PM Viresh Kumar wrote:
> On 6 February 2013 15:38, Amit Kucheria wrote:
> > On Wed, Feb 6, 2013 at 3:28 PM, Viresh Kumar
> > wrote:
> >> I have pushed the complete patchset here:
> >>
> >> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog
On 6 February 2013 15:38, Amit Kucheria wrote:
> On Wed, Feb 6, 2013 at 3:28 PM, Viresh Kumar wrote:
>> I have pushed the complete patchset here:
>>
>> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/cpufreq-updates
>>
>
> Viresh, perhaps you should ask Stephen Rot
On Wed, Feb 6, 2013 at 3:28 PM, Viresh Kumar wrote:
> On 5 February 2013 21:51, Viresh Kumar wrote:
>> commit 15b5548c9ccfb8088270f7574710d9d67edfe33b
>> Author: Viresh Kumar
>> Date: Tue Feb 5 21:29:05 2013 +0530
>>
>> cpufreq: Make governors directory sysfs location based on
>> have_mult
On 5 February 2013 21:51, Viresh Kumar wrote:
> commit 15b5548c9ccfb8088270f7574710d9d67edfe33b
> Author: Viresh Kumar
> Date: Tue Feb 5 21:29:05 2013 +0530
>
> cpufreq: Make governors directory sysfs location based on
> have_multiple_policies
>
> Until now directory for governors tunab
>
> On Tue, Feb 05, 2013 at 11:29:04AM +, Charles Garcia-Tobin wrote:
> > Actually shooting myself in the foot here, Krait is not such a great
> > example because although you can use difference between frequencies
> > you are less likely to use different tunables (not inconceivable
> > but unl
On 4 February 2013 17:08, Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor. i.e. We can't
> have
On 5 February 2013 18:52, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 05:54:57PM +0530, Viresh Kumar wrote:q
>> This indication isn't enough. On a single image solution, we need to
>> identify the system which needs support for multiple policies and i
>> still feel we need that variable type
On 5 February 2013 17:02, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 04:56:03PM +0530, Viresh Kumar wrote:
>> Just some kind of indication from platform driver is required about
>> how/where it wants its governor directory to be present.
>
> The indication is this:
>
> config CPUFREQ_PLATFOR
>
> Qualcomm's ARM based "krait". Currently shipping in millions of Android
> phones.
>
> http://en.wikipedia.org/wiki/Krait_(CPU)
>
> Thanks Charles for pointing it out, I knew there is one :)
>
> --
> viresh
> On 4 February 2013 19:06, Borislav Petkov wrote:
> > On Mon, Feb 04, 2013 at 06:55:25
On 5 February 2013 16:49, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 04:42:23PM +0530, Viresh Kumar wrote:
>> Tricky part is the name of this routine: add_additional_sysfs_entries().
>
> Now you're just being silly - this is just an example how to do it. If
> you want me to do it for ya, you
On 5 February 2013 16:34, Borislav Petkov wrote:
> Here's an even cleaner way:
>
> platform_driver:
> init(struct cpufreq_policy *policy)
> {
> ...
>
> add_additional_sysfs_entries(policy);
>
> ...
> }
>
> ...
>
> static void add_additional_sysfs_entries(struct cpufreq_poli
On 5 February 2013 15:57, Borislav Petkov wrote:
> Are you kidding me? You're simply not reading what I'm saying to you:
> "... should be optional and selectable in Kconfig so that systems which
> don't need that, don't have to see or use it." Because on those systems
> it doesn't apply.
>
> How a
On 5 February 2013 14:45, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 12:50:31PM +0530, Viresh Kumar wrote:
>> > I think this is cleaner but whatever - I don't care that much. My
>> > only strong concern is that this thing should be a Kconfig option and
>> > optional for arches where it doesn
On 4 February 2013 19:06, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
>> Its not only for multicluster system, but a system where multiple cpus
>> have separate clock control and hence multiple policy structures.
>
> What are those systems? Examples?
Qu
On Mon, Feb 4, 2013 at 10:20 PM, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 09:07:11PM +0530, Viresh Kumar wrote:
>> └── ondemand
>> ├── sampling_rate
>> ├── up_threshold
>> └── ignore_nice
>
> So this is adding the current governor as a per-cpu thing.
Its per policy, but yes it
On 4 February 2013 20:35, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:51:33PM +0530, Viresh Kumar wrote:
>> We correlate things with cpus rather than policies and so the current
>> directory structure of cpu/cpu*/cpufreq/*** is the best suited ones.
>
> Ok, show me the details of that layo
On 4 February 2013 19:39, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 07:28:16PM +0530, Viresh Kumar wrote:
>> All files which are directly present in cpu/cpu*/cpufreq/ folder. I am
>> not talking about governor tunables but policy tunables. Things like
>> scaling_[min]max_freq are policy tun
On 4 February 2013 19:06, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:55:25PM +0530, Viresh Kumar wrote:
>> That's not completely true. There lies cpufreq directory in cpu/cpu*/
>> too, where we have per policy stuff in cpu/cpu*/, like policy tunables
>> and stats. And the same is true for
On 4 February 2013 18:34, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote:
>> What i believe is, the place where this directory was present earlier
>> (cpu/cpufreq/) wasn't the right place. Everything else was in
>> cpu/cpu*/cpufreq,
>> then why this in cpu/
On 4 February 2013 18:02, Borislav Petkov wrote:
> On Mon, Feb 04, 2013 at 05:54:18PM +0530, Viresh Kumar wrote:
>> One important point i would like to highlight is: governors directory
>> would be present in cpu/cpu*/cpufreq/ now instead of cpu/cpufreq/.
>
> Uh, hold on, isn't this breaking a bun
On 4 February 2013 17:47, Rafael J. Wysocki wrote:
> Well, [1-2/4] are things I can take for v3.9 no problem. The other two I'd
> wait for the next cycle to be honest. We already have 30+ cpufreq patches
> scheduled for v3.9 and some of them quite subtle for that matter.
To be honest, i wanted
On Monday, February 04, 2013 05:08:50 PM Viresh Kumar wrote:
> Currently, there can't be multiple instances of single governor_type. If we
> have
> a multi-package system, where we have multiple instances of struct policy (per
> package), we can't have multiple instances of same governor. i.e. We
36 matches
Mail list logo
