http://bugs.freedesktop.org/show_bug.cgi?id=26347
--- Comment #22 from Tobias Jakobi <liquid.a...@gmx.net> 2010-03-07 12:10:10 PST --- @Rafał: > Uhm. Just to make sure - I don't mean to criticize you here. I appreciate your work but at least from my point of view there are some big issues here. I'm still waiting for some AMD guy to reply here (Alex?) to shed some light on the issue. > What you want is static PM, I never claimed we have that. I focus on dynpm. No, I don't just want static PM (that would come for free if the reclocking is implement similar to the Windows driver). I want some cpufreq like (however simplified a lot) interface in userspace to configure PM (and also dynpm). > No. Power states in AtomBIOS are for both: dynamic and static PM. I never said it wasn't. Of course the tables include both "dynamic" and "static" states - I never doubt that since it's obvious from the kernel log / DRM module output. > How do you imagine dynamic PM without knowing valid modes? I don't think you get my point. The power state entries are profiles which are based on the "need" of the current system state. See my post about the Windows driver behaviour on my friend's laptop system. There are in total 4 power states defined by the BIOS (in his case!). The driver only uses 2 (lets call them A and B) of them (unimportant for my point). A is the state that is selected when the laptop is plugged to AC. When plugged to AC the system doesn't have to worry so much about power consumption which is reflected in the clocks of power state (high). Of course the whole PM is still dynamic since the power state A has more than 1 entry and the entries aren't identical. Same goes for power state B which is selected (by the driver) when the system is running on battery. On battery the driver should worry about power consumption since each battery has limited capacity. This is again reflected in the clocks of power state B. But again it's dynamic - only the individual clocks are lower. > About providing UI for > static PM I don't think there is much we can learn from Catalyst. We just need > someone who will implement that. I may be totally wrong here - but isn't that just fixing the specific power state (lets call it C) and let the driver only switch between the entries of C (with the effect that no effective clock changes occur)? > Well, what really more would you like to use from power states? They just > provide clocks and voltage with some flags (which we don't parse fully yet). > Don't see much more magic about them we could use. Then why does AMD define the notion of a "power state" at all? Why are entries _grouped_ together to a power state? Why not just leave the whole notion of "power state" away and just put the entries (without grouping) into the BIOS? Again, why this grouping if (according to you) there is no meaning to it in the first place? Greets, Tobias -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
