From owner-freebsd-current@FreeBSD.ORG Sat Mar 2 01:36:53 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 63ACE48B; Sat, 2 Mar 2013 01:36:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by mx1.freebsd.org (Postfix) with ESMTP id E51A8167; Sat, 2 Mar 2013 01:36:52 +0000 (UTC) Received: by mail-da0-f46.google.com with SMTP id z8so1664781dad.19 for ; Fri, 01 Mar 2013 17:36:46 -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=WINdfxl1BDHFpdoQjwESYbHPe/rOzpSWMepdfeFmUfU=; b=t6IkzkKZonWPFi0dbh36Z0gShCMT+zNh8cepZ70Bd7ny8UPSZgWw0R1WWhPRzxAUvw bQg11znj9C/mlV2KChGjhULdi3pdSyewy6cVyReNs03k7VT45cMw5StnxtvrUvhxQz2c QZEQ6I/1JGuAZFPBytRxU0bAhiXExOE11uOlUd8XrSwDdbLoTDtwtq6RptuvA08kmuZ4 iR7fBNuzy0BEq0TaL2iBVFIEp/F5MRsHHwj/AfEwOTWoIdN3RzNEO5Zs+DQUDHD2ptN6 t2GEkHrBSLw8X8txrHqwbsHQwG89jbeB2oL9YSTYMVC+LNlIwJ0LHpOKYe+bHLD5/mvM SKnQ== X-Received: by 10.66.151.226 with SMTP id ut2mr21489306pab.53.1362188206527; Fri, 01 Mar 2013 17:36:46 -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 hs8sm13757378pbc.27.2013.03.01.17.36.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 17:36:45 -0800 (PST) Message-ID: <5131576E.2080403@gmail.com> Date: Fri, 01 Mar 2013 17:35:42 -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> <201302271527.37079.jhb@freebsd.org> <512F5882.7080004@gmail.com> <201302281209.45170.jhb@freebsd.org> In-Reply-To: <201302281209.45170.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 02 Mar 2013 01:36:53 -0000 On 02/28/13 09:09, John Baldwin wrote: > On Thursday, February 28, 2013 8:15:46 am matt wrote: >> On 02/27/13 12:27, John Baldwin wrote: >>> On Wednesday, February 27, 2013 1:35:43 pm matt wrote: >>>> On 02/27/13 09:00, John Baldwin wrote: >>>>> If that is true, it's because your BIOS is lying. Do you have a URL to >>>>> your ASL lying around already? >>>> Too big for pastebin :( +500k >>>> >>>> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing >>> Here is where I find _DOD and _DOS methods: >>> >>> Device (PCI0) >>> Device (VID) >>> Name (_ADR, 0x00020000) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> Device (PEG) >>> Name (_ADR, 0x00010000) // _ADR: Address >>> Device (VID) >>> Name (_ADR, 0x00) // _ADR: Address >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching >>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices >>> >>> PCI0.VID is a PCI device at pci0:0:2:0. >>> PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0. >>> It would have a child device at 0:0 that would be PCI0.PEG.VID. Does the X220 >>> have a switchable GPU (e.g. it has built-in Intel graphics, but also has an >>> Nvidia GPU or some such?). If so, I imagine that PCI0.VID is the Intel graphics >>> and PEG is the non-Intel. The output of 'pciconf -lcv' would be useful to determine >>> that. If both PCI devices exist you shoudl have both acpi_video0 and acpi_video1. >>> However, it may be that the acpi_video driver doesn't cope well with having multiple >>> devices. >> Only Intel graphics, there is no option for switchable graphics. >> I initially thought that PEG was for Optimus usage, and left in the bios >> by accident (i.e. Lenovo using a generic DSDT for many machines) >> >> Here is pciconf -lcf, truncated >> hostb0@pci0:0:0:0: class=0x060000 card=0x21da17aa chip=0x01048086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family DRAM Controller' >> class = bridge >> subclass = HOST-PCI >> cap 09[e0] = vendor (length 12) Intel cap 0 version 1 >> vgapci0@pci0:0:2:0: class=0x030000 card=0x21da17aa chip=0x01268086 >> rev=0x09 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '2nd Generation Core Processor Family Integrated >> Graphics Controller' >> class = display >> subclass = VGA >> cap 05[90] = MSI supports 1 message enabled with 1 message >> cap 01[d0] = powerspec 2 supports D0 D3 current D0 >> cap 13[a4] = PCI Advanced Features: FLR TP >> none0@pci0:0:22:0: class=0x078000 card=0x21da17aa chip=0x1c3a8086 >> rev=0x04 hdr=0x00 >> vendor = 'Intel Corporation' >> >> As you can see there is no device at pci0:0:1:0. So no dev_t with for >> acpi_video to probe or attach to. >> >> Nonetheless, only PEGs ACPI methods work, which is quite broken. This is >> true for a large number of Lenovo devices, back to x61 (non-attaching >> AGP adr) and probably including some other x series and t series. >> >> Unfortunately the ASL will not compile which makes fixing the DSDT an >> exercise in fixing broken ACPI. >> >> What I find interesting is that as far as I can tell, there's no special >> case handling for this device in Linux, yet backlight controls work out >> of the box since about 3.0. Installing Linux as the OSI via loader.conf >> is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows >> 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs >> _BCM... :( >> >> Is Linux getting this to work by doing it wrong, essentially? > Yes. I think the best way to fix this is to add a way to specify a > hint to override the ACPI path associated with a PCI device. Something > like: > > hw.pci0.0.2.0.handle="\_SB_.PCI0.PEG.VID" > > I think this patch should do the trick: > > Index: sys/dev/acpica/acpi_pci.c > =================================================================== > --- acpi_pci.c (revision 247320) > +++ acpi_pci.c (working copy) > @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le > return_ACPI_STATUS (AE_OK); > } > > +static void > +acpi_pci_override_handles(device_t dev) > +{ > + struct acpi_pci_devinfo *dinfo; > + device_t *devlist; > + int error, i, numdevs; > + char tunable_name[64], *path; > + ACPI_HANDLE handle; > + > + error = device_get_children(dev, &devlist, &numdevs); > + if (error) > + return; > + for (i = 0; i < numdevs; i++) { > + dinfo = device_get_ivars(devlist[i]); > + snprintf(tunable_name, sizeof(tunable_name), > + "hw.pci%d.%d.%d.%d.handle", dinfo->ap_dinfo.cfg.domain, > + dinfo->ap_dinfo.cfg.bus, dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func); > + path = getenv(tunable_name); > + if (path == NULL) > + continue; > + if (ACPI_SUCCESS(AcpiGetHandle(NULL, path, &handle))) { > + device_printf(dev, > + "Forcing device at %d.%d to use path %s\n", > + dinfo->ap_dinfo.cfg.slot, > + dinfo->ap_dinfo.cfg.func, path); > + dinfo->ap_handle = handle; > + acpi_pci_update_device(handle, devlist[i]); > + } > + freeenv(path); > + } > + free(devlist, M_TEMP); > +} > + > static int > acpi_pci_probe(device_t dev) > { > @@ -306,5 +340,10 @@ acpi_pci_attach(device_t dev) > AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, > acpi_pci_save_handle, NULL, dev, NULL); > > + /* > + * Perform another pass over child devices to allow their > + * handles to be overridden via a hint from the user. > + */ > + acpi_pci_override_handles(dev); > return (bus_generic_attach(dev)); > } > > Initial attempt with this patch failed to change the result in devinfo -rv...I will hopefully have more info tonight. Thanks, Matt