Asus PN62S vs PN50 - ITE8708

From: Chris McCrae <chrismccraeworks@gmail.com>
To: linux-media@vger.kernel.org
Subject: Asus PN62S vs PN50 - ITE8708
Date: Fri, 30 Apr 2021 19:37:10 -0400	[thread overview]
Message-ID: <CAN2W0iNOsa6GYK28Vz=DmkyjY72H_bq=8EUkzFuy0_p9ZVms4A@mail.gmail.com> (raw)

Long time stalker, first time caller, so go easy please :-)  (I've
already learned I need to use plain text mode ... what's next?)

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.

I have learned a lot about ACPI lately, and am continuing to learn.
In the end, ACPI may have nothing to do with my problem.  If anyone
has other suggestions as to where an issue might originate, I'm ready
to look there too (like when does the kernel make the decision to bind
or not).  I've used acpi.debug_layer and debug_level options, tested
with fwts, recompiled kernels and drivers with patches, rebuilt the
DSDT to force some parameters, installed Windows 10 and confirmed
things actually work, and probably a few other things I can't
remember.

Any help is appreciated.

Chris