From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Subject: Re: [PATCH v3 11/13] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector Date: Wed, 17 Apr 2019 11:52:00 +0200 Message-ID: References: <20190412134122.82903-1-heikki.krogerus@linux.intel.com> <20190412134122.82903-12-heikki.krogerus@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190412134122.82903-12-heikki.krogerus@linux.intel.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Heikki Krogerus , "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Darren Hart , Andy Shevchenko , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Andy Shevchenko List-Id: linux-acpi@vger.kernel.org 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 > Signed-off-by: Heikki Krogerus > --- > 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 > #include > #include > +#include > > #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. 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). Regards, Hans > { } > }; > > @@ -148,6 +170,15 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data *data) > data->node[i] = fwnode; > } > > + /* Node for the USB connector (FUSB302 is the parent) */ > + fwnode = fwnode_create_software_node(usb_connector_props, > + data->node[INT33FE_NODE_FUSB302]); > + if (IS_ERR(fwnode)) { > + ret = PTR_ERR(fwnode); > + goto err_remove_nodes; > + } > + data->node[INT33FE_NODE_USB_CONNECTOR] = fwnode; > + > return 0; > > err_remove_nodes: > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4122C10F12 for ; Wed, 17 Apr 2019 09:52:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E13021773 for ; Wed, 17 Apr 2019 09:52:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728531AbfDQJwF (ORCPT ); Wed, 17 Apr 2019 05:52:05 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:37174 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727013AbfDQJwE (ORCPT ); Wed, 17 Apr 2019 05:52:04 -0400 Received: by mail-ed1-f65.google.com with SMTP id f53so18852395ede.4 for ; Wed, 17 Apr 2019 02:52:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+zT28kDMButlPwZHfCkpmJ/Ssw+TDsJCMi0mgZkOg2Q=; b=lcZUf8LeaFGOxxeCHEzxLQaM/4g98lIWWMt6BipzJe7ux57THNVxGD/1qcYCsRpEiR et+z3vHeG567e5Kr6mauPrrM8penM03Rliqco3FiOqZqdK6tUKui9P6LZb9rmUd9LIkJ tJZH3onQ56mrRbsrHgKcHfbZEwUph/fuiWSSSOAKPpReS1OB5B12MuNAzQ2L4NPqVlHd PUM+JGqoZTR9H2boFItFktlbxql+s6IKbcbd4do2jeUDOQebKIhdNKhMampYiZNzfJAq 1fGoZF2CBROrs/KzIUKmFvsvQEexqlq7LZ6mTidxP94NFTHlus/qTCTdZ543pCO5kf4i 7myA== X-Gm-Message-State: APjAAAUgbEFQ3c2MzKHRHbLSNaCiTd9BTAjEVstIyWMFAsJevpORqyCe wKIbpJH14ZXj/6b6pG7aSjlcsA== X-Google-Smtp-Source: APXvYqxWqx1BXim3osj7InhTfgyiU/TFaZ8oSwxYwGC9hVRHUp26/iX/AIwhfiWLSMBsDRPy0dFkYQ== X-Received: by 2002:a50:9317:: with SMTP id m23mr6204623eda.114.1555494722581; Wed, 17 Apr 2019 02:52:02 -0700 (PDT) Received: from shalem.localdomain (84-106-84-65.cable.dynamic.v4.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id h16sm8082640eja.23.2019.04.17.02.52.01 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 02:52:01 -0700 (PDT) Subject: Re: [PATCH v3 11/13] platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector To: Heikki Krogerus , "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , Darren Hart , Andy Shevchenko , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Andy Shevchenko References: <20190412134122.82903-1-heikki.krogerus@linux.intel.com> <20190412134122.82903-12-heikki.krogerus@linux.intel.com> From: Hans de Goede Message-ID: Date: Wed, 17 Apr 2019 11:52:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190412134122.82903-12-heikki.krogerus@linux.intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Message-ID: <20190417095200.hj2-Yp5FzWuk9quBYCmy0ujUFE_i6M_rlPnAaPpdkS4@z> 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 > Signed-off-by: Heikki Krogerus > --- > 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 > #include > #include > +#include > > #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. 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). Regards, Hans > { } > }; > > @@ -148,6 +170,15 @@ static int cht_int33fe_add_nodes(struct cht_int33fe_data *data) > data->node[i] = fwnode; > } > > + /* Node for the USB connector (FUSB302 is the parent) */ > + fwnode = fwnode_create_software_node(usb_connector_props, > + data->node[INT33FE_NODE_FUSB302]); > + if (IS_ERR(fwnode)) { > + ret = PTR_ERR(fwnode); > + goto err_remove_nodes; > + } > + data->node[INT33FE_NODE_USB_CONNECTOR] = fwnode; > + > return 0; > > err_remove_nodes: >