On Tue, Aug 29, 2023 at 02:42:29PM -0400, Douglas Gilbert wrote:
> On 2023-08-28 05:21, Heikki Krogerus wrote:
> > On Thu, Aug 24, 2023 at 12:51:04PM -0400, Douglas Gilbert wrote:
> > > On 2023-08-23 04:56, Heikki Krogerus wrote:
> > > > Hi Douglas,
> > > >
> > > > On Tue, Aug 22, 2023 at 10:52:12AM -0400, Douglas Gilbert wrote:
> > > > > On 2023-08-22 09:32, Heikki Krogerus wrote:
> > > > > On a related matter, I wonder why there aren't symlinks between typec ports
> > > > > (under /sys/class/typec ) and/or the corresponding pd objects (under
> > > > > /sys/class/usb_power_delivery ) to the related power_supply objects under
> > > > > /sys/class/power_supply . For example under the latter directory I see:
> > > > > $ ls | more
> > > > > AC
> > > > > BAT0
> > > > > hidpp_battery_1
> > > > > ucsi-source-psy-USBC000:001
> > > > > ucsi-source-psy-USBC000:002
> > > > >
> > > > > Those last two power supplies are obviously connected to typec port0 and port1
> > > > > (but offset by 1). Those power_supply objects hold inaccurate data which I hope
> > > > > will improve in time. Significantly power_supply objects don't seem to report
> > > > > the direction of the power. Here is a little utility I have been working on
> > > > > to report the USB Type-C port/pd disposition on my machine:
> > > > > $ lsucpd
> > > > > port0 [pd0] > {5V, 0.9A}
> > > > > port1 [pd1] <<=== partner: [pd8]
> > > > >
> > > > > My laptop (Thinkpad X13 G3) has two type-C ports and port1 is a sink with a
> > > > > PD contract. I would like that second line to have 20V, 3.25A appended to it
> > > > > but there are several issues:
> > > > > - no typec or pd symlink to ucsi-source-psy-USBC000:002
> > > > > - that power supply_object says it is online (correct) with a voltage_now:
> > > > > 5000000 uV (incorrect) and current_now: 3000000 uA (incorrect). See below.
> > > > >
> > > > > ucsi-source-psy-USBC000:002 $ ls_name_value
> > > > > current_max : 3250000
> > > > > current_now : 3000000
> > > > > online : 1
> > > > > scope : Unknown
> > > > > type : USB
> > > > > uevent : <removed>
> > > > > usb_type : C [PD] PD_PPS
> > > > > voltage_max : 20000000
> > > > > voltage_min : 5000000
> > > > > voltage_now : 5000000
> > > >
> > > > I'm glad you brought that up. The major problem with the Type-C power
> > > > supplies is that the Type-C connector class does not actually take
> > > > care of them. They are all registered by the device drivers, and all
> > > > of them seem to expose different kind of information. In your case the
> > > > power supplies are registered by the UCSI driver, and the above may
> > > > indicate a bug in that driver.
> > >
> > > Hi,
> > > Thanks for the background.
> > >
> > > My X13 Gen 3 (i5-1240P) uses the typec_ucsi and ucsi_acpi modules. Some time
> > > back in a post you explained how to use debugfs with ucsi. Following that
> > > procedure, just after a 20 Volt PD contract is negotiated on port 0 I see:
> > >
> > > # cat /sys/kernel/debug/tracing/trace
> > > ....
> > > kworker/0:1-18718 [000] ..... 137813.407189: ucsi_connector_change:
> > > port0 status: change=0000, opmode=5, connected=1, sourcing=0,
> > > partner_flags=1, partner_type=1,
> > > request_data_obj=1304b12c, BC status=1
> > >
> > > That RDO is incorrect, the top nibble (1) is the index of the default Vsafe5v
> > > PDO. The correct PDO index would be 4 in this case. The source is an Apple 140W
> > > USB-C power adapter so I doubt that it is breaking any PD 3.0/3.1 protocol
> > > rules.
> >
> > The driver reads the RDO from the UCSI interface, so if it's wrong,
> > there is possibly a problem in the Embedded Controller firmware :-(.
> >
> > > According the a PD analyzer (km002c) only one Request is sent by the sink:
> > > 82 10 d6 59 87 43 which it decodes as "Pos: 4 Fixed: 20V, 4.7A" which is
> > > Accepted and 200 ms later a PS RDY is sent by the source and Vbus
> > > transitions from from 5.17 Volts to 20.4 Volts. So I can see no Request for
> > > PDO index 1 being sent.
> > >
> > > With acpi_listen the following traffic occurs just after the power adapter
> > > is plugged into port 0:
> > > battery PNP0C0A:00 00000080 00000001
> > > battery PNP0C0A:00 00000080 00000001
> > > ibm/hotkey LEN0268:00 00000080 00006032
> > > ac_adapter ACPI0003:00 00000080 00000001
> > > ac_adapter ACPI0003:00 00000080 00000001
> > > ibm/hotkey LEN0268:00 00000080 00006030
> > > thermal_zone LNXTHERM:00 00000081 00000000
> > > ibm/hotkey LEN0268:00 00000080 00006030
> > > thermal_zone LNXTHERM:00 00000081 00000000
> > >
> > > Hope this helps if you find time to look at this.
> >
> > Thank you. I'll try to reproduce the issue this week, but I don't have
> > that exact model of Thinkpad available I'm afraid (UCSI tends to
> > behave a little bit differently on every single platform).
>
> Could it be a CPU generation thing? My CPU is 12th generation (2022) and
> there is another report of a Lenovo P15gen2 (11th generation 2021 I assume)
> not reporting PDOs at all. I have an older Dell XPS 9380 which has an 8th
> generation CPU (3 USB-C port and no Type A ports) that has no UCSI support.
> So do PDOs and the active RDO get properly reported on 13th generation
> CPUs?
Probable not. It really depends on the embedded controller or PD
controller firmware, so ultimately the platform and product.
It could be that the reference embedded controller firmware from Intel
is only patched ones for every CPU generation (I don't know), but for
example Dell does not use Intel's reference embedded controller
firmware, or they at least patch it heavily for every product, so the
CPU gen should not play a huge role there.
Now some (most?) USB PD controllers also support UCSI natively, so the
EC firmware may be just a proxy between the OS and the PD controller.
The PD controller can be anything regardless of the CPU generation,
and theare are several vendors, and on top of that, the PD controller
firmwares may be customised for every single product line.
thanks,
--
heikki
