From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 13:44:10 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B467916A4CE for ; Thu, 11 Dec 2003 13:44:10 -0800 (PST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C4443D29 for ; Thu, 11 Dec 2003 13:44:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 28088 invoked from network); 11 Dec 2003 21:44:08 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Dec 2003 21:44:08 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id hBBLi51S012577; Thu, 11 Dec 2003 16:44:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031211125356.V50668@root.org> Date: Thu, 11 Dec 2003 16:44:07 -0500 (EST) From: John Baldwin To: Nate Lawson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: RE: Common device driver classes? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 21:44:10 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/