Hi,
I have been doing some CPUFreq cleanup work and
wanted to know if the below mentioned machines have separate
clock domains for their CPUs or all share the same domain?
So, that we can use some generic routines for these drivers which
would eventually do:
cpumask_setall(policy->cpus);
And I wanted to make sure that this doesn't break them.. :)
......
The drivers are:
drivers/cpufreq/at32ap-cpufreq.c
drivers/cpufreq/blackfin-cpufreq.c
drivers/cpufreq/cris-artpec3-cpufreq.c
drivers/cpufreq/cris-etraxfs-cpufreq.c
drivers/cpufreq/davinci-cpufreq.c
drivers/cpufreq/e_powersaver.c
drivers/cpufreq/elanfreq.c
drivers/cpufreq/longhaul.c
drivers/cpufreq/loongson2_cpufreq.c
drivers/cpufreq/pmac32-cpufreq.c
drivers/cpufreq/powernow-k6.c
drivers/cpufreq/powernow-k7.c
drivers/cpufreq/pxa2xx-cpufreq.c
drivers/cpufreq/pxa3xx-cpufreq.c
drivers/cpufreq/sc520_freq.c
drivers/cpufreq/sh-cpufreq.c
drivers/cpufreq/sparc-us2e-cpufreq.c
drivers/cpufreq/sparc-us3-cpufreq.c
--
Viresh
On Thursday 29 August 2013 03:45 PM, Viresh Kumar wrote:
> Hi,
>
> I have been doing some CPUFreq cleanup work and
> wanted to know if the below mentioned machines have separate
> clock domains for their CPUs or all share the same domain?
On DaVinci (DA850), there is an async domain available to keep some
peripheral clocks insulated from cpu frequency changes. But there are a
bunch of other clocks which do get affected by CPU frequency change
(they need to run at a fixed ratio to CPU frequency).
Thanks,
Sekhar
On 29 August 2013 15:53, Sekhar Nori <[email protected]> wrote:
> On DaVinci (DA850), there is an async domain available to keep some
> peripheral clocks insulated from cpu frequency changes. But there are a
> bunch of other clocks which do get affected by CPU frequency change
> (they need to run at a fixed ratio to CPU frequency).
My question wasn't about how peripherals are getting clocks.. but how
CPUs are getting them..
Does all CPUs share clock line in Davinci? i.e. if we change freq of one
cpu then freq of other one also gets changed?
Or they are capable of running at different frequencies?
--
viresh
On Thursday 29 August 2013 04:00 PM, Viresh Kumar wrote:
> On 29 August 2013 15:53, Sekhar Nori <[email protected]> wrote:
>> On DaVinci (DA850), there is an async domain available to keep some
>> peripheral clocks insulated from cpu frequency changes. But there are a
>> bunch of other clocks which do get affected by CPU frequency change
>> (they need to run at a fixed ratio to CPU frequency).
>
> My question wasn't about how peripherals are getting clocks.. but how
> CPUs are getting them..
>
> Does all CPUs share clock line in Davinci? i.e. if we change freq of one
> cpu then freq of other one also gets changed?
>
> Or they are capable of running at different frequencies?
I get it now. All DaVinci devices are UP only.
Thanks,
Sekhar
On 29 August 2013 15:57, Sekhar Nori <[email protected]> wrote:
> I get it now. All DaVinci devices are UP only.
Thanks..
Hi,
On Thu, Aug 29, 2013 at 03:45:58PM +0530, Viresh Kumar wrote:
> I have been doing some CPUFreq cleanup work and
> wanted to know if the below mentioned machines have separate
> clock domains for their CPUs or all share the same domain?
[...]
> drivers/cpufreq/loongson2_cpufreq.c
Loongson2 is UP only.
A.
Cris are also UP
29 aug 2013 kl. 12:16 skrev "Viresh Kumar" <[email protected]>:
> Hi,
>
> I have been doing some CPUFreq cleanup work and
> wanted to know if the below mentioned machines have separate
> clock domains for their CPUs or all share the same domain?
>
> So, that we can use some generic routines for these drivers which
> would eventually do:
>
> cpumask_setall(policy->cpus);
>
> And I wanted to make sure that this doesn't break them.. :)
>
> ......
>
> The drivers are:
>
> drivers/cpufreq/at32ap-cpufreq.c
> drivers/cpufreq/blackfin-cpufreq.c
> drivers/cpufreq/cris-artpec3-cpufreq.c
> drivers/cpufreq/cris-etraxfs-cpufreq.c
> drivers/cpufreq/davinci-cpufreq.c
> drivers/cpufreq/e_powersaver.c
> drivers/cpufreq/elanfreq.c
> drivers/cpufreq/longhaul.c
> drivers/cpufreq/loongson2_cpufreq.c
> drivers/cpufreq/pmac32-cpufreq.c
> drivers/cpufreq/powernow-k6.c
> drivers/cpufreq/powernow-k7.c
> drivers/cpufreq/pxa2xx-cpufreq.c
> drivers/cpufreq/pxa3xx-cpufreq.c
> drivers/cpufreq/sc520_freq.c
> drivers/cpufreq/sh-cpufreq.c
> drivers/cpufreq/sparc-us2e-cpufreq.c
> drivers/cpufreq/sparc-us3-cpufreq.c
>
> --
> Viresh
Hi Viresh,
On Thu, Aug 29, 2013 at 7:15 PM, Viresh Kumar <[email protected]> wrote:
> Hi,
>
> I have been doing some CPUFreq cleanup work and
> wanted to know if the below mentioned machines have separate
> clock domains for their CPUs or all share the same domain?
>
> So, that we can use some generic routines for these drivers which
> would eventually do:
>
> cpumask_setall(policy->cpus);
>
> And I wanted to make sure that this doesn't break them.. :)
>
> ......
>
> The drivers are:
...
> drivers/cpufreq/sh-cpufreq.c
...
The above SH cpufreq driver seems to be written with SMP in mind, but
I would say SMP is a very rare case for SH. So I believe it can be
considered as UP-only at this point. If Paul disagrees I'm quite sure
he will tell us.
Cheers,
/ magnus
On 30 August 2013 12:18, Magnus Damm <[email protected]> wrote:
> Hi Viresh,
>
> On Thu, Aug 29, 2013 at 7:15 PM, Viresh Kumar <[email protected]> wrote:
>> Hi,
>>
>> I have been doing some CPUFreq cleanup work and
>> wanted to know if the below mentioned machines have separate
>> clock domains for their CPUs or all share the same domain?
>>
>> So, that we can use some generic routines for these drivers which
>> would eventually do:
>>
>> cpumask_setall(policy->cpus);
>>
>> And I wanted to make sure that this doesn't break them.. :)
>>
>> ......
>>
>> The drivers are:
> ...
>> drivers/cpufreq/sh-cpufreq.c
> ...
>
> The above SH cpufreq driver seems to be written with SMP in mind, but
> I would say SMP is a very rare case for SH. So I believe it can be
> considered as UP-only at this point. If Paul disagrees I'm quite sure
> he will tell us.
Okay.. The problem isn't really SMP but different clock domains for CPUs
in a SMP system..
So, even if we have a SMP SH machine, will it have same clock line for
all CPUs?
I will go with the change anyway..
Thanks.
--
viresh
On Thu, 2013-08-29 at 15:45 +0530, Viresh Kumar wrote:
> drivers/cpufreq/pmac32-cpufreq.c
This is always UP.
Cheers,
Ben.
Hi Viresh,
On Fri, Aug 30, 2013 at 4:33 PM, Viresh Kumar <[email protected]> wrote:
> On 30 August 2013 12:18, Magnus Damm <[email protected]> wrote:
>> Hi Viresh,
>>
>> On Thu, Aug 29, 2013 at 7:15 PM, Viresh Kumar <[email protected]> wrote:
>>> Hi,
>>>
>>> I have been doing some CPUFreq cleanup work and
>>> wanted to know if the below mentioned machines have separate
>>> clock domains for their CPUs or all share the same domain?
>>>
>>> So, that we can use some generic routines for these drivers which
>>> would eventually do:
>>>
>>> cpumask_setall(policy->cpus);
>>>
>>> And I wanted to make sure that this doesn't break them.. :)
>>>
>>> ......
>>>
>>> The drivers are:
>> ...
>>> drivers/cpufreq/sh-cpufreq.c
>> ...
>>
>> The above SH cpufreq driver seems to be written with SMP in mind, but
>> I would say SMP is a very rare case for SH. So I believe it can be
>> considered as UP-only at this point. If Paul disagrees I'm quite sure
>> he will tell us.
>
> Okay.. The problem isn't really SMP but different clock domains for CPUs
> in a SMP system..
>
> So, even if we have a SMP SH machine, will it have same clock line for
> all CPUs?
Yeah, I understand your question but I'm afraid that I don't know the
answer myself.
> I will go with the change anyway..
Good plan. Thanks for cleaning up the cpufreq bits.
Cheers,
/ magnus