All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v3 11/13] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector
Date: Wed, 8 May 2019 14:30:17 +0300	[thread overview]
Message-ID: <20190508113017.GC19816@kuha.fi.intel.com> (raw)
In-Reply-To: <daed3557-7595-86c5-fde1-6ec048b0935d@redhat.com>

On Wed, Apr 17, 2019 at 11:52:00AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 12-04-19 15:41, Heikki Krogerus wrote:
> > In ACPI, and now also in DT, the USB connectors usually have
> > their own device nodes. In case of USB Type-C, those
> > connector (port) nodes are child nodes of the controller or
> > PHY device, in our case the fusb302. The software fwnodes
> > allow us to create a similar child node for fusb302 that
> > represents the connector also on Intel CHT.
> > 
> > This makes it possible replace the fusb302 specific device
> > properties which were deprecated with the common USB
> > connector properties that tcpm.c is able to use directly.
> > 
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > ---
> >   drivers/platform/x86/intel_cht_int33fe.c | 37 ++++++++++++++++++++++--
> >   1 file changed, 34 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
> > index 863a792d9282..eff5990322ff 100644
> > --- a/drivers/platform/x86/intel_cht_int33fe.c
> > +++ b/drivers/platform/x86/intel_cht_int33fe.c
> > @@ -24,6 +24,7 @@
> >   #include <linux/platform_device.h>
> >   #include <linux/regulator/consumer.h>
> >   #include <linux/slab.h>
> > +#include <linux/usb/pd.h>
> >   #define EXPECTED_PTYPE		4
> > @@ -31,6 +32,7 @@ enum {
> >   	INT33FE_NODE_FUSB302,
> >   	INT33FE_NODE_MAX17047,
> >   	INT33FE_NODE_PI3USB30532,
> > +	INT33FE_NODE_USB_CONNECTOR,
> >   	INT33FE_NODE_MAX,
> >   };
> > @@ -111,9 +113,29 @@ cht_int33fe_register_max17047(struct device *dev, struct cht_int33fe_data *data)
> >   static const struct property_entry fusb302_props[] = {
> >   	PROPERTY_ENTRY_STRING("linux,extcon-name", "cht_wcove_pwrsrc"),
> > -	PROPERTY_ENTRY_U32("fcs,max-sink-microvolt", 12000000),
> > -	PROPERTY_ENTRY_U32("fcs,max-sink-microamp",   3000000),
> > -	PROPERTY_ENTRY_U32("fcs,max-sink-microwatt", 36000000),
> 
> Note that the 36000000 value being removed here is max-sink-microwatt,
> esp. the _max_ part is important. And recent versions of the fusb302
> code ignore this entirely.
> 
> > +	{ }
> > +};
> > +
> > +#define PDO_FIXED_FLAGS \
> > +	(PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP | PDO_FIXED_USB_COMM)
> > +
> > +static const u32 src_pdo[] = {
> > +	PDO_FIXED(5000, 1500, PDO_FIXED_FLAGS),
> > +};
> > +
> > +static const u32 snk_pdo[] = {
> > +	PDO_FIXED(5000, 400, PDO_FIXED_FLAGS),
> > +	PDO_VAR(5000, 12000, 3000),
> > +};
> > +
> > +static const struct property_entry usb_connector_props[] = {
> > +	PROPERTY_ENTRY_STRING("name", "connector"),
> > +	PROPERTY_ENTRY_STRING("data-role", "dual"),
> > +	PROPERTY_ENTRY_STRING("power-role", "dual"),
> > +	PROPERTY_ENTRY_STRING("try-power-role", "sink"),
> > +	PROPERTY_ENTRY_U32_ARRAY("source-pdos", src_pdo),
> > +	PROPERTY_ENTRY_U32_ARRAY("sink-pdos", snk_pdo),
> > +	PROPERTY_ENTRY_U32("op-sink-microwatt", 36000000),
> 
> Where as "op-sink-microwatt" is more interpreted as a minimum
> value for non PPS supplies not being able to deliver this causes
> the Capability Mismatch to get set. But for PPS supplies if I'm
> reading the code correctly, the entire PPS negotiation is failed
> by tcpm.c if this cannot be matched. I guess / hope that there
> is a fallback to none PPS PDOs then but I'm not sure.

OK. I'll change that to the current default value, 2500000.

> Anyways the charger the GPD-win ships with is a non PD capable
> 5V/2A charger and the GPD-pocket ships with a charger which does
> max 12V/2A. The device itself will work fine on around 10W and
> even charge at that level (albeit slowly). So I believe that 10W
> would be a better value for "op-sink-microwatt" (the dt-binding
> says it is mandatory so we cannot just leave it out).

I have no objections. If you prefer, I can include a separate patch
where I change the value to 10W.

thanks,

-- 
heikki

  reply	other threads:[~2019-05-08 11:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 13:41 [PATCH v3 00/13] Software fwnode references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 01/13] software node: Allow node creation without properties Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 02/13] software node: Simplify software_node_release() function Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 03/13] software node: Add support for references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 04/13] software node: Implement .get_reference_args fwnode operation Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 05/13] driver core: Add helper device_find_child_by_name() Heikki Krogerus
2019-04-25 19:46   ` Greg Kroah-Hartman
2019-04-12 13:41 ` [PATCH v3 06/13] ACPI / property: Don't limit named child node matching to data nodes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 07/13] device connection: Find connections also by checking the references Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 08/13] usb: typec: Registering real device entries for the muxes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 09/13] platform/x86: intel_cht_int33fe: Register max17047 in its own function Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 10/13] platform/x86: intel_cht_int33fe: Provide software nodes for the devices Heikki Krogerus
2019-04-12 15:29   ` Andy Shevchenko
2019-04-12 13:41 ` [PATCH v3 11/13] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector Heikki Krogerus
2019-04-17  9:52   ` Hans de Goede
2019-05-08 11:30     ` Heikki Krogerus [this message]
2019-04-12 13:41 ` [PATCH v3 12/13] platform/x86: intel_cht_int33fe: Link with external dependencies using fwnodes Heikki Krogerus
2019-04-12 13:41 ` [PATCH v3 13/13] platform/x86: intel_cht_int33fe: Replacing the old connections with references Heikki Krogerus
2019-04-16 21:35   ` Hans de Goede
2019-04-17  6:39     ` Heikki Krogerus
2019-04-17  9:19       ` Hans de Goede
2019-04-17  9:32         ` Heikki Krogerus
2019-04-17  9:52           ` Hans de Goede
2019-04-17 11:04             ` Heikki Krogerus
2019-04-17 11:15               ` Hans de Goede
2019-04-17 10:15           ` Hans de Goede
2019-04-17 10:44             ` Heikki Krogerus
2019-04-17 16:03               ` Hans de Goede
2019-04-17 16:03                 ` Hans de Goede
2019-05-08 11:28                 ` Heikki Krogerus
2019-04-17 21:14         ` Hans de Goede
2019-04-17 21:14           ` Hans de Goede
2019-05-08 11:40           ` Heikki Krogerus
2019-04-17  7:54 ` [PATCH v3 00/13] Software fwnode references Rafael J. Wysocki
2019-04-17  8:13   ` 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=20190508113017.GC19816@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.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 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.