Common device driver classes?

[John Baldwin]

On 11-Dec-2003 Nate Lawson wrote:
> I'm in the middle of implementing various drivers and all of them have the
> same problem.  I want to have a generic set of functionality that is
> provided in various hardware specific ways.  The two drivers I'm working
> on are a cpu freq driver (hw-specific drivers: speedstep, longrun, acpi
> px, amd64) and a laptop buttons/control driver (hw-specific drivers:
> toshiba, asus, apm).
> 
> Let's take clock frequency manipulation as an example.  There might be a
> sysctl like "hw.cpu.0.freq" that can be set to change the clock frequency.
> The actual transition would be handled by a hardware-specific driver that
> would program the right registers for SpeedStep, for instance.
> 
> The various drivers would also need to set priorities for how they attach.
> For instance, certain drivers may implement subsets of other drivers'
> functionality.  If so, the attach routine would return -100 for the simple
> drivers and 0 for the full-featured ones.  If one driver returns -100 and
> another returns 0, the sysctl function handler should point to the second
> driver and the first should not be called since it has been superseded.
> 
> Since this sounds like newbus, here's an example how this might work:
> 
>     cpubusXXX
>         cpu0
>             cpufreq (speedstep) - hw.cpu.0.freq
>         cpu1
>             cpufreq (acpi performance states) - hw.cpu.1.freq
> 
> Note that cpu0 might also support ACPI performance states but speedstep is
> a more accurate driver for the given hardware.  The user could change the
> frequency for each CPU through a generic sysctl without knowing the
> underlying technology used to make the transition.
> 
> Finally, the probe/attach routines of each driver should be called for
> each logical processor in the system and would then call cpuid or other
> things for that processor to determine what capabilities it has.
> Wouldn't we need a bus layer for CPU drivers to hang off of that was
> filled out by our CPU enumeration?

Yes, you will need some sort of bus layer.  It shouldn't be impossible
to do.  You could have a cpubus that hangs off of root0 (stick it in
kern/subr_smp.c maybe) and then each MD arch could provide a CPU driver
in mp_machdep.c that has an identify routine that adds cpu objects for
each CPU in system to cpubus.  Either that or you could drop cpubus
altogether, and just have cpuX hang directly off of root0, or off of
something like nexus0 if that's what you want to do.  I can do a sample
implementation for i386 that creates cpu drivers and hangs them off of
nexus0 for i386 if you would like.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/