Re: CPU local things [was Re: Nested suspends; messages vs. states]

[Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On Thu, Mar 24, 2005 at 07:59:21AM -0800, Patrick Mochel wrote:
> 
> On Thu, 24 Mar 2005, Pavel Machek wrote:
> 
> > Hi!
> >
> > > > Just for clarity's sake, what are you thinking should happen to MTRR
> > > > support?
> > >
> > > 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?


> > 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

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]