All of lore.kernel.org
 help / color / mirror / Atom feed
* Asus PN62S - CIR ITE8708 device definition in DSDT
@ 2021-05-07  3:11 Chris McCrae
  0 siblings, 0 replies; only message in thread
From: Chris McCrae @ 2021-05-07  3:11 UTC (permalink / raw)
  To: linux-acpi; +Cc: Sean Young

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 */
        }
    }

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-05-07  3:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-07  3:11 Asus PN62S - CIR ITE8708 device definition in DSDT Chris McCrae

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.