All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	Guenter Roeck <linux@roeck-us.net>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sebastian Reichel <sre@kernel.org>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Breck <liam@networkimprov.net>,
	linux-i2c@vger.kernel.org, linux-pm@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org
Subject: Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper
Date: Wed, 16 Aug 2017 19:38:29 +0200	[thread overview]
Message-ID: <327357a2-3491-fa7c-f715-eb1c321c3c38@redhat.com> (raw)
In-Reply-To: <20170816155443.GH8569@atomide.com>

Hi,

On 16-08-17 17:54, Tony Lindgren wrote:
> * Hans de Goede <hdegoede@redhat.com> [170815 13:06]:
>> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
>> done by a separate port-controller IC, while the current limit is
>> controlled through another (charger) IC.
>>
>> It has been decided to model this by modelling the external Type-C
>> power brick (adapter/charger) as a power-supply class device which
>> supplies the charger-IC, with its voltage-now and current-max representing
>> the negotiated voltage and max current draw.
>>
>> This commit adds a power_supply_set_input_current_limit_from_supplier
>> helper function which charger power-supply drivers can call to get
>> the max-current from their supplier and have this applied
>> through their set_property call-back to their input-current-limit.
> 
> Hmm so can this also be used for the USB gadget subsystem
> to tell charge controller when it's OK to enable 500mA
> charging after enumeration?

I'm not sure that that would be best modeled this way. Perhaps
the phy-driver can directly control the gpio you have for that,
that seems better then trying to solve this with cross subsystem
calls which are always tricky.

> FYI, that's controlled by the bq24190 pin named OTG that should
> be only set high after enumeration. Any ideas how that is wired
> on your device? Does it connect to the USB PHY or to a GPIO
> line?

I believe it is just hardwired to be logical high all the time
on my board.

Regards,

Hans

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Tony Lindgren <tony@atomide.com>
Cc: devel@driverdev.osuosl.org,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	linux-kernel@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-pm@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
	platform-driver-x86@vger.kernel.org,
	Liam Breck <liam@networkimprov.net>,
	Guenter Roeck <linux@roeck-us.net>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper
Date: Wed, 16 Aug 2017 19:38:29 +0200	[thread overview]
Message-ID: <327357a2-3491-fa7c-f715-eb1c321c3c38@redhat.com> (raw)
In-Reply-To: <20170816155443.GH8569@atomide.com>

Hi,

On 16-08-17 17:54, Tony Lindgren wrote:
> * Hans de Goede <hdegoede@redhat.com> [170815 13:06]:
>> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
>> done by a separate port-controller IC, while the current limit is
>> controlled through another (charger) IC.
>>
>> It has been decided to model this by modelling the external Type-C
>> power brick (adapter/charger) as a power-supply class device which
>> supplies the charger-IC, with its voltage-now and current-max representing
>> the negotiated voltage and max current draw.
>>
>> This commit adds a power_supply_set_input_current_limit_from_supplier
>> helper function which charger power-supply drivers can call to get
>> the max-current from their supplier and have this applied
>> through their set_property call-back to their input-current-limit.
> 
> Hmm so can this also be used for the USB gadget subsystem
> to tell charge controller when it's OK to enable 500mA
> charging after enumeration?

I'm not sure that that would be best modeled this way. Perhaps
the phy-driver can directly control the gpio you have for that,
that seems better then trying to solve this with cross subsystem
calls which are always tricky.

> FYI, that's controlled by the bq24190 pin named OTG that should
> be only set high after enumeration. Any ideas how that is wired
> on your device? Does it connect to the USB PHY or to a GPIO
> line?

I believe it is just hardwired to be logical high all the time
on my board.

Regards,

Hans

  reply	other threads:[~2017-08-16 17:38 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-15 20:04 [PATCH v2 00/14] Hookup typec power-negotation to the PMIC and charger Hans de Goede
2017-08-15 20:04 ` [PATCH v2 01/14] i2c: Allow overriding dev_name through board_info Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-15 20:04 ` [PATCH v2 02/14] staging: typec: tcpm: Add get_current_limit tcpc_dev callback Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-16 15:11   ` Guenter Roeck
2017-08-15 20:04 ` [PATCH v2 03/14] staging: typec: fusb302: Set max supply voltage to 5V Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-15 20:04 ` [PATCH v2 04/14] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-17 21:41   ` Rob Herring
2017-08-17 21:41     ` Rob Herring
2017-08-28 16:11     ` Hans de Goede
2017-08-15 20:04 ` [PATCH v2 05/14] staging: typec: fusb302: Use client->irq as irq if set Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-15 20:04 ` [PATCH v2 06/14] staging: typec: fusb302: Add support for USB2 charger detection through extcon Hans de Goede
2017-08-15 20:04 ` [PATCH v2 07/14] staging: typec: fusb302: Export current-limit through a power_supply class dev Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-15 20:04 ` [PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-16 15:54   ` Tony Lindgren
2017-08-16 17:38     ` Hans de Goede [this message]
2017-08-16 17:38       ` Hans de Goede
2017-08-16 19:21       ` Tony Lindgren
2017-08-29 10:54   ` Sebastian Reichel
2017-08-15 20:04 ` [PATCH v2 09/14] power: supply: bq24190_charger: Export 5V boost converter as regulator Hans de Goede
2017-08-15 20:04   ` Hans de Goede
2017-08-29 11:28   ` Sebastian Reichel
2017-08-29 11:28     ` Sebastian Reichel
2017-08-15 20:04 ` [PATCH v2 10/14] power: supply: bq24190_charger: Add input_current_limit property Hans de Goede
2017-08-29 11:29   ` Sebastian Reichel
2017-08-15 20:04 ` [PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier Hans de Goede
2017-08-16 20:28   ` Liam Breck
2017-08-28 16:04     ` Hans de Goede
2017-08-28 17:02       ` Liam Breck
2017-08-28 18:07       ` Liam Breck
2017-08-28 18:07         ` Liam Breck
2017-08-28 19:08         ` Hans de Goede
2017-08-29 11:40   ` Sebastian Reichel
2017-08-29 11:53     ` Hans de Goede
2017-08-29 11:53       ` Hans de Goede
2017-08-29 12:12       ` Sebastian Reichel
2017-08-15 20:05 ` [PATCH v2 12/14] power: supply: bq24190_charger: Remove extcon handling Hans de Goede
2017-08-15 20:05 ` [PATCH v2 13/14] i2c-cht-wc: Add device-properties for fusb302 integration Hans de Goede
2017-08-15 20:05 ` [PATCH v2 14/14] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties Hans de Goede

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=327357a2-3491-fa7c-f715-eb1c321c3c38@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy@infradead.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=liam@networkimprov.net \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sre@kernel.org \
    --cc=tony@atomide.com \
    --cc=wsa@the-dreams.de \
    /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.