From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 02:33:46 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 9524538C; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D710280; Wed, 27 Feb 2013 02:33:46 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id kq12so112925pab.15 for ; Tue, 26 Feb 2013 18:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8LiL99Bmq+xNM42JSz8TEHPxIx/BMzvsPekUfb/OxSQ=; b=L+K/0iocCn76PA6UsCXnTUfhSLwRqtANzB8Dme6pEQkIg1SjKlBZj6HRT0ErMM5o4W /W6ToTlGtK5QjmgWXJf53+0F78ZnnaDrilz8NvqLPhQvLoM0E+IZAZRnWpnFwLsy4XTE g51+7quBNfKvmNYqEwWp1rc9lPwD06K2e0N6v1tyC/W/hgGWTyDnowL2IxRjzLssPgQa sO+dK+np6ZVgRVxIN3HBzcgtI12QSiVogBJq5DWdnqs48uS3ztkI4EKtXDANp6GYrje6 7OQHghGzCoBc/CTlAx1BTPMgwl+HMM8QLIWzuXGGSQz+Ucos6oTtsu+SrrMVNrzQF3V0 wQwA== X-Received: by 10.66.122.74 with SMTP id lq10mr4902075pab.189.1361932420532; Tue, 26 Feb 2013 18:33:40 -0800 (PST) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id 1sm2845981pbg.18.2013.02.26.18.33.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 18:33:39 -0800 (PST) Message-ID: <512D7041.50608@gmail.com> Date: Tue, 26 Feb 2013 18:32:33 -0800 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130224 Thunderbird/17.0.3 MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing X220 Video The Right Way References: <512A6FFF.2060603@gmail.com> <512C380D.5030506@gmail.com> <201302261346.46197.jhb@freebsd.org> In-Reply-To: <201302261346.46197.jhb@freebsd.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit 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: Wed, 27 Feb 2013 02:33:46 -0000 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. Matt Matt