All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benson Leung <bleung@google.com>
To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Prashant Malani <pmalani@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"bleung@chromium.org" <bleung@chromium.org>,
	"badhri@google.com" <badhri@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sebastian Reichel <sre@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [RFC PATCH 2/3] power: supply: Add support for PDOs props
Date: Mon, 13 Sep 2021 12:30:58 -0700	[thread overview]
Message-ID: <YT+m8jr8Ehe3R55G@google.com> (raw)
In-Reply-To: <DB9PR10MB4652B4A6A2A2157018307AE380D99@DB9PR10MB4652.EURPRD10.PROD.OUTLOOK.COM>

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

Hi Adam and Heikki,

On Mon, Sep 13, 2021 at 03:15:46PM +0000, Adam Thomson wrote:
> On 13 September 2021 14:30, Heikki Krogerus wrote:
> >
> > My plan is to register a separate power supply for each PDO. So for
> > every source PDO and every sink PDO a port has in its capabilities,
> > you'll have a separate power supply registered, and the same for the
> > partner when it's connected. With every connection there should always
> > be one active (online) source psy and active sink psy (if the port is
> > source, one of the port's source psys will be active and the partner
> > will have the active sink psy, or vise versa - depending on the role).
> >
> > Each PDO represents a "Power Supply" so to me that approach just
> > makes the most sense. It will require a bit of work in kernel, however
> > in user space it should mean that we only have a single new attribute
> > file for the power supplies named "pdo" that returns a single PDO.
> >
> > Let me know if you guys see any obvious problems with the idea.
> > Otherwise, that is how we really need to do this. That will make
> > things much more clear in user space. I have a feeling it will make
> > things easier in kernel as well in the long run.
> >
> > Adding Adam and Guenter. It would be good if you guys could comment
> > the idea as well.
> 
> 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 thought of one more potential downside to one-psy-per-pdo:

Remember that a source or sink's Capabilities may dynamically change without
a port disconnect, and this could make one-psy-per-pdo much more chatty with
power supply deletions and re-registrations on load balancing events.

At basically any time, a power source may send a new SRC_CAP to the sink which
adjusts, deletes, or adds to the list of PDOs, without the connection state
machine registering a disconnect.

In a real world case, I have a charger in my kitchen that has 2 USB-C ports
and supports a total of 30W output. When one device is plugged in:
5V 3A, 9V 3A, 15V 2A
However, when two devices are plugged in, each sees:
5V 3A

The load balancing event would result in two power supply deletions, whereas
if it were a single psy per power supply (incorporating the list of PDO choices)
it would just be a single PROP_CHANGED event.

It seems cleaner to me to have deletions and additions only possible when the
thing is unplugged or plugged.

Thanks,
Benson

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2021-09-13 19:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 21:34 [RFC PATCH 0/3] Type C partner power supply and PDO support Prashant Malani
2021-09-02 21:34 ` [RFC PATCH 1/3] usb: pd: Increase max PDO objects to 13 Prashant Malani
2021-09-03  6:47   ` Jack Pham
2021-09-03 18:05     ` Jack Pham
2021-09-07 21:36       ` Prashant Malani
2021-09-07 23:28     ` Benson Leung
2021-09-09 17:37       ` Jack Pham
2021-09-02 21:35 ` [RFC PATCH 2/3] power: supply: Add support for PDOs props Prashant Malani
2021-09-13 13:30   ` Heikki Krogerus
2021-09-13 15:15     ` Adam Thomson
2021-09-13 19:30       ` Benson Leung [this message]
2021-09-14 10:28         ` Heikki Krogerus
2021-09-14 10:14       ` Heikki Krogerus
2021-09-16  7:22         ` Benson Leung
2021-09-16 10:23           ` Heikki Krogerus
2021-09-16 14:12             ` Adam Thomson
2021-09-16 16:16               ` Badhri Jagan Sridharan
2021-09-20 13:20                 ` Rajaram R
2021-09-22 10:40                   ` Heikki Krogerus
2021-09-21 10:53               ` Heikki Krogerus
2021-09-24 15:38                 ` Adam Thomson
2021-10-07 22:32                   ` Prashant Malani
2021-10-08 11:09                     ` Heikki Krogerus
2021-10-11 23:05                       ` Prashant Malani
2021-10-12 10:42                       ` Adam Thomson
2021-09-13 17:40     ` Benson Leung
2021-09-14 11:04       ` Heikki Krogerus
2021-09-02 21:35 ` [RFC PATCH 3/3] usb: typec: Add partner power registration call Prashant Malani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YT+m8jr8Ehe3R55G@google.com \
    --to=bleung@google.com \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=badhri@google.com \
    --cc=bleung@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmalani@chromium.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.