All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Pham <quic_jackp@quicinc.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: <linux-usb@vger.kernel.org>,
	Prashant Malani <pmalani@chromium.org>,
	Benson Leung <bleung@google.com>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Badhri Jagan Sridharan <badhri@google.com>,
	Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Subject: Re: [PATCH] usb: typec: ucsi: Only get source PDOs from the actual source
Date: Tue, 2 Nov 2021 00:01:31 -0700	[thread overview]
Message-ID: <20211102070131.GA31877@jackp-linux.qualcomm.com> (raw)
In-Reply-To: <YXqPtNmETT0ZtnKl@kuha.fi.intel.com>

Hi Heikki,

On Thu, Oct 28, 2021 at 02:55:32PM +0300, Heikki Krogerus wrote:
> On Tue, Oct 26, 2021 at 11:48:42PM -0700, Jack Pham wrote:
> > The intent of ucsi_get_src_pdos() is to obtain the source's PDOs
> > in order to provide the power_supply object the required data to
> > report the mininum, maximum and currently operating voltage &
> > current should a PD contract be in place.
> > 
> > If however, the port is operating as a PD source, this call would
> > invoke GET_PDOS on the partner causing the PPM to send a
> > Get_Source_Caps PD message to the port partner which may not make
> > sense especially if the partner is not a dual-power role capable
> > device.  Further, it has been observed that certain DisplayPort
> > adapter cables (which are power sink-only devices) even fail to
> > bring up the display link after receiving a Get_Source_Caps
> > message, suggesting they can't cope well with an unsupported PD
> > message to the point that it renders them functionally inoperable.
> > 
> > Fix this by checking the connector status flags for the power
> > direction and use this to decide whether to send the GET_PDOs
> > query to the partner or the port.  This also helps to make the
> > power_supply VOLTAGE_{MIN,MAX,NOW} and CURRENT_{MAX,NOW}
> > properties more consistent when the port is in source mode.
> > 
> > Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
> > ---
> > Hi Heikki,
> > 
> > Was wrestling with how exactly to do this.  The other approach I was
> > thinking was to not even do GET_PDOs at all if operating as a source,
> > but that would also mean we'd need to add similar checking to the
> > VOLTAGE/CURRENT property getters in psy.c so that they would not
> > return incorrect/stale data.  Since the ONLINE property will already
> > be 0 anyway it may make more sense to invalidate the rest of the props?
> > 
> > The patch below is concise though...so that's what I went with ;)
> 
> Would it still make sense / help if we had separate power supplies
> registered for the port-source, port-sink, partner-source and
> partner-sink?

The name "power_supply" of the class to me implies a source :). So I
can see perhaps having separate port-source and partner-source supplies
making sense; they would effectively be mutually exclusive as only one
of the pair would be "online" at a time when a partner is present
depending on the power direction.

But I'm not sure I see a use for having port-sink/partner-sink objects
though.  While the VOLTAGE_NOW / CURRENT_NOW properties might be
redundantly reporting the same value from corresponding -source objects,
would there be different MIN/MAX values which are obtained from
Get_Sink_Caps?

> I also think we need to unify these power supplies so that tcpm and
> ucsi (and others) always register the same power supplies.

I like that idea too!

Thanks,
Jack

  reply	other threads:[~2021-11-02  7:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  6:48 [PATCH] usb: typec: ucsi: Only get source PDOs from the actual source Jack Pham
2021-10-28 11:55 ` Heikki Krogerus
2021-11-02  7:01   ` Jack Pham [this message]
2021-11-02  8:04     ` Heikki Krogerus

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=20211102070131.GA31877@jackp-linux.qualcomm.com \
    --to=quic_jackp@quicinc.com \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=badhri@google.com \
    --cc=bleung@google.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=pmalani@chromium.org \
    --cc=quic_subbaram@quicinc.com \
    /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.