From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
Subject: Re: [PATCH] AMD,
 powernow: Update P-state directly when _PSD's CoordType is
 DOMAIN_COORD_TYPE_HW_ALL
Date: Fri, 17 Aug 2012 09:50:50 -0400
Message-ID: <502E4C3A.5050409@amd.com>
References: <85190245a94d9945b765.1345135279@localhost.localdomain>
	<502E399B0200007800095DA1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <502E399B0200007800095DA1@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org



On 08/17/2012 06:31 AM, Jan Beulich wrote:
>>>> On 16.08.12 at 18:41, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> @@ -137,26 +122,28 @@ static int powernow_cpufreq_target(struc
>>               return 0;
>>       }
>>
>> -    if (policy->shared_type != CPUFREQ_SHARED_TYPE_ANY)
>> -        cmd.mask = &online_policy_cpus;
>> -    else
>> -        cmd.mask = cpumask_of(policy->cpu);
>> +    if (policy->shared_type == CPUFREQ_SHARED_TYPE_HW &&
>> +        likely(policy->cpu == smp_processor_id())) {
>> +        transition_pstate(&next_perf_state);
>> +        cpufreq_statistic_update(policy->cpu, perf->state, next_perf_state);
>
> Actually - is this enough? Doesn't this also need to be done based
> on policy->cpus?

With HW-coordinated transitions there is a policy structure per CPU so 
policy->cpus is always 1 and policy->cpu is the same as policy->cpus. 
You can see this in cpufreq_add_cpu(), when hw_all is set.

(This is consistent with ACPI spec:
	When hardware coordinates transitions, OSPM continues to
	initiate state transitions as it would if there were no
	dependencies.
)

-boris


>
> Jan
>
>> +    } else {
>> +        cpumask_and(&online_policy_cpus, policy->cpus, &cpu_online_map);
>>
>> -    freqs.old = perf->states[perf->state].core_frequency * 1000;
>> -    freqs.new = data->freq_table[next_state].frequency;
>> +        if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
>> +            unlikely(policy->cpu != smp_processor_id()))
>> +            on_selected_cpus(&online_policy_cpus, transition_pstate,
>> +                             &next_perf_state, 1);
>> +        else
>> +            transition_pstate(&next_perf_state);
>>
>> -    cmd.val = next_perf_state;
>> -    cmd.turbo = policy->turbo;
>> -
>> -    on_selected_cpus(cmd.mask, transition_pstate, &cmd, 1);
>> -
>> -    for_each_cpu(j, &online_policy_cpus)
>> -        cpufreq_statistic_update(j, perf->state, next_perf_state);
>> +        for_each_cpu(j, &online_policy_cpus)
>> +            cpufreq_statistic_update(j, perf->state, next_perf_state);
>> +    }
>>
>>       perf->state = next_perf_state;
>> -    policy->cur = freqs.new;
>> +    policy->cur = data->freq_table[next_state].frequency;
>>
>> -    return result;
>> +    return 0;
>>   }
>>
>>   static int powernow_cpufreq_verify(struct cpufreq_policy *policy)
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
>