From: Michael Clark <michael@metaparadigm.com>
To: "Clark, Michael" <michael@metaparadigm.com>
Cc: Pavel Machek <pavel@suse.cz>,
jeremy@goop.org, davej@codemonkey.org.uk,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] - Initial dothan speedstep support
Date: Mon, 23 Aug 2004 08:33:05 +0800 [thread overview]
Message-ID: <41293B41.5040800@metaparadigm.com> (raw)
In-Reply-To: <56689.210.86.92.219.1093159902.squirrel@mail.metaparadigm.com>
On 08/22/04 15:31, Clark, Michael wrote:
>>Hi!
>>
>>
>>>So here's a patch on top of the above patch that adds all of the
>>>dothan frequency/voltages for processors 715, 725, 735, 745, 755
>>>
>>>Tested and working as it should so far with a 745. The stepping in the
>>>model table for the others may need to be tweaked.
>>>
>>>The Dothan processor datasheet 30218903.pdf defines 4 voltages for
>>>each frequency (VID#A through VID#D) whereas Banias only suggests a
>>>typical voltage and no min or max for each freq so i've used the OP
>>>macro to allow definition of all voltages (A through D) but the macro
>>>currently just uses VID#C at compile time (the second lowest voltage
>>>profile).
>>
>>I thought that whether to use VID#A, B, C or D depends on
>>your concrete chip? Not all chips are certified to run on VID#C...
>
>
> Yes, I believe this is the case. When I read the processor spec
> document it did not mention this but since then i found this out. I've
> since changed the patch to use the VID#A voltages which is more
> conservative (assuming that all of them will run at the higher voltage
> okay which according to the upper voltage rating of 1.6 volts might be
On re-looking at the spec and the voltage tolerance tables in particular
I realize my approach is not valid. A VID#B can be driven at VID#A
voltages but there is no voltage in common for some frequencies between
all VID# variants.
> okay). It would of course be preferrable to work out the the type
> VID#A,B,C,D via software - not sure if this is possible.
Perhaps the VID# variant can be found via MSRs - if not the static tables
will not be workable and the ACPI approach will have to be the sole method.
~mc
prev parent reply other threads:[~2004-08-23 0:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-06 5:03 [PATCH] - Initial dothan speedstep support Michael Clark
2004-08-06 11:04 ` Michael Clark
2004-08-09 14:28 ` Dave Jones
2004-08-10 11:59 ` Michael Clark
2004-08-10 12:16 ` Michael Clark
2004-08-18 13:53 ` Pavel Machek
2004-08-22 7:31 ` Clark, Michael
2004-08-23 0:33 ` Michael Clark [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=41293B41.5040800@metaparadigm.com \
--to=michael@metaparadigm.com \
--cc=davej@codemonkey.org.uk \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
/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.