Re: Asus PN62S vs PN50 - ITE8708

[Chris McCrae <chrismccraeworks@gmail.com>]

Thanks for answering the call Sean.

On Mon, 3 May 2021 at 05:20, Sean Young <sean@mess.org> 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