From owner-freebsd-arch@FreeBSD.ORG Thu Dec 11 15:15:47 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 23B6816A4CE for ; Thu, 11 Dec 2003 15:15:47 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5314343D2D for ; Thu, 11 Dec 2003 15:15:43 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 51107 invoked by uid 1000); 11 Dec 2003 23:15:44 -0000 Date: Thu, 11 Dec 2003 15:15:44 -0800 (PST) From: Nate Lawson To: John Baldwin In-Reply-To: Message-ID: <20031211145311.Q51054@root.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 23:15:47 -0000 On Thu, 11 Dec 2003, John Baldwin wrote: > 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. > > 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. Thanks, that would be nice if you can do that in p4. I agree there's no need to have a cpubus. It would be good to be able to get a pointer to the pcpu data via an ivar in cpu0. Also, it would be good for acpi_cpu0 to set the acpi_handle ivar for its associated cpu0 object. That would make it possible for the cpufreq driver in its probe routine to pull out the acpi_handle for the associated \_PR.CPU0 object and check it for _PSS methods, for instance. Hmm, this part needs some more thought. 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. 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: cpu0 speedset-cpufreq0 cpufreq0 cpu1 acpi-cpufreq0 cpufreq1 Is that how miibus works? Is that an appropriate approach 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. -Nate