Hi Nathan. On Fri, 2005-03-25 at 04:14, Nathan Lynch wrote: > > > > Become more componentized. We need a better way to represent optional > > > > features of any device, but in particular CPUs. We should never be calling > > > > it directly; we should be looping over the feature drivers bound to a 'CPU > > > > Driver' and suspending them. > > > > > > Actually, no. > > > > > > mtrr's are cpu local. That means they need to be handled by CPU > > > hotplug framework. I guess we should just drop them from "normal" > > > device trees, and create something per-CPU. > > > > Sorry, it was late and that explanation sucked. > > > > - Every CPU has a set of optional features that it supports. > > > > - MTRRs are an optional feature that a CPU may support. > > > > - When the MTRR driver is loaded, a data structure should be allocated for > > each CPU and added to a list. > > > > - The list that the per-CPU MTRR data structure is added to could be part > > of a 'CPU driver'. > > > > - We should be looping over the set of optional features that a CPU > > supports to suspend/resume them, rather than calling them directly. > > Don't sysdev_suspend and sysdev_resume do this already? I guess you missed part of the context of this discussion. MTRR sysdev suspend and resume work fine for one CPU, but there's a potential SMP deadlock. For Suspend2, MTRR sysdev support was removed a number of months ago, and tied in to CPU state saving and restoring. This addressed the deadlock, correctly, I believe. Hope this helps. Nigel > > > Perhaps plain old notification list is enough for this one. > > > > It's possible, but notification lists present some problems. Like the fact > > they use a hard-coded set of events in a global header file. They are good > > only for a certain set of events. > > > > It's damn simple to create a struct type for CPU features and a method > > contained in each one for cpu offline/online. I would suggest adding a > > list_head to struct cpu (include/linux/cpu.h) called 'features', then > > having things like MTRR add themselves to that list. > > Why is the existing sysdev auxiliary driver support not sufficient? > Last time I checked, cpufreq uses it for this kind of purpose. > > > Nathan > > ______________________________________________________________________ > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxx > http://lists.osdl.org/mailman/listinfo/linux-pm -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net
