Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Dominik Brodowski]

On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
> Of course, we can't guarantee that there will always be a match; or that 
> there won't be duplicate matches. Also, this approach relies on having 
> ACPI P-states, to build up the frequency/voltage table. However, it 
> still seems to me to be a pretty robust way of determining the VID# in a 
> system, and one that could be incorporated into speedstep-centrino. 
> Dominik, what do you think?

It indeed seems somewhat robust to me, I'd like to get Venkatesh's input on
this, though. "Transient voltages" may pose a problem, though...

I wouldn't favor for inclusion into speedstep-centrino, though -- one
cpufreq driver requiring at first one other to run, then to unload the other
with speedstep-centrino taking over... no, that doesn't _feel_ right. I
wouldn't vote against including the Dothan tables but only using them if the
user passes a parameter "vid=[a-f]", though.

Just my $0.02,

	Dominik

PS: moved this discussion to the cpufreq list which seems more appropriate
for this stuff.

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Rich Townsend]

Dominik Brodowski wrote:
> On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
> 
>>Of course, we can't guarantee that there will always be a match; or that 
>>there won't be duplicate matches. Also, this approach relies on having 
>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>still seems to me to be a pretty robust way of determining the VID# in a 
>>system, and one that could be incorporated into speedstep-centrino. 
>>Dominik, what do you think?
> 
> 
> It indeed seems somewhat robust to me, I'd like to get Venkatesh's input on
> this, though. "Transient voltages" may pose a problem, though...

Gak, hadn't thought of that.

> 
> I wouldn't favor for inclusion into speedstep-centrino, though -- one
> cpufreq driver requiring at first one other to run, then to unload the other
> with speedstep-centrino taking over... no, that doesn't _feel_ right. I
> wouldn't vote against including the Dothan tables but only using them if the
> user passes a parameter "vid=[a-f]", though.

I concurr. Unless a subset of acpi_cpufreq could be implemented within 
speedstep-centrino without nasty hackery, you end up with an unpleasant 
dependency problem. I'll look into adding the vid= option over the 
Dothan tables patch.

cheers,

Rich

RE: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: cpufreq-bounces@ZenII.linux.org.uk 
>[mailto:cpufreq-bounces@ZenII.linux.org.uk] On Behalf Of Rich Townsend
>Sent: Sunday, February 13, 2005 6:12 AM
>To: Dominik Brodowski
>Cc: cpufreq@ZenII.linux.org.uk; Simon Moore
>Subject: Re: Dothan VID# identification script (was Re: [ACPI] 
>Speedstep-centrino problems)
>
>Dominik Brodowski wrote:
>> On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
>> 
>>>Of course, we can't guarantee that there will always be a 
>match; or that 
>>>there won't be duplicate matches. Also, this approach relies 
>on having 
>>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>>still seems to me to be a pretty robust way of determining 
>the VID# in a 
>>>system, and one that could be incorporated into speedstep-centrino. 
>>>Dominik, what do you think?
>> 
>> 
>> It indeed seems somewhat robust to me, I'd like to get 
>Venkatesh's input on
>> this, though. "Transient voltages" may pose a problem, though...
>
>Gak, hadn't thought of that.
>

Actually, if you use CNTL MSR in place of STATUS MSR, you don't have to
worry about transients.

Thanks,
Venki

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Rich Townsend]

Pallipadi, Venkatesh wrote:
>>-----Original Message-----
>>From: cpufreq-bounces@ZenII.linux.org.uk 
>>[mailto:cpufreq-bounces@ZenII.linux.org.uk] On Behalf Of Rich Townsend
>>Sent: Sunday, February 13, 2005 6:12 AM
>>To: Dominik Brodowski
>>Cc: cpufreq@ZenII.linux.org.uk; Simon Moore
>>Subject: Re: Dothan VID# identification script (was Re: [ACPI] 
>>Speedstep-centrino problems)
>>
>>Dominik Brodowski wrote:
>>
>>>On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
>>>
>>>
>>>>Of course, we can't guarantee that there will always be a 
>>
>>match; or that 
>>
>>>>there won't be duplicate matches. Also, this approach relies 
>>
>>on having 
>>
>>>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>>>still seems to me to be a pretty robust way of determining 
>>
>>the VID# in a 
>>
>>>>system, and one that could be incorporated into speedstep-centrino. 
>>>>Dominik, what do you think?
>>>
>>>
>>>It indeed seems somewhat robust to me, I'd like to get 
>>
>>Venkatesh's input on
>>
>>>this, though. "Transient voltages" may pose a problem, though...
>>
>>Gak, hadn't thought of that.
>>
> 
> 
> Actually, if you use CNTL MSR in place of STATUS MSR, you don't have to
> worry about transients.

OK! What is the offset of the CNTL MSR? And does it decode to a 
freq/voltage pair in the same way as STATUS?

On a related note, is there a simple way to set the CPU to its maximum 
frequency, without having to know what the associated voltage is?

cheers,

Rich

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Dominik Brodowski]

On Sun, Feb 20, 2005 at 09:23:12AM -0500, Rich Townsend wrote:
> OK! What is the offset of the CNTL MSR?

MSR_IA32_PERF_CTL


> And does it decode to a freq/voltage pair in the same way as STATUS?

Yes.

> On a related note, is there a simple way to set the CPU to its maximum 
> frequency, without having to know what the associated voltage is?

Using speedstep-centrino, no.

	Dominik