No PNP0CA0 device on a Dell Precision 5520 laptop

Hi,

I just not getting ucsi_acpi to bind on this laptop.
There just is no PNP0CA0 device. Any idea about what I am doing wrong?

cat /sys/bus/acpi/devices/USBC000\:00/status

Am Dienstag, den 11.02.2020, 15:59 +0200 schrieb Heikki Krogerus:

Quoted 1 line

cat /sys/bus/acpi/devices/USBC000\:00/status

Technically -ENODEV. It does not exist, even in a listing. But this thing definitely has a type C port. It is connected to a docking station which supplies the whole system with power. Ethernet also works.

Quoted 7 lines

Am Dienstag, den 11.02.2020, 15:59 +0200 schrieb Heikki Krogerus:

Quoted 1 line

cat /sys/bus/acpi/devices/USBC000\:00/status

Technically -ENODEV. It does not exist, even in a listing. But this thing definitely has a type C port. It is connected to a docking station which supplies the whole system with power. Ethernet also works.

There is still no requirement for the BIOS or the EC firmware to expose UCSI to the operating system. If the ACPI node is not there, then there is no UCSI on that system. The USB Type-C connectors function autonomously in any case on a system that exposes them to the operating system with UCSI. UCSI is more like an optional status interface that allows limited control over some specific things like role swapping.

UCSI is usually supported when the USB Power Delivery (USB PD) controllers are connected to the Embedded Controller on the system, but on some of our platforms they are directly connected to the SOC instead. So on those platforms we can directly communicate with the USB PD controller from the operating system, which is actually much better situation compared to UCSI IMO.

Do you have this ACPI node: INT3515 ?

It's for the TI TPS6598x USB PD controllers.

Am Dienstag, den 11.02.2020, 16:28 +0200 schrieb Heikki Krogerus:

Quoted 24 lines · Oliver Neukum

Quoted 7 lines

Am Dienstag, den 11.02.2020, 15:59 +0200 schrieb Heikki Krogerus:

Quoted 1 line

cat /sys/bus/acpi/devices/USBC000\:00/status

Technically -ENODEV. It does not exist, even in a listing. But this thing definitely has a type C port. It is connected to a docking station which supplies the whole system with power. Ethernet also works.

There is still no requirement for the BIOS or the EC firmware to expose UCSI to the operating system. If the ACPI node is not there, then there is no UCSI on that system. The USB Type-C connectors function autonomously in any case on a system that exposes them to the operating system with UCSI. UCSI is more like an optional status interface that allows limited control over some specific things like role swapping.

UCSI is usually supported when the USB Power Delivery (USB PD) controllers are connected to the Embedded Controller on the system, but on some of our platforms they are directly connected to the SOC instead. So on those platforms we can directly communicate with the USB PD controller from the operating system, which is actually much better situation compared to UCSI IMO.

Quoted 3 lines

Do you have this ACPI node: INT3515 ?

It's for the TI TPS6598x USB PD controllers.

Hi,

yes I got that one. Thanks for the tip.

Quoted 7 lines

Quoted 3 lines

Do you have this ACPI node: INT3515 ?

It's for the TI TPS6598x USB PD controllers.

Hi,

yes I got that one. Thanks for the tip.

OK, cool! Let me know if the tps6598x.c driver works with that.

Quoted 4 lines

Quoted 2 lines

yes I got that one. Thanks for the tip.

OK, cool! Let me know if the tps6598x.c driver works with that.

thanks,

Am Dienstag, den 11.02.2020, 16:44 +0200 schrieb Heikki Krogerus:

Quoted 9 lines · Oliver Neukum

Quoted 4 lines

Quoted 2 lines

yes I got that one. Thanks for the tip.

OK, cool! Let me know if the tps6598x.c driver works with that.

thanks,

Sorry for my earlier rather short report. It turns out that even i2c_multi_instantiate does not load. A bit of debugging points to rather inexplicable ACPI code:

        Device (UCM1)
        {
            Name (_HID, "INT3515")  // _HID: Hardware ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (SBFB, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0038, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PCI0.I2C0",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Name (SBFI, ResourceTemplate ()
                {
                    Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, _Y28)
                    {
                        0x00000000,
                    }
                })
                CreateDWordField (SBFI, \_SB.PCI0.I2C0.UCM1._CRS._Y28._INT, GINT)  // _INT: Interrupts
                GINT = INUM (UCG1)
                Return (ConcatenateResTemplate (SBFB, SBFI))
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((UCSI == One))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }

And indeed 'status' is 0 in sysfs. I am puzzled. I can see no sense in that unless I am supposed to use ucsi_acpi but there is no node for that.

Quoted 40 lines

Am Dienstag, den 11.02.2020, 16:44 +0200 schrieb Heikki Krogerus:

        Device (UCM1)
        {
            Name (_HID, "INT3515")  // _HID: Hardware ID
            Name (_UID, Zero)  // _UID: Unique ID
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (SBFB, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0038, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PCI0.I2C0",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Name (SBFI, ResourceTemplate ()
                {
                    Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, _Y28)
                    {
                        0x00000000,
                    }
                })
                CreateDWordField (SBFI, \_SB.PCI0.I2C0.UCM1._CRS._Y28._INT, GINT)  // _INT: Interrupts
                GINT = INUM (UCG1)
                Return (ConcatenateResTemplate (SBFB, SBFI))
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((UCSI == One))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }

Quoted 2 lines

And indeed 'status' is 0 in sysfs. I am puzzled. I can see no sense in that unless I am supposed to use ucsi_acpi but there is no node for that.

The "UCSI" in that condition is just a variable name. It does not actually have anything to do with the actual UCSI interface.

It looks to me like the operating system is not even made aware of the connectors on that laptop. That is fairly common unfortunately.

The connectors will work, the firmware takes care of everything, but they are simply not visible to the operating system. There is of course also no way to for example swap the roles, or do anything else.

Do you have this ACPI node: INT3515 ?

It's for the TI TPS6598x USB PD controllers.