Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1723169 > unrolled thread

[PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger

Started byHans de Goede <hdegoede@redhat.com>
First post2017-08-30 11:50 +0200
Last post2017-08-31 18:30 +0200
Articles 11 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger Hans de Goede <hdegoede@redhat.com> - 2017-08-30 11:50 +0200
    [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties Hans de Goede <hdegoede@redhat.com> - 2017-08-30 11:50 +0200
      Re: [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw  from device-properties Guenter Roeck <linux@roeck-us.net> - 2017-08-30 16:00 +0200
    [PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev Hans de Goede <hdegoede@redhat.com> - 2017-08-30 12:00 +0200
      Re: [PATCH v3 07/11] staging: typec: fusb302: Export current-limit  through a power_supply class dev Guenter Roeck <linux@roeck-us.net> - 2017-08-30 16:10 +0200
    [PATCH v3 01/11] i2c: Allow overriding dev_name through board_info Hans de Goede <hdegoede@redhat.com> - 2017-08-30 12:00 +0200
    [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set Hans de Goede <hdegoede@redhat.com> - 2017-08-30 12:00 +0200
      Re: [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq  if set Guenter Roeck <linux@roeck-us.net> - 2017-08-30 16:00 +0200
    [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V Hans de Goede <hdegoede@redhat.com> - 2017-08-30 12:00 +0200
      Re: [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage  to 5V Guenter Roeck <linux@roeck-us.net> - 2017-08-30 15:40 +0200
    Re: [PATCH v3 00/11] Hookup typec power-negotation to the PMIC and  charger Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-31 18:30 +0200

#1723169 — [PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 11:50 +0200
Subject[PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger
Message-ID<uk7Ng-6DT-3@gated-at.bofh.it>
Hi All,

Here is v3 of my typec power-negotation hookup series. New this version:
- Drop a few patches merged into linux-power-supply.git/for-next
- Drop the "power: supply: bq24190_charger: Remove extcon handling"
  patch *for now*, this can only be merged once all the other patches are
  in place (and extcon handling is no longer needed)
- Address some review comments in some of the other patches, see the
  per patch changelogs inside the commit messages

I believe that this series is ready for merging now and I would like to
ask the various subsys maintainers to pick up and merge these patches.
All the patches can be merged independent of eachother with the exception
of the last 2 patches:

i2c-cht-wc: Add device-properties for fusb302 integration
platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

Which should not be merged until all the other patches are in place.

For reference below is the cover letter of v2 of this patch.

Regards,

Hans


v2 series cover letter:

This series implements a number of typec changes discussed a while back:

- It exports the negotiated voltage and max-current in the form of a
  power-supply class device which represents the USB Type-C power-brick
  (adapter/charger)
- It adds a power_supply_set_input_current_limit_from_supplier helper
  function which charger drivers can use to get the max-current from
  their supplier
- It adds regulator support to the charger IC on the device I've. The
  exported regulator controls the 5v boost convertor which generates the
  5V USB vbus which gets output when the Type-C port is in host / power-src
  mode
- It adds a bunch of misc. related fixes and glue code to tie everything
  together

One thing which was undecided in the previous discussion was how to make
port-controller drivers hookup to external ICs (e.g. a non Type-C aware PMIC)
to decect the input-current-limit for USB2 power-sources (through e.g. BC1.2
detection). Since a number of existing drivers, including the one for the
PMIC used on the 2 mini laptops I'm working on, already use the extcon
framework to communicate the detected USB2 charger-type, I've decided to
simply hook into this existing code. As this patch set shows this can be
done with zero changes to the existing PMIC/extcon drivers.

With this series the GPD win and GPD pocket mini laptops both fully
support any type of Type-C charging. When hooked up with:
-A -> C cable and plugged into a regular port they charge at 5V 0.5A
-A -> C cable and plugged into a dedictaed charger they charge at 5V 2A
-C -> C cable and plugged into a fixed 5V 3A charger, at 5V 3A
-C -> C cable and plugged into a PD capable charger, which delivers max 12V, 2A
 they charge at 12V, 2A

And when a Type-C to USB-A receptacle (so host mode) cable gets plugged in
the port correctly supplies 5V to any plugged in USB-A peripherals.

This is v2 of this series, which has the following changes (see
changelog inside individual patches for details):

-Add "i2c: Allow overriding dev_name through board_info" patch, this is
 necessary for getting stable dev_names which are necessary for specifying
 regulator-mappings through regulator_init_data
-Use regulator_init_data to specify mapping,  drop "staging: typec:
 fusb302: Add support for fcs,vbus-regulator-name device-property" patch
-Merged helper code for port-c related extcon / power_supply handling
 directly into the fusb302 patches using the code, rather then trying
 to add generic helpers even though there is only 1 user

[toc] | [next] | [standalone]


#1723170 — [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 11:50 +0200
Subject[PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties
Message-ID<uk7Nh-6DT-31@gated-at.bofh.it>
In reply to#1723169
This is board specific info so it should come from board config, such
as devicetree.

I've chosen to prefix these with "fcs," treating them as fusb302 driver
specific for now. We may want to revisit this and replace these with
properties which are part of a (to be written) generic type-c controller
devicetree binding.

Since this commit adds new dt-properties it also adds devicetree-bindings
documentation (which so far was absent for the fusb302 driver).

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
-Use micro... instead of mili...
-Add devicetree bindings documentation

Changes in v3:
-Use sink rather then snk in property names
-Add Rob's Acked-by
---
 .../devicetree/bindings/usb/fcs,fusb302.txt        | 29 ++++++++++++++++++++++
 drivers/staging/typec/fusb302/TODO                 |  4 +++
 drivers/staging/typec/fusb302/fusb302.c            | 18 +++++++++++++-
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/usb/fcs,fusb302.txt

diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
new file mode 100644
index 000000000000..472facfa5a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -0,0 +1,29 @@
+Fairchild FUSB302 Type-C Port controllers
+
+Required properties :
+- compatible             : "fcs,fusb302"
+- reg                    : I2C slave address
+- interrupts             : Interrupt specifier
+
+Optional properties :
+- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink
+- fcs,max-sink-microamp  : Maximum current to negotiate when configured as sink
+- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink
+			   If this is less then max-sink-microvolt *
+			   max-sink-microamp then the configured current will
+			   be clamped.
+- fcs,operating-sink-microwatt :
+			   Minimum amount of power accepted from a sink
+			   when negotiating
+
+Example:
+
+fusb302: typec-portc@54 {
+	compatible = "fcs,fusb302";
+	reg = <0x54>;
+	interrupt-parent = <&nmi_intc>;
+	interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	fcs,max-sink-microvolt = <12000000>;
+	fcs,max-sink-microamp = <3000000>;
+	fcs,max-sink-microwatt = <36000000>;
+};
diff --git a/drivers/staging/typec/fusb302/TODO b/drivers/staging/typec/fusb302/TODO
index 4933a1d92c32..19b466eb585d 100644
--- a/drivers/staging/typec/fusb302/TODO
+++ b/drivers/staging/typec/fusb302/TODO
@@ -4,3 +4,7 @@ fusb302:
 - Find a non-hacky way to coordinate between PM and I2C access
 - Documentation? The FUSB302 datasheet provides information on the chip to help
   understand the code. But it may still be helpful to have a documentation.
+- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
+  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
+  properties with properties which are part of a generic type-c controller
+  devicetree binding.
diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
index 6baed06a3c0d..1c1751c994db 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -90,6 +90,7 @@ struct fusb302_chip {
 	struct i2c_client *i2c_client;
 	struct tcpm_port *tcpm_port;
 	struct tcpc_dev tcpc_dev;
+	struct tcpc_config tcpc_config;
 
 	struct regulator *vbus;
 
@@ -1198,7 +1199,6 @@ static const struct tcpc_config fusb302_tcpc_config = {
 
 static void init_tcpc_dev(struct tcpc_dev *fusb302_tcpc_dev)
 {
-	fusb302_tcpc_dev->config = &fusb302_tcpc_config;
 	fusb302_tcpc_dev->init = tcpm_init;
 	fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
 	fusb302_tcpc_dev->set_cc = tcpm_set_cc;
@@ -1684,7 +1684,9 @@ static int fusb302_probe(struct i2c_client *client,
 {
 	struct fusb302_chip *chip;
 	struct i2c_adapter *adapter;
+	struct device *dev = &client->dev;
 	int ret = 0;
+	u32 v;
 
 	adapter = to_i2c_adapter(client->dev.parent);
 	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_I2C_BLOCK)) {
@@ -1699,8 +1701,22 @@ static int fusb302_probe(struct i2c_client *client,
 	chip->i2c_client = client;
 	i2c_set_clientdata(client, chip);
 	chip->dev = &client->dev;
+	chip->tcpc_config = fusb302_tcpc_config;
+	chip->tcpc_dev.config = &chip->tcpc_config;
 	mutex_init(&chip->lock);
 
+	if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", &v))
+		chip->tcpc_config.max_snk_mv = v / 1000;
+
+	if (!device_property_read_u32(dev, "fcs,max-sink-microamp", &v))
+		chip->tcpc_config.max_snk_ma = v / 1000;
+
+	if (!device_property_read_u32(dev, "fcs,max-sink-microwatt", &v))
+		chip->tcpc_config.max_snk_mw = v / 1000;
+
+	if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", &v))
+		chip->tcpc_config.operating_snk_mw = v / 1000;
+
 	ret = fusb302_debugfs_init(chip);
 	if (ret < 0)
 		return ret;
-- 
2.13.4

[toc] | [prev] | [next] | [standalone]


#1723354 — Re: [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

FromGuenter Roeck <linux@roeck-us.net>
Date2017-08-30 16:00 +0200
SubjectRe: [PATCH v3 04/11] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties
Message-ID<ukbHc-yr-29@gated-at.bofh.it>
In reply to#1723170
On 08/30/2017 02:48 AM, Hans de Goede wrote:
> This is board specific info so it should come from board config, such
> as devicetree.
> 
> I've chosen to prefix these with "fcs," treating them as fusb302 driver
> specific for now. We may want to revisit this and replace these with
> properties which are part of a (to be written) generic type-c controller
> devicetree binding.
> 
> Since this commit adds new dt-properties it also adds devicetree-bindings
> documentation (which so far was absent for the fusb302 driver).
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: devicetree@vger.kernel.org
> Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Rob Herring <robh@kernel.org>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
> Changes in v2:
> -Use micro... instead of mili...
> -Add devicetree bindings documentation
> 
> Changes in v3:
> -Use sink rather then snk in property names
> -Add Rob's Acked-by
> ---
>   .../devicetree/bindings/usb/fcs,fusb302.txt        | 29 ++++++++++++++++++++++
>   drivers/staging/typec/fusb302/TODO                 |  4 +++
>   drivers/staging/typec/fusb302/fusb302.c            | 18 +++++++++++++-
>   3 files changed, 50 insertions(+), 1 deletion(-)
>   create mode 100644 Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> new file mode 100644
> index 000000000000..472facfa5a71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> @@ -0,0 +1,29 @@
> +Fairchild FUSB302 Type-C Port controllers
> +
> +Required properties :
> +- compatible             : "fcs,fusb302"
> +- reg                    : I2C slave address
> +- interrupts             : Interrupt specifier
> +
> +Optional properties :
> +- fcs,max-sink-microvolt : Maximum voltage to negotiate when configured as sink
> +- fcs,max-sink-microamp  : Maximum current to negotiate when configured as sink
> +- fcs,max-sink-microwatt : Maximum power to negotiate when configured as sink
> +			   If this is less then max-sink-microvolt *
> +			   max-sink-microamp then the configured current will
> +			   be clamped.
> +- fcs,operating-sink-microwatt :
> +			   Minimum amount of power accepted from a sink
> +			   when negotiating
> +
> +Example:
> +
> +fusb302: typec-portc@54 {
> +	compatible = "fcs,fusb302";
> +	reg = <0x54>;
> +	interrupt-parent = <&nmi_intc>;
> +	interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +	fcs,max-sink-microvolt = <12000000>;
> +	fcs,max-sink-microamp = <3000000>;
> +	fcs,max-sink-microwatt = <36000000>;
> +};
> diff --git a/drivers/staging/typec/fusb302/TODO b/drivers/staging/typec/fusb302/TODO
> index 4933a1d92c32..19b466eb585d 100644
> --- a/drivers/staging/typec/fusb302/TODO
> +++ b/drivers/staging/typec/fusb302/TODO
> @@ -4,3 +4,7 @@ fusb302:
>   - Find a non-hacky way to coordinate between PM and I2C access
>   - Documentation? The FUSB302 datasheet provides information on the chip to help
>     understand the code. But it may still be helpful to have a documentation.
> +- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
> +  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
> +  properties with properties which are part of a generic type-c controller
> +  devicetree binding.
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 6baed06a3c0d..1c1751c994db 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -90,6 +90,7 @@ struct fusb302_chip {
>   	struct i2c_client *i2c_client;
>   	struct tcpm_port *tcpm_port;
>   	struct tcpc_dev tcpc_dev;
> +	struct tcpc_config tcpc_config;
>   
>   	struct regulator *vbus;
>   
> @@ -1198,7 +1199,6 @@ static const struct tcpc_config fusb302_tcpc_config = {
>   
>   static void init_tcpc_dev(struct tcpc_dev *fusb302_tcpc_dev)
>   {
> -	fusb302_tcpc_dev->config = &fusb302_tcpc_config;
>   	fusb302_tcpc_dev->init = tcpm_init;
>   	fusb302_tcpc_dev->get_vbus = tcpm_get_vbus;
>   	fusb302_tcpc_dev->set_cc = tcpm_set_cc;
> @@ -1684,7 +1684,9 @@ static int fusb302_probe(struct i2c_client *client,
>   {
>   	struct fusb302_chip *chip;
>   	struct i2c_adapter *adapter;
> +	struct device *dev = &client->dev;
>   	int ret = 0;
> +	u32 v;
>   
>   	adapter = to_i2c_adapter(client->dev.parent);
>   	if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_I2C_BLOCK)) {
> @@ -1699,8 +1701,22 @@ static int fusb302_probe(struct i2c_client *client,
>   	chip->i2c_client = client;
>   	i2c_set_clientdata(client, chip);
>   	chip->dev = &client->dev;
> +	chip->tcpc_config = fusb302_tcpc_config;
> +	chip->tcpc_dev.config = &chip->tcpc_config;
>   	mutex_init(&chip->lock);
>   
> +	if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", &v))
> +		chip->tcpc_config.max_snk_mv = v / 1000;
> +
> +	if (!device_property_read_u32(dev, "fcs,max-sink-microamp", &v))
> +		chip->tcpc_config.max_snk_ma = v / 1000;
> +
> +	if (!device_property_read_u32(dev, "fcs,max-sink-microwatt", &v))
> +		chip->tcpc_config.max_snk_mw = v / 1000;
> +
> +	if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", &v))
> +		chip->tcpc_config.operating_snk_mw = v / 1000;
> +
>   	ret = fusb302_debugfs_init(chip);
>   	if (ret < 0)
>   		return ret;
> 

[toc] | [prev] | [next] | [standalone]


#1723171 — [PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 12:00 +0200
Subject[PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev
Message-ID<uk7WW-6Hb-5@gated-at.bofh.it>
In reply to#1723169
The fusb302 Type-C port-controller cannot control the current-limit
directly, so we need to exported the limit so that another driver
(e.g. the charger driver) can pick the limit up and configure the
system accordingly.

The power-supply subsys already provides infrastructure for this,
power-supply devices have the notion of being supplied by another
power-supply and have properties through which we can export the
current-limit.

Register a power_supply and export the current-limit through the
power_supply's current-max property.

Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Put the psy class device code directly in fusb302.c rather then introducing
 helpers which are only used by fusb302.c
-Add an online property to the psy so that upower does not mistake it for a
 second battery in the system
---
 drivers/staging/typec/fusb302/Kconfig   |  2 +-
 drivers/staging/typec/fusb302/fusb302.c | 63 +++++++++++++++++++++++++++++++--
 2 files changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/Kconfig b/drivers/staging/typec/fusb302/Kconfig
index fce099ff39fe..48a4f2fcee03 100644
--- a/drivers/staging/typec/fusb302/Kconfig
+++ b/drivers/staging/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
 config TYPEC_FUSB302
 	tristate "Fairchild FUSB302 Type-C chip driver"
-	depends on I2C
+	depends on I2C && POWER_SUPPLY
 	help
 	  The Fairchild FUSB302 Type-C chip driver that works with
 	  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
index 6f007f66d597..cf6355f59cd9 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -28,6 +28,7 @@
 #include <linux/of_device.h>
 #include <linux/of_gpio.h>
 #include <linux/pinctrl/consumer.h>
+#include <linux/power_supply.h>
 #include <linux/proc_fs.h>
 #include <linux/regulator/consumer.h>
 #include <linux/sched/clock.h>
@@ -108,6 +109,11 @@ struct fusb302_chip {
 	/* lock for sharing chip states */
 	struct mutex lock;
 
+	/* psy + psy status */
+	struct power_supply *psy;
+	u32 current_limit;
+	u32 supply_voltage;
+
 	/* chip status */
 	enum toggling_mode toggling_mode;
 	enum src_current_status src_current_status;
@@ -876,11 +882,13 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, bool charge)
 		chip->vbus_on = on;
 		fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
 	}
-	if (chip->charge_on == charge)
+	if (chip->charge_on == charge) {
 		fusb302_log(chip, "charge is already %s",
 			    charge ? "On" : "Off");
-	else
+	} else {
 		chip->charge_on = charge;
+		power_supply_changed(chip->psy);
+	}
 
 done:
 	mutex_unlock(&chip->lock);
@@ -896,6 +904,11 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, u32 max_ma, u32 mv)
 	fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
 		    max_ma, mv);
 
+	chip->supply_voltage = mv;
+	chip->current_limit = max_ma;
+
+	power_supply_changed(chip->psy);
+
 	return 0;
 }
 
@@ -1681,6 +1694,43 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int fusb302_psy_get_property(struct power_supply *psy,
+				    enum power_supply_property psp,
+				    union power_supply_propval *val)
+{
+	struct fusb302_chip *chip = power_supply_get_drvdata(psy);
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_ONLINE:
+		val->intval = chip->charge_on;
+		break;
+	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+		val->intval = chip->supply_voltage * 1000; /* mV -> µV */
+		break;
+	case POWER_SUPPLY_PROP_CURRENT_MAX:
+		val->intval = chip->current_limit * 1000; /* mA -> µA */
+		break;
+	default:
+		return -ENODATA;
+	}
+
+	return 0;
+}
+
+static enum power_supply_property fusb302_psy_properties[] = {
+	POWER_SUPPLY_PROP_ONLINE,
+	POWER_SUPPLY_PROP_VOLTAGE_NOW,
+	POWER_SUPPLY_PROP_CURRENT_MAX,
+};
+
+const struct power_supply_desc fusb302_psy_desc = {
+	.name		= "fusb302-typec-source",
+	.type		= POWER_SUPPLY_TYPE_USB_TYPE_C,
+	.properties	= fusb302_psy_properties,
+	.num_properties	= ARRAY_SIZE(fusb302_psy_properties),
+	.get_property	= fusb302_psy_get_property,
+};
+
 static int init_gpio(struct fusb302_chip *chip)
 {
 	struct device_node *node;
@@ -1720,6 +1770,7 @@ static int fusb302_probe(struct i2c_client *client,
 	struct fusb302_chip *chip;
 	struct i2c_adapter *adapter;
 	struct device *dev = &client->dev;
+	struct power_supply_config cfg = {};
 	const char *name;
 	int ret = 0;
 	u32 v;
@@ -1766,6 +1817,14 @@ static int fusb302_probe(struct i2c_client *client,
 			return -EPROBE_DEFER;
 	}
 
+	cfg.drv_data = chip;
+	chip->psy = devm_power_supply_register(dev, &fusb302_psy_desc, &cfg);
+	if (IS_ERR(chip->psy)) {
+		ret = PTR_ERR(chip->psy);
+		dev_err(chip->dev, "Error registering power-supply: %d\n", ret);
+		return ret;
+	}
+
 	ret = fusb302_debugfs_init(chip);
 	if (ret < 0)
 		return ret;
-- 
2.13.4

[toc] | [prev] | [next] | [standalone]


#1723368 — Re: [PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev

FromGuenter Roeck <linux@roeck-us.net>
Date2017-08-30 16:10 +0200
SubjectRe: [PATCH v3 07/11] staging: typec: fusb302: Export current-limit through a power_supply class dev
Message-ID<ukbQT-R3-41@gated-at.bofh.it>
In reply to#1723171
On 08/30/2017 02:48 AM, Hans de Goede wrote:
> The fusb302 Type-C port-controller cannot control the current-limit
> directly, so we need to exported the limit so that another driver
> (e.g. the charger driver) can pick the limit up and configure the
> system accordingly.
> 
> The power-supply subsys already provides infrastructure for this,
> power-supply devices have the notion of being supplied by another
> power-supply and have properties through which we can export the
> current-limit.
> 
> Register a power_supply and export the current-limit through the
> power_supply's current-max property.
> 
> Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
> Changes in v2:
> -Put the psy class device code directly in fusb302.c rather then introducing
>   helpers which are only used by fusb302.c
> -Add an online property to the psy so that upower does not mistake it for a
>   second battery in the system
> ---
>   drivers/staging/typec/fusb302/Kconfig   |  2 +-
>   drivers/staging/typec/fusb302/fusb302.c | 63 +++++++++++++++++++++++++++++++--
>   2 files changed, 62 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/typec/fusb302/Kconfig b/drivers/staging/typec/fusb302/Kconfig
> index fce099ff39fe..48a4f2fcee03 100644
> --- a/drivers/staging/typec/fusb302/Kconfig
> +++ b/drivers/staging/typec/fusb302/Kconfig
> @@ -1,6 +1,6 @@
>   config TYPEC_FUSB302
>   	tristate "Fairchild FUSB302 Type-C chip driver"
> -	depends on I2C
> +	depends on I2C && POWER_SUPPLY
>   	help
>   	  The Fairchild FUSB302 Type-C chip driver that works with
>   	  Type-C Port Controller Manager to provide USB PD and USB
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 6f007f66d597..cf6355f59cd9 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -28,6 +28,7 @@
>   #include <linux/of_device.h>
>   #include <linux/of_gpio.h>
>   #include <linux/pinctrl/consumer.h>
> +#include <linux/power_supply.h>
>   #include <linux/proc_fs.h>
>   #include <linux/regulator/consumer.h>
>   #include <linux/sched/clock.h>
> @@ -108,6 +109,11 @@ struct fusb302_chip {
>   	/* lock for sharing chip states */
>   	struct mutex lock;
>   
> +	/* psy + psy status */
> +	struct power_supply *psy;
> +	u32 current_limit;
> +	u32 supply_voltage;
> +
>   	/* chip status */
>   	enum toggling_mode toggling_mode;
>   	enum src_current_status src_current_status;
> @@ -876,11 +882,13 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, bool charge)
>   		chip->vbus_on = on;
>   		fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
>   	}
> -	if (chip->charge_on == charge)
> +	if (chip->charge_on == charge) {
>   		fusb302_log(chip, "charge is already %s",
>   			    charge ? "On" : "Off");
> -	else
> +	} else {
>   		chip->charge_on = charge;
> +		power_supply_changed(chip->psy);
> +	}
>   
>   done:
>   	mutex_unlock(&chip->lock);
> @@ -896,6 +904,11 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, u32 max_ma, u32 mv)
>   	fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
>   		    max_ma, mv);
>   
> +	chip->supply_voltage = mv;
> +	chip->current_limit = max_ma;
> +
> +	power_supply_changed(chip->psy);
> +
>   	return 0;
>   }
>   
> @@ -1681,6 +1694,43 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
>   	return IRQ_HANDLED;
>   }
>   
> +static int fusb302_psy_get_property(struct power_supply *psy,
> +				    enum power_supply_property psp,
> +				    union power_supply_propval *val)
> +{
> +	struct fusb302_chip *chip = power_supply_get_drvdata(psy);
> +
> +	switch (psp) {
> +	case POWER_SUPPLY_PROP_ONLINE:
> +		val->intval = chip->charge_on;
> +		break;
> +	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> +		val->intval = chip->supply_voltage * 1000; /* mV -> µV */
> +		break;
> +	case POWER_SUPPLY_PROP_CURRENT_MAX:
> +		val->intval = chip->current_limit * 1000; /* mA -> µA */
> +		break;
> +	default:
> +		return -ENODATA;
> +	}
> +
> +	return 0;
> +}
> +
> +static enum power_supply_property fusb302_psy_properties[] = {
> +	POWER_SUPPLY_PROP_ONLINE,
> +	POWER_SUPPLY_PROP_VOLTAGE_NOW,
> +	POWER_SUPPLY_PROP_CURRENT_MAX,
> +};
> +
> +const struct power_supply_desc fusb302_psy_desc = {
> +	.name		= "fusb302-typec-source",
> +	.type		= POWER_SUPPLY_TYPE_USB_TYPE_C,
> +	.properties	= fusb302_psy_properties,
> +	.num_properties	= ARRAY_SIZE(fusb302_psy_properties),
> +	.get_property	= fusb302_psy_get_property,
> +};
> +
>   static int init_gpio(struct fusb302_chip *chip)
>   {
>   	struct device_node *node;
> @@ -1720,6 +1770,7 @@ static int fusb302_probe(struct i2c_client *client,
>   	struct fusb302_chip *chip;
>   	struct i2c_adapter *adapter;
>   	struct device *dev = &client->dev;
> +	struct power_supply_config cfg = {};
>   	const char *name;
>   	int ret = 0;
>   	u32 v;
> @@ -1766,6 +1817,14 @@ static int fusb302_probe(struct i2c_client *client,
>   			return -EPROBE_DEFER;
>   	}
>   
> +	cfg.drv_data = chip;
> +	chip->psy = devm_power_supply_register(dev, &fusb302_psy_desc, &cfg);
> +	if (IS_ERR(chip->psy)) {
> +		ret = PTR_ERR(chip->psy);
> +		dev_err(chip->dev, "Error registering power-supply: %d\n", ret);
> +		return ret;
> +	}
> +
>   	ret = fusb302_debugfs_init(chip);
>   	if (ret < 0)
>   		return ret;
> 

[toc] | [prev] | [next] | [standalone]


#1723173 — [PATCH v3 01/11] i2c: Allow overriding dev_name through board_info

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 12:00 +0200
Subject[PATCH v3 01/11] i2c: Allow overriding dev_name through board_info
Message-ID<uk7WW-6Hb-15@gated-at.bofh.it>
In reply to#1723169
For devices not instantiated through ACPI the i2c-client's device-name
gets set to <busnr>-<addr> by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.

In some cases having a predictable constant device-name is desirable,
for example on non device-tree platforms the link between a regulator
and its consumers is specified by the platform code by setting
regulator_init_data.consumers. This array identifies the regulator's
consumers by dev_name and supply(-name). Which requires a constant
dev_name.

This commit adds a dev_name field to i2c_board_info allowing
platform code to set a contstant dev_name so that the device can
be identified by its dev_name in other platform code.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/i2c/i2c-core-base.c | 10 ++++++++--
 include/linux/i2c.h         |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 45fafcc88b93..5cdf3b947c23 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -672,10 +672,16 @@ static void i2c_adapter_unlock_bus(struct i2c_adapter *adapter,
 }
 
 static void i2c_dev_set_name(struct i2c_adapter *adap,
-			     struct i2c_client *client)
+			     struct i2c_client *client,
+			     struct i2c_board_info const *info)
 {
 	struct acpi_device *adev = ACPI_COMPANION(&client->dev);
 
+	if (info && info->dev_name) {
+		dev_set_name(&client->dev, "i2c-%s", info->dev_name);
+		return;
+	}
+
 	if (adev) {
 		dev_set_name(&client->dev, "i2c-%s", acpi_dev_name(adev));
 		return;
@@ -772,7 +778,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
 	client->dev.of_node = info->of_node;
 	client->dev.fwnode = info->fwnode;
 
-	i2c_dev_set_name(adap, client);
+	i2c_dev_set_name(adap, client, info);
 
 	if (info->properties) {
 		status = device_add_properties(&client->dev, info->properties);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 701ad26fa6b4..d3655cfe9a3e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -310,6 +310,7 @@ static inline bool i2c_detect_slave_mode(struct device *dev) { return false; }
  * @type: chip type, to initialize i2c_client.name
  * @flags: to initialize i2c_client.flags
  * @addr: stored in i2c_client.addr
+ * @dev_name: Overrides the default <busnr>-<addr> dev_name if set
  * @platform_data: stored in i2c_client.dev.platform_data
  * @archdata: copied into i2c_client.dev.archdata
  * @of_node: pointer to OpenFirmware device node
@@ -334,6 +335,7 @@ struct i2c_board_info {
 	char		type[I2C_NAME_SIZE];
 	unsigned short	flags;
 	unsigned short	addr;
+	const char	*dev_name;
 	void		*platform_data;
 	struct dev_archdata	*archdata;
 	struct device_node *of_node;
-- 
2.13.4

[toc] | [prev] | [next] | [standalone]


#1723178 — [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 12:00 +0200
Subject[PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set
Message-ID<uk7WW-6Hb-23@gated-at.bofh.it>
In reply to#1723169
The fusb302 is also used on x86 systems where the platform code sets
the irq in client->irq and there is no gpio named fcs,int_n.

Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/staging/typec/fusb302/fusb302.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
index 1c1751c994db..675161cf4f3a 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1735,9 +1735,13 @@ static int fusb302_probe(struct i2c_client *client,
 		goto destroy_workqueue;
 	}
 
-	ret = init_gpio(chip);
-	if (ret < 0)
-		goto destroy_workqueue;
+	if (client->irq) {
+		chip->gpio_int_n_irq = client->irq;
+	} else {
+		ret = init_gpio(chip);
+		if (ret < 0)
+			goto destroy_workqueue;
+	}
 
 	chip->tcpm_port = tcpm_register_port(&client->dev, &chip->tcpc_dev);
 	if (IS_ERR(chip->tcpm_port)) {
-- 
2.13.4

[toc] | [prev] | [next] | [standalone]


#1723349 — Re: [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set

FromGuenter Roeck <linux@roeck-us.net>
Date2017-08-30 16:00 +0200
SubjectRe: [PATCH v3 05/11] staging: typec: fusb302: Use client->irq as irq if set
Message-ID<ukbHb-yr-9@gated-at.bofh.it>
In reply to#1723178
On 08/30/2017 02:48 AM, Hans de Goede wrote:
> The fusb302 is also used on x86 systems where the platform code sets
> the irq in client->irq and there is no gpio named fcs,int_n.
> 
> Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>   drivers/staging/typec/fusb302/fusb302.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 1c1751c994db..675161cf4f3a 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -1735,9 +1735,13 @@ static int fusb302_probe(struct i2c_client *client,
>   		goto destroy_workqueue;
>   	}
>   
> -	ret = init_gpio(chip);
> -	if (ret < 0)
> -		goto destroy_workqueue;
> +	if (client->irq) {
> +		chip->gpio_int_n_irq = client->irq;
> +	} else {
> +		ret = init_gpio(chip);
> +		if (ret < 0)
> +			goto destroy_workqueue;
> +	}
>   
>   	chip->tcpm_port = tcpm_register_port(&client->dev, &chip->tcpc_dev);
>   	if (IS_ERR(chip->tcpm_port)) {
> 

[toc] | [prev] | [next] | [standalone]


#1723180 — [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V

FromHans de Goede <hdegoede@redhat.com>
Date2017-08-30 12:00 +0200
Subject[PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V
Message-ID<uk7WX-6Hb-25@gated-at.bofh.it>
In reply to#1723169
Anything higher then 5V may damage hardware not capable of it, so
the only sane default here is 5V. If a board is able to handle a
higher voltage that should come from board specific data such as
device-tree and not be hard coded into the fusb302 code.

Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/staging/typec/fusb302/fusb302.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
index 03a3809d18f0..6baed06a3c0d 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1187,9 +1187,9 @@ static const struct tcpc_config fusb302_tcpc_config = {
 	.nr_src_pdo = ARRAY_SIZE(src_pdo),
 	.snk_pdo = snk_pdo,
 	.nr_snk_pdo = ARRAY_SIZE(snk_pdo),
-	.max_snk_mv = 9000,
+	.max_snk_mv = 5000,
 	.max_snk_ma = 3000,
-	.max_snk_mw = 27000,
+	.max_snk_mw = 15000,
 	.operating_snk_mw = 2500,
 	.type = TYPEC_PORT_DRP,
 	.default_role = TYPEC_SINK,
-- 
2.13.4

[toc] | [prev] | [next] | [standalone]


#1723340 — Re: [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V

FromGuenter Roeck <linux@roeck-us.net>
Date2017-08-30 15:40 +0200
SubjectRe: [PATCH v3 03/11] staging: typec: fusb302: Set max supply voltage to 5V
Message-ID<ukbnP-rR-7@gated-at.bofh.it>
In reply to#1723180
On 08/30/2017 02:48 AM, Hans de Goede wrote:
> Anything higher then 5V may damage hardware not capable of it, so
> the only sane default here is 5V. If a board is able to handle a
> higher voltage that should come from board specific data such as
> device-tree and not be hard coded into the fusb302 code.
> 
> Cc: "Yueyao (Nathan) Zhu" <yueyao@google.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

> ---
>   drivers/staging/typec/fusb302/fusb302.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 03a3809d18f0..6baed06a3c0d 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -1187,9 +1187,9 @@ static const struct tcpc_config fusb302_tcpc_config = {
>   	.nr_src_pdo = ARRAY_SIZE(src_pdo),
>   	.snk_pdo = snk_pdo,
>   	.nr_snk_pdo = ARRAY_SIZE(snk_pdo),
> -	.max_snk_mv = 9000,
> +	.max_snk_mv = 5000,
>   	.max_snk_ma = 3000,
> -	.max_snk_mw = 27000,
> +	.max_snk_mw = 15000,
>   	.operating_snk_mw = 2500,
>   	.type = TYPEC_PORT_DRP,
>   	.default_role = TYPEC_SINK,
> 

[toc] | [prev] | [next] | [standalone]


#1724396 — Re: [PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-31 18:30 +0200
SubjectRe: [PATCH v3 00/11] Hookup typec power-negotation to the PMIC and charger
Message-ID<ukAvU-7Un-13@gated-at.bofh.it>
In reply to#1723169
On Wed, Aug 30, 2017 at 11:48:03AM +0200, Hans de Goede wrote:
> Hi All,
> 
> Here is v3 of my typec power-negotation hookup series. New this version:
> - Drop a few patches merged into linux-power-supply.git/for-next
> - Drop the "power: supply: bq24190_charger: Remove extcon handling"
>   patch *for now*, this can only be merged once all the other patches are
>   in place (and extcon handling is no longer needed)
> - Address some review comments in some of the other patches, see the
>   per patch changelogs inside the commit messages
> 
> I believe that this series is ready for merging now and I would like to
> ask the various subsys maintainers to pick up and merge these patches.
> All the patches can be merged independent of eachother with the exception
> of the last 2 patches:
> 
> i2c-cht-wc: Add device-properties for fusb302 integration
> platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties
> 
> Which should not be merged until all the other patches are in place.

staging patches all now merged, thanks!

greg k-h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web