On Thursday, July 09, 2015 10:43:56 AM Viresh Kumar wrote:
> On 09-07-15, 02:40, Rafael J. Wysocki wrote:
> > The above sentence is completely unclear to anyone unfamiliar with the
> > code in question.
> >
> > The fix is to access the policy data structure for the given CPU directly
> > (which al
On 09-07-15, 02:40, Rafael J. Wysocki wrote:
> The above sentence is completely unclear to anyone unfamiliar with the
> code in question.
>
> The fix is to access the policy data structure for the given CPU directly
> (which also returns a valid policy for offline CPUs), but the policy
> itself ha
On Wednesday, July 08, 2015 01:08:15 PM Viresh Kumar wrote:
> Users of freq table may want to access it for any CPU from
> policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
> list of 'clip_cpus' (equivalent to policy->related_cpus) during
> registration and tries to get freq_
Hi Viresh,
one minor nit below
On Wed, Jul 08, 2015 at 08:38:15AM +0100, Viresh Kumar wrote:
> Users of freq table may want to access it for any CPU from
> policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
> list of 'clip_cpus' (equivalent to policy->related_cpus) during
>
On Wed, Jul 8, 2015 at 3:38 PM, Viresh Kumar wrote:
> Users of freq table may want to access it for any CPU from
> policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
> list of 'clip_cpus' (equivalent to policy->related_cpus) during
> registration and tries to get freq_table f
Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.
If the CPU, for which it trie
6 matches
Mail list logo
