Thanks for answering the call Sean. On Mon, 3 May 2021 at 05:20, Sean Young <sean@xxxxxxxx> wrote: > > Hi Chris, > > On Fri, Apr 30, 2021 at 07:37:10PM -0400, Chris McCrae wrote: > > Recently acquired an Asus PN62S (Intel) as a media centre frontend > > (currently testing with Xubuntu 20.04 and a 5.10 kernel, and the most > > current BIOS available). Having an integrated IR was part of the > > selling features. However, getting it to be recognized by my system > > has become a challenge that I am getting obsessed with. There's very > > little to find online on this device that is current, but there has > > been some recent conversation on this list about the same device, on a > > related machine, the PN50 (AMD). I'm hoping that the knowledge here > > may lead to a solution for my issue. > > > > I can provide more detail on request, but at the moment I am focusing > > on the DSDT as a possible suspect. I do not have the 16 byte issue > > that the PN50 experiences. Mine is defined as 8 bytes, which is > > compatible with the ite-cir driver. My issue is that there appears to > > be no attempt to bind the device to the driver (but it is visible in > > lsmod)... no messages about the driver in dmesg at all. My thought is > > that the definition of the device in DSDT may somehow give it enough > > information (ITE8708) to know the driver could be needed, but not the > > correct information to make it work. > > > > An earlier message provided only part of the device definition in DSDT > > for the PN50. I would like to be able to see the full definition for > > it from the PN50, to see if anything is significantly different. > > Ideally, if I had the full DSDT as a starting point, I could compare > > other areas such as motherboard resources. > > It would be great if we could see the entries for the IR device in your > DSDT. There is a guide here https://wiki.archlinux.org/title/DSDT on > how to do that. > Here the full device from the DSDT: 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 */ } } > Thanks > > Sean I've been using the latest ACPI Spec (6.3) to better comprehend the macros, and what they should produce. Running the DSDT through acpiexec for \_SB.PCI0.CR00._CRS gives: - execute \_SB.PCI0.CR00._CRS Evaluating \_SB.PCI0.CR00._CRS 0x1 Outstanding allocations after evaluation of \_SB.PCI0.CR00._CRS Evaluation of \_SB.PCI0.CR00._CRS returned object 0x562c4e9a9c90, external buffer length 28 [Buffer] Length 10 = 0000: 47 01 80 06 80 06 01 08 22 00 04 2A 00 00 79 00 // G......."..*..y. I'm still a little unclear on the first byte (47) and the last two (79 00), generated presumably by ResourceTemplate(), but the rest seem to match the expected results based on the inputs. Aside from the obvious difference in the address range length compared to the PN50's BUF0, which seems to be the PN50's problem, the definition of BUF0 is consistent. I've even recompiled the DSDT with a length of 0x10 just to see if that made a difference, and it doesn't. Still no sign of the driver in dmesg. Although it would be nice to see the full CR00 definition for the PN50, it seems less likely that the problem lies here. I've tried various acpi kernel debugging settings, but easily get swamped with output. Is there a process path somewhere that can be followed to understand how the device goes through the ACPI process and eventually gets picked up by the kernel? I still feel like the problem precedes the kernel's involvement. The kernel obviously has some degree of awareness of the DSDT entry, because I can find : /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ITE8708:00/ The status is correct (0x0F), but under the physical_node, I have no 'resources' entry. Should there be one? I have a 'resource' file, but it only returns zeroes. And instead of being linked to ite_cir (which is showing in lsmod, but not used by anything), the driver -> ../../../bus/pci/drivers/skl_uncore To me, that seems like it's processing what it has been presented, but I've been wrong before. I'm open for directions on where to investigate next. Thanks, Chris
