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: > > > > 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@xxxxxxxxxx Chromium OS Project bleung@xxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
