Re: VIA PowerSaver (Re: Linux 2.6.30-rc8 [also: VIA Support])

From: Michael S. Zick
Date: Fri Jun 05 2009 - 09:41:56 EST


On Fri June 5 2009, Harald Welte wrote:
> Hi Linus and Michael,
>
> On Thu, Jun 04, 2009 at 10:46:00AM -0700, Linus Torvalds wrote:
>
> > On Thu, 4 Jun 2009, Michael S. Zick wrote:
> > >
> > > Yes, I build test cases with and without - -
> > > It was a fixed-speed kernel build that first hit the 4 hour up-time mark.
> > > I just reposted that build today (the -09143lk).
> > >
> > > > Features like that easily put a huge stress on power regulators etc, if
> > > > they result in sudden changes in current draw. Underspecced capacitors
> > > > etc can cause CPU "brown-outs", which in turn can easily cause total
> > > > failure.
> > >
> > > There is also a possible thermal issue with these machines - -
> > > I doubt that VIA runs their qualification testing in bake ovens;
> > > which is what NetBook cases amount too. ;)
> >
> > If the fixed-speed case runs for longer, it's not likely to be a thermal
> > issue. The fixed speed case should be the higher-power one.
> >
> > So it can easily be a weak power setup (insufficient grounding, bad
> > capacitors etc). But it could also be external bus issues, in case VIA
> > power management also impact the external bus (eg "stopclock" like
> > behavior on the CPU<->chipset bus).
>
> I'm not intending to disagree with you, I just wanted to quote from
> a not [yet] public document on the C7-M. This quote describes model A
> (family 6, model 10(hex A), stepping 0-15):
> ===============
> Enhanced PowerSaver technology allows the dynamic adjustment of the operating
> frequency and operating voltage. The VIA C7-M can only change from the
> highest supported performance state to the lowest supported performance state:
> intermediate performance states are not guaranteed to work and are not offi-
> cially supported. System software can use Enhanced PowerSaver to request the
> sufficient amount of performance. Each individual performance state (P-State)
> is described in the system bios according to 8.4.4 of the ACPI 3.0
> specification.
>
> The VIA C7-M processor incorporates two on-chip core clock PLLs. This allows
> the processor to ping-pong between two frequencies instantaneously. In the
> simplest scenario, where there are only two clock frequencies of interest and
> no voltage changes, the transition can be instantaneous with no latency. In
> more complex scenarios, where there are multiple clock frequencies of interest,
> the "old" frequency can continue to be used while the new frequency is ramped
> up. The transition is still instantaneous from a software point of view (code
> still executes), but there is a latency associated with switching to the ramp-
> ing "new" frequency.
>

This appears to be what the e_powersaver is trying to do - -
It just needs to do it better. ;)

The current behavior ends up as 9 speeds, (I.E: 8 steps) of twice the FSB
frequency. I do show "stats/time_in_state" for all of them.

It is one heck of a system, It will be nice if I can make it work - -
If it has to be turned into a two-speed system, so be it.

= = = =

Note: This is one of VIA's claims to fame - and a good one - -
and different than what the cpufreq stuff was probably tested with.

Most other brands of CPU will "stall" (or some such) internally while
re-syncing the core clock chain (there-by "stalling" the code progress) -
The VIA processors do not - they keep on computing - something the
general code may not account for. ;)

Since I have a machine that is sensitive to this, I can test other
ways of doing something other than the two speed solution.

>
> VIA C7-M allows for a clean hardware approach to processor operating point
> transitions. The transitions are performed instantaneously from a software and
> functional point of view. Snoops and interrupts, for example, are unaffected by
> transitions.
> ===============
>
> A C7-M model D (family 6, model 13(hex D), stepping 0-15) has advanced performance
> states, they use an inflection ratio, as well as adaptive-p-state control and
> adaptive overclocking, as well as iteravie P-state transitions and adaptive
> thermal control. I'm not yet aware of all the details, but have requested them.
>
> In any case, the problems that have been reported by Michael were "Model A",
> so those particular deatils shouldn't matter at this point.
>

dmesg is reporting it as an "Model D" - I will check if that reporting is correct.
Tell the Silicon Grower's department "Thanks" for the recommendation of what to look for.

Mike
> Regards,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/