Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Dec 2003 16:21:19 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        nate@root.org
Cc:        arch@freebsd.org
Subject:   Re: Common device driver classes?
Message-ID:  <20031211.162119.128604849.imp@bsdimp.com>
In-Reply-To: <20031211145311.Q51054@root.org>
References:  <XFMail.20031211164407.jhb@FreeBSD.org> <20031211145311.Q51054@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20031211145311.Q51054@root.org>
            Nate Lawson <nate@root.org> writes:
: This leaves my second question, which is how to make multiple hw-dependent
: drivers that implement the same interface (sysctls) such that if one
: probes ok, others of the same "type" don't attach.  For instance, there
: are multiple ways to control the Centrino -- both SpeedStep and ACPI
: performance states.  However, if the speedstep driver has attached, it
: should supersede the ACPI driver since it offers more hw-aware control.

acpi driver's probe returns -100, speedstep returns -10.  attach
routine does the dynamic sysctl creation, detach does the destroy.
Only one of the attach routines will get called.  This is exactly the
same as the pci and the acpi pci goo.

: So each CPU should have exactly one cpufreq driver attached and the one
: that provides the best control.  Warner suggested making a bus driver for
: cpufreq that attaches to the "winner" of the probe and provides the
: generic interface like this:

cpu freq bus not needed, since all the frequency things would attach
to a cpu.

: Is that how miibus works?  Is that an appropriate approach here?  

Yes and I don't think so.  miibus has lots of upstream attachments,
which isn't the case here.

: One
: issue is that other systems in the kernel will need a generic way to
: control the cpu.  For instance, passive cooling by acpi_thermal needs to
: be able to use the cpufreq0 interface (through devclass_get_device) to
: find what clock rates are available and adjust the clock rate without
: caring about the underlying hardware.  Advice on the above approach is
: welcome.

Sounds like a .m interface to me, but your milage may vary.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031211.162119.128604849.imp>