Date: Thu, 11 Dec 2003 13:09:31 -0800 (PST) From: Nate Lawson <nate@root.org> To: arch@freebsd.org Subject: Common device driver classes? Message-ID: <20031211125356.V50668@root.org>
next in thread | raw e-mail | index | archive | help
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?
-Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031211125356.V50668>