All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafał Bilski" <rafalbilski@interia.pl>
To: Len Brown <lenb@kernel.org>
Cc: cpufreq@lists.linux.org.uk
Subject: Re: [PATCH] Longhaul - Add ignore_latency option
Date: Thu, 24 Aug 2006 23:09:34 +0200	[thread overview]
Message-ID: <44EE158E.6050601@interia.pl> (raw)
In-Reply-To: <200608241554.11782.len.brown@intel.com>

[...]
>> 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

      reply	other threads:[~2006-08-24 21:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-13  7:16 [PATCH] Longhaul - Add ignore_latency option Rafał Bilski
2006-08-24  3:22 ` Len Brown
2006-08-24 17:18   ` Rafał Bilski
2006-08-24 19:54     ` Len Brown
2006-08-24 21:09       ` Rafał Bilski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44EE158E.6050601@interia.pl \
    --to=rafalbilski@interia.pl \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=lenb@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.