Hi,
This message stems from a longer conversation started in linux-media.
I thought I'd shorten that story, and just get more to the point.
After a couple weeks of investigating, and a steep learning curve,
I've decided my issue is the definition of the integrated CIR in DSDT.
As originally written, the kernel does not correctly detect this
device, and the correct driver does not bind. It creates folders in
/sys, but the device gets connected to skl_uncore. Setting pci=noacpi
allowed the driver to connect properly, but obviously opened the door
for other issues.
By changing _ADR from Zero to any other number (I've tested 0x01 to
0x0F, and they all work), the driver is properly loaded. Booting from
a custom DSDT solves my problem. However, I'd like to help other
people avoid this problem altogether by providing this fix to Asus,
which will hopefully make it into a future revision. So this leads me
to why I'm posting here, asking people who know far more about this
than I do:
1. While this fix seems to solve the problem, is it possible that
_ADR should be Zero, and something else has the wrong address? PCI
bridge, PNP, motherboard resources ... these are all areas my
debugging took me, and my understanding of these inner workings is
still not solid enough for me to confidently say the device is wrong,
and everything else is fine. Are there other areas to
check/test/debug? I could just tell Asus that this works for me and
let them figure out if it's the right fix, but since I've come this
far, part of me wants to be sure this is the correct solution, and
understand why.
2. This seems much less likely, but Is it possible that DSDT is fine,
and something on the kernel side has an issue? I was never able to
trace when the kernel gets the data and makes the driver decision ...
too many kernel options, not enough buffer space :-(
3. Is there a practical way to provide a technical issue like this to
Asus? I could try the basic support email address, but I don't know
if something like this would get passed on correctly, or ignored.
Since people here have likely encountered this sort of thing before, a
more direct approach might be known. Maybe someone here works for
Asus ... in which case you'll be happy to know my PII motherboard
(P2L97) still works if I need Windows 98 for anything :-)
I can provide lots more info if needed. Thanks.
Chris
Device (CR00)
{
Name (_ADR, Zero) // _ADR: Address
Name (VBAN, 0x0680)
Name (VIRQ, 0x0A)
Name (UIDN, Zero)
Name (_HID, EisaId ("ITE8708")) // _HID: Hardware ID
Method (_UID, 0, NotSerialized) // _UID: Unique ID
{
Return (UIDN) /* \_SB_.PCI0.CR00.UIDN */
}
Method (_STA, 0, Serialized) // _STA: Status
{
If ((CIRE == Zero))
{
Return (Zero)
}
Return (0x0F)
}
Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings
{
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0000, // Range Minimum
0x0000, // Range Maximum
0x01, // Alignment
0x08, // Length
_Y10)
IRQNoFlags (_Y11)
{}
DMA (Compatibility, NotBusMaster, Transfer8, )
{}
})
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MIN,
IOPL) // _MIN: Minimum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y10._MAX,
IOPH) // _MAX: Maximum Base Address
CreateWordField (BUF0, \_SB.PCI0.CR00._CRS._Y11._INT, IRQ)
// _INT: Interrupts
IOPL = VBAN /* \_SB_.PCI0.CR00.VBAN */
IOPH = VBAN /* \_SB_.PCI0.CR00.VBAN */
IRQ = (One << VIRQ) /* \_SB_.PCI0.CR00.VIRQ */
Return (BUF0) /* \_SB_.PCI0.CR00._CRS.BUF0 */
}
}
