From owner-p4-projects@FreeBSD.ORG Thu May 13 14:51:58 2004 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 30D7016A4D1; Thu, 13 May 2004 14:51:58 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73E116A4CE for ; Thu, 13 May 2004 14:51:57 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C496D43D4C for ; Thu, 13 May 2004 14:51:56 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 91591 invoked by uid 1000); 13 May 2004 21:51:58 -0000 Date: Thu, 13 May 2004 14:51:58 -0700 (PDT) From: Nate Lawson To: Takanori Watanabe In-Reply-To: <200405130157.i4D1vPSA020480@sana.init-main.com> Message-ID: <20040513144346.W91362@root.org> References: <200405130157.i4D1vPSA020480@sana.init-main.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: perforce@freebsd.org cc: jhb@freebsd.org Subject: Re: PERFORCE change 52156 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2004 21:51:59 -0000 On Thu, 13 May 2004, Takanori Watanabe wrote: > In message <20040512174010.L85042@root.org>, Nate Lawson wrote: > >You bring up a problem that I've been having also. When I commit the ACPI > >performance states driver, it needs to be able to get an ACPI handle. My > >solution to this is to have multiple drivers with the same name. Only the > >acpi one will supply a handle to the processor object. > >legacy mode: > >legacy0 > > cpu0 (implemented in legacy.c) > > speedstep0 > > > >acpi mode: > >acpi0 > > cpu0 (implemented in acpi_cpu.c) > > acpi_perf0 > > speedstep0 > > > >In the legacy case, acpi_perf's probe method will be called but it will > >return ENXIO because the non-acpi cpu0 will always return NULL for the > >ACPI_HANDLE ivar. It's kind of lame because it requires two different > >drivers to implement the same ivars but it's the only way I could figure > >out to allow both non-acpi and acpi-based cpufreq drivers attach. > > In this case, pci1 and its children know ACPI handle, if > ACPI vga extension is appeard in the name space tree. > You will see this by devinfo(8) with -v option. So the > role of video0 driver is manage child drivers. > All request may forwarded to the grand parent. I guess I haven't looked closely enough at acpi_pci.c. So it calls child probe based on _ADR data in child ACPI objects via WalkNamespace? Does it then call normal pci config register probe for devices that don't appear in the acpi namespace? > >> >There is DPMS on Sparc, for example, although I don't know how it is > >> >implemented. > >> > >> Should we have to imprement machine independent in-kernel VM86 > >> by emulating real mode x86? This will be needed for especially > >> amd64/ia32e, which inherits many assets from ia32. > > > >I thought DPMS on sparc was through openfirmware or some other non-x86 > >device. > > XFree86 has x86 emulator to use vga bios for initializing in other > archtecture. Ah, interesting. I hope we don't have to go this far in FreeBSD. It would be important to talk to Nicholas Souchu. http://people.freebsd.org/~nsouch/kgi4BSD/content-home.html -Nate