From: Len Brown <lenb@kernel.org>
To: Graham Adams <gadams@takelap.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: ACPI dmidecode output requested in dmesg output - Dell Dimension 5150
Date: Mon, 21 Jan 2008 21:57:47 -0500 [thread overview]
Message-ID: <200801212157.47125.lenb@kernel.org> (raw)
In-Reply-To: <5aedf440801210928m31840000qed11c986437bd1e9@mail.gmail.com>
On Monday 21 January 2008 12:28, Graham Adams wrote:
> On 1/19/08, Len Brown <lenb@kernel.org> wrote:
> >
> > > Please find attached the output of dmidecode after booting with
> > > acpi_osi=!Linux as requested in dmesg output. The system seems to be
> > > working OK apart from problems with STAC9221 Line In (which has never
> > > worked under Linux).
> >
> > > The system is a Dell Dimension 5150.
> >
> > > System Information
> > > Manufacturer: Dell Inc.
> > > Product Name: Dell DM051
> > > Version: Not Specified
> > > Serial Number: 6X8B32J
> > > UUID: 44454C4C-5800-1038-8042-B6C04F33324A
> > > Wake-up Type: Power Switch
> > >
> > > Handle 0x0200, DMI type 2, 8 bytes
> > > Base Board Information
> > > Manufacturer: Dell Inc.
> > > Product Name: 0WG261
This is "different"....
some magic happens at initialization and at wake from suspend-to-disk
to PCI device 00:1d -- which is apparently USB.
The code reads as if Dell really did intend to do something special for Linux -
at least the version of Linux they were testing...
for non-Linux, ISLI does some SMI magic, for Linux the SMI magic is skipped.
Does USB work properly in both cases, both before and after suspend to disk?
thanks,
-Len
Method (ISLI, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Linux"))
{
Return (One)
}
Else
{
Return (Zero)
}
}
Else
{
Return (Zero)
}
}
...
Method (GUSB, 0, NotSerialized)
{
If (ISLI ()) # the only reference to ISLI is this one
{
Return (Zero)
# return valie of GUSB is ignored,
# so this is the NO-OP path
}
Else
{
Return (SMI2 (0xBA))
}
}
...
# surely this is SMI command/SMI Data method:
# no telling what the actual command 0xBA is, though...
Method (SMI2, 1, NotSerialized)
{
Acquire (SMIM, 0xFFFF)
Store (Arg0, SMIC)
Store (SMIC, Local0)
Store (SMID, Local0)
ShiftLeft (Local0, 0x08, Local0)
Add (SMIC, Local0, Local0)
Release (SMIM)
Return (Local0)
}
...
Method (_WAK, 1, NotSerialized)
{
If (LEqual (Arg0, 0x04))
{
# we come here on wakeup from suspend-to-disk
GUSB ()
}
If (Or (And (PMS2, One), Or (And (LNot (HACK ()),
And (GLBT, 0x11)), And (LNot (HACK ()), And (THRP, 0x18
)))))
{
Notify (\_SB.VBTN, 0x02)
}
Return (Zero)
}
...
Scope (_SB.PCI0)
{
Device (USB0)
{
Name (_ADR, 0x001D0000)
Name (_UID, 0x05)
Name (_PRW, Package (0x02)
{
0x03,
0x03
})
OperationRegion (UPC1, PCI_Config, 0xC1, One)
Field (UPC1, ByteAcc, NoLock, Preserve)
{
LEGK, 8
}
Method (_INI, 0, NotSerialized)
{
If (HACK ()) {}
Else
{
Store (LEGK, Local0)
And (Local0, 0x60, Local0)
Or (Local0, 0x20, Local0)
Store (Local0, LEGK)
}
GUSB ()
}
...
This is different too....
Method (_INI, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Windows 2001"))
{
Store (0x04, MSOS)
# yes, Linux does come here
# MSOS is effectively "XP" or newer
}
}
}
...
Method (HACK, 0, NotSerialized)
{
If (LEqual (MSOS, 0x04))
{
Store (CMRD (0x6F), Local0)
Or (Local0, 0x04, Local0)
CMWR (0x6F, Local0)
# Linux come shere b/c of OSI(Microsoft Windows 2001)
Return (One)
}
Else
{
Store (CMRD (0x6F), Local0)
And (Local0, 0xFB, Local0)
CMWR (0x6F, Local0)
}
Add (SizeOf (_OS), One, Local0)
Store (Local0, Local1)
Name (BUF0, Buffer (Local0) {})
Name (BUF1, Buffer (Local0) {})
Name (OSNT, One)
Name (OS98, One)
Store (_OS, BUF0)
Store ("Microsoft Windows NT", BUF1)
While (Local0)
{
# an in-line strcmp()...
Decrement (Local0)
If (LEqual (DerefOf (Index (BUF0, Local0)), DerefOf (Index (BUF1,
Local0)))) {}
Else
{
Store (Zero, OSNT)
}
}
If (OSNT)
{
Store (0x03, MSOS)
Return (One)
}
Else
{
Store ("Microsoft Windows", BUF1)
While (Local1)
{
Decrement (Local1)
If (LEqual (DerefOf (Index (BUF0, Local1)), DerefOf (Index (BUF1,
Local1)))) {}
Else
{
Store (Zero, OS98)
}
}
If (OS98)
{
Store (One, MSOS)
Return (Zero)
}
Else
{
Store (0x02, MSOS)
Return (Zero)
}
}
}
next prev parent reply other threads:[~2008-01-22 2:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-15 11:04 ACPI dmidecode output requested in dmesg output Graham Adams
[not found] ` <200801182305.48685.lenb@kernel.org>
[not found] ` <5aedf440801210928m31840000qed11c986437bd1e9@mail.gmail.com>
2008-01-22 2:57 ` Len Brown [this message]
[not found] ` <5aedf440801220956h3f99cbffp97c664fdea0ef571@mail.gmail.com>
2008-01-23 5:43 ` ACPI dmidecode output requested in dmesg output - Dell Dimension 5150 Len Brown
[not found] ` <5aedf440801230032m45a9defbs735887c2ea0b302c@mail.gmail.com>
[not found] ` <5aedf440801270507gca2d36cvb7feacaf431453c4@mail.gmail.com>
2008-02-03 22:03 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801212157.47125.lenb@kernel.org \
--to=lenb@kernel.org \
--cc=gadams@takelap.com \
--cc=linux-acpi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.