On Thursday, March 07, 2013 9:13:38 pm matt wrote:
> 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, 0x0002) // _ADR: Address
> >>> Method (_DOS, 1, NotSerialized) // _DOS: Disable
Output Switching
> >>> Method (_DOD, 0, NotSerialized) // _DOD: Display
Output Devices
> >>> Device (PEG)
> >>> Name (_ADR, 0x0001) // _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=0x06 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=0x03 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
