From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 17:12:51 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1106D9B2; Wed, 27 Feb 2013 17:12:51 +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 D5CB7F77; Wed, 27 Feb 2013 17:12:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3E588B976; Wed, 27 Feb 2013 12:12:50 -0500 (EST) From: John Baldwin To: matt Subject: Re: Fixing X220 Video The Right Way Date: Wed, 27 Feb 2013 12:00:22 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <512A6FFF.2060603@gmail.com> <201302261346.46197.jhb@freebsd.org> <512D7041.50608@gmail.com> In-Reply-To: <512D7041.50608@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201302271200.22976.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 27 Feb 2013 12:12:50 -0500 (EST) Cc: Adrian Chadd , freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:12:51 -0000 On Tuesday, February 26, 2013 9:32:33 pm matt wrote: > On 02/26/13 10:46, John Baldwin wrote: > > 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? > It's not in devinfo at all for me, Adrian may have a different situation. > > So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID > Only _SB.PCI0.VID is represented in devinfo -rv. > As far as I know, PEG is not a "real" device, but an abstraction, > possibly for Optimus use. > It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?) > This is potentially the broken bios part of things. > > I think I have multiple ACPI devices for a single physical device, and > pci is attaching the wrong ACPI device to the physical device in an ivar. > acpi_video happily uses this ivar to attempt to control video brightness. > > I could be entirely wrong on that, all I do know is that the working > handle doesn't get used and the useless handle does. If that is true, it's because your BIOS is lying. Do you have a URL to your ASL lying around already? -- John Baldwin