Hi Chris, On Mon, May 03, 2021 at 11:44:04AM -0400, Chris McCrae wrote: > 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 */ > } > } Hmm this is not really telling us everything yet. Would you mind sending on the entire dmesg please? > > 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. This does _sound_ like an acpi issue, I've cc'ed linux-acpi@xxxxxxxxxxxxxxx. > 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. This is not something I can help with, I'm afraid. Thanks, Sean
