LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To: Guenter Roeck <linux@roeck-us.net>,
	Badhri Jagan Sridharan <badhri@google.com>,
	Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: "heikki.krogerus@linux.intel.com"
	<heikki.krogerus@linux.intel.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"dan.carpenter@oracle.com" <dan.carpenter@oracle.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/2 v7] typec: tcpm: Only request matching pdos
Date: Tue, 28 Nov 2017 09:31:17 +0000	[thread overview]
Message-ID: <2E89032DDAA8B9408CB92943514A0337014C1B164C@SW-EX-MBX01.diasemi.com> (raw)
In-Reply-To: <7db1c9f5-a621-d2b9-7400-c05ab2ffbb83@roeck-us.net>

On 28 November 2017 02:07, Guenter Roeck wrote:

> On 11/27/2017 05:38 PM, Badhri Jagan Sridharan wrote:
> > On Thu, Nov 23, 2017 at 3:10 AM, Adam Thomson
> > <Adam.Thomson.Opensource@diasemi.com> wrote:
> >> On 16 November 2017 01:02, Badhri Jagan Sridharan wrote:
> >>
> >>> At present, TCPM code assumes that local device supports
> >>> variable/batt pdos and always selects the pdo with highest
> >>> possible power within the board limit. This assumption
> >>> might not hold good for all devices. To overcome this,
> >>> this patch makes TCPM only accept a source_pdo when there is
> >>> a matching sink pdo.
> >>>
> >>> For Fixed pdos: The voltage should match between the
> >>> incoming source_cap and the registered snk_pdo
> >>> For Variable/Batt pdos: The incoming source_cap voltage
> >>> range should fall within the registered snk_pdo's voltage
> >>> range.
> >>>
> >>> Also, when the cap_mismatch bit is set, the max_power/current
> >>> should be set to the max_current/power of the sink_pdo.
> >>> This is according to:
> >>>
> >>> "If the Capability Mismatch bit is set to one
> >>> The Maximum Operating Current/Power field may contain a value
> >>> larger than the maximum current/power offered in the Source
> >>> Capabilities message’s PDO as referenced by the Object position field.
> >>> This enables the Sink to indicate that it requires more current/power
> >>> than is being offered. If the Sink requires a different voltage this
> >>> will be indicated by its Sink Capabilities message.
> >>
> >> Hi Badhri,
> >>
> >> I have some queries on this change. At the moment the src/snk PDOs are hard
> >> coded in the relevant PD controller driver (e.g. fusb302.c), and the only way
> >> to update these is to call the tcpm_update_source_capabilities() or
> >> tcpm_update_sink_capabilities() functions. However there are no real world
> >
> > Good point ! But I dont see any code which calls this either. I believe
> > Guenter added this. Guenter do you know ?
> >
> 
> A source might change its power capabilities dynamically. Practical example is
> a system with two USB-C ports. If one is in use, it may support 3A output power.
> If two are in use, it may support 1.5A each. This isn't currently used in the
> kernel, but some of our devices have this behavior, so I thought it would be
> prudent to have support for it. The same is true for a sink, which may change
> its power requirements at runtime (same situation - a device is inserted at
> the second USB port) and ask for more or less power.
> 
> Is that a problem ? I won't object if you want to take it out because there is
> no current user, but you should keep in mind that those are valid use cases,
> and that the code should at least be extensible (ie the patch taking it away
> should be revertible) to support those use cases.

No, I have no desire to remove it and definitely see the valid use-cases. I was
curious though as to where these functions might be called from within the
kernel as wherever that is it will need to have the ability to retrieve the port
instance to be able to call these functions.

  reply	other threads:[~2017-11-28  9:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  1:01 [PATCH 1/2 v7] typec: tcpm: Validate source and sink caps Badhri Jagan Sridharan
2017-11-16  1:01 ` [PATCH 2/2 v7] typec: tcpm: Only request matching pdos Badhri Jagan Sridharan
2017-11-23 11:10   ` Adam Thomson
2017-11-28  1:38     ` Badhri Jagan Sridharan
2017-11-28  2:06       ` Guenter Roeck
2017-11-28  9:31         ` Adam Thomson [this message]
2017-11-28  9:23       ` Adam Thomson

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=2E89032DDAA8B9408CB92943514A0337014C1B164C@SW-EX-MBX01.diasemi.com \
    --to=adam.thomson.opensource@diasemi.com \
    --cc=badhri@google.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).