2010/2/18 Rafał Miłecki <zaj...@gmail.com>: > W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher > <alexdeuc...@gmail.com> napisał: >> 2010/2/17 Rafał Miłecki <zaj...@gmail.com>: >>> We kept requested and current modes in many places, depending on current >>> state. >>> That was useless, one place for holding that is enough. >>> >>> Signed-off-by: Rafał Miłecki <zaj...@gmail.com> >>> --- >>> Tested on my RV620, no problems. Alex: can you review this patch? It's your >>> code I modify/remove in it. >> >> NACK. Why are you replacing pointers with copies of of the power >> state structs? The idea is to keep one array of power states and >> pointers to the current one, default one, and requested one. Then >> comparing power states is just comparing pointers and when you change >> the power state, you just update the pointer rather then memcpying the >> entire struct. > > Then first of all we would need to reduce modes pointers. Keeping mode > pointer in every state struct is/was useless.
What do you mean? There is not a pointer to every state. There are only 3 (1. current, 2. requested 3. default) and they are not useless. You have power states which defines the global state of a particular power state and then each power state has a set of 1 or more clock modes. So within a power state you can switch between clock modes. You need a set of clock pointers to track the current clock mode and the requested clock mode. You also need to know the current and requested power state so you need pointers there as well. We could get rid of the default pointers, but that's mostly there for convenience to avoid having to look up the default state when we need it. For example, say you had the following power tables: 1. 3d power state: a. low clock mode b. medium clock mode c. high clock mode 2. battery power state a. low clock mode b. medium clock mode c. high clock mode 3. default power state a. low clock mode b. medium clock mode c. high clock mode By default state 3 would be selected so the current state would be '3' and the current clock mode would be a say 'a'. The current state pointer would point to '3' and the current clock mode pointer would point to 'a'. If you then went on battery, you'd want power state '2'. At that point, the requested state pointer points to '2' and one of the clock modes gets selected, lets say 'c', so the requested clock mode pointer points to 'c'. When we change the power state, we compare the current and requested power state pointers, if they are the same, no need to change anything. if they are different, we make the changes, then set the current power state pointer to the requested power state pointer and the current clock mode pointer to the requested clock mode pointer. Now say we are in power state '2' and clock mode 'c' (the high clock for power state '2') and the system goes idle; at the point we will want to stay in power state '2', but select clock mode 'a' (the low clock for power state '2'). So we compare the current and requested clock mode pointers and if they are not equal, we change the clock mode, at which time we update the current clock mode pointers to point to the requested clock. > > About introduced solution (keeping struct and memcpy to it) I > introduced that to make hacking requested mode possible. Info from > AtomBIOS about PCIE lanes seem to be useless (I've never seen anything > else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE > lane. Without keeping whole struct it would be impossible without > overwriting original entry in array and loosing original info. That's fine for a local hack, but we don't want that upstream. If you are planning to hack all the power tables, then why even use them? I'm not sure we really change the lanes that often if at all on r6xx+. In my experience, a lot of cards lock up when change the lanes or fail to change properly which results in getting stuck at lower numbers of lanes. Alex ------------------------------------------------------------------------------ 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
