[PATCH] Longhaul - Add ignore_latency option

[PATCH] Longhaul - Add ignore_latency option

[Rafał Bilski]

Some laptops with VIA C3 processor, CLE266 chipset and
AMI BIOS have incorrect latency values in FADT table. These
laptops seems to be C3 capable, but latency values are to
big: 101 for C2 and 1017 for C3. This option will allow
user to skip C3 latency test but not C3 address test. AMI
BIOS is setting C3 address to correct value in DSDT table.

Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>

---

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -65,7 +65,7 @@ static int port22_en = 0;
 
 /* Module parameters */
 static int dont_scale_voltage;
-
+static int ignore_latency = 0;
 
 #define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "longhaul", msg)
 
@@ -665,8 +665,10 @@ static int __init longhaul_cpu_init(stru
 	if (longhaul_version == TYPE_POWERSAVER) {
 		/* Check ACPI support for C3 state */
 		cx = &pr->power.states[ACPI_STATE_C3];
-		if (cx->address == 0 || cx->latency > 1000)
+		if (cx->address == 0 || 
+		   (cx->latency > 1000 && ignore_latency == 0) )
 			goto err_acpi;
+
 	} else {
 		/* Check ACPI support for bus master arbiter disable */
 		if (!pr->flags.bm_control) {
@@ -773,6 +775,8 @@ static void __exit longhaul_exit(void)
 
 module_param (dont_scale_voltage, int, 0644);
 MODULE_PARM_DESC(dont_scale_voltage, "Don't scale voltage of processor");
+module_param(ignore_latency, int, 0644);
+MODULE_PARM_DESC(ignore_latency, "Skip ACPI C3 latency test");
 
 MODULE_AUTHOR ("Dave Jones <davej@codemonkey.org.uk>");
 MODULE_DESCRIPTION ("Longhaul driver for VIA Cyrix processors.");
@@ -780,4 +784,3 @@ MODULE_LICENSE ("GPL");
 
 late_initcall(longhaul_init);
 module_exit(longhaul_exit);
-

Re: [PATCH] Longhaul - Add ignore_latency option

[Len Brown]

On Sunday 13 August 2006 03:16, Rafa³ Bilski wrote:
> Some laptops with VIA C3 processor, CLE266 chipset and
> AMI BIOS have incorrect latency values in FADT table. These
> laptops seems to be C3 capable, but latency values are to
> big: 101 for C2 and 1017 for C3. This option will allow
> user to skip C3 latency test but not C3 address test. AMI
> BIOS is setting C3 address to correct value in DSDT table.

This looks very fishy.

C2 latency above 100usec and C3 latency above 1000 usec
are the official way for the BIOS to tell the OS to NOT USE
those C-states.  Under no conditions should Linux second
guess those explicit instructions -- the BIOS may have put
those values there because you get silent data corruption
on that particular stepping of the processor or chipset
if they are enabled.

But the real question is why the longhaul driver is checking
for C2 and C3 support in the first place -- as they are not
directly related to the availability of P-states.

-Len


> Signed-off-by: Rafa³ Bilski <rafalbilski@interia.pl>
> 
> ---
> 
> diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
> --- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
> +++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
> @@ -65,7 +65,7 @@ static int port22_en = 0;
>  
>  /* Module parameters */
>  static int dont_scale_voltage;
> -
> +static int ignore_latency = 0;
>  
>  #define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "longhaul", msg)
>  
> @@ -665,8 +665,10 @@ static int __init longhaul_cpu_init(stru
>  	if (longhaul_version == TYPE_POWERSAVER) {
>  		/* Check ACPI support for C3 state */
>  		cx = &pr->power.states[ACPI_STATE_C3];
> -		if (cx->address == 0 || cx->latency > 1000)
> +		if (cx->address == 0 || 
> +		   (cx->latency > 1000 && ignore_latency == 0) )
>  			goto err_acpi;
> +
>  	} else {
>  		/* Check ACPI support for bus master arbiter disable */
>  		if (!pr->flags.bm_control) {
> @@ -773,6 +775,8 @@ static void __exit longhaul_exit(void)
>  
>  module_param (dont_scale_voltage, int, 0644);
>  MODULE_PARM_DESC(dont_scale_voltage, "Don't scale voltage of processor");
> +module_param(ignore_latency, int, 0644);
> +MODULE_PARM_DESC(ignore_latency, "Skip ACPI C3 latency test");
>  
>  MODULE_AUTHOR ("Dave Jones <davej@codemonkey.org.uk>");
>  MODULE_DESCRIPTION ("Longhaul driver for VIA Cyrix processors.");
> @@ -780,4 +784,3 @@ MODULE_LICENSE ("GPL");
>  
>  late_initcall(longhaul_init);
>  module_exit(longhaul_exit);
> -
> 
> 
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@lists.linux.org.uk
> http://lists.linux.org.uk/mailman/listinfo/cpufreq
> 

Re: [PATCH] Longhaul - Add ignore_latency option

[Rafał Bilski]

>> Some laptops with VIA C3 processor, CLE266 chipset and
>> AMI BIOS have incorrect latency values in FADT table. These
>> laptops seems to be C3 capable, but latency values are to
>> big: 101 for C2 and 1017 for C3. This option will allow
>> user to skip C3 latency test but not C3 address test. AMI
>> BIOS is setting C3 address to correct value in DSDT table.
> 
> This looks very fishy.

So why P_BLK address is valid and have proper lenght?

> 
> C2 latency above 100usec and C3 latency above 1000 usec
> are the official way for the BIOS to tell the OS to NOT USE
> those C-states.  Under no conditions should Linux second
> guess those explicit instructions -- the BIOS may have put
> those values there because you get silent data corruption
> on that particular stepping of the processor or chipset
> if they are enabled.
> 

It is disabled by default.
It is only needed for some laptops.
As far I know there is no data corruption. Chipset and processor 
are exacly the same as on Epia M10000 so I don't expect any.

Why force user to recompilation of distro kernel?

> But the real question is why the longhaul driver is checking
> for C2 and C3 support in the first place -- as they are not
> directly related to the availability of P-states.
> 
> -Len
> 

Because Longhaul isn't using P-states.

Rafa³

----------------------------------------------------------------------
Zostan Chlopakiem Lata! >>> http://link.interia.pl/f1998

Re: [PATCH] Longhaul - Add ignore_latency option

[Len Brown]

On Thursday 24 August 2006 13:18, you wrote:
> >> Some laptops with VIA C3 processor, CLE266 chipset and
> >> AMI BIOS have incorrect latency values in FADT table. These
> >> laptops seems to be C3 capable, but latency values are to
> >> big: 101 for C2 and 1017 for C3. This option will allow
> >> user to skip C3 latency test but not C3 address test. AMI
> >> BIOS is setting C3 address to correct value in DSDT table.
> > 
> > This looks very fishy.
> 
> So why P_BLK address is valid and have proper lenght?

One possible scenario is that the same BIOS source runs on
multiple hardware steppings.  If a broken stepping is found,
the BIOS writer knows that setting the latency above the
legal threshold is sufficient to disable the C-state in
all known ACPI-enabled operating systems, per below.

> > C2 latency above 100usec and C3 latency above 1000 usec
> > are the official way for the BIOS to tell the OS to NOT USE
> > those C-states.  Under no conditions should Linux second
> > guess those explicit instructions -- the BIOS may have put
> > those values there because you get silent data corruption
> > on that particular stepping of the processor or chipset
> > if they are enabled.
> > 
> 
> It is disabled by default.
> It is only needed for some laptops.
> As far I know there is no data corruption. Chipset and processor 
> are exacly the same as on Epia M10000 so I don't expect any.
> 
> Why force user to recompilation of distro kernel?

Why should a distro support this if the BIOS vendor disabled it?
Is the fact that you have not noticed data corruption a
sufficient test such that they can suport this?

> > But the real question is why the longhaul driver is checking
> > for C2 and C3 support in the first place -- as they are not
> > directly related to the availability of P-states.
> 
> Because Longhaul isn't using P-states.

I guess I don't understand what longhaul.c is doing.
Why is it using ACPI's C2 and C3 register addresses in order
to do frequency/voltage scaling?

In the case there those addresses have been deemed invalid for
the purpose of ACPI C-states, why are they still valid for longhaul?

-Len

Re: [PATCH] Longhaul - Add ignore_latency option

[Rafał Bilski]

[...]
>> So why P_BLK address is valid and have proper lenght?
> 
> One possible scenario is that the same BIOS source runs on
> multiple hardware steppings.  If a broken stepping is found,
> the BIOS writer knows that setting the latency above the
> legal threshold is sufficient to disable the C-state in
> all known ACPI-enabled operating systems, per below.
> 
[...]
>>
>> Why force user to recompilation of distro kernel?
> 
> Why should a distro support this if the BIOS vendor disabled it?
> Is the fact that you have not noticed data corruption a
> sufficient test such that they can suport this?
> 

This is only BIOS that is saying this. Other are saying that this 
combination is C3 capable. What test would be sufficent for You?
Are You aware that don't working C3:
- isn't causing frequency transition,
- will lockup the CPU if there is bus master activity on PCI bus
during transition?

>>> But the real question is why the longhaul driver is checking
>>> for C2 and C3 support in the first place -- as they are not
>>> directly related to the availability of P-states.
>> Because Longhaul isn't using P-states.
> 
> I guess I don't understand what longhaul.c is doing.
> Why is it using ACPI's C2 and C3 register addresses in order
> to do frequency/voltage scaling?
> 

VIA CPU don't like any bus activity during transition (flushing 
caches before isn't enough). If there is change on any pin during PLL 
resync (flush caches or interrupt for example) CPU will be frozen. 
Thanks to ACPI C3 (C2 isn't used) processor have enough time for 
resync. Bus master activity is disabled and will not triger caches 
flush or anything else.

> In the case there those addresses have been deemed invalid for
> the purpose of ACPI C-states, why are they still valid for longhaul?
> 
> -Len
> 

As I explained before this is single case. I don't know any other BIOS 
for mainboard/motherboard with VIA CPU and VIA chipset claiming that 
mobo don't support ACPI C3.

Rafa³


----------------------------------------------------------------------
Zostan Chlopakiem Lata! >>> http://link.interia.pl/f1998