From owner-freebsd-current@FreeBSD.ORG Tue Feb 26 18:53:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB0D7968; Tue, 26 Feb 2013 18:53:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98E4218DC; Tue, 26 Feb 2013 18:53:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 124A5B958; Tue, 26 Feb 2013 13:53:03 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Tue, 26 Feb 2013 13:46:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> In-Reply-To: <512C380D.5030506@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302261346.46197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 26 Feb 2013 13:53:03 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:53:03 -0000 On Monday, February 25, 2013 11:20:29 pm matt wrote: > On 02/25/13 18:33, Adrian Chadd wrote: > > [101232] acpi_video0: on vgapci0 > > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > > > And what do I do with acpi_get_handle ? > > > > > > > > > I threw printfs into acpi_video, not sure if that would work for both > vgapci or not. > I'm not sure if I wiped out my debug patches yet, I may have a patch. > Basically the idea is to figure out which paths in the DSDT are getting > attached to the vgapci devices. devinfo -v already tells you that. For example: nexus0 acpi0 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 class=0x060000 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1 pci1 vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 subdevice=0xc973 class=0x030000 at slot=0 function=0 (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the vgapci device, but you can see how it displays the handle for other PCI devices like pcib1 which are in the ACPI namespace.) > It seems like we could either try to find these paths on affected > models, or have a tunable override for acpi_video. Note that the Linux discussion you posted seems a bit off. The _ADR is not supposed to be unique to the entire system. For PCI devices, _ADR contains the PCI device (slot) and function (as slot << 16 | func), and the domain:bus portion of the address is implied by the parent PCI bus device in the ACPI namespace. Thus, the specific handle assigned by ACPI is for the exact PCI location of the requisite vgapci device. If your BIOS lies it is hard for us to do anything useful, at least automatically. Do the other devices in your system that have _DOD or _DOS methods show up as unknown ACPI devices in your devinfo -v output? -- John Baldwin