On Tue, 4 May 2021 at 05:03, Sean Young <sean@xxxxxxxx> wrote: > > 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? > I could send dmesg output, but aside from the fact that it's almost 1000 lines, I have just had a moderate degree of success. Using the pci=noacpi kernel option, gives me: [ 1.767176] ite_cir: Auto-detected model: ITE8708 CIR transceiver [ 1.767177] ite_cir: Using model: ITE8708 CIR transceiver [ 1.767178] ite_cir: TX-capable: 1 [ 1.767179] ite_cir: Sample period (ns): 8680 [ 1.767180] ite_cir: TX carrier frequency (Hz): 38000 [ 1.767180] ite_cir: TX duty cycle (%): 33 [ 1.767181] ite_cir: RX low carrier frequency (Hz): 0 [ 1.767182] ite_cir: RX high carrier frequency (Hz): 0 [ 1.840766] rc rc0: ITE8708 CIR transceiver as /devices/virtual/rc/rc0 [ 1.840842] rc rc0: lirc_dev: driver ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter [ 1.840881] input: ITE8708 CIR transceiver as /devices/virtual/rc/rc0/input3 [ 1.844915] ite_cir: driver has been successfully loaded So after a couple of weeks, I should be happier, right? Never seen any of these lines before. I am happy that there's progress, but some things still aren't right. 1. The kernel option will be used to focus my debugging efforts. At least this seems to support the idea that ACPI plays a role in this. I was beginning to lose faith in that idea. 2. Since the device seems to be recognized by the system, I thought I'd take a quick stab at seeing if it recognized a remote. No matter the protocol, the remote, or distance, neither ir-keytable or ir-ctl (thanks for that tool!) wanted to register any signals. So far I'm chalking that up to the previous point. Maybe it's possible that communication is still hampered, even though the device can be identified. Sort out PCI, and maybe things start rolling. I know the receiver works, since I confirmed that with a test install of Windows 10 early on in this process. Thanks for taking the time Sean. I know you've got a lot of other things on the go, so I really do appreciate it. > > > 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
