On Sun, 2009-08-23 at 01:02 +0300, Maxim Levitsky wrote:
> On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> > On Saturday 22 August 2009, Maxim Levitsky wrote:
> > > Hi,
> > >
> > > <joke>
> > > This should be brought to a Microsoft antitrust case...
> > > </joke>
> > >
> > >
> > > Today many notebooks ship with a embedded infrared receiver.
> > > In Vista there is new subsystem that decodes these signals.
> > > (of course it works only with Microsoft Certificated Remotes (TM)...)
> > >
> > > The receiver is usually presented to system as a pnp device
> > > (using acpi tables)
> > >
> > > It turns out that some bioses actually use the OSI, ACPI feature of the
> > > operation system to detect if running inside Vista. If not they disable
> > > the infrared receiver.
>
> Just one note. At least I am now sure that OSI("Windows 2006") does
> return true by default.
>
> I have tried booting here with acpi_osi="!Windows 2006", and actually
> the CIR PNP device disappeared. I guess that _STA that returns zero
> causes that.
>
> On his laptop, ENE0100 device doesn't disappear, but still someone
> writes zero to LPCB.IOR2 (we checked and found out that it was zero)
>
> Maybe its zero by default, but some 'magic' driver in windows sets it
> up, but this is a PCI config register on LPC bridge, (0x88) and I am
> almost sure that nobody except bios knows about it.
>
> Windows IR driver doesn't touch it for sure.
>
> So, it could be that _STA is once called before the _SB._INI ?
We have just tested, and it turns out that on boot, the device is
unlocked. So it must ACPI
I have put a printk very early in kernel initialization, and it proved
that CIR io range is accessible, before acpi initialization.
Best regards,
Maxim Levitsky
> Best regards,
> Maxim Levitsky
>
> >
> > Oh well.
> >
> > That should've been Cced to linux-acpi (now added). I'm looking forward to
> > seeng a comment from Len.
> Sorry....
> >
> > > On my system this it is still tolerable:
> > >
> > > Device (MIR)
> > > {
> > > Name (_HID, EisaId ("ENE0100"))
> > > Method (_STA, 0, NotSerialized)
> > > {
> > > If (LGreaterEqual (OSYS, 0x07D6))
> > > {
> > > If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
> > > {
> > > Return (0x00)
> > > }
> > > Else
> > > {
> > > Return (0x0F)
> > > }
> > > }
> > > Else
> > > {
> > > Return (0x00)
> > > }
> > > }
> > >
> > > But not so, on Mairo's system:
> > >
> > > Device (MIR)
> > > {
> > > Name (_HID, EisaId ("ENE0100"))
> > > Method (_STA, 0, NotSerialized)
> > > {
> > > If (LAnd (MCIR, LEqual (OSYS, 0x07D6)))
> > > {
> > > Return (0x0F)
> > > }
> > > Else
> > > {
> > > Store (Zero, ^^LPCB.IOR2)
> > > Return (Zero)
> > > }
> > > }
> > >
> > > .......
> > >
> > > Method (_WAK, 1, NotSerialized)
> > > {
> > > .......
> > > If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> > > {
> > > Store (Zero, \_SB.PCI0.LPCB.IOR2)
> > > }
> > >
> > >
> > > .....
> > >
> > > Scope (_SB)
> > > {
> > > Method (_INI, 0, NotSerialized)
> > > {
> > > If (DTSE)
> > > {
> > > TRAP (0x47)
> > > }
> > >
> > > Store (0x07D0, OSYS)
> > > If (CondRefOf (_OSI, Local0))
> > > {
> > > If (_OSI ("Linux"))
> > > {
> > > Store (One, LINX)
> > > Store (Zero, ECDY)
> > > }
> > >
> > > If (_OSI ("Windows 2001"))
> > > {
> > > Store (0x07D1, OSYS)
> > > }
> > >
> > > If (_OSI ("Windows 2001 SP1"))
> > > {
> > > Store (0x07D1, OSYS)
> > > }
> > >
> > > If (_OSI ("Windows 2001 SP2"))
> > > {
> > > Store (0x07D2, OSYS)
> > > }
> > >
> > > If (_OSI ("Windows 2006"))
> > > {
> > > Store (0x07D6, OSYS)
> > > }
> > >
> > > If (LEqual (TPMV, One))
> > > {
> > > If (LLessEqual (OSYS, 0x07D2))
> > > {
> > > TRAP (0x49)
> > > }
> > > }
> > > }
> > >
> > > If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> > > {
> > > TRAP (0x3D)
> > > }
> > >
> > > TRAP (0x2B)
> > > }
> > > }
> > >
> > > We have tried to boot the system with acpi_osi="Windows 2006", but it
> > > didn't help (kernel log confirmed that this parameter was set)
> > >
> > > The only explanation I think of is ether his laptop is whitelisted on
> > > osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> > > or that acpi_osi isn't yet in charge when _SB._INI is called.
> > >
> > >
> > > The kernel in question is quite recent kernel, (2.6.30.5 from debian
> > > unstable).
> > >
> > >
> > > The only way I managed to 'enable' this device is to
> > > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > >
> > > Or in other words undo the damage done by these ACPI commands.
> > >
> > > Mairo, can you boot the system with acpi=off, and then poke the cir IO
> > > range (0x700-0x703) ?
> >
> > Best,
> > Rafael
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
