Message-ID: <DB9PR10MB46525E6CA4C6BB101059D93C80DC9@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>
Date:   Thu, 16 Sep 2021 14:12:23 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Benson Leung <bleung@...gle.com>
CC:     Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        Prashant Malani <pmalani@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "bleung@...omium.org" <bleung@...omium.org>,
        "badhri@...gle.com" <badhri@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sebastian Reichel <sre@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>
Subject: RE: [RFC PATCH 2/3] power: supply: Add support for PDOs props

On 16 September 2021 11:23, Heikki Krogerus wrote:

> > 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?)
> 
> Yes, exactly.
> 
> > 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 don't yet, but I'll prepare something. I did notice already that the
> power supply class does not seem to display the suppliers nor
> supplicants in sysfs. But we can always improve the class.
> 
> I probable should not talk about "hierarchy". Maybe taking about
> simply "chain" of power supplies is more correct?
> 
> > 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?
> 
> My idea is to utilise the "present" property with the ports. You would
> always display all the possible supplies, but only the ones that you
> expose in your current capabilities will be present.
> 
> The idea is also that the ports are always supplied by normal power
> supplies of type "battery", "AC" and what have you. Those you can use
> to see the maximum power your port can get, and to determine the
> currently available power by checking the other ports that consume the
> same supply.
> 
> So if you need more power for one port, you most likely will need to
> attempt to adjust the power levels of the source PDO power supplies of
> the other ports that share the base supply (like battery), or possibly
> disable them, and that way enable (make present) more source supplies
> for your port. That is the idea, but I admit I have not thought of
> everything, so I'm not completely sure would it work exactly like
> that, but the power balancing should in any case be possible with the
> chain of power supplies one way or the other.
> 
> I hope I understood your question correctly, and I hope I was able to
> give you an answer :-)

Thanks for the additional updates. So is the intention here to move control of
PDO selection away from TCPM, or add more flexibility to it? As I understand it
from previous efforts around all of this, the intention was that TCPM makes the
decision as to which PDO to select (and which APDO for PPS) based on the offered
capabilities of the source and the sink capabilities which are described in FW.
Am just trying to envisage the use-cases here and how the kernel/user is
involved in selecting PDOs/voltages/currents.

IIRC there used to be functions for updating source/sink capabilities but these
never had users and were subsequently removed. I guess this would be essentially
the functional replacement for those APIs?

Personally, I think the idea of source/sink PSY instances supplying each other
seems reasonable. Right now we represent the external PD/Type-C supply (partner)
through TCPM as a PSY instance which is always present for the associated port,
although obviously when no source partner exists we're marked as offline. For
the partner side I'm guessing the PSY instance will be dynamically
created/destroyed? From previous experience PSY classes have tended to be
statically included so would be interested in seeing what this looks like in
reality.

Am still unsure on using PSY to expose individual PDOs though and this still
feels quite heavyweight. I assume we're not wanting to expose everything in PDOs
really, just the voltage/current info? Feels like we should be able to do this
with individual properties which a user can be notified of changes to through
the normal prop notifier, rather than a collection of PSY class instances.
However, I'm happy to be convinced the other way so will await further
details. :)

Powered by blists - more mailing lists