Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1642879
| From | Hans de Goede <hdegoede@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support |
| Date | 2017-05-17 00:30 +0200 |
| Message-ID | <tHT8C-3a6-15@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <tyLWF-Sq-7@gated-at.bofh.it> <tzK2u-6io-19@gated-at.bofh.it> <tzM4h-7tv-11@gated-at.bofh.it> <tGqil-2fu-7@gated-at.bofh.it> <tHJsB-5rS-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi, On 05/16/2017 02:07 PM, Heikki Krogerus wrote: > Hi Hans, > > On Fri, May 12, 2017 at 11:22:46PM +0200, Hans de Goede wrote: <snip> >> To me making the combination of the 2 sources the problem >> of the consumer seems just wrong, as you mentioned >> above there should really be only one extcon for the >> connector, likewise their should be only one definitive >> source on what the input current limit is. > > Why? The consumer driver, bq24290 in this case, does not need to > understand it has multiple sources. It will just react to events from > *a* source, and the psy framework takes care of everything else. The > psy framework will need some tuning, but that should not be a problem. > I'm preparing support for _PCL (power consumer list) ACPI method > handling for the psy framework, so I have some patches already. The > idea is that in the future USB ports could have virtual power source > object with _PCL. > > This is in any case separate issue compared to the problem of telling > the BC1.2 detection to start in case of TYPEC_CC_RP_DEF. > >> TL;DR: We need some way to combine the current limit info >> from TYPE-C and USB-2 BC detection into a single source and >> to propagate that current to drivers which can actually set >> the current-limit. >> >> Note I'm happy to use something else then extcon for this, >> but we do need some way to combine + propagate the >> current-limit. > > That must be handled using psy framework. Otherwise we'll just be > trying to re-invent the wheel. There is no problem for a consumer to > have multiple sources. But we don't really have multiple sources here, we have only one source, the USB-C cable hooked to an external power-supply. Just because 2 different pieces of hardware may be involved in determining the current limit does not mean that we should model this as 2 different sources. Just as you rightfully pointed out that me using 2 extcon devices for the single Type-C connector is wrong, modelling it as 2 sources is wrong too. <snip> > Back to this topic. I can see at least the following problems: > > 1. Tell the BC1.2 detection to start from fusb302 driver > 2. Deliver the power limits to the discrete charger ic or battery driver > 3. Tell what ever regulates VBUS to start driving VBUS. > > You are trying to solve everything using extcon, and that is wrong. As indicated I'm not stuck on using extcon, I started using it in my paches because it is used to set the current limit in some other places already, but I'm fine with using something else. > The second problem definitely needs to be handled using psy framework. > The psy framework provides already everything needed for that. So above you're talking about sources to the bq24190, which if I understand you correctly suggest that you want the tcpm code to register a power-supply device per Type-C port ? I'm not sure that is a good idea, any registered power-supply devices will show up under /sys/class/power_supply, currently on a typical system there will be 2 entries under /sys/class/power_supply one for the "Mains" or USB power input and one for the battery, adding more entries there is likely to confuse userspace. More in general having 2 power-supply devices for what is in essence one power-input feels wrong. We can still use the power-supply framework, but I would envision this working like this: The platform code which enumerates the type-c controller sets a "input-current-power-supply-name" string device-property on the tcpm's (parent)device. When this is set the tpcm code will do a power_supply_get_by_name and set the input current on the returned power_supply by setting the POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT property. For 3. (vbus) we could do something similar using a "vbus-regulator-id" device-property and the regulator framework, making the driver which controls Vbus register itself as a regulator. I can take a shot at implementing both suggestions, but first lets try to get some general idea of how we want to solve this. Regards, Hans
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support Hans de Goede <hdegoede@redhat.com> - 2017-05-12 23:30 +0200
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-05-16 14:10 +0200
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support Hans de Goede <hdegoede@redhat.com> - 2017-05-17 00:30 +0200
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-05-17 13:50 +0200
USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Hans de Goede <hdegoede@redhat.com> - 2017-05-17 16:50 +0200
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-05-18 10:50 +0200
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-05-18 14:00 +0200
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Hans de Goede <hdegoede@redhat.com> - 2017-05-19 22:20 +0200
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Hans de Goede <hdegoede@redhat.com> - 2017-05-19 22:20 +0200
Re: USB TYPE-C support and the power-supply subsys (was Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support) Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2017-05-22 17:10 +0200
Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support Guenter Roeck <linux@roeck-us.net> - 2017-05-17 01:00 +0200
csiph-web