Hi Heikki,

On Tue, Sep 14, 2021 at 01:14:02PM +0300, Heikki Krogerus wrote:

Mon, Sep 13, 2021 at 03:15:46PM +0000, Adam Thomson kirjoitti:

quoted

Hi Heikki,

Thanks for CCing me. My two pence worth is that I always envisaged the PSY
representation as being 1 PSY for 1 power source. I consider this in a
similar manner to the Regulator framework, where 1 regulator can support a range
of voltages and currents, but this is covered by 1 regulator instance as it's
just a single output. For USB-PD we have a number of options for voltage/current
combos, including PPS which is even lower granularity, but it's still only one
port. I get the feeling that having PSY instances for each and every PDO might
be a little confusing and these will never be concurrent.

However, I'd be keen to understand further and see what restrictions/issues are
currently present as I probably don't have a complete view of this right now. I
wouldn't want to dismiss something out of turn, especially when you obviously
have good reason to suggest such an approach.

I'm not proposing that we drop the port-psys. I'm sorry if I've been
unclear about that. The port-psy we can not drop because of several
reasons. For starters, we still can not assume that USB PD is always
supported.

What I'm trying to propose is that we take advantage of the
power-supply framework by building a "dynamic" hierarchy of power
supplies that supply each other in order to represent the actual
situation as closely as possible. For example, a port-psy that is
supplied by port-Fixed-sink-psy that is supplied by
port-partner-Fixed-source (that is supplied by port-partner-psy).
Something like that. The only "static" part in the hierarchy is the
port-psy, as everything else about it can change, even without
disconnection.

So the port-psy always either supplies another psy or is supplied by
another psy in this hierarchy, depending on the role of the port. But
most importantly, the properties of the port-psy itself are _newer_
adjustable - they are read-only. The psy that supplies the port-psy
can be adjustable, if it's for example PPS, but not the port-psy
itself.

The problem with having only a single psy per port (and possibly
partners) is that it does not work well enough when the capabilities
change, and the capabilities can really change at any moment, we don't
need to disconnect for that to happen - simply by plugging another
device to another port can change the power budget for your port and
change your capabilities. The biggest problem is when we loose the
ability to adjust the values if we for example loose the PPS that we
were using in the middle of operation. The single psy has to attempt
to handle the situation by adjusting something like the ranges of the
properties, because it can't change the actual property set itself.
That is hacky, and to be honest, a little bit risky, because it leaves
us at the mercy of programmers completely unnecessarily.

With my proposal, if the capabilities change, it only means we rebuild
the psy hierarchy, and that's it. Nothing else needs to be done in
kernel, and all changes are super visible and clear in user space.

Thanks for providing the clarification. So you're proposing a port-psy and a
port-partner-psy that are connected to each other (one supplying the other).
If PD is not present, those two will exist per port and partner, and there
will be information about Type-C current (and possibly BC 1.2 and other
methods?)

Do you have an example hierarchy you could share that explains what it would
look like in /sys/class/power_supply with PD with Source Caps and Sink Caps on
both sides?

I think this all makes sense if the connector class is a read interface
for this info. Have you considered how the type-c connector class and this pd
psy support will handle dynamic PDO changes for advertisement FROM the ports?

For example, let's say you wanted the kernel and user to manage two USB-C ports
with higher power support (meaning, 5V, 9V, 15V, 20V capable), but then your
kernel and user needs to edit the Source Caps on the fly based on load
balancing.

If caps are represented as a group of psys together, how do you as a kernel
and user create an modify the set of Source_Caps you put out on a port?

Thanks,
Benson

thanks,

-- 
heikki

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
bleung@google.com
Chromium OS Project
bleung@chromium.org