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).
--
heikki
