On 10/14/2015 11:55 PM, Viresh Kumar wrote:
On 13-10-15, 12:29, Saravana Kannan wrote:
But we don't need to track track of "present-cpus" separately
though. We could do the for_each_cpu_and() when we create the
symlinks for the first time. And after that, we can just use the
subsystem interface
On 13-10-15, 12:29, Saravana Kannan wrote:
> But we don't need to track track of "present-cpus" separately
> though. We could do the for_each_cpu_and() when we create the
> symlinks for the first time. And after that, we can just use the
> subsystem interface callbacks (cpufreq_add_dev() and
>
On 13-10-15, 12:29, Saravana Kannan wrote:
> But we don't need to track track of "present-cpus" separately
> though. We could do the for_each_cpu_and() when we create the
> symlinks for the first time. And after that, we can just use the
> subsystem interface callbacks (cpufreq_add_dev() and
>
On 10/14/2015 11:55 PM, Viresh Kumar wrote:
On 13-10-15, 12:29, Saravana Kannan wrote:
But we don't need to track track of "present-cpus" separately
though. We could do the for_each_cpu_and() when we create the
symlinks for the first time. And after that, we can just use the
subsystem interface
On 10/12/2015 08:39 PM, Viresh Kumar wrote:
On 12-10-15, 12:31, Saravana Kannan wrote:
Can we use the first CPU in the related CPUs mask? Instead of the
first CPU that the policy got created on? The policyX numbering
would be a bit more consistent that way.
Okay..
Suggested-by: ?
Will
On 10/12/2015 11:15 PM, Viresh Kumar wrote:
On 12-10-15, 12:31, Saravana Kannan wrote:
Can we use the first CPU in the related CPUs mask? Instead of the
first CPU that the policy got created on? The policyX numbering
would be a bit more consistent that way.
Okay, checked this again. The
On 12-10-15, 12:31, Saravana Kannan wrote:
> Can we use the first CPU in the related CPUs mask? Instead of the
> first CPU that the policy got created on? The policyX numbering
> would be a bit more consistent that way.
Okay, checked this again. The problem is that ->init() isn't called
yet and
On 10/12/2015 08:39 PM, Viresh Kumar wrote:
On 12-10-15, 12:31, Saravana Kannan wrote:
Can we use the first CPU in the related CPUs mask? Instead of the
first CPU that the policy got created on? The policyX numbering
would be a bit more consistent that way.
Okay..
Suggested-by: ?
Will
On 10/12/2015 11:15 PM, Viresh Kumar wrote:
On 12-10-15, 12:31, Saravana Kannan wrote:
Can we use the first CPU in the related CPUs mask? Instead of the
first CPU that the policy got created on? The policyX numbering
would be a bit more consistent that way.
Okay, checked this again. The
On 12-10-15, 12:31, Saravana Kannan wrote:
> Can we use the first CPU in the related CPUs mask? Instead of the
> first CPU that the policy got created on? The policyX numbering
> would be a bit more consistent that way.
Okay, checked this again. The problem is that ->init() isn't called
yet and
On 12-10-15, 12:31, Saravana Kannan wrote:
> Can we use the first CPU in the related CPUs mask? Instead of the
> first CPU that the policy got created on? The policyX numbering
> would be a bit more consistent that way.
Okay..
> Suggested-by: ?
Will add. Though me/Rafael thought about it long
On 10/11/2015 10:21 AM, Viresh Kumar wrote:
The cpufreq sysfs interface had been a bit inconsistent as one of the
CPUs for a policy had a real directory within its sysfs 'cpuX' directory
and all other CPUs had links to it. That also made the code a bit
complex as we need to take care of moving
On 10/11/2015 10:21 AM, Viresh Kumar wrote:
The cpufreq sysfs interface had been a bit inconsistent as one of the
CPUs for a policy had a real directory within its sysfs 'cpuX' directory
and all other CPUs had links to it. That also made the code a bit
complex as we need to take care of moving
On 12-10-15, 12:31, Saravana Kannan wrote:
> Can we use the first CPU in the related CPUs mask? Instead of the
> first CPU that the policy got created on? The policyX numbering
> would be a bit more consistent that way.
Okay..
> Suggested-by: ?
Will add. Though me/Rafael thought about it long
The cpufreq sysfs interface had been a bit inconsistent as one of the
CPUs for a policy had a real directory within its sysfs 'cpuX' directory
and all other CPUs had links to it. That also made the code a bit
complex as we need to take care of moving the sysfs directory if the CPU
containing the
The cpufreq sysfs interface had been a bit inconsistent as one of the
CPUs for a policy had a real directory within its sysfs 'cpuX' directory
and all other CPUs had links to it. That also made the code a bit
complex as we need to take care of moving the sysfs directory if the CPU
containing the
16 matches
Mail list logo
