I've added support for PowerPlayInfo_V4 (the one I reverse engineered
lately) in radeonhd today - and a whole bunch of heuristic validation
routines. Which means that the driver *finally* has some idea about the
possible chip frequencies and voltages :-D
Determination of some of the values is still scary, and I don't know yet
whether we will stumble over them - especially the minimum frequencies
are sort-of guessed from the (known) minimum PLL output frequencies. But
we need them, because some cards (e.g. one RV770 I have here) only have
one known good memory clock configuration, while it can save *tons* of
power if it is lowered (tested + measured, GDDR5 memory really uses a
lot of power). Therefor, the values are checked for reasonable bounds,
and rejected if they exceed. So if a future chip needs less than 500mV
for operation, we will have to update these tests...
The current code has all these bits in place, but doesn't configure
anything different than previous versions. First, a set of reasonable
settings has to be determined, which will need additional heuristics
(this is done in rhdPmSelectSettings(), which needs some love still).
This selection also depends on how difficult it will be to change the
engine and memory clock, and the VDDC voltage. So far we only set the
engine clock, but code is already in place for the other two.
Before setting a clock, it must be made sure that the engines using this
clock are idle - that's why we (ahem!) only set the engine clock once at
the beginning so far:
- For setting the engine clock, the engine must be idle (surprise).
- For setting the memory clock, memory accesses must be prohibited.
Which means that the screen will be blank during this phase. It
remains to be seen whether the vertical blank is long enough to do
this on the fly. Otherwise this means that we *typically* shouldn't
change the memory clock during runtime. Things get messy when multiple
screens are attached...
- For setting the VDDC voltage, all engines must be idle. Also, certain
combinations of engine and memory clock require certain VDDC voltages.
The amount of known good configurations is limited, and sometimes they
are contradicting :-[ Remains to be seen whether we can sort-of
interpolate between good settings, because typically there are more
voltage values available than used...
Later we will need an oracle for selecting the right power state
according to the current usage pattern. It might be easier to do that in
kernel space, but this remains to be seen.
That's it for today, I actually hoped to get more accomplished during
our HackWeek. But reading out dynamic AtomBIOS tables can be...
intriguingly complex.
CU all
Matthias
--
Matthias Hopf