* [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-02-20 8:51 Baolin Wang
2017-02-20 8:51 ` Baolin Wang
` (5 more replies)
0 siblings, 6 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.
Now introduce one user with wm831x_power to support and test the usb charger.
Another user introduced to support charger detection by Jun Li:
https://www.spinics.net/lists/linux-usb/msg139425.html
Moreover there may be other potential users will use it in future.
1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
phy driver, now all were merged. (Thanks for Neil's suggestion)
(1) Have fixed the inconsistencies with USB connector types in extcon subsystem
by following links:
https://lkml.org/lkml/2016/12/21/13
https://lkml.org/lkml/2016/12/21/15
https://lkml.org/lkml/2016/12/21/79
https://lkml.org/lkml/2017/1/3/13
(2) Instead of using 'set_power' callback in phy drivers, we will introduce
USB charger to set PMIC current drawn from USB configuration, moreover some
'set_power' callbacks did not implement anything to set PMIC current, thus
remove them by following links:
https://lkml.org/lkml/2017/1/18/436
https://lkml.org/lkml/2017/1/18/439
https://lkml.org/lkml/2017/1/18/438
Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
used 'set_power' callback to set current, we can remove them in future. (I
have no platform with enabling these two phy drivers, so I can not test them
if I converted 'set_power' callback to USB charger.)
2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
I expalined each issue and may be need discuss again:
(1) Change all usb phys to register an extcon and to send appropriate notifications.
Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
usb phys to register an extcon, since there are no extcon device to register
for these different phy drivers.
Secondly, I also agreed with Peter's comments: Not only USB PHY to register
an extcon, but also for the drivers which can detect USB charger type, it may
be USB controller driver, USB type-c driver, pmic driver, and these drivers
may not have an extcon device since the internal part can finish the vbus
detect.
(2) Change the notifier of usb_phy to be used consistently.
Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
send out the connect events, and phy-ab8500-usb.c also was used to send out the
MUSB connect events. There are no phy drivers will notify 'vbus_draw' information
by the notifier of usb_phy, which was used consistently now.
Moreover it is difficult to change the notifier of usb_phy to be used only to
communicate the 'vbus_draw' information, since we need to refactor and test these
related phy drivers, power drivers or some mfd drivers, which is a huge workload.
(3) Still keep charger_type_show() API.
Firstly I think we should combine all charger related information into one
place for users, which is convenient.
Secondly not only we get charger type from extcon, but also in some scenarios
we can get charger type from USB controller driver, USB type-c driver, pmic
driver, we should also need one place to export the charger type.
Changes since v18:
Other issues addressed in this patchset:
- Modify the method of looking up one USB charger instance, we assume there is
only one USB charger in the system. But leaving things there to avoid any need
for future refactoring to touch the usb_charger_register() interface.
- Remove usb_charger_set_current() API.
- Rename usb charger state.
- Remove ->get_charger_type() interface.
- Add some documentation for ->charger_detect() interface explicitly.
- Fix one issue: reset current to default values when cable was unplugged.
- Only notify the max current to power users, but users can get the min current
by usb_charger_get_current() if users want to use the min current.
- Other small optimizations.
Changes since v17:
- Remove goto section in usb_charger_register() function.
- Remove 'extern' in charger.h file.
- Move the kfree() to usb_charger_exit() function.
Changes since v16:
- Modify the charger current range with introducing the maximum and minimum
current.
- Remove the getting charger type method from power supply.
- Add the getting charger type method from extcon system.
- Introduce new usb_charger_get_current() API for users to get the maximum and
minimum current.
- Rename some APIs and other optimization.
Changes since v15:
- Add charger state checking to avoid sending out duplicate notifies to users.
- Add one work to notify power users the current has been changed.
Changes since v14:
- Add kernel documentation for struct usb_cahrger.
- Remove some redundant WARN() functions.
Changes since v13:
- Remove the charger checking in usb_gadget_vbus_draw() function.
- Rename some functions in charger.c file.
- Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.8
Changes since v12:
- Remove the class and device things.
- Link usb charger to udc-core.ko.
- Create one "charger" subdirectory which holds all charger-related attributes.
Changes since v11:
- Reviewed and tested by Li Jun.
Changes since v10:
- Introduce usb_charger_get_state() function to check charger state.
- Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
in case will be issued in atomic context.
Baolin Wang (4):
usb: gadget: Introduce the usb charger framework
usb: gadget: Support for the usb charger framework
usb: gadget: Integrate with the usb gadget supporting for usb charger
power: wm831x_power: Support USB charger current limit management
drivers/power/supply/wm831x_power.c | 63 +++
drivers/usb/gadget/Kconfig | 8 +
drivers/usb/gadget/udc/Makefile | 1 +
drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
drivers/usb/gadget/udc/core.c | 19 +-
include/linux/usb/charger.h | 176 +++++++
include/linux/usb/gadget.h | 3 +
include/uapi/linux/usb/charger.h | 31 ++
8 files changed, 1165 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/gadget/udc/charger.c
create mode 100644 include/linux/usb/charger.h
create mode 100644 include/uapi/linux/usb/charger.h
--
1.7.9.5
^ permalink raw reply [flat|nested] 50+ messages in thread
* [PATCH v19 1/4] usb: gadget: Introduce the usb charger framework
@ 2017-02-20 8:51 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.
The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.
Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.
This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Reviewed-by: Li Jun <jun.li@nxp.com>
Tested-by: Li Jun <jun.li@nxp.com>
---
drivers/usb/gadget/Kconfig | 8 +
drivers/usb/gadget/udc/Makefile | 1 +
drivers/usb/gadget/udc/charger.c | 770 ++++++++++++++++++++++++++++++++++++++
include/linux/usb/charger.h | 176 +++++++++
include/uapi/linux/usb/charger.h | 31 ++
5 files changed, 986 insertions(+)
create mode 100644 drivers/usb/gadget/udc/charger.c
create mode 100644 include/linux/usb/charger.h
create mode 100644 include/uapi/linux/usb/charger.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8ad2032..60d2f29 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
It supports the serial gadget can be used as a console.
+config USB_CHARGER
+ bool "USB charger support"
+ select EXTCON
+ help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
source "drivers/usb/gadget/udc/Kconfig"
#
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
CFLAGS_trace.o := -I$(src)
udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
#
# USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 0000000..6d62f54
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,770 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/extcon.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/ch9.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/charger.h>
+
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN 2
+#define DEFAULT_SDP_CUR_MAX 500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN 500
+#define DEFAULT_DCP_CUR_MAX 5000
+#define DEFAULT_CDP_CUR_MIN 1500
+#define DEFAULT_CDP_CUR_MAX 5000
+#define DEFAULT_ACA_CUR_MIN 1500
+#define DEFAULT_ACA_CUR_MAX 5000
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+ return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current.
+ */
+static ssize_t charger_current_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ unsigned int min, max;
+
+ usb_charger_get_current(uchger, &min, &max);
+ return sprintf(buf, "%u-%u\n", min, max);
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ enum usb_charger_type type = usb_charger_get_type(uchger);
+ int cnt;
+
+ switch (type) {
+ case SDP_TYPE:
+ cnt = sprintf(buf, "%s\n", "SDP");
+ break;
+ case DCP_TYPE:
+ cnt = sprintf(buf, "%s\n", "DCP");
+ break;
+ case CDP_TYPE:
+ cnt = sprintf(buf, "%s\n", "CDP");
+ break;
+ case ACA_TYPE:
+ cnt = sprintf(buf, "%s\n", "ACA");
+ break;
+ default:
+ cnt = sprintf(buf, "%s\n", "UNKNOWN");
+ break;
+ }
+
+ return cnt;
+}
+static DEVICE_ATTR_RO(charger_type);
+
+/*
+ * charger_state_show() - Show the charger state.
+ *
+ * Charger state can be present or removed.
+ */
+static ssize_t charger_state_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ enum usb_charger_state state = usb_charger_get_state(uchger);
+ int cnt;
+
+ switch (state) {
+ case USB_CHARGER_PRESENT:
+ cnt = sprintf(buf, "%s\n", "PRESENT");
+ break;
+ case USB_CHARGER_ABSENT:
+ cnt = sprintf(buf, "%s\n", "REMOVE");
+ break;
+ default:
+ cnt = sprintf(buf, "%s\n", "UNKNOWN");
+ break;
+ }
+
+ return cnt;
+}
+static DEVICE_ATTR_RO(charger_state);
+
+static struct attribute *usb_charger_attrs[] = {
+ &dev_attr_charger_current.attr,
+ &dev_attr_charger_type.attr,
+ &dev_attr_charger_state.attr,
+ NULL
+};
+
+static const struct attribute_group usb_charger_group = {
+ .name = "charger",
+ .attrs = usb_charger_attrs,
+};
+__ATTRIBUTE_GROUPS(usb_charger);
+
+/*
+ * usb_charger_get_instance() - Get the first usb charger instance.
+ *
+ * Note: We assume that there is only one USB charger in the system.
+ */
+struct usb_charger *usb_charger_get_instance()
+{
+ struct usb_charger *uchger;
+
+ mutex_lock(&charger_lock);
+ list_for_each_entry(uchger, &charger_list, list) {
+ if (uchger->name)
+ break;
+ }
+ mutex_unlock(&charger_lock);
+
+ if (WARN(!uchger, "can't find usb charger"))
+ return ERR_PTR(-ENODEV);
+
+ return uchger;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_instance);
+
+/*
+ * usb_charger_get_type() - get the usb charger type with lock protection.
+ * @uchger - usb charger instance.
+ *
+ * Users can get the charger type by this safe API, rather than using the
+ * usb_charger structure directly.
+ */
+enum usb_charger_type usb_charger_get_type(struct usb_charger *uchger)
+{
+ enum usb_charger_type type;
+
+ mutex_lock(&uchger->lock);
+ type = uchger->type;
+ mutex_unlock(&uchger->lock);
+
+ return type;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_type);
+
+/*
+ * usb_charger_get_state() - Get the charger state with lock protection.
+ * @uchger - the usb charger instance.
+ *
+ * Users should get the charger state by this safe API.
+ */
+enum usb_charger_state usb_charger_get_state(struct usb_charger *uchger)
+{
+ enum usb_charger_state state;
+
+ mutex_lock(&uchger->lock);
+ state = uchger->state;
+ mutex_unlock(&uchger->lock);
+
+ return state;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_state);
+
+/*
+ * usb_charger_detect_type() - detect the charger type manually.
+ * @uchger - usb charger instance.
+ *
+ * Note: You should ensure you need to detect the charger type manually on
+ * your platform. You should call it at the right gadget state to avoid
+ * affecting gadget enumeration.
+ */
+int usb_charger_detect_type(struct usb_charger *uchger)
+{
+ enum usb_charger_type type;
+
+ if (!uchger->charger_detect)
+ return -EINVAL;
+
+ type = uchger->charger_detect(uchger);
+
+ mutex_lock(&uchger->lock);
+ uchger->type = type;
+ mutex_unlock(&uchger->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_detect_type);
+
+/*
+ * usb_charger_set_default_current() - Set default current for charger.
+ * @uchger - usb charger instance.
+ */
+static void usb_charger_set_default_current(struct usb_charger *uchger)
+{
+ uchger->cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+ uchger->cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+ uchger->cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+ uchger->cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+ uchger->cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+ uchger->cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+ uchger->cur.aca_min = DEFAULT_ACA_CUR_MIN;
+ uchger->cur.aca_max = DEFAULT_ACA_CUR_MAX;
+ uchger->sdp_default_cur_change = 0;
+}
+
+/*
+ * __usb_charger_get_current() - Get the charger current.
+ * @uchger - the usb charger instance.
+ * @min - return the minimum current.
+ * @max - return the maximum current.
+ *
+ * Callers should get the charger lock before issuing this function.
+ */
+static void __usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min,
+ unsigned int *max)
+{
+ enum usb_charger_type type = uchger->type;
+
+ switch (type) {
+ case SDP_TYPE:
+ /*
+ * For super speed gadget, the default charger maximum current
+ * should be 900 mA and the default minimum current should be
+ * 150mA.
+ */
+ if (uchger->gadget &&
+ uchger->gadget->speed >= USB_SPEED_SUPER) {
+ if (!uchger->sdp_default_cur_change)
+ uchger->cur.sdp_max = DEFAULT_SDP_CUR_MAX_SS;
+
+ uchger->cur.sdp_min = DEFAULT_SDP_CUR_MIN_SS;
+ }
+
+ *min = uchger->cur.sdp_min;
+ *max = uchger->cur.sdp_max;
+ break;
+ case DCP_TYPE:
+ *min = uchger->cur.dcp_min;
+ *max = uchger->cur.dcp_max;
+ break;
+ case CDP_TYPE:
+ *min = uchger->cur.cdp_min;
+ *max = uchger->cur.cdp_max;
+ break;
+ case ACA_TYPE:
+ *min = uchger->cur.aca_min;
+ *max = uchger->cur.aca_max;
+ break;
+ default:
+ *min = 0;
+ *max = 0;
+ break;
+ }
+}
+
+/*
+ * usb_charger_get_cur_limit() - Get the maximum charger current.
+ * @uchger - the usb charger instance.
+ *
+ * This function should under the charger lock protection.
+ */
+static unsigned int usb_charger_get_cur_limit(struct usb_charger *uchger)
+{
+ unsigned int min_cur, max_cur;
+
+ __usb_charger_get_current(uchger, &min_cur, &max_cur);
+ return max_cur;
+}
+
+/*
+ * usb_charger_get_current() - Get the charger current with lock protection.
+ * @uchger - the usb charger instance.
+ * @min - return the minimum current.
+ * @max - return the maximum current.
+ *
+ * Users should get the charger current by this safe API.
+ */
+int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min,
+ unsigned int *max)
+{
+ if (!uchger)
+ return -EINVAL;
+
+ mutex_lock(&uchger->lock);
+ __usb_charger_get_current(uchger, min, max);
+ mutex_unlock(&uchger->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_current);
+
+/*
+ * usb_charger_notify_work() - Notify users the current has changed by work.
+ * @work - the work instance.
+ *
+ * Note: When users receive the charger present event, they should check the
+ * charger current by usb_charger_get_current() API.
+ */
+static void usb_charger_notify_work(struct work_struct *work)
+{
+ struct usb_charger *uchger = work_to_charger(work);
+
+ mutex_lock(&uchger->lock);
+ if (uchger->state == USB_CHARGER_PRESENT) {
+ raw_notifier_call_chain(&uchger->uchger_nh,
+ usb_charger_get_cur_limit(uchger),
+ uchger);
+ }
+ mutex_unlock(&uchger->lock);
+}
+
+/*
+ * __usb_charger_set_cur_limit_by_type() - Set the current limitation
+ * by charger type.
+ * @uchger - the usb charger instance.
+ * @type - the usb charger type.
+ * @cur_limit - the current limitation.
+ */
+static int __usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ switch (type) {
+ case SDP_TYPE:
+ if (uchger->gadget && uchger->gadget->speed >= USB_SPEED_SUPER) {
+ uchger->cur.sdp_max =
+ (cur_limit > DEFAULT_SDP_CUR_MAX_SS) ?
+ DEFAULT_SDP_CUR_MAX_SS : cur_limit;
+ } else {
+ uchger->cur.sdp_max =
+ (cur_limit > DEFAULT_SDP_CUR_MAX) ?
+ DEFAULT_SDP_CUR_MAX : cur_limit;
+ }
+
+ uchger->sdp_default_cur_change = 1;
+ break;
+ case DCP_TYPE:
+ uchger->cur.dcp_max = (cur_limit > DEFAULT_DCP_CUR_MAX) ?
+ DEFAULT_DCP_CUR_MAX : cur_limit;
+ break;
+ case CDP_TYPE:
+ uchger->cur.cdp_max = (cur_limit > DEFAULT_CDP_CUR_MAX) ?
+ DEFAULT_CDP_CUR_MAX : cur_limit;
+ break;
+ case ACA_TYPE:
+ uchger->cur.aca_max = (cur_limit > DEFAULT_ACA_CUR_MAX) ?
+ DEFAULT_ACA_CUR_MAX : cur_limit;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
+ * usb_charger_set_cur_limit_by_gadget() - Set the current limitation from
+ * gadget layer.
+ * @gadget - the usb gadget device.
+ * @cur_limit - the current limitation.
+ *
+ * Note: This function is used in atomic contexts without mutex lock.
+ */
+int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
+
+/*
+ * usb_charger_set_cur_limit_by_type() - Set the current limitation
+ * by charger type with lock protection.
+ * @uchger - the usb charger instance.
+ * @type - the usb charger type.
+ * @cur_limit - the current limitation.
+ *
+ * Users should set the current limitation by this lock protection API.
+ */
+int usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ int ret;
+
+ if (!uchger)
+ return -EINVAL;
+
+ mutex_lock(&uchger->lock);
+ ret = __usb_charger_set_cur_limit_by_type(uchger, type, cur_limit);
+ mutex_unlock(&uchger->lock);
+ if (ret)
+ return ret;
+
+ schedule_work(&uchger->work);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_type);
+
+/*
+ * usb_charger_register_notify() - Register a notifiee to get notified by
+ * any attach status changes from the usb charger detection.
+ * @uchger - the usb charger instance which is monitored.
+ * @nb - a notifier block to be registered.
+ */
+int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ int ret;
+
+ if (!uchger || !nb) {
+ pr_err("Charger or nb can not be NULL.\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&uchger->lock);
+ ret = raw_notifier_chain_register(&uchger->uchger_nh, nb);
+ mutex_unlock(&uchger->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_register_notify);
+
+/*
+ * usb_charger_unregister_notify() - Unregister a notifiee from the usb charger.
+ * @uchger - the usb charger instance which is monitored.
+ * @nb - a notifier block to be unregistered.
+ */
+int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ int ret;
+
+ if (!uchger || !nb) {
+ pr_err("Charger or nb can not be NULL.\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&uchger->lock);
+ ret = raw_notifier_chain_unregister(&uchger->uchger_nh, nb);
+ mutex_unlock(&uchger->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_unregister_notify);
+
+/*
+ * usb_charger_notify_state() - It will notify other device registered
+ * on usb charger when the usb charger state is changed.
+ * @uchger - the usb charger instance.
+ * @state - the state of the usb charger.
+ *
+ * Note: When notify the charger present state to power driver, the power driver
+ * should get the current by usb_charger_get_current() API to set current.
+ */
+static void usb_charger_notify_state(struct usb_charger *uchger,
+ enum usb_charger_state state)
+{
+ char uchger_state[50] = { 0 };
+ char *envp[] = { uchger_state, NULL };
+
+ mutex_lock(&uchger->lock);
+ if (uchger->state == state) {
+ mutex_unlock(&uchger->lock);
+ return;
+ }
+
+ uchger->state = state;
+
+ switch (state) {
+ case USB_CHARGER_PRESENT:
+ raw_notifier_call_chain(&uchger->uchger_nh,
+ usb_charger_get_cur_limit(uchger),
+ uchger);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+ "USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+ break;
+ case USB_CHARGER_ABSENT:
+ uchger->type = UNKNOWN_TYPE;
+ usb_charger_set_default_current(uchger);
+ raw_notifier_call_chain(&uchger->uchger_nh, 0, uchger);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+ "USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+ break;
+ default:
+ pr_warn("Unknown USB charger state: %d\n", state);
+ mutex_unlock(&uchger->lock);
+ return;
+ }
+
+ kobject_uevent_env(&uchger->gadget->dev.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(&uchger->lock);
+}
+
+/*
+ * usb_charger_type_by_extcon() - The notifier call function which is registered
+ * on the extcon device.
+ * @nb - the notifier block that notified by extcon device.
+ * @state - the extcon device state.
+ * @data - here specify a extcon device.
+ *
+ * return the notify flag.
+ */
+static int usb_charger_type_by_extcon(struct notifier_block *nb,
+ unsigned long state, void *data)
+{
+ struct usb_charger_nb *extcon_nb =
+ container_of(nb, struct usb_charger_nb, nb);
+ struct usb_charger *uchger = extcon_nb->uchger;
+ enum usb_charger_state uchger_state;
+ enum usb_charger_type type;
+
+ if (WARN(!uchger, "charger can not be NULL"))
+ return NOTIFY_BAD;
+
+ /* Determine charger type */
+ if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_SDP) > 0) {
+ type = SDP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_CDP) > 0) {
+ type = CDP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_DCP) > 0) {
+ type = DCP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_ACA) > 0) {
+ type = ACA_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else {
+ type = UNKNOWN_TYPE;
+ uchger_state = USB_CHARGER_ABSENT;
+ }
+
+ mutex_lock(&uchger->lock);
+ uchger->type = type;
+ mutex_unlock(&uchger->lock);
+
+ usb_charger_notify_state(uchger, uchger_state);
+
+ return NOTIFY_OK;
+}
+
+/*
+ * usb_charger_plug_by_extcon() - The notifier call function which is registered
+ * on the extcon device.
+ * @nb - the notifier block that notified by extcon device.
+ * @state - the extcon device state.
+ * @data - here specify a extcon device.
+ *
+ * return the notify flag.
+ */
+static int usb_charger_plug_by_extcon(struct notifier_block *nb,
+ unsigned long state, void *data)
+{
+ struct usb_charger_nb *extcon_nb =
+ container_of(nb, struct usb_charger_nb, nb);
+ struct usb_charger *uchger = extcon_nb->uchger;
+ enum usb_charger_state uchger_state;
+
+ if (WARN(!uchger, "charger can not be NULL"))
+ return NOTIFY_BAD;
+
+ /*
+ * Report event to power users to setting the current limitation
+ * for this usb charger when one usb charger is added or removed
+ * with detecting by extcon device.
+ */
+ if (state)
+ uchger_state = USB_CHARGER_PRESENT;
+ else
+ uchger_state = USB_CHARGER_ABSENT;
+
+ usb_charger_notify_state(uchger, uchger_state);
+
+ return NOTIFY_OK;
+}
+
+/*
+ * usb_charger_plug_by_gadget() - Set the usb charger current limitation
+ * according to the usb gadget device state.
+ * @gadget - the usb gadget device.
+ * @state - the usb gadget state.
+ */
+int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
+ unsigned long state)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
+
+/*
+ * usb_charger_register() - Register a new usb charger.
+ * @uchger - the new usb charger instance.
+ */
+static int usb_charger_register(struct usb_charger *uchger)
+{
+ int ret;
+
+ ret = ida_simple_get(&usb_charger_ida, 0, 0, GFP_KERNEL);
+ if (ret < 0) {
+ pr_err("Failed to register usb charger: %d\n", ret);
+ return ret;
+ }
+
+ uchger->id = ret;
+ scnprintf(uchger->name, CHARGER_NAME_MAX, "usb-charger.%d", uchger->id);
+
+ ret = sysfs_create_groups(&uchger->gadget->dev.kobj,
+ usb_charger_groups);
+ if (ret) {
+ pr_err("Failed to create usb charger attributes: %d\n", ret);
+ ida_simple_remove(&usb_charger_ida, uchger->id);
+ uchger->id = -1;
+ return ret;
+ }
+
+ mutex_lock(&charger_lock);
+ list_add_tail(&uchger->list, &charger_list);
+ mutex_unlock(&charger_lock);
+
+ return 0;
+}
+
+int usb_charger_init(struct usb_gadget *ugadget)
+{
+ struct usb_charger *uchger;
+ struct extcon_dev *edev;
+ int ret;
+
+ uchger = kzalloc(sizeof(struct usb_charger), GFP_KERNEL);
+ if (!uchger)
+ return -ENOMEM;
+
+ uchger->type = UNKNOWN_TYPE;
+ uchger->state = USB_CHARGER_DEFAULT;
+ uchger->id = -1;
+ usb_charger_set_default_current(uchger);
+
+ mutex_init(&uchger->lock);
+ RAW_INIT_NOTIFIER_HEAD(&uchger->uchger_nh);
+ INIT_WORK(&uchger->work, usb_charger_notify_work);
+
+ /* Register a notifier on a extcon device if it is exsited */
+ edev = extcon_get_edev_by_phandle(ugadget->dev.parent, 0);
+ if (!IS_ERR_OR_NULL(edev)) {
+ uchger->extcon_dev = edev;
+ uchger->extcon_nb.nb.notifier_call = usb_charger_plug_by_extcon;
+ uchger->extcon_nb.uchger = uchger;
+ ret = extcon_register_notifier(edev, EXTCON_USB,
+ &uchger->extcon_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB notifier.\n");
+ goto fail_extcon;
+ }
+
+ uchger->extcon_type_nb.nb.notifier_call =
+ usb_charger_type_by_extcon;
+ uchger->extcon_type_nb.uchger = uchger;
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_SDP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB SDP notifier.\n");
+ goto fail_extcon_sdp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_CDP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB CDP notifier.\n");
+ goto fail_extcon_cdp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_DCP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB DCP notifier.\n");
+ goto fail_extcon_dcp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_ACA,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB ACA notifier.\n");
+ goto fail_extcon_aca;
+ }
+ }
+
+ uchger->gadget = ugadget;
+ uchger->old_gadget_state = USB_STATE_NOTATTACHED;
+
+ /* Register a new usb charger */
+ ret = usb_charger_register(uchger);
+ if (ret)
+ goto fail_register;
+
+ return 0;
+
+fail_register:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_ACA,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_aca:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_DCP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_dcp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_CDP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_cdp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_SDP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_sdp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_USB,
+ &uchger->extcon_nb.nb);
+fail_extcon:
+ kfree(uchger);
+
+ return ret;
+}
+
+int usb_charger_exit(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+
+MODULE_AUTHOR("Baolin Wang <baolin.wang@linaro.org>");
+MODULE_DESCRIPTION("USB charger driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/charger.h b/include/linux/usb/charger.h
new file mode 100644
index 0000000..e9b1c8a
--- /dev/null
+++ b/include/linux/usb/charger.h
@@ -0,0 +1,176 @@
+#ifndef __LINUX_USB_CHARGER_H__
+#define __LINUX_USB_CHARGER_H__
+
+#include <uapi/linux/usb/ch9.h>
+#include <uapi/linux/usb/charger.h>
+
+#define CHARGER_NAME_MAX 30
+#define work_to_charger(w) (container_of((w), struct usb_charger, work))
+
+/* Current range by charger type */
+struct usb_charger_current {
+ unsigned int sdp_min;
+ unsigned int sdp_max;
+ unsigned int dcp_min;
+ unsigned int dcp_max;
+ unsigned int cdp_min;
+ unsigned int cdp_max;
+ unsigned int aca_min;
+ unsigned int aca_max;
+};
+
+struct usb_charger_nb {
+ struct notifier_block nb;
+ struct usb_charger *uchger;
+};
+
+/**
+ * struct usb_charger - describe one usb charger
+ * @name: Charger name.
+ * @list: For linking usb charger instances into one global list.
+ * @uchger_nh: Notifier head for users to register.
+ * @lock: Protect the notifier head and charger.
+ * @id: The charger id.
+ * @type: The charger type, it can be SDP_TYPE, DCP_TYPE, CDP_TYPE or
+ * ACA_TYPE.
+ * @state: Indicate the charger state.
+ * @cur: Describe the current range by charger type.
+ * @work: Workqueue to be used for reporting users current has changed.
+ * @extcon_dev: For supporting extcon usb gpio device to detect usb cable
+ * event (plugin or not).
+ * @extcon_nb: Report the events to charger from extcon device.
+ * @extcon_type_nb: Report the charger type from extcon device.
+ * @gadget: One usb charger is always tied to one usb gadget.
+ * @old_gadget_state: Record the previous state of one usb gadget to check if
+ * the gadget state is changed. If gadget state is changed, then notify the
+ * event to charger.
+ * @sdp_default_cur_change: Check if it is needed to change the SDP charger
+ * default maximum current.
+ * @charger_detect: User can detect the charger type by software or hardware,
+ * then the charger detection method can be implemented if you need to detect
+ * the charger type by software.
+ *
+ * Users can set and 'charger_detect' callbacks directly according to their
+ * own requirements. Beyond that, users can not touch anything else directly
+ * in this structure.
+ */
+struct usb_charger {
+ char name[CHARGER_NAME_MAX];
+ struct list_head list;
+ struct raw_notifier_head uchger_nh;
+ struct mutex lock;
+ int id;
+ enum usb_charger_type type;
+ enum usb_charger_state state;
+ struct usb_charger_current cur;
+ struct work_struct work;
+
+ struct extcon_dev *extcon_dev;
+ struct usb_charger_nb extcon_nb;
+ struct usb_charger_nb extcon_type_nb;
+
+ struct usb_gadget *gadget;
+ enum usb_device_state old_gadget_state;
+ unsigned int sdp_default_cur_change;
+
+ enum usb_charger_type (*charger_detect)(struct usb_charger *);
+};
+
+#ifdef CONFIG_USB_CHARGER
+struct usb_charger *usb_charger_get_instance(void);
+
+int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb);
+int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb);
+
+int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min, unsigned int *max);
+
+int usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit);
+int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit);
+
+int usb_charger_plug_by_gadget(struct usb_gadget *gadget, unsigned long state);
+enum usb_charger_type usb_charger_get_type(struct usb_charger *uchger);
+int usb_charger_detect_type(struct usb_charger *uchger);
+enum usb_charger_state usb_charger_get_state(struct usb_charger *uchger);
+
+int usb_charger_init(struct usb_gadget *ugadget);
+int usb_charger_exit(struct usb_gadget *ugadget);
+#else
+static inline struct usb_charger *usb_charger_get_instance(void)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min, unsigned int *max)
+{
+ return 0;
+}
+
+static inline int
+usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+
+static inline int
+usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+
+static inline enum usb_charger_type
+usb_charger_get_type(struct usb_charger *uchger)
+{
+ return UNKNOWN_TYPE;
+}
+
+static inline enum usb_charger_state
+usb_charger_get_state(struct usb_charger *uchger)
+{
+ return USB_CHARGER_REMOVE;
+}
+
+static inline int usb_charger_detect_type(struct usb_charger *uchger)
+{
+ return 0;
+}
+
+static inline int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
+ unsigned long state)
+{
+ return 0;
+}
+
+static inline int usb_charger_init(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+
+static inline int usb_charger_exit(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+#endif
+
+#endif /* __LINUX_USB_CHARGER_H__ */
diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 0000000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+ UNKNOWN_TYPE,
+ SDP_TYPE,
+ DCP_TYPE,
+ CDP_TYPE,
+ ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+ USB_CHARGER_DEFAULT,
+ USB_CHARGER_PRESENT,
+ USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
--
1.7.9.5
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v19 1/4] usb: gadget: Introduce the usb charger framework
@ 2017-02-20 8:51 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
sre-DgEjT+Ai2ygdnm+yROfE0A, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, jun.li-3arQi8VN3Tc,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
ruslan.bilovol-Re5JQEeQqe8AvxtiuMwx3w,
peter.chen-KZfg59tc24xl57MIdRCFDg,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
grygorii.strashko-l0cyMroinI0,
yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
john.stultz-QSEj5FYQhm4dnm+yROfE0A, neilb-IBi9RG/b67k,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
baolin.wang-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
device-mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.
The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.
Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.
This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.
Signed-off-by: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Li Jun <jun.li-3arQi8VN3Tc@public.gmane.org>
Tested-by: Li Jun <jun.li-3arQi8VN3Tc@public.gmane.org>
---
drivers/usb/gadget/Kconfig | 8 +
drivers/usb/gadget/udc/Makefile | 1 +
drivers/usb/gadget/udc/charger.c | 770 ++++++++++++++++++++++++++++++++++++++
include/linux/usb/charger.h | 176 +++++++++
include/uapi/linux/usb/charger.h | 31 ++
5 files changed, 986 insertions(+)
create mode 100644 drivers/usb/gadget/udc/charger.c
create mode 100644 include/linux/usb/charger.h
create mode 100644 include/uapi/linux/usb/charger.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8ad2032..60d2f29 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
It supports the serial gadget can be used as a console.
+config USB_CHARGER
+ bool "USB charger support"
+ select EXTCON
+ help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
source "drivers/usb/gadget/udc/Kconfig"
#
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
CFLAGS_trace.o := -I$(src)
udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
#
# USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 0000000..6d62f54
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,770 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/extcon.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/usb.h>
+#include <linux/usb/ch9.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/charger.h>
+
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN 2
+#define DEFAULT_SDP_CUR_MAX 500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN 500
+#define DEFAULT_DCP_CUR_MAX 5000
+#define DEFAULT_CDP_CUR_MIN 1500
+#define DEFAULT_CDP_CUR_MAX 5000
+#define DEFAULT_ACA_CUR_MIN 1500
+#define DEFAULT_ACA_CUR_MAX 5000
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+ return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current.
+ */
+static ssize_t charger_current_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ unsigned int min, max;
+
+ usb_charger_get_current(uchger, &min, &max);
+ return sprintf(buf, "%u-%u\n", min, max);
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ enum usb_charger_type type = usb_charger_get_type(uchger);
+ int cnt;
+
+ switch (type) {
+ case SDP_TYPE:
+ cnt = sprintf(buf, "%s\n", "SDP");
+ break;
+ case DCP_TYPE:
+ cnt = sprintf(buf, "%s\n", "DCP");
+ break;
+ case CDP_TYPE:
+ cnt = sprintf(buf, "%s\n", "CDP");
+ break;
+ case ACA_TYPE:
+ cnt = sprintf(buf, "%s\n", "ACA");
+ break;
+ default:
+ cnt = sprintf(buf, "%s\n", "UNKNOWN");
+ break;
+ }
+
+ return cnt;
+}
+static DEVICE_ATTR_RO(charger_type);
+
+/*
+ * charger_state_show() - Show the charger state.
+ *
+ * Charger state can be present or removed.
+ */
+static ssize_t charger_state_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ enum usb_charger_state state = usb_charger_get_state(uchger);
+ int cnt;
+
+ switch (state) {
+ case USB_CHARGER_PRESENT:
+ cnt = sprintf(buf, "%s\n", "PRESENT");
+ break;
+ case USB_CHARGER_ABSENT:
+ cnt = sprintf(buf, "%s\n", "REMOVE");
+ break;
+ default:
+ cnt = sprintf(buf, "%s\n", "UNKNOWN");
+ break;
+ }
+
+ return cnt;
+}
+static DEVICE_ATTR_RO(charger_state);
+
+static struct attribute *usb_charger_attrs[] = {
+ &dev_attr_charger_current.attr,
+ &dev_attr_charger_type.attr,
+ &dev_attr_charger_state.attr,
+ NULL
+};
+
+static const struct attribute_group usb_charger_group = {
+ .name = "charger",
+ .attrs = usb_charger_attrs,
+};
+__ATTRIBUTE_GROUPS(usb_charger);
+
+/*
+ * usb_charger_get_instance() - Get the first usb charger instance.
+ *
+ * Note: We assume that there is only one USB charger in the system.
+ */
+struct usb_charger *usb_charger_get_instance()
+{
+ struct usb_charger *uchger;
+
+ mutex_lock(&charger_lock);
+ list_for_each_entry(uchger, &charger_list, list) {
+ if (uchger->name)
+ break;
+ }
+ mutex_unlock(&charger_lock);
+
+ if (WARN(!uchger, "can't find usb charger"))
+ return ERR_PTR(-ENODEV);
+
+ return uchger;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_instance);
+
+/*
+ * usb_charger_get_type() - get the usb charger type with lock protection.
+ * @uchger - usb charger instance.
+ *
+ * Users can get the charger type by this safe API, rather than using the
+ * usb_charger structure directly.
+ */
+enum usb_charger_type usb_charger_get_type(struct usb_charger *uchger)
+{
+ enum usb_charger_type type;
+
+ mutex_lock(&uchger->lock);
+ type = uchger->type;
+ mutex_unlock(&uchger->lock);
+
+ return type;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_type);
+
+/*
+ * usb_charger_get_state() - Get the charger state with lock protection.
+ * @uchger - the usb charger instance.
+ *
+ * Users should get the charger state by this safe API.
+ */
+enum usb_charger_state usb_charger_get_state(struct usb_charger *uchger)
+{
+ enum usb_charger_state state;
+
+ mutex_lock(&uchger->lock);
+ state = uchger->state;
+ mutex_unlock(&uchger->lock);
+
+ return state;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_state);
+
+/*
+ * usb_charger_detect_type() - detect the charger type manually.
+ * @uchger - usb charger instance.
+ *
+ * Note: You should ensure you need to detect the charger type manually on
+ * your platform. You should call it at the right gadget state to avoid
+ * affecting gadget enumeration.
+ */
+int usb_charger_detect_type(struct usb_charger *uchger)
+{
+ enum usb_charger_type type;
+
+ if (!uchger->charger_detect)
+ return -EINVAL;
+
+ type = uchger->charger_detect(uchger);
+
+ mutex_lock(&uchger->lock);
+ uchger->type = type;
+ mutex_unlock(&uchger->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_detect_type);
+
+/*
+ * usb_charger_set_default_current() - Set default current for charger.
+ * @uchger - usb charger instance.
+ */
+static void usb_charger_set_default_current(struct usb_charger *uchger)
+{
+ uchger->cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+ uchger->cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+ uchger->cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+ uchger->cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+ uchger->cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+ uchger->cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+ uchger->cur.aca_min = DEFAULT_ACA_CUR_MIN;
+ uchger->cur.aca_max = DEFAULT_ACA_CUR_MAX;
+ uchger->sdp_default_cur_change = 0;
+}
+
+/*
+ * __usb_charger_get_current() - Get the charger current.
+ * @uchger - the usb charger instance.
+ * @min - return the minimum current.
+ * @max - return the maximum current.
+ *
+ * Callers should get the charger lock before issuing this function.
+ */
+static void __usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min,
+ unsigned int *max)
+{
+ enum usb_charger_type type = uchger->type;
+
+ switch (type) {
+ case SDP_TYPE:
+ /*
+ * For super speed gadget, the default charger maximum current
+ * should be 900 mA and the default minimum current should be
+ * 150mA.
+ */
+ if (uchger->gadget &&
+ uchger->gadget->speed >= USB_SPEED_SUPER) {
+ if (!uchger->sdp_default_cur_change)
+ uchger->cur.sdp_max = DEFAULT_SDP_CUR_MAX_SS;
+
+ uchger->cur.sdp_min = DEFAULT_SDP_CUR_MIN_SS;
+ }
+
+ *min = uchger->cur.sdp_min;
+ *max = uchger->cur.sdp_max;
+ break;
+ case DCP_TYPE:
+ *min = uchger->cur.dcp_min;
+ *max = uchger->cur.dcp_max;
+ break;
+ case CDP_TYPE:
+ *min = uchger->cur.cdp_min;
+ *max = uchger->cur.cdp_max;
+ break;
+ case ACA_TYPE:
+ *min = uchger->cur.aca_min;
+ *max = uchger->cur.aca_max;
+ break;
+ default:
+ *min = 0;
+ *max = 0;
+ break;
+ }
+}
+
+/*
+ * usb_charger_get_cur_limit() - Get the maximum charger current.
+ * @uchger - the usb charger instance.
+ *
+ * This function should under the charger lock protection.
+ */
+static unsigned int usb_charger_get_cur_limit(struct usb_charger *uchger)
+{
+ unsigned int min_cur, max_cur;
+
+ __usb_charger_get_current(uchger, &min_cur, &max_cur);
+ return max_cur;
+}
+
+/*
+ * usb_charger_get_current() - Get the charger current with lock protection.
+ * @uchger - the usb charger instance.
+ * @min - return the minimum current.
+ * @max - return the maximum current.
+ *
+ * Users should get the charger current by this safe API.
+ */
+int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min,
+ unsigned int *max)
+{
+ if (!uchger)
+ return -EINVAL;
+
+ mutex_lock(&uchger->lock);
+ __usb_charger_get_current(uchger, min, max);
+ mutex_unlock(&uchger->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_get_current);
+
+/*
+ * usb_charger_notify_work() - Notify users the current has changed by work.
+ * @work - the work instance.
+ *
+ * Note: When users receive the charger present event, they should check the
+ * charger current by usb_charger_get_current() API.
+ */
+static void usb_charger_notify_work(struct work_struct *work)
+{
+ struct usb_charger *uchger = work_to_charger(work);
+
+ mutex_lock(&uchger->lock);
+ if (uchger->state == USB_CHARGER_PRESENT) {
+ raw_notifier_call_chain(&uchger->uchger_nh,
+ usb_charger_get_cur_limit(uchger),
+ uchger);
+ }
+ mutex_unlock(&uchger->lock);
+}
+
+/*
+ * __usb_charger_set_cur_limit_by_type() - Set the current limitation
+ * by charger type.
+ * @uchger - the usb charger instance.
+ * @type - the usb charger type.
+ * @cur_limit - the current limitation.
+ */
+static int __usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ switch (type) {
+ case SDP_TYPE:
+ if (uchger->gadget && uchger->gadget->speed >= USB_SPEED_SUPER) {
+ uchger->cur.sdp_max =
+ (cur_limit > DEFAULT_SDP_CUR_MAX_SS) ?
+ DEFAULT_SDP_CUR_MAX_SS : cur_limit;
+ } else {
+ uchger->cur.sdp_max =
+ (cur_limit > DEFAULT_SDP_CUR_MAX) ?
+ DEFAULT_SDP_CUR_MAX : cur_limit;
+ }
+
+ uchger->sdp_default_cur_change = 1;
+ break;
+ case DCP_TYPE:
+ uchger->cur.dcp_max = (cur_limit > DEFAULT_DCP_CUR_MAX) ?
+ DEFAULT_DCP_CUR_MAX : cur_limit;
+ break;
+ case CDP_TYPE:
+ uchger->cur.cdp_max = (cur_limit > DEFAULT_CDP_CUR_MAX) ?
+ DEFAULT_CDP_CUR_MAX : cur_limit;
+ break;
+ case ACA_TYPE:
+ uchger->cur.aca_max = (cur_limit > DEFAULT_ACA_CUR_MAX) ?
+ DEFAULT_ACA_CUR_MAX : cur_limit;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
+ * usb_charger_set_cur_limit_by_gadget() - Set the current limitation from
+ * gadget layer.
+ * @gadget - the usb gadget device.
+ * @cur_limit - the current limitation.
+ *
+ * Note: This function is used in atomic contexts without mutex lock.
+ */
+int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
+
+/*
+ * usb_charger_set_cur_limit_by_type() - Set the current limitation
+ * by charger type with lock protection.
+ * @uchger - the usb charger instance.
+ * @type - the usb charger type.
+ * @cur_limit - the current limitation.
+ *
+ * Users should set the current limitation by this lock protection API.
+ */
+int usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ int ret;
+
+ if (!uchger)
+ return -EINVAL;
+
+ mutex_lock(&uchger->lock);
+ ret = __usb_charger_set_cur_limit_by_type(uchger, type, cur_limit);
+ mutex_unlock(&uchger->lock);
+ if (ret)
+ return ret;
+
+ schedule_work(&uchger->work);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_type);
+
+/*
+ * usb_charger_register_notify() - Register a notifiee to get notified by
+ * any attach status changes from the usb charger detection.
+ * @uchger - the usb charger instance which is monitored.
+ * @nb - a notifier block to be registered.
+ */
+int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ int ret;
+
+ if (!uchger || !nb) {
+ pr_err("Charger or nb can not be NULL.\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&uchger->lock);
+ ret = raw_notifier_chain_register(&uchger->uchger_nh, nb);
+ mutex_unlock(&uchger->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_register_notify);
+
+/*
+ * usb_charger_unregister_notify() - Unregister a notifiee from the usb charger.
+ * @uchger - the usb charger instance which is monitored.
+ * @nb - a notifier block to be unregistered.
+ */
+int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ int ret;
+
+ if (!uchger || !nb) {
+ pr_err("Charger or nb can not be NULL.\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(&uchger->lock);
+ ret = raw_notifier_chain_unregister(&uchger->uchger_nh, nb);
+ mutex_unlock(&uchger->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_charger_unregister_notify);
+
+/*
+ * usb_charger_notify_state() - It will notify other device registered
+ * on usb charger when the usb charger state is changed.
+ * @uchger - the usb charger instance.
+ * @state - the state of the usb charger.
+ *
+ * Note: When notify the charger present state to power driver, the power driver
+ * should get the current by usb_charger_get_current() API to set current.
+ */
+static void usb_charger_notify_state(struct usb_charger *uchger,
+ enum usb_charger_state state)
+{
+ char uchger_state[50] = { 0 };
+ char *envp[] = { uchger_state, NULL };
+
+ mutex_lock(&uchger->lock);
+ if (uchger->state == state) {
+ mutex_unlock(&uchger->lock);
+ return;
+ }
+
+ uchger->state = state;
+
+ switch (state) {
+ case USB_CHARGER_PRESENT:
+ raw_notifier_call_chain(&uchger->uchger_nh,
+ usb_charger_get_cur_limit(uchger),
+ uchger);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+ "USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+ break;
+ case USB_CHARGER_ABSENT:
+ uchger->type = UNKNOWN_TYPE;
+ usb_charger_set_default_current(uchger);
+ raw_notifier_call_chain(&uchger->uchger_nh, 0, uchger);
+ snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+ "USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+ break;
+ default:
+ pr_warn("Unknown USB charger state: %d\n", state);
+ mutex_unlock(&uchger->lock);
+ return;
+ }
+
+ kobject_uevent_env(&uchger->gadget->dev.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(&uchger->lock);
+}
+
+/*
+ * usb_charger_type_by_extcon() - The notifier call function which is registered
+ * on the extcon device.
+ * @nb - the notifier block that notified by extcon device.
+ * @state - the extcon device state.
+ * @data - here specify a extcon device.
+ *
+ * return the notify flag.
+ */
+static int usb_charger_type_by_extcon(struct notifier_block *nb,
+ unsigned long state, void *data)
+{
+ struct usb_charger_nb *extcon_nb =
+ container_of(nb, struct usb_charger_nb, nb);
+ struct usb_charger *uchger = extcon_nb->uchger;
+ enum usb_charger_state uchger_state;
+ enum usb_charger_type type;
+
+ if (WARN(!uchger, "charger can not be NULL"))
+ return NOTIFY_BAD;
+
+ /* Determine charger type */
+ if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_SDP) > 0) {
+ type = SDP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_CDP) > 0) {
+ type = CDP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_DCP) > 0) {
+ type = DCP_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (extcon_get_cable_state_(uchger->extcon_dev,
+ EXTCON_CHG_USB_ACA) > 0) {
+ type = ACA_TYPE;
+ uchger_state = USB_CHARGER_PRESENT;
+ } else {
+ type = UNKNOWN_TYPE;
+ uchger_state = USB_CHARGER_ABSENT;
+ }
+
+ mutex_lock(&uchger->lock);
+ uchger->type = type;
+ mutex_unlock(&uchger->lock);
+
+ usb_charger_notify_state(uchger, uchger_state);
+
+ return NOTIFY_OK;
+}
+
+/*
+ * usb_charger_plug_by_extcon() - The notifier call function which is registered
+ * on the extcon device.
+ * @nb - the notifier block that notified by extcon device.
+ * @state - the extcon device state.
+ * @data - here specify a extcon device.
+ *
+ * return the notify flag.
+ */
+static int usb_charger_plug_by_extcon(struct notifier_block *nb,
+ unsigned long state, void *data)
+{
+ struct usb_charger_nb *extcon_nb =
+ container_of(nb, struct usb_charger_nb, nb);
+ struct usb_charger *uchger = extcon_nb->uchger;
+ enum usb_charger_state uchger_state;
+
+ if (WARN(!uchger, "charger can not be NULL"))
+ return NOTIFY_BAD;
+
+ /*
+ * Report event to power users to setting the current limitation
+ * for this usb charger when one usb charger is added or removed
+ * with detecting by extcon device.
+ */
+ if (state)
+ uchger_state = USB_CHARGER_PRESENT;
+ else
+ uchger_state = USB_CHARGER_ABSENT;
+
+ usb_charger_notify_state(uchger, uchger_state);
+
+ return NOTIFY_OK;
+}
+
+/*
+ * usb_charger_plug_by_gadget() - Set the usb charger current limitation
+ * according to the usb gadget device state.
+ * @gadget - the usb gadget device.
+ * @state - the usb gadget state.
+ */
+int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
+ unsigned long state)
+{
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
+
+/*
+ * usb_charger_register() - Register a new usb charger.
+ * @uchger - the new usb charger instance.
+ */
+static int usb_charger_register(struct usb_charger *uchger)
+{
+ int ret;
+
+ ret = ida_simple_get(&usb_charger_ida, 0, 0, GFP_KERNEL);
+ if (ret < 0) {
+ pr_err("Failed to register usb charger: %d\n", ret);
+ return ret;
+ }
+
+ uchger->id = ret;
+ scnprintf(uchger->name, CHARGER_NAME_MAX, "usb-charger.%d", uchger->id);
+
+ ret = sysfs_create_groups(&uchger->gadget->dev.kobj,
+ usb_charger_groups);
+ if (ret) {
+ pr_err("Failed to create usb charger attributes: %d\n", ret);
+ ida_simple_remove(&usb_charger_ida, uchger->id);
+ uchger->id = -1;
+ return ret;
+ }
+
+ mutex_lock(&charger_lock);
+ list_add_tail(&uchger->list, &charger_list);
+ mutex_unlock(&charger_lock);
+
+ return 0;
+}
+
+int usb_charger_init(struct usb_gadget *ugadget)
+{
+ struct usb_charger *uchger;
+ struct extcon_dev *edev;
+ int ret;
+
+ uchger = kzalloc(sizeof(struct usb_charger), GFP_KERNEL);
+ if (!uchger)
+ return -ENOMEM;
+
+ uchger->type = UNKNOWN_TYPE;
+ uchger->state = USB_CHARGER_DEFAULT;
+ uchger->id = -1;
+ usb_charger_set_default_current(uchger);
+
+ mutex_init(&uchger->lock);
+ RAW_INIT_NOTIFIER_HEAD(&uchger->uchger_nh);
+ INIT_WORK(&uchger->work, usb_charger_notify_work);
+
+ /* Register a notifier on a extcon device if it is exsited */
+ edev = extcon_get_edev_by_phandle(ugadget->dev.parent, 0);
+ if (!IS_ERR_OR_NULL(edev)) {
+ uchger->extcon_dev = edev;
+ uchger->extcon_nb.nb.notifier_call = usb_charger_plug_by_extcon;
+ uchger->extcon_nb.uchger = uchger;
+ ret = extcon_register_notifier(edev, EXTCON_USB,
+ &uchger->extcon_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB notifier.\n");
+ goto fail_extcon;
+ }
+
+ uchger->extcon_type_nb.nb.notifier_call =
+ usb_charger_type_by_extcon;
+ uchger->extcon_type_nb.uchger = uchger;
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_SDP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB SDP notifier.\n");
+ goto fail_extcon_sdp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_CDP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB CDP notifier.\n");
+ goto fail_extcon_cdp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_DCP,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB DCP notifier.\n");
+ goto fail_extcon_dcp;
+ }
+
+ ret = extcon_register_notifier(edev, EXTCON_CHG_USB_ACA,
+ &uchger->extcon_type_nb.nb);
+ if (ret) {
+ pr_err("Failed to register extcon USB ACA notifier.\n");
+ goto fail_extcon_aca;
+ }
+ }
+
+ uchger->gadget = ugadget;
+ uchger->old_gadget_state = USB_STATE_NOTATTACHED;
+
+ /* Register a new usb charger */
+ ret = usb_charger_register(uchger);
+ if (ret)
+ goto fail_register;
+
+ return 0;
+
+fail_register:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_ACA,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_aca:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_DCP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_dcp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_CDP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_cdp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_SDP,
+ &uchger->extcon_type_nb.nb);
+fail_extcon_sdp:
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_USB,
+ &uchger->extcon_nb.nb);
+fail_extcon:
+ kfree(uchger);
+
+ return ret;
+}
+
+int usb_charger_exit(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+
+MODULE_AUTHOR("Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
+MODULE_DESCRIPTION("USB charger driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/charger.h b/include/linux/usb/charger.h
new file mode 100644
index 0000000..e9b1c8a
--- /dev/null
+++ b/include/linux/usb/charger.h
@@ -0,0 +1,176 @@
+#ifndef __LINUX_USB_CHARGER_H__
+#define __LINUX_USB_CHARGER_H__
+
+#include <uapi/linux/usb/ch9.h>
+#include <uapi/linux/usb/charger.h>
+
+#define CHARGER_NAME_MAX 30
+#define work_to_charger(w) (container_of((w), struct usb_charger, work))
+
+/* Current range by charger type */
+struct usb_charger_current {
+ unsigned int sdp_min;
+ unsigned int sdp_max;
+ unsigned int dcp_min;
+ unsigned int dcp_max;
+ unsigned int cdp_min;
+ unsigned int cdp_max;
+ unsigned int aca_min;
+ unsigned int aca_max;
+};
+
+struct usb_charger_nb {
+ struct notifier_block nb;
+ struct usb_charger *uchger;
+};
+
+/**
+ * struct usb_charger - describe one usb charger
+ * @name: Charger name.
+ * @list: For linking usb charger instances into one global list.
+ * @uchger_nh: Notifier head for users to register.
+ * @lock: Protect the notifier head and charger.
+ * @id: The charger id.
+ * @type: The charger type, it can be SDP_TYPE, DCP_TYPE, CDP_TYPE or
+ * ACA_TYPE.
+ * @state: Indicate the charger state.
+ * @cur: Describe the current range by charger type.
+ * @work: Workqueue to be used for reporting users current has changed.
+ * @extcon_dev: For supporting extcon usb gpio device to detect usb cable
+ * event (plugin or not).
+ * @extcon_nb: Report the events to charger from extcon device.
+ * @extcon_type_nb: Report the charger type from extcon device.
+ * @gadget: One usb charger is always tied to one usb gadget.
+ * @old_gadget_state: Record the previous state of one usb gadget to check if
+ * the gadget state is changed. If gadget state is changed, then notify the
+ * event to charger.
+ * @sdp_default_cur_change: Check if it is needed to change the SDP charger
+ * default maximum current.
+ * @charger_detect: User can detect the charger type by software or hardware,
+ * then the charger detection method can be implemented if you need to detect
+ * the charger type by software.
+ *
+ * Users can set and 'charger_detect' callbacks directly according to their
+ * own requirements. Beyond that, users can not touch anything else directly
+ * in this structure.
+ */
+struct usb_charger {
+ char name[CHARGER_NAME_MAX];
+ struct list_head list;
+ struct raw_notifier_head uchger_nh;
+ struct mutex lock;
+ int id;
+ enum usb_charger_type type;
+ enum usb_charger_state state;
+ struct usb_charger_current cur;
+ struct work_struct work;
+
+ struct extcon_dev *extcon_dev;
+ struct usb_charger_nb extcon_nb;
+ struct usb_charger_nb extcon_type_nb;
+
+ struct usb_gadget *gadget;
+ enum usb_device_state old_gadget_state;
+ unsigned int sdp_default_cur_change;
+
+ enum usb_charger_type (*charger_detect)(struct usb_charger *);
+};
+
+#ifdef CONFIG_USB_CHARGER
+struct usb_charger *usb_charger_get_instance(void);
+
+int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb);
+int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb);
+
+int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min, unsigned int *max);
+
+int usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit);
+int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit);
+
+int usb_charger_plug_by_gadget(struct usb_gadget *gadget, unsigned long state);
+enum usb_charger_type usb_charger_get_type(struct usb_charger *uchger);
+int usb_charger_detect_type(struct usb_charger *uchger);
+enum usb_charger_state usb_charger_get_state(struct usb_charger *uchger);
+
+int usb_charger_init(struct usb_gadget *ugadget);
+int usb_charger_exit(struct usb_gadget *ugadget);
+#else
+static inline struct usb_charger *usb_charger_get_instance(void)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline int usb_charger_register_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int usb_charger_unregister_notify(struct usb_charger *uchger,
+ struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline int usb_charger_get_current(struct usb_charger *uchger,
+ unsigned int *min, unsigned int *max)
+{
+ return 0;
+}
+
+static inline int
+usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
+ enum usb_charger_type type,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+
+static inline int
+usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
+ unsigned int cur_limit)
+{
+ return 0;
+}
+
+static inline enum usb_charger_type
+usb_charger_get_type(struct usb_charger *uchger)
+{
+ return UNKNOWN_TYPE;
+}
+
+static inline enum usb_charger_state
+usb_charger_get_state(struct usb_charger *uchger)
+{
+ return USB_CHARGER_REMOVE;
+}
+
+static inline int usb_charger_detect_type(struct usb_charger *uchger)
+{
+ return 0;
+}
+
+static inline int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
+ unsigned long state)
+{
+ return 0;
+}
+
+static inline int usb_charger_init(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+
+static inline int usb_charger_exit(struct usb_gadget *ugadget)
+{
+ return 0;
+}
+#endif
+
+#endif /* __LINUX_USB_CHARGER_H__ */
diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 0000000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+ UNKNOWN_TYPE,
+ SDP_TYPE,
+ DCP_TYPE,
+ CDP_TYPE,
+ ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+ USB_CHARGER_DEFAULT,
+ USB_CHARGER_PRESENT,
+ USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v19 2/4] usb: gadget: Support for the usb charger framework
2017-02-20 8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2017-02-20 8:51 ` Baolin Wang
@ 2017-02-20 8:51 ` Baolin Wang
2017-02-20 10:08 ` kbuild test robot
2017-02-20 8:51 ` [PATCH v19 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
` (3 subsequent siblings)
5 siblings, 1 reply; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Reviewed-by: Li Jun <jun.li@nxp.com>
Tested-by: Li Jun <jun.li@nxp.com>
---
drivers/usb/gadget/udc/core.c | 19 ++++++++++++++++++-
include/linux/usb/gadget.h | 3 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489..90df022 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -25,6 +25,7 @@
#include <linux/dma-mapping.h>
#include <linux/workqueue.h>
+#include <linux/usb/charger.h>
#include <linux/usb/ch9.h>
#include <linux/usb/gadget.h>
#include <linux/usb.h>
@@ -576,12 +577,17 @@ int usb_gadget_vbus_connect(struct usb_gadget *gadget)
* reporting how much power the device may consume. For example, this
* could affect how quickly batteries are recharged.
*
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
* Returns zero on success, else negative errno.
*/
int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
{
int ret = 0;
+ usb_charger_set_cur_limit_by_gadget(gadget, mA);
+
if (!gadget->ops->vbus_draw) {
ret = -EOPNOTSUPP;
goto out;
@@ -963,6 +969,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
+ /* when the gadget state is changed, then report to USB charger */
+ usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(&udc->dev.kobj, NULL, "state");
}
@@ -1132,6 +1141,10 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
if (ret)
goto err4;
+ ret = usb_charger_init(gadget);
+ if (ret)
+ goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
@@ -1143,7 +1156,7 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
if (ret != -EPROBE_DEFER)
list_del(&driver->pending);
if (ret)
- goto err5;
+ goto err6;
break;
}
}
@@ -1152,6 +1165,9 @@ int usb_add_gadget_udc_release(struct device *parent, struct usb_gadget *gadget,
return 0;
+err6:
+ usb_charger_exit(gadget);
+
err5:
device_del(&udc->dev);
@@ -1263,6 +1279,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
device_unregister(&udc->dev);
+ usb_charger_exit(gadget);
device_unregister(&gadget->dev);
}
EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9..b4d7be2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
#include <linux/types.h>
#include <linux/workqueue.h>
#include <linux/usb/ch9.h>
+#include <linux/usb/charger.h>
#define UDC_TRACE_STR_MAX 512
@@ -328,6 +329,7 @@ struct usb_gadget_ops {
* @in_epnum: last used in ep number
* @mA: last set mA value
* @otg_caps: OTG capabilities of this gadget.
+ * @charger: Negotiate the power with the usb charger.
* @sg_supported: true if we can handle scatter-gather
* @is_otg: True if the USB device port uses a Mini-AB jack, so that the
* gadget driver must provide a USB OTG descriptor.
@@ -387,6 +389,7 @@ struct usb_gadget {
unsigned in_epnum;
unsigned mA;
struct usb_otg_caps *otg_caps;
+ struct usb_charger *charger;
unsigned sg_supported:1;
unsigned is_otg:1;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v19 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger
2017-02-20 8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2017-02-20 8:51 ` Baolin Wang
2017-02-20 8:51 ` [PATCH v19 2/4] usb: gadget: Support for " Baolin Wang
@ 2017-02-20 8:51 ` Baolin Wang
2017-02-20 8:51 ` Baolin Wang
` (2 subsequent siblings)
5 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Reviewed-by: Li Jun <jun.li@nxp.com>
Tested-by: Li Jun <jun.li@nxp.com>
---
drivers/usb/gadget/udc/charger.c | 97 +++++++++++++++++++++++++++++++++++++-
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index 6d62f54..19eb044 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -38,7 +38,9 @@
static struct usb_charger *dev_to_uchger(struct device *dev)
{
- return NULL;
+ struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+ return gadget->charger;
}
/*
@@ -398,6 +400,18 @@ static int __usb_charger_set_cur_limit_by_type(struct usb_charger *uchger,
int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
unsigned int cur_limit)
{
+ struct usb_charger *uchger = gadget->charger;
+ int ret;
+
+ if (!uchger)
+ return -EINVAL;
+
+ ret = __usb_charger_set_cur_limit_by_type(uchger, uchger->type,
+ cur_limit);
+ if (ret)
+ return ret;
+
+ schedule_work(&uchger->work);
return 0;
}
EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
@@ -622,11 +636,66 @@ static int usb_charger_plug_by_extcon(struct notifier_block *nb,
int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
unsigned long state)
{
+ struct usb_charger *uchger = gadget->charger;
+ enum usb_charger_state uchger_state;
+
+ if (WARN(!uchger, "charger can not be NULL"))
+ return -EINVAL;
+
+ /*
+ * Report event to power to setting the current limitation
+ * for this usb charger when one usb charger state is changed
+ * with detecting by usb gadget state.
+ */
+ if (uchger->old_gadget_state != state) {
+ uchger->old_gadget_state = state;
+
+ if (state >= USB_STATE_ATTACHED) {
+ uchger_state = USB_CHARGER_PRESENT;
+ } else if (state == USB_STATE_NOTATTACHED) {
+ mutex_lock(&uchger->lock);
+
+ /*
+ * Need check the charger type to make sure the usb
+ * cable is removed, in case it just changes the usb
+ * function with configfs.
+ */
+ if (uchger->type != UNKNOWN_TYPE) {
+ mutex_unlock(&uchger->lock);
+ return 0;
+ }
+
+ mutex_unlock(&uchger->lock);
+ uchger_state = USB_CHARGER_ABSENT;
+ } else {
+ uchger_state = USB_CHARGER_DEFAULT;
+ }
+
+ usb_charger_notify_state(uchger, uchger_state);
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
/*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+ ida_simple_remove(&usb_charger_ida, uchger->id);
+ sysfs_remove_groups(&uchger->gadget->dev.kobj, usb_charger_groups);
+ uchger->id = -1;
+
+ mutex_lock(&charger_lock);
+ list_del(&uchger->list);
+ mutex_unlock(&charger_lock);
+
+ return 0;
+}
+
+/*
* usb_charger_register() - Register a new usb charger.
* @uchger - the new usb charger instance.
*/
@@ -725,6 +794,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
}
uchger->gadget = ugadget;
+ ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
/* Register a new usb charger */
@@ -762,6 +832,31 @@ int usb_charger_init(struct usb_gadget *ugadget)
int usb_charger_exit(struct usb_gadget *ugadget)
{
+ struct usb_charger *uchger = ugadget->charger;
+
+ if (!uchger)
+ return -EINVAL;
+
+ usb_charger_unregister(uchger);
+ ugadget->charger = NULL;
+
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_USB,
+ &uchger->extcon_nb.nb);
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_SDP,
+ &uchger->extcon_type_nb.nb);
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_CDP,
+ &uchger->extcon_type_nb.nb);
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_DCP,
+ &uchger->extcon_type_nb.nb);
+ extcon_unregister_notifier(uchger->extcon_dev,
+ EXTCON_CHG_USB_ACA,
+ &uchger->extcon_type_nb.nb);
+
+ kfree(uchger);
return 0;
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management
@ 2017-02-20 8:51 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
---
drivers/power/supply/wm831x_power.c | 63 +++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/drivers/power/supply/wm831x_power.c b/drivers/power/supply/wm831x_power.c
index 7082301..b5f1652 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/slab.h>
+#include <linux/usb/charger.h>
#include <linux/mfd/wm831x/core.h>
#include <linux/mfd/wm831x/auxadc.h>
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+ struct usb_charger *usb_charger;
+ struct notifier_block usb_notify;
};
static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,42 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+ unsigned long limit, void *data)
+{
+ struct wm831x_power *wm831x_power = container_of(nb,
+ struct wm831x_power,
+ usb_notify);
+
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit >= wm831x_usb_limits[i] &&
+ wm831x_usb_limits[best] < wm831x_usb_limits[i])
+ best = i;
+ }
+
+ dev_dbg(wm831x_power->wm831x->dev,
+ "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+ wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+ WM831X_USB_ILIM_MASK, best);
+
+ return 0;
+}
+
/*********************************************************************
* Battery properties
*********************************************************************/
@@ -607,8 +646,26 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
+ power->usb_charger = usb_charger_get_instance();
+ if (IS_ERR(power->usb_charger)) {
+ ret = PTR_ERR(power->usb_charger);
+ dev_err(&pdev->dev, "Failed to find USB gadget: %d\n", ret);
+ goto err_bat_irq;
+ }
+
+ power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+ ret = usb_charger_register_notify(power->usb_charger,
+ &power->usb_notify);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "Failed to register notifier: %d\n", ret);
+ goto err_usb_charger;
+ }
+
return ret;
+err_usb_charger:
+ /* put_device on charger */
err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +694,12 @@ static int wm831x_power_remove(struct platform_device *pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
+ if (wm831x_power->usb_charger) {
+ usb_charger_unregister_notify(wm831x_power->usb_charger,
+ &wm831x_power->usb_notify);
+ /* Free charger */
+ }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x,
platform_get_irq_byname(pdev,
--
1.7.9.5
^ permalink raw reply related [flat|nested] 50+ messages in thread
* [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management
@ 2017-02-20 8:51 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 8:51 UTC (permalink / raw)
To: balbi-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
sre-DgEjT+Ai2ygdnm+yROfE0A, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, jun.li-3arQi8VN3Tc,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
ruslan.bilovol-Re5JQEeQqe8AvxtiuMwx3w,
peter.chen-KZfg59tc24xl57MIdRCFDg,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
grygorii.strashko-l0cyMroinI0,
yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, broonie-DgEjT+Ai2ygdnm+yROfE0A,
john.stultz-QSEj5FYQhm4dnm+yROfE0A, neilb-IBi9RG/b67k,
ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
baolin.wang-QSEj5FYQhm4dnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
device-mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Acked-by: Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Acked-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
drivers/power/supply/wm831x_power.c | 63 +++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/drivers/power/supply/wm831x_power.c b/drivers/power/supply/wm831x_power.c
index 7082301..b5f1652 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
#include <linux/platform_device.h>
#include <linux/power_supply.h>
#include <linux/slab.h>
+#include <linux/usb/charger.h>
#include <linux/mfd/wm831x/core.h>
#include <linux/mfd/wm831x/auxadc.h>
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+ struct usb_charger *usb_charger;
+ struct notifier_block usb_notify;
};
static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,42 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+ unsigned long limit, void *data)
+{
+ struct wm831x_power *wm831x_power = container_of(nb,
+ struct wm831x_power,
+ usb_notify);
+
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit >= wm831x_usb_limits[i] &&
+ wm831x_usb_limits[best] < wm831x_usb_limits[i])
+ best = i;
+ }
+
+ dev_dbg(wm831x_power->wm831x->dev,
+ "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+ wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+ WM831X_USB_ILIM_MASK, best);
+
+ return 0;
+}
+
/*********************************************************************
* Battery properties
*********************************************************************/
@@ -607,8 +646,26 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
+ power->usb_charger = usb_charger_get_instance();
+ if (IS_ERR(power->usb_charger)) {
+ ret = PTR_ERR(power->usb_charger);
+ dev_err(&pdev->dev, "Failed to find USB gadget: %d\n", ret);
+ goto err_bat_irq;
+ }
+
+ power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+ ret = usb_charger_register_notify(power->usb_charger,
+ &power->usb_notify);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "Failed to register notifier: %d\n", ret);
+ goto err_usb_charger;
+ }
+
return ret;
+err_usb_charger:
+ /* put_device on charger */
err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +694,12 @@ static int wm831x_power_remove(struct platform_device *pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
+ if (wm831x_power->usb_charger) {
+ usb_charger_unregister_notify(wm831x_power->usb_charger,
+ &wm831x_power->usb_notify);
+ /* Free charger */
+ }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x,
platform_get_irq_byname(pdev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v19 2/4] usb: gadget: Support for the usb charger framework
2017-02-20 8:51 ` [PATCH v19 2/4] usb: gadget: Support for " Baolin Wang
@ 2017-02-20 10:08 ` kbuild test robot
0 siblings, 0 replies; 50+ messages in thread
From: kbuild test robot @ 2017-02-20 10:08 UTC (permalink / raw)
To: Baolin Wang
Cc: kbuild-all, balbi, gregkh, sre, dbaryshkov, dwmw2, robh, jun.li,
m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
Hi Baolin,
[auto build test ERROR on v4.9-rc8]
[cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
config: i386-randconfig-x015-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/usb/gadget/udc/core.c:28:0:
include/linux/usb/charger.h: In function 'usb_charger_get_state':
>> include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
return USB_CHARGER_REMOVE;
^~~~~~~~~~~~~~~~~~
include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
vim +/USB_CHARGER_REMOVE +151 include/linux/usb/charger.h
28929615 Baolin Wang 2017-02-20 145 return UNKNOWN_TYPE;
28929615 Baolin Wang 2017-02-20 146 }
28929615 Baolin Wang 2017-02-20 147
28929615 Baolin Wang 2017-02-20 148 static inline enum usb_charger_state
28929615 Baolin Wang 2017-02-20 149 usb_charger_get_state(struct usb_charger *uchger)
28929615 Baolin Wang 2017-02-20 150 {
28929615 Baolin Wang 2017-02-20 @151 return USB_CHARGER_REMOVE;
28929615 Baolin Wang 2017-02-20 152 }
28929615 Baolin Wang 2017-02-20 153
28929615 Baolin Wang 2017-02-20 154 static inline int usb_charger_detect_type(struct usb_charger *uchger)
:::::: The code at line 151 was first introduced by commit
:::::: 289296154f05985dedc08273f04d5b738450b3c7 usb: gadget: Introduce the usb charger framework
:::::: TO: Baolin Wang <baolin.wang@linaro.org>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29207 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 2/4] usb: gadget: Support for the usb charger framework
@ 2017-02-20 10:08 ` kbuild test robot
0 siblings, 0 replies; 50+ messages in thread
From: kbuild test robot @ 2017-02-20 10:08 UTC (permalink / raw)
Cc: kbuild-all, balbi, gregkh, sre, dbaryshkov, dwmw2, robh, jun.li,
m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
Hi Baolin,
[auto build test ERROR on v4.9-rc8]
[cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
config: i386-randconfig-x015-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/usb/gadget/udc/core.c:28:0:
include/linux/usb/charger.h: In function 'usb_charger_get_state':
>> include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
return USB_CHARGER_REMOVE;
^~~~~~~~~~~~~~~~~~
include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
vim +/USB_CHARGER_REMOVE +151 include/linux/usb/charger.h
28929615 Baolin Wang 2017-02-20 145 return UNKNOWN_TYPE;
28929615 Baolin Wang 2017-02-20 146 }
28929615 Baolin Wang 2017-02-20 147
28929615 Baolin Wang 2017-02-20 148 static inline enum usb_charger_state
28929615 Baolin Wang 2017-02-20 149 usb_charger_get_state(struct usb_charger *uchger)
28929615 Baolin Wang 2017-02-20 150 {
28929615 Baolin Wang 2017-02-20 @151 return USB_CHARGER_REMOVE;
28929615 Baolin Wang 2017-02-20 152 }
28929615 Baolin Wang 2017-02-20 153
28929615 Baolin Wang 2017-02-20 154 static inline int usb_charger_detect_type(struct usb_charger *uchger)
:::::: The code at line 151 was first introduced by commit
:::::: 289296154f05985dedc08273f04d5b738450b3c7 usb: gadget: Introduce the usb charger framework
:::::: TO: Baolin Wang <baolin.wang@linaro.org>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29207 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 2/4] usb: gadget: Support for the usb charger framework
2017-02-20 10:08 ` kbuild test robot
@ 2017-02-20 10:18 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 10:18 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, NeilBrown, Charles Keepax, patches, Linux PM list,
USB, device-mainlining, LKML
On 20 February 2017 at 18:08, kbuild test robot <lkp@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on v4.9-rc8]
> [cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
> config: i386-randconfig-x015-201708 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> In file included from drivers/usb/gadget/udc/core.c:28:0:
> include/linux/usb/charger.h: In function 'usb_charger_get_state':
>>> include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
> return USB_CHARGER_REMOVE;
Ah, missed fixing the state name without enable USB charger. Will fix
in next version.
> ^~~~~~~~~~~~~~~~~~
> include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
>
> vim +/USB_CHARGER_REMOVE +151 include/linux/usb/charger.h
>
> 28929615 Baolin Wang 2017-02-20 145 return UNKNOWN_TYPE;
> 28929615 Baolin Wang 2017-02-20 146 }
> 28929615 Baolin Wang 2017-02-20 147
> 28929615 Baolin Wang 2017-02-20 148 static inline enum usb_charger_state
> 28929615 Baolin Wang 2017-02-20 149 usb_charger_get_state(struct usb_charger *uchger)
> 28929615 Baolin Wang 2017-02-20 150 {
> 28929615 Baolin Wang 2017-02-20 @151 return USB_CHARGER_REMOVE;
> 28929615 Baolin Wang 2017-02-20 152 }
> 28929615 Baolin Wang 2017-02-20 153
> 28929615 Baolin Wang 2017-02-20 154 static inline int usb_charger_detect_type(struct usb_charger *uchger)
>
> :::::: The code at line 151 was first introduced by commit
> :::::: 289296154f05985dedc08273f04d5b738450b3c7 usb: gadget: Introduce the usb charger framework
>
> :::::: TO: Baolin Wang <baolin.wang@linaro.org>
> :::::: CC: 0day robot <fengguang.wu@intel.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 2/4] usb: gadget: Support for the usb charger framework
@ 2017-02-20 10:18 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-02-20 10:18 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, NeilBrown, Charles Keepax, patches, Linux PM list
On 20 February 2017 at 18:08, kbuild test robot <lkp@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on v4.9-rc8]
> [cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
> config: i386-randconfig-x015-201708 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
> In file included from drivers/usb/gadget/udc/core.c:28:0:
> include/linux/usb/charger.h: In function 'usb_charger_get_state':
>>> include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
> return USB_CHARGER_REMOVE;
Ah, missed fixing the state name without enable USB charger. Will fix
in next version.
> ^~~~~~~~~~~~~~~~~~
> include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
>
> vim +/USB_CHARGER_REMOVE +151 include/linux/usb/charger.h
>
> 28929615 Baolin Wang 2017-02-20 145 return UNKNOWN_TYPE;
> 28929615 Baolin Wang 2017-02-20 146 }
> 28929615 Baolin Wang 2017-02-20 147
> 28929615 Baolin Wang 2017-02-20 148 static inline enum usb_charger_state
> 28929615 Baolin Wang 2017-02-20 149 usb_charger_get_state(struct usb_charger *uchger)
> 28929615 Baolin Wang 2017-02-20 150 {
> 28929615 Baolin Wang 2017-02-20 @151 return USB_CHARGER_REMOVE;
> 28929615 Baolin Wang 2017-02-20 152 }
> 28929615 Baolin Wang 2017-02-20 153
> 28929615 Baolin Wang 2017-02-20 154 static inline int usb_charger_detect_type(struct usb_charger *uchger)
>
> :::::: The code at line 151 was first introduced by commit
> :::::: 289296154f05985dedc08273f04d5b738450b3c7 usb: gadget: Introduce the usb charger framework
>
> :::::: TO: Baolin Wang <baolin.wang@linaro.org>
> :::::: CC: 0day robot <fengguang.wu@intel.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management
2017-02-20 8:51 ` Baolin Wang
@ 2017-02-20 10:20 ` kbuild test robot
-1 siblings, 0 replies; 50+ messages in thread
From: kbuild test robot @ 2017-02-20 10:20 UTC (permalink / raw)
To: Baolin Wang
Cc: kbuild-all, balbi, gregkh, sre, dbaryshkov, dwmw2, robh, jun.li,
m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6122 bytes --]
Hi Baolin,
[auto build test ERROR on v4.9-rc8]
[cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
config: i386-randconfig-x017-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/power/supply/wm831x_power.c:16:0:
include/linux/usb/charger.h: In function 'usb_charger_get_state':
include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
return USB_CHARGER_REMOVE;
^~~~~~~~~~~~~~~~~~
include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/power/supply/wm831x_power.c: In function 'wm831x_usb_limit_change':
>> drivers/power/supply/wm831x_power.c:151:2: error: 'best' undeclared (first use in this function)
best = 0;
^~~~
>> drivers/power/supply/wm831x_power.c:152:7: error: 'i' undeclared (first use in this function)
for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
^
vim +/best +151 drivers/power/supply/wm831x_power.c
10
11 #include <linux/module.h>
12 #include <linux/err.h>
13 #include <linux/platform_device.h>
14 #include <linux/power_supply.h>
15 #include <linux/slab.h>
> 16 #include <linux/usb/charger.h>
17
18 #include <linux/mfd/wm831x/core.h>
19 #include <linux/mfd/wm831x/auxadc.h>
20 #include <linux/mfd/wm831x/pmu.h>
21 #include <linux/mfd/wm831x/pdata.h>
22
23 struct wm831x_power {
24 struct wm831x *wm831x;
25 struct power_supply *wall;
26 struct power_supply *usb;
27 struct power_supply *battery;
28 struct power_supply_desc wall_desc;
29 struct power_supply_desc usb_desc;
30 struct power_supply_desc battery_desc;
31 char wall_name[20];
32 char usb_name[20];
33 char battery_name[20];
34 bool have_battery;
35 struct usb_charger *usb_charger;
36 struct notifier_block usb_notify;
37 };
38
39 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
40 union power_supply_propval *val)
41 {
42 int ret;
43
44 ret = wm831x_reg_read(wm831x, WM831X_SYSTEM_STATUS);
45 if (ret < 0)
46 return ret;
47
48 if (ret & supply)
49 val->intval = 1;
50 else
51 val->intval = 0;
52
53 return 0;
54 }
55
56 static int wm831x_power_read_voltage(struct wm831x *wm831x,
57 enum wm831x_auxadc src,
58 union power_supply_propval *val)
59 {
60 int ret;
61
62 ret = wm831x_auxadc_read_uv(wm831x, src);
63 if (ret >= 0)
64 val->intval = ret;
65
66 return ret;
67 }
68
69 /*********************************************************************
70 * WALL Power
71 *********************************************************************/
72 static int wm831x_wall_get_prop(struct power_supply *psy,
73 enum power_supply_property psp,
74 union power_supply_propval *val)
75 {
76 struct wm831x_power *wm831x_power = dev_get_drvdata(psy->dev.parent);
77 struct wm831x *wm831x = wm831x_power->wm831x;
78 int ret = 0;
79
80 switch (psp) {
81 case POWER_SUPPLY_PROP_ONLINE:
82 ret = wm831x_power_check_online(wm831x, WM831X_PWR_WALL, val);
83 break;
84 case POWER_SUPPLY_PROP_VOLTAGE_NOW:
85 ret = wm831x_power_read_voltage(wm831x, WM831X_AUX_WALL, val);
86 break;
87 default:
88 ret = -EINVAL;
89 break;
90 }
91
92 return ret;
93 }
94
95 static enum power_supply_property wm831x_wall_props[] = {
96 POWER_SUPPLY_PROP_ONLINE,
97 POWER_SUPPLY_PROP_VOLTAGE_NOW,
98 };
99
100 /*********************************************************************
101 * USB Power
102 *********************************************************************/
103 static int wm831x_usb_get_prop(struct power_supply *psy,
104 enum power_supply_property psp,
105 union power_supply_propval *val)
106 {
107 struct wm831x_power *wm831x_power = dev_get_drvdata(psy->dev.parent);
108 struct wm831x *wm831x = wm831x_power->wm831x;
109 int ret = 0;
110
111 switch (psp) {
112 case POWER_SUPPLY_PROP_ONLINE:
113 ret = wm831x_power_check_online(wm831x, WM831X_PWR_USB, val);
114 break;
115 case POWER_SUPPLY_PROP_VOLTAGE_NOW:
116 ret = wm831x_power_read_voltage(wm831x, WM831X_AUX_USB, val);
117 break;
118 default:
119 ret = -EINVAL;
120 break;
121 }
122
123 return ret;
124 }
125
126 static enum power_supply_property wm831x_usb_props[] = {
127 POWER_SUPPLY_PROP_ONLINE,
128 POWER_SUPPLY_PROP_VOLTAGE_NOW,
129 };
130
131 /* In milliamps */
132 static const unsigned int wm831x_usb_limits[] = {
133 0,
134 2,
135 100,
136 500,
137 900,
138 1500,
139 1800,
140 550,
141 };
142
143 static int wm831x_usb_limit_change(struct notifier_block *nb,
144 unsigned long limit, void *data)
145 {
146 struct wm831x_power *wm831x_power = container_of(nb,
147 struct wm831x_power,
148 usb_notify);
149
150 /* Find the highest supported limit */
> 151 best = 0;
> 152 for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
153 if (limit >= wm831x_usb_limits[i] &&
154 wm831x_usb_limits[best] < wm831x_usb_limits[i])
155 best = i;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26745 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management
@ 2017-02-20 10:20 ` kbuild test robot
0 siblings, 0 replies; 50+ messages in thread
From: kbuild test robot @ 2017-02-20 10:20 UTC (permalink / raw)
Cc: kbuild-all, balbi, gregkh, sre, dbaryshkov, dwmw2, robh, jun.li,
m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, neilb, ckeepax, patches, baolin.wang, linux-pm,
linux-usb, device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6122 bytes --]
Hi Baolin,
[auto build test ERROR on v4.9-rc8]
[cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
config: i386-randconfig-x017-201708 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/power/supply/wm831x_power.c:16:0:
include/linux/usb/charger.h: In function 'usb_charger_get_state':
include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared (first use in this function)
return USB_CHARGER_REMOVE;
^~~~~~~~~~~~~~~~~~
include/linux/usb/charger.h:151:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/power/supply/wm831x_power.c: In function 'wm831x_usb_limit_change':
>> drivers/power/supply/wm831x_power.c:151:2: error: 'best' undeclared (first use in this function)
best = 0;
^~~~
>> drivers/power/supply/wm831x_power.c:152:7: error: 'i' undeclared (first use in this function)
for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
^
vim +/best +151 drivers/power/supply/wm831x_power.c
10
11 #include <linux/module.h>
12 #include <linux/err.h>
13 #include <linux/platform_device.h>
14 #include <linux/power_supply.h>
15 #include <linux/slab.h>
> 16 #include <linux/usb/charger.h>
17
18 #include <linux/mfd/wm831x/core.h>
19 #include <linux/mfd/wm831x/auxadc.h>
20 #include <linux/mfd/wm831x/pmu.h>
21 #include <linux/mfd/wm831x/pdata.h>
22
23 struct wm831x_power {
24 struct wm831x *wm831x;
25 struct power_supply *wall;
26 struct power_supply *usb;
27 struct power_supply *battery;
28 struct power_supply_desc wall_desc;
29 struct power_supply_desc usb_desc;
30 struct power_supply_desc battery_desc;
31 char wall_name[20];
32 char usb_name[20];
33 char battery_name[20];
34 bool have_battery;
35 struct usb_charger *usb_charger;
36 struct notifier_block usb_notify;
37 };
38
39 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
40 union power_supply_propval *val)
41 {
42 int ret;
43
44 ret = wm831x_reg_read(wm831x, WM831X_SYSTEM_STATUS);
45 if (ret < 0)
46 return ret;
47
48 if (ret & supply)
49 val->intval = 1;
50 else
51 val->intval = 0;
52
53 return 0;
54 }
55
56 static int wm831x_power_read_voltage(struct wm831x *wm831x,
57 enum wm831x_auxadc src,
58 union power_supply_propval *val)
59 {
60 int ret;
61
62 ret = wm831x_auxadc_read_uv(wm831x, src);
63 if (ret >= 0)
64 val->intval = ret;
65
66 return ret;
67 }
68
69 /*********************************************************************
70 * WALL Power
71 *********************************************************************/
72 static int wm831x_wall_get_prop(struct power_supply *psy,
73 enum power_supply_property psp,
74 union power_supply_propval *val)
75 {
76 struct wm831x_power *wm831x_power = dev_get_drvdata(psy->dev.parent);
77 struct wm831x *wm831x = wm831x_power->wm831x;
78 int ret = 0;
79
80 switch (psp) {
81 case POWER_SUPPLY_PROP_ONLINE:
82 ret = wm831x_power_check_online(wm831x, WM831X_PWR_WALL, val);
83 break;
84 case POWER_SUPPLY_PROP_VOLTAGE_NOW:
85 ret = wm831x_power_read_voltage(wm831x, WM831X_AUX_WALL, val);
86 break;
87 default:
88 ret = -EINVAL;
89 break;
90 }
91
92 return ret;
93 }
94
95 static enum power_supply_property wm831x_wall_props[] = {
96 POWER_SUPPLY_PROP_ONLINE,
97 POWER_SUPPLY_PROP_VOLTAGE_NOW,
98 };
99
100 /*********************************************************************
101 * USB Power
102 *********************************************************************/
103 static int wm831x_usb_get_prop(struct power_supply *psy,
104 enum power_supply_property psp,
105 union power_supply_propval *val)
106 {
107 struct wm831x_power *wm831x_power = dev_get_drvdata(psy->dev.parent);
108 struct wm831x *wm831x = wm831x_power->wm831x;
109 int ret = 0;
110
111 switch (psp) {
112 case POWER_SUPPLY_PROP_ONLINE:
113 ret = wm831x_power_check_online(wm831x, WM831X_PWR_USB, val);
114 break;
115 case POWER_SUPPLY_PROP_VOLTAGE_NOW:
116 ret = wm831x_power_read_voltage(wm831x, WM831X_AUX_USB, val);
117 break;
118 default:
119 ret = -EINVAL;
120 break;
121 }
122
123 return ret;
124 }
125
126 static enum power_supply_property wm831x_usb_props[] = {
127 POWER_SUPPLY_PROP_ONLINE,
128 POWER_SUPPLY_PROP_VOLTAGE_NOW,
129 };
130
131 /* In milliamps */
132 static const unsigned int wm831x_usb_limits[] = {
133 0,
134 2,
135 100,
136 500,
137 900,
138 1500,
139 1800,
140 550,
141 };
142
143 static int wm831x_usb_limit_change(struct notifier_block *nb,
144 unsigned long limit, void *data)
145 {
146 struct wm831x_power *wm831x_power = container_of(nb,
147 struct wm831x_power,
148 usb_notify);
149
150 /* Find the highest supported limit */
> 151 best = 0;
> 152 for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
153 if (limit >= wm831x_usb_limits[i] &&
154 wm831x_usb_limits[best] < wm831x_usb_limits[i])
155 best = i;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26745 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-02-20 8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
@ 2017-03-03 2:23 ` NeilBrown
2017-02-20 8:51 ` [PATCH v19 2/4] usb: gadget: Support for " Baolin Wang
` (4 subsequent siblings)
5 siblings, 0 replies; 50+ messages in thread
From: NeilBrown @ 2017-03-03 2:23 UTC (permalink / raw)
To: Baolin Wang, balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, ckeepax, patches, baolin.wang, linux-pm, linux-usb,
device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 10819 bytes --]
On Mon, Feb 20 2017, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> Another user introduced to support charger detection by Jun Li:
> https://www.spinics.net/lists/linux-usb/msg139425.html
> Moreover there may be other potential users will use it in future.
>
> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
> phy driver, now all were merged. (Thanks for Neil's suggestion)
> (1) Have fixed the inconsistencies with USB connector types in extcon subsystem
> by following links:
> https://lkml.org/lkml/2016/12/21/13
> https://lkml.org/lkml/2016/12/21/15
> https://lkml.org/lkml/2016/12/21/79
> https://lkml.org/lkml/2017/1/3/13
>
> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
> USB charger to set PMIC current drawn from USB configuration, moreover some
> 'set_power' callbacks did not implement anything to set PMIC current, thus
> remove them by following links:
> https://lkml.org/lkml/2017/1/18/436
> https://lkml.org/lkml/2017/1/18/439
> https://lkml.org/lkml/2017/1/18/438
> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
> used 'set_power' callback to set current, we can remove them in future. (I
> have no platform with enabling these two phy drivers, so I can not test them
> if I converted 'set_power' callback to USB charger.)
>
> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
> I expalined each issue and may be need discuss again:
> (1) Change all usb phys to register an extcon and to send appropriate notifications.
> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
> usb phys to register an extcon, since there are no extcon device to register
> for these different phy drivers.
You don't have to change every driver. You just need to make it easy
and obvious how to change drivers in a consistent coherent way.
For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
possibly add or extend some 'static inline's in linux/usb/phy.h to send
notification on that extcon (if it is non-NULL).
e.g. usb_phy_vbus_on() could send an extcon notification.
Then any phy driver which adds support for setting phy->extcon_dev
appropriately, immediately gets the relevant notifications sent.
> Secondly, I also agreed with Peter's comments: Not only USB PHY to register
> an extcon, but also for the drivers which can detect USB charger type, it may
> be USB controller driver, USB type-c driver, pmic driver, and these drivers
> may not have an extcon device since the internal part can finish the vbus
> detect.
Whichever part can detect vbus, the driver for that part must be able to
find the extcon and trigger a notification.
Maybe one part can detect VBUS, another can measure the resistance on ID
and a third can work through the state machine to determine if D+ and D-
are shorted together.
Somehow these three need to work together to determine what is plugged
in to the external connection port. Somewhere there much an 'extcon'
device which represents that port and which the three devices can find
and can interact with.
I think it makes sense for the usb_phy to be the connection point. Each
of the devices can get to the phy, and the phy can get to the extcon.
It doesn't matter very much if the usb phy driver creates the extcon, or
if something else creates the extcon and the phy driver performs a
lookup to find it (e.g. based on devicetree info).
The point is that there is obviously an external physical connection,
and so there should be an 'extcon' device that represents it.
>
> (2) Change the notifier of usb_phy to be used consistently.
> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
> send out the connect events, and phy-ab8500-usb.c also was used to send out the
> MUSB connect events. There are no phy drivers will notify 'vbus_draw' information
> by the notifier of usb_phy, which was used consistently now.
> Moreover it is difficult to change the notifier of usb_phy to be used only to
> communicate the 'vbus_draw' information, since we need to refactor and test these
> related phy drivers, power drivers or some mfd drivers, which is a
> huge workload.
You missed drivers/usb/musb/omap2430.c in you list, but that hardly
matters.
phy-ab8500-usb.c appears to send vbus_draw information.
I understand your reluctance to change drivers that you cannot test.
An alternative it do change all the
atomic_notifier_call_chain(.*notifier,
calls that don't pass a pointer to vbus_draw to pass NULL, and to
declare the passing of NULL to be deprecated (so hopefully people won't
use it in new code).
Then any notification callback that expects a current can just ignore
calls where the pointer is NULL.
The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
It is the only driver which expects a 'gadget', and it doesn't really
need to as it already knows the gadget.
The patch below fixes this.
With that in place, phy-generic and phy-gpio-vbus-usb can be changed to
pass NULL. When we can safely use the notifier to pass vbus_draw
information uniformly.
>
> (3) Still keep charger_type_show() API.
> Firstly I think we should combine all charger related information into one
> place for users, which is convenient.
convenience is very much a secondary issue.
> Secondly not only we get charger type from extcon, but also in some scenarios
> we can get charger type from USB controller driver, USB type-c driver, pmic
> driver, we should also need one place to export the charger type.
As I have said, all of these sources of information should feed into the
extcon.
There are ultimately two possible sources of information about the
current available from the usb port.
One is the physical properties of the cable, such as resistance of ID,
any short between D+ and D- etc. Being properties of the cable, they
should be reported through the extcon.
The other is information gathered during the USB protocol handshake.
For USB2, this is the requested current of the profile that the host
activates. This should be reported though the USB gadget device.
I don't know how USB3 and/or type-C work but I would be surprised if they
don't fit into the two cases above. If you think otherwise, please
surprise me. I'm always keen to learn.
If the extcon reports the type of cable detected, and the gadget reports
the result of any negotiation, then that is enough to determine the
charger type. It doesn't need to be more convenient than that.
Thanks,
NeilBrown
From 75a77246d2e9224f579ab996640a435a1c587d5f Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.com>
Date: Fri, 3 Mar 2017 13:05:17 +1100
Subject: [PATCH] usb: gadget: pxa27x: change event handler to not expect
gadget.
We are planning to change the usb notifier to not pass a gadget,
as different drivers pass different things and consistency would
be nice.
The only driver to expect a gadget is pxa27x.
Unlike other drivers that register a usb notifier, pxa27x uses a static
notifier_block. Other drivers embed a notifer_block in their data
struct so that struct can be access from the notifer callback.
So change pxa27x to use as embedded notifer_block, and to use that
to find the target gadget.
With this, it can ignore that pointer that is passed. This will
allow us to change all calls that pass a gadget, to instead pass
NULL.
Signed-off-by: NeilBrown <neilb@suse.com>
---
drivers/usb/gadget/udc/pxa27x_udc.c | 14 ++++++--------
drivers/usb/gadget/udc/pxa27x_udc.h | 2 ++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c b/drivers/usb/gadget/udc/pxa27x_udc.c
index e1335ad5bce9..885a6c80fd08 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -1669,7 +1669,8 @@ static int pxa_udc_vbus_draw(struct usb_gadget *_gadget, unsigned mA)
static int pxa_udc_phy_event(struct notifier_block *nb, unsigned long action,
void *data)
{
- struct usb_gadget *gadget = data;
+ struct pxa_udc *udc = container_of(nb, struct pxa_udc, nb);
+ struct usb_gadget *gadget = &udc->gadget;
switch (action) {
case USB_EVENT_VBUS:
@@ -1683,10 +1684,6 @@ static int pxa_udc_phy_event(struct notifier_block *nb, unsigned long action,
}
}
-static struct notifier_block pxa27x_udc_phy = {
- .notifier_call = pxa_udc_phy_event,
-};
-
static int pxa27x_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver);
static int pxa27x_udc_stop(struct usb_gadget *g);
@@ -2504,8 +2501,9 @@ static int pxa_udc_probe(struct platform_device *pdev)
goto err;
}
+ udc->nb.notifier_call = pxa_udc_phy_event;
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_register_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_register_notifier(udc->transceiver, &udc->nb);
retval = usb_add_gadget_udc(&pdev->dev, &udc->gadget);
if (retval)
goto err_add_gadget;
@@ -2517,7 +2515,7 @@ static int pxa_udc_probe(struct platform_device *pdev)
err_add_gadget:
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_unregister_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_unregister_notifier(udc->transceiver, &udc->nb);
err:
clk_unprepare(udc->clk);
return retval;
@@ -2535,7 +2533,7 @@ static int pxa_udc_remove(struct platform_device *_dev)
pxa_cleanup_debugfs(udc);
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_unregister_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_unregister_notifier(udc->transceiver, &udc->nb);
usb_put_phy(udc->transceiver);
udc->transceiver = NULL;
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.h b/drivers/usb/gadget/udc/pxa27x_udc.h
index cea2cb79b30c..acefb07427bd 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.h
+++ b/drivers/usb/gadget/udc/pxa27x_udc.h
@@ -461,6 +461,8 @@ struct pxa_udc {
struct gpio_desc *gpiod;
struct usb_phy *transceiver;
+ struct notifier_block nb;
+
enum ep0_state ep0state;
struct udc_stats stats;
--
2.11.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-03 2:23 ` NeilBrown
0 siblings, 0 replies; 50+ messages in thread
From: NeilBrown @ 2017-03-03 2:23 UTC (permalink / raw)
To: balbi, gregkh, sre, dbaryshkov, dwmw2
Cc: robh, jun.li, m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, lee.jones, broonie,
john.stultz, ckeepax, patches, baolin.wang, linux-pm, linux-usb,
device-mainlining, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 10819 bytes --]
On Mon, Feb 20 2017, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> Another user introduced to support charger detection by Jun Li:
> https://www.spinics.net/lists/linux-usb/msg139425.html
> Moreover there may be other potential users will use it in future.
>
> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
> phy driver, now all were merged. (Thanks for Neil's suggestion)
> (1) Have fixed the inconsistencies with USB connector types in extcon subsystem
> by following links:
> https://lkml.org/lkml/2016/12/21/13
> https://lkml.org/lkml/2016/12/21/15
> https://lkml.org/lkml/2016/12/21/79
> https://lkml.org/lkml/2017/1/3/13
>
> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
> USB charger to set PMIC current drawn from USB configuration, moreover some
> 'set_power' callbacks did not implement anything to set PMIC current, thus
> remove them by following links:
> https://lkml.org/lkml/2017/1/18/436
> https://lkml.org/lkml/2017/1/18/439
> https://lkml.org/lkml/2017/1/18/438
> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
> used 'set_power' callback to set current, we can remove them in future. (I
> have no platform with enabling these two phy drivers, so I can not test them
> if I converted 'set_power' callback to USB charger.)
>
> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
> I expalined each issue and may be need discuss again:
> (1) Change all usb phys to register an extcon and to send appropriate notifications.
> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
> usb phys to register an extcon, since there are no extcon device to register
> for these different phy drivers.
You don't have to change every driver. You just need to make it easy
and obvious how to change drivers in a consistent coherent way.
For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
possibly add or extend some 'static inline's in linux/usb/phy.h to send
notification on that extcon (if it is non-NULL).
e.g. usb_phy_vbus_on() could send an extcon notification.
Then any phy driver which adds support for setting phy->extcon_dev
appropriately, immediately gets the relevant notifications sent.
> Secondly, I also agreed with Peter's comments: Not only USB PHY to register
> an extcon, but also for the drivers which can detect USB charger type, it may
> be USB controller driver, USB type-c driver, pmic driver, and these drivers
> may not have an extcon device since the internal part can finish the vbus
> detect.
Whichever part can detect vbus, the driver for that part must be able to
find the extcon and trigger a notification.
Maybe one part can detect VBUS, another can measure the resistance on ID
and a third can work through the state machine to determine if D+ and D-
are shorted together.
Somehow these three need to work together to determine what is plugged
in to the external connection port. Somewhere there much an 'extcon'
device which represents that port and which the three devices can find
and can interact with.
I think it makes sense for the usb_phy to be the connection point. Each
of the devices can get to the phy, and the phy can get to the extcon.
It doesn't matter very much if the usb phy driver creates the extcon, or
if something else creates the extcon and the phy driver performs a
lookup to find it (e.g. based on devicetree info).
The point is that there is obviously an external physical connection,
and so there should be an 'extcon' device that represents it.
>
> (2) Change the notifier of usb_phy to be used consistently.
> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
> send out the connect events, and phy-ab8500-usb.c also was used to send out the
> MUSB connect events. There are no phy drivers will notify 'vbus_draw' information
> by the notifier of usb_phy, which was used consistently now.
> Moreover it is difficult to change the notifier of usb_phy to be used only to
> communicate the 'vbus_draw' information, since we need to refactor and test these
> related phy drivers, power drivers or some mfd drivers, which is a
> huge workload.
You missed drivers/usb/musb/omap2430.c in you list, but that hardly
matters.
phy-ab8500-usb.c appears to send vbus_draw information.
I understand your reluctance to change drivers that you cannot test.
An alternative it do change all the
atomic_notifier_call_chain(.*notifier,
calls that don't pass a pointer to vbus_draw to pass NULL, and to
declare the passing of NULL to be deprecated (so hopefully people won't
use it in new code).
Then any notification callback that expects a current can just ignore
calls where the pointer is NULL.
The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
It is the only driver which expects a 'gadget', and it doesn't really
need to as it already knows the gadget.
The patch below fixes this.
With that in place, phy-generic and phy-gpio-vbus-usb can be changed to
pass NULL. When we can safely use the notifier to pass vbus_draw
information uniformly.
>
> (3) Still keep charger_type_show() API.
> Firstly I think we should combine all charger related information into one
> place for users, which is convenient.
convenience is very much a secondary issue.
> Secondly not only we get charger type from extcon, but also in some scenarios
> we can get charger type from USB controller driver, USB type-c driver, pmic
> driver, we should also need one place to export the charger type.
As I have said, all of these sources of information should feed into the
extcon.
There are ultimately two possible sources of information about the
current available from the usb port.
One is the physical properties of the cable, such as resistance of ID,
any short between D+ and D- etc. Being properties of the cable, they
should be reported through the extcon.
The other is information gathered during the USB protocol handshake.
For USB2, this is the requested current of the profile that the host
activates. This should be reported though the USB gadget device.
I don't know how USB3 and/or type-C work but I would be surprised if they
don't fit into the two cases above. If you think otherwise, please
surprise me. I'm always keen to learn.
If the extcon reports the type of cable detected, and the gadget reports
the result of any negotiation, then that is enough to determine the
charger type. It doesn't need to be more convenient than that.
Thanks,
NeilBrown
From 75a77246d2e9224f579ab996640a435a1c587d5f Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.com>
Date: Fri, 3 Mar 2017 13:05:17 +1100
Subject: [PATCH] usb: gadget: pxa27x: change event handler to not expect
gadget.
We are planning to change the usb notifier to not pass a gadget,
as different drivers pass different things and consistency would
be nice.
The only driver to expect a gadget is pxa27x.
Unlike other drivers that register a usb notifier, pxa27x uses a static
notifier_block. Other drivers embed a notifer_block in their data
struct so that struct can be access from the notifer callback.
So change pxa27x to use as embedded notifer_block, and to use that
to find the target gadget.
With this, it can ignore that pointer that is passed. This will
allow us to change all calls that pass a gadget, to instead pass
NULL.
Signed-off-by: NeilBrown <neilb@suse.com>
---
drivers/usb/gadget/udc/pxa27x_udc.c | 14 ++++++--------
drivers/usb/gadget/udc/pxa27x_udc.h | 2 ++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.c b/drivers/usb/gadget/udc/pxa27x_udc.c
index e1335ad5bce9..885a6c80fd08 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@ -1669,7 +1669,8 @@ static int pxa_udc_vbus_draw(struct usb_gadget *_gadget, unsigned mA)
static int pxa_udc_phy_event(struct notifier_block *nb, unsigned long action,
void *data)
{
- struct usb_gadget *gadget = data;
+ struct pxa_udc *udc = container_of(nb, struct pxa_udc, nb);
+ struct usb_gadget *gadget = &udc->gadget;
switch (action) {
case USB_EVENT_VBUS:
@@ -1683,10 +1684,6 @@ static int pxa_udc_phy_event(struct notifier_block *nb, unsigned long action,
}
}
-static struct notifier_block pxa27x_udc_phy = {
- .notifier_call = pxa_udc_phy_event,
-};
-
static int pxa27x_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver);
static int pxa27x_udc_stop(struct usb_gadget *g);
@@ -2504,8 +2501,9 @@ static int pxa_udc_probe(struct platform_device *pdev)
goto err;
}
+ udc->nb.notifier_call = pxa_udc_phy_event;
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_register_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_register_notifier(udc->transceiver, &udc->nb);
retval = usb_add_gadget_udc(&pdev->dev, &udc->gadget);
if (retval)
goto err_add_gadget;
@@ -2517,7 +2515,7 @@ static int pxa_udc_probe(struct platform_device *pdev)
err_add_gadget:
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_unregister_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_unregister_notifier(udc->transceiver, &udc->nb);
err:
clk_unprepare(udc->clk);
return retval;
@@ -2535,7 +2533,7 @@ static int pxa_udc_remove(struct platform_device *_dev)
pxa_cleanup_debugfs(udc);
if (!IS_ERR_OR_NULL(udc->transceiver))
- usb_unregister_notifier(udc->transceiver, &pxa27x_udc_phy);
+ usb_unregister_notifier(udc->transceiver, &udc->nb);
usb_put_phy(udc->transceiver);
udc->transceiver = NULL;
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.h b/drivers/usb/gadget/udc/pxa27x_udc.h
index cea2cb79b30c..acefb07427bd 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.h
+++ b/drivers/usb/gadget/udc/pxa27x_udc.h
@@ -461,6 +461,8 @@ struct pxa_udc {
struct gpio_desc *gpiod;
struct usb_phy *transceiver;
+ struct notifier_block nb;
+
enum ep0_state ep0state;
struct udc_stats stats;
--
2.11.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-07 9:38 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-07 9:38 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, Charles Keepax, patches, Linux PM list, USB,
device-mainlining, LKML
On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> On Mon, Feb 20 2017, Baolin Wang wrote:
>
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should. Thus provide a standard framework for doing this in kernel.
>>
>> Now introduce one user with wm831x_power to support and test the usb charger.
>> Another user introduced to support charger detection by Jun Li:
>> https://www.spinics.net/lists/linux-usb/msg139425.html
>> Moreover there may be other potential users will use it in future.
>>
>> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
>> phy driver, now all were merged. (Thanks for Neil's suggestion)
>> (1) Have fixed the inconsistencies with USB connector types in extcon subsystem
>> by following links:
>> https://lkml.org/lkml/2016/12/21/13
>> https://lkml.org/lkml/2016/12/21/15
>> https://lkml.org/lkml/2016/12/21/79
>> https://lkml.org/lkml/2017/1/3/13
>>
>> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
>> USB charger to set PMIC current drawn from USB configuration, moreover some
>> 'set_power' callbacks did not implement anything to set PMIC current, thus
>> remove them by following links:
>> https://lkml.org/lkml/2017/1/18/436
>> https://lkml.org/lkml/2017/1/18/439
>> https://lkml.org/lkml/2017/1/18/438
>> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
>> used 'set_power' callback to set current, we can remove them in future. (I
>> have no platform with enabling these two phy drivers, so I can not test them
>> if I converted 'set_power' callback to USB charger.)
>>
>> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
>> I expalined each issue and may be need discuss again:
>> (1) Change all usb phys to register an extcon and to send appropriate notifications.
>> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
>> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
>> usb phys to register an extcon, since there are no extcon device to register
>> for these different phy drivers.
>
> You don't have to change every driver. You just need to make it easy
> and obvious how to change drivers in a consistent coherent way.
> For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
> possibly add or extend some 'static inline's in linux/usb/phy.h to send
> notification on that extcon (if it is non-NULL).
> e.g. usb_phy_vbus_on() could send an extcon notification.
>
> Then any phy driver which adds support for setting phy->extcon_dev
> appropriately, immediately gets the relevant notifications sent.
OK. We can make these extcon related code into phy common part.
>
>> Secondly, I also agreed with Peter's comments: Not only USB PHY to register
>> an extcon, but also for the drivers which can detect USB charger type, it may
>> be USB controller driver, USB type-c driver, pmic driver, and these drivers
>> may not have an extcon device since the internal part can finish the vbus
>> detect.
>
> Whichever part can detect vbus, the driver for that part must be able to
> find the extcon and trigger a notification.
> Maybe one part can detect VBUS, another can measure the resistance on ID
> and a third can work through the state machine to determine if D+ and D-
> are shorted together.
> Somehow these three need to work together to determine what is plugged
> in to the external connection port. Somewhere there much an 'extcon'
> device which represents that port and which the three devices can find
> and can interact with.
> I think it makes sense for the usb_phy to be the connection point. Each
> of the devices can get to the phy, and the phy can get to the extcon.
> It doesn't matter very much if the usb phy driver creates the extcon, or
> if something else creates the extcon and the phy driver performs a
> lookup to find it (e.g. based on devicetree info).
>
> The point is that there is obviously an external physical connection,
> and so there should be an 'extcon' device that represents it.
Peter & Jun, is it OK for you every phy has one extcon device to
receive VBUS notification, especially for detecting the charger type
by software?
>
>>
>> (2) Change the notifier of usb_phy to be used consistently.
>> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
>> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
>> send out the connect events, and phy-ab8500-usb.c also was used to send out the
>> MUSB connect events. There are no phy drivers will notify 'vbus_draw' information
>> by the notifier of usb_phy, which was used consistently now.
>> Moreover it is difficult to change the notifier of usb_phy to be used only to
>> communicate the 'vbus_draw' information, since we need to refactor and test these
>> related phy drivers, power drivers or some mfd drivers, which is a
>> huge workload.
>
> You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> matters.
But it did not use the notifier of usb_phy.
> phy-ab8500-usb.c appears to send vbus_draw information.
Users will not use the vbus_draw information send from phy-ab8500-usb.c
>
> I understand your reluctance to change drivers that you cannot test.
> An alternative it do change all the
> atomic_notifier_call_chain(.*notifier,
> calls that don't pass a pointer to vbus_draw to pass NULL, and to
> declare the passing of NULL to be deprecated (so hopefully people won't
> use it in new code).
> Then any notification callback that expects a current can just ignore
> calls where the pointer is NULL.
I am afraid if it is enough to send out vbus draw information from USB
phy driver, for example you will miss super speed (900mA), which need
get the speed information from gadget driver.
>
> The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> It is the only driver which expects a 'gadget', and it doesn't really
> need to as it already knows the gadget.
> The patch below fixes this.
> With that in place, phy-generic and phy-gpio-vbus-usb can be changed to
> pass NULL. When we can safely use the notifier to pass vbus_draw
> information uniformly.
>
>>
>> (3) Still keep charger_type_show() API.
>> Firstly I think we should combine all charger related information into one
>> place for users, which is convenient.
>
> convenience is very much a secondary issue.
>
>> Secondly not only we get charger type from extcon, but also in some scenarios
>> we can get charger type from USB controller driver, USB type-c driver, pmic
>> driver, we should also need one place to export the charger type.
>
> As I have said, all of these sources of information should feed into the
> extcon.
>
> There are ultimately two possible sources of information about the
> current available from the usb port.
> One is the physical properties of the cable, such as resistance of ID,
> any short between D+ and D- etc. Being properties of the cable, they
> should be reported through the extcon.
>
> The other is information gathered during the USB protocol handshake.
> For USB2, this is the requested current of the profile that the host
> activates. This should be reported though the USB gadget device.
>
> I don't know how USB3 and/or type-C work but I would be surprised if they
> don't fit into the two cases above. If you think otherwise, please
> surprise me. I'm always keen to learn.
>
> If the extcon reports the type of cable detected, and the gadget reports
> the result of any negotiation, then that is enough to determine the
> charger type. It doesn't need to be more convenient than that.
If we are all agree we did not need the USB charger, then we can add
'current' attribute of USB gadget device.
Thanks for your suggestion.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-07 9:38 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-07 9:38 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse,
robh-DgEjT+Ai2ygdnm+yROfE0A, Jun Li, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko-l0cyMroinI0, Yoshihiro Shimoda, Lee Jones,
Mark Brown, John Stultz, Charles Keepax,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
Linux PM list, USB
On 3 March 2017 at 10:23, NeilBrown <neilb-IBi9RG/b67k@public.gmane.org> wrote:
> On Mon, Feb 20 2017, Baolin Wang wrote:
>
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should. Thus provide a standard framework for doing this in kernel.
>>
>> Now introduce one user with wm831x_power to support and test the usb charger.
>> Another user introduced to support charger detection by Jun Li:
>> https://www.spinics.net/lists/linux-usb/msg139425.html
>> Moreover there may be other potential users will use it in future.
>>
>> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
>> phy driver, now all were merged. (Thanks for Neil's suggestion)
>> (1) Have fixed the inconsistencies with USB connector types in extcon subsystem
>> by following links:
>> https://lkml.org/lkml/2016/12/21/13
>> https://lkml.org/lkml/2016/12/21/15
>> https://lkml.org/lkml/2016/12/21/79
>> https://lkml.org/lkml/2017/1/3/13
>>
>> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
>> USB charger to set PMIC current drawn from USB configuration, moreover some
>> 'set_power' callbacks did not implement anything to set PMIC current, thus
>> remove them by following links:
>> https://lkml.org/lkml/2017/1/18/436
>> https://lkml.org/lkml/2017/1/18/439
>> https://lkml.org/lkml/2017/1/18/438
>> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
>> used 'set_power' callback to set current, we can remove them in future. (I
>> have no platform with enabling these two phy drivers, so I can not test them
>> if I converted 'set_power' callback to USB charger.)
>>
>> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
>> I expalined each issue and may be need discuss again:
>> (1) Change all usb phys to register an extcon and to send appropriate notifications.
>> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
>> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
>> usb phys to register an extcon, since there are no extcon device to register
>> for these different phy drivers.
>
> You don't have to change every driver. You just need to make it easy
> and obvious how to change drivers in a consistent coherent way.
> For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
> possibly add or extend some 'static inline's in linux/usb/phy.h to send
> notification on that extcon (if it is non-NULL).
> e.g. usb_phy_vbus_on() could send an extcon notification.
>
> Then any phy driver which adds support for setting phy->extcon_dev
> appropriately, immediately gets the relevant notifications sent.
OK. We can make these extcon related code into phy common part.
>
>> Secondly, I also agreed with Peter's comments: Not only USB PHY to register
>> an extcon, but also for the drivers which can detect USB charger type, it may
>> be USB controller driver, USB type-c driver, pmic driver, and these drivers
>> may not have an extcon device since the internal part can finish the vbus
>> detect.
>
> Whichever part can detect vbus, the driver for that part must be able to
> find the extcon and trigger a notification.
> Maybe one part can detect VBUS, another can measure the resistance on ID
> and a third can work through the state machine to determine if D+ and D-
> are shorted together.
> Somehow these three need to work together to determine what is plugged
> in to the external connection port. Somewhere there much an 'extcon'
> device which represents that port and which the three devices can find
> and can interact with.
> I think it makes sense for the usb_phy to be the connection point. Each
> of the devices can get to the phy, and the phy can get to the extcon.
> It doesn't matter very much if the usb phy driver creates the extcon, or
> if something else creates the extcon and the phy driver performs a
> lookup to find it (e.g. based on devicetree info).
>
> The point is that there is obviously an external physical connection,
> and so there should be an 'extcon' device that represents it.
Peter & Jun, is it OK for you every phy has one extcon device to
receive VBUS notification, especially for detecting the charger type
by software?
>
>>
>> (2) Change the notifier of usb_phy to be used consistently.
>> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
>> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
>> send out the connect events, and phy-ab8500-usb.c also was used to send out the
>> MUSB connect events. There are no phy drivers will notify 'vbus_draw' information
>> by the notifier of usb_phy, which was used consistently now.
>> Moreover it is difficult to change the notifier of usb_phy to be used only to
>> communicate the 'vbus_draw' information, since we need to refactor and test these
>> related phy drivers, power drivers or some mfd drivers, which is a
>> huge workload.
>
> You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> matters.
But it did not use the notifier of usb_phy.
> phy-ab8500-usb.c appears to send vbus_draw information.
Users will not use the vbus_draw information send from phy-ab8500-usb.c
>
> I understand your reluctance to change drivers that you cannot test.
> An alternative it do change all the
> atomic_notifier_call_chain(.*notifier,
> calls that don't pass a pointer to vbus_draw to pass NULL, and to
> declare the passing of NULL to be deprecated (so hopefully people won't
> use it in new code).
> Then any notification callback that expects a current can just ignore
> calls where the pointer is NULL.
I am afraid if it is enough to send out vbus draw information from USB
phy driver, for example you will miss super speed (900mA), which need
get the speed information from gadget driver.
>
> The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> It is the only driver which expects a 'gadget', and it doesn't really
> need to as it already knows the gadget.
> The patch below fixes this.
> With that in place, phy-generic and phy-gpio-vbus-usb can be changed to
> pass NULL. When we can safely use the notifier to pass vbus_draw
> information uniformly.
>
>>
>> (3) Still keep charger_type_show() API.
>> Firstly I think we should combine all charger related information into one
>> place for users, which is convenient.
>
> convenience is very much a secondary issue.
>
>> Secondly not only we get charger type from extcon, but also in some scenarios
>> we can get charger type from USB controller driver, USB type-c driver, pmic
>> driver, we should also need one place to export the charger type.
>
> As I have said, all of these sources of information should feed into the
> extcon.
>
> There are ultimately two possible sources of information about the
> current available from the usb port.
> One is the physical properties of the cable, such as resistance of ID,
> any short between D+ and D- etc. Being properties of the cable, they
> should be reported through the extcon.
>
> The other is information gathered during the USB protocol handshake.
> For USB2, this is the requested current of the profile that the host
> activates. This should be reported though the USB gadget device.
>
> I don't know how USB3 and/or type-C work but I would be surprised if they
> don't fit into the two cases above. If you think otherwise, please
> surprise me. I'm always keen to learn.
>
> If the extcon reports the type of cable detected, and the gadget reports
> the result of any negotiation, then that is enough to determine the
> charger type. It doesn't need to be more convenient than that.
If we are all agree we did not need the USB charger, then we can add
'current' attribute of USB gadget device.
Thanks for your suggestion.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-07 9:38 ` Baolin Wang
@ 2017-03-09 1:50 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-09 1:50 UTC (permalink / raw)
To: Baolin Wang, NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown <neilb@suse.com>
> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH <gregkh@linuxfoundation.org>;
> Sebastian Reichel <sre@kernel.org>; Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com>; David Woodhouse <dwmw2@infradead.org>;
> robh@kernel.org; Jun Li <jun.li@nxp.com>; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> charger.
> >> Another user introduced to support charger detection by Jun Li:
> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> Moreover there may be other potential users will use it in future.
> >>
> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
> >> and usb phy driver, now all were merged. (Thanks for Neil's
> >> suggestion)
> >> (1) Have fixed the inconsistencies with USB connector types in extcon
> >> subsystem by following links:
> >> https://lkml.org/lkml/2016/12/21/13
> >> https://lkml.org/lkml/2016/12/21/15
> >> https://lkml.org/lkml/2016/12/21/79
> >> https://lkml.org/lkml/2017/1/3/13
> >>
> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> introduce USB charger to set PMIC current drawn from USB
> >> configuration, moreover some 'set_power' callbacks did not implement
> >> anything to set PMIC current, thus remove them by following links:
> >> https://lkml.org/lkml/2017/1/18/436
> >> https://lkml.org/lkml/2017/1/18/439
> >> https://lkml.org/lkml/2017/1/18/438
> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
> >> still used 'set_power' callback to set current, we can remove them in
> >> future. (I have no platform with enabling these two phy drivers, so I
> >> can not test them if I converted 'set_power' callback to USB
> >> charger.)
> >>
> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> patchset, and I expalined each issue and may be need discuss again:
> >> (1) Change all usb phys to register an extcon and to send appropriate
> notifications.
> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> phy-omap-otg.c and
> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> change all usb phys to register an extcon, since there are no extcon
> >> device to register for these different phy drivers.
> >
> > You don't have to change every driver. You just need to make it easy
> > and obvious how to change drivers in a consistent coherent way.
> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
> > send notification on that extcon (if it is non-NULL).
> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
>
> OK. We can make these extcon related code into phy common part.
>
Will generic phy need add extcon as well?
> >
> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> register an extcon, but also for the drivers which can detect USB
> >> charger type, it may be USB controller driver, USB type-c driver,
> >> pmic driver, and these drivers may not have an extcon device since
> >> the internal part can finish the vbus detect.
> >
> > Whichever part can detect vbus, the driver for that part must be able
> > to find the extcon and trigger a notification.
> > Maybe one part can detect VBUS, another can measure the resistance on
> > ID and a third can work through the state machine to determine if D+
> > and D- are shorted together.
> > Somehow these three need to work together to determine what is
> plugged
> > in to the external connection port. Somewhere there much an 'extcon'
> > device which represents that port and which the three devices can find
> > and can interact with.
> > I think it makes sense for the usb_phy to be the connection point.
> > Each of the devices can get to the phy, and the phy can get to the extcon.
> > It doesn't matter very much if the usb phy driver creates the extcon,
> > or if something else creates the extcon and the phy driver performs a
> > lookup to find it (e.g. based on devicetree info).
> >
> > The point is that there is obviously an external physical connection,
> > and so there should be an 'extcon' device that represents it.
>
> Peter & Jun, is it OK for you every phy has one extcon device to receive VBUS
> notification, especially for detecting the charger type by software?
>
My understanding is phy/usb_phy as the connection point, will send the notification
to PMIC driver which actually control the charge current, also this will be done in
your common framework, right?
Li Jun
> >
> >>
> >> (2) Change the notifier of usb_phy to be used consistently.
> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c and
> >> phy-gpio-vbus-usb.c were used to send out the connect events, and
> >> phy-ab8500-usb.c also was used to send out the MUSB connect events.
> >> There are no phy drivers will notify 'vbus_draw' information by the
> notifier of usb_phy, which was used consistently now.
> >> Moreover it is difficult to change the notifier of usb_phy to be used
> >> only to communicate the 'vbus_draw' information, since we need to
> >> refactor and test these related phy drivers, power drivers or some
> >> mfd drivers, which is a huge workload.
> >
> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> > matters.
>
> But it did not use the notifier of usb_phy.
>
> > phy-ab8500-usb.c appears to send vbus_draw information.
>
> Users will not use the vbus_draw information send from phy-ab8500-usb.c
>
> >
> > I understand your reluctance to change drivers that you cannot test.
> > An alternative it do change all the
> > atomic_notifier_call_chain(.*notifier,
> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
> > declare the passing of NULL to be deprecated (so hopefully people
> > won't use it in new code).
> > Then any notification callback that expects a current can just ignore
> > calls where the pointer is NULL.
>
> I am afraid if it is enough to send out vbus draw information from USB phy
> driver, for example you will miss super speed (900mA), which need get the
> speed information from gadget driver.
>
> >
> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> > It is the only driver which expects a 'gadget', and it doesn't really
> > need to as it already knows the gadget.
> > The patch below fixes this.
> > With that in place, phy-generic and phy-gpio-vbus-usb can be changed
> > to pass NULL. When we can safely use the notifier to pass vbus_draw
> > information uniformly.
> >
> >>
> >> (3) Still keep charger_type_show() API.
> >> Firstly I think we should combine all charger related information
> >> into one place for users, which is convenient.
> >
> > convenience is very much a secondary issue.
> >
> >> Secondly not only we get charger type from extcon, but also in some
> >> scenarios we can get charger type from USB controller driver, USB
> >> type-c driver, pmic driver, we should also need one place to export the
> charger type.
> >
> > As I have said, all of these sources of information should feed into
> > the extcon.
> >
> > There are ultimately two possible sources of information about the
> > current available from the usb port.
> > One is the physical properties of the cable, such as resistance of ID,
> > any short between D+ and D- etc. Being properties of the cable, they
> > should be reported through the extcon.
> >
> > The other is information gathered during the USB protocol handshake.
> > For USB2, this is the requested current of the profile that the host
> > activates. This should be reported though the USB gadget device.
> >
> > I don't know how USB3 and/or type-C work but I would be surprised if
> > they don't fit into the two cases above. If you think otherwise,
> > please surprise me. I'm always keen to learn.
> >
> > If the extcon reports the type of cable detected, and the gadget
> > reports the result of any negotiation, then that is enough to
> > determine the charger type. It doesn't need to be more convenient than
> that.
>
> If we are all agree we did not need the USB charger, then we can add
> 'current' attribute of USB gadget device.
> Thanks for your suggestion.
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-09 1:50 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-09 1:50 UTC (permalink / raw)
To: Baolin Wang, NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Li
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown <neilb@suse.com>
> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH <gregkh@linuxfoundation.org>;
> Sebastian Reichel <sre@kernel.org>; Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com>; David Woodhouse <dwmw2@infradead.org>;
> robh@kernel.org; Jun Li <jun.li@nxp.com>; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> charger.
> >> Another user introduced to support charger detection by Jun Li:
> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> Moreover there may be other potential users will use it in future.
> >>
> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
> >> and usb phy driver, now all were merged. (Thanks for Neil's
> >> suggestion)
> >> (1) Have fixed the inconsistencies with USB connector types in extcon
> >> subsystem by following links:
> >> https://lkml.org/lkml/2016/12/21/13
> >> https://lkml.org/lkml/2016/12/21/15
> >> https://lkml.org/lkml/2016/12/21/79
> >> https://lkml.org/lkml/2017/1/3/13
> >>
> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> introduce USB charger to set PMIC current drawn from USB
> >> configuration, moreover some 'set_power' callbacks did not implement
> >> anything to set PMIC current, thus remove them by following links:
> >> https://lkml.org/lkml/2017/1/18/436
> >> https://lkml.org/lkml/2017/1/18/439
> >> https://lkml.org/lkml/2017/1/18/438
> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
> >> still used 'set_power' callback to set current, we can remove them in
> >> future. (I have no platform with enabling these two phy drivers, so I
> >> can not test them if I converted 'set_power' callback to USB
> >> charger.)
> >>
> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> patchset, and I expalined each issue and may be need discuss again:
> >> (1) Change all usb phys to register an extcon and to send appropriate
> notifications.
> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> phy-omap-otg.c and
> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> change all usb phys to register an extcon, since there are no extcon
> >> device to register for these different phy drivers.
> >
> > You don't have to change every driver. You just need to make it easy
> > and obvious how to change drivers in a consistent coherent way.
> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
> > send notification on that extcon (if it is non-NULL).
> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
>
> OK. We can make these extcon related code into phy common part.
>
Will generic phy need add extcon as well?
> >
> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> register an extcon, but also for the drivers which can detect USB
> >> charger type, it may be USB controller driver, USB type-c driver,
> >> pmic driver, and these drivers may not have an extcon device since
> >> the internal part can finish the vbus detect.
> >
> > Whichever part can detect vbus, the driver for that part must be able
> > to find the extcon and trigger a notification.
> > Maybe one part can detect VBUS, another can measure the resistance on
> > ID and a third can work through the state machine to determine if D+
> > and D- are shorted together.
> > Somehow these three need to work together to determine what is
> plugged
> > in to the external connection port. Somewhere there much an 'extcon'
> > device which represents that port and which the three devices can find
> > and can interact with.
> > I think it makes sense for the usb_phy to be the connection point.
> > Each of the devices can get to the phy, and the phy can get to the extcon.
> > It doesn't matter very much if the usb phy driver creates the extcon,
> > or if something else creates the extcon and the phy driver performs a
> > lookup to find it (e.g. based on devicetree info).
> >
> > The point is that there is obviously an external physical connection,
> > and so there should be an 'extcon' device that represents it.
>
> Peter & Jun, is it OK for you every phy has one extcon device to receive VBUS
> notification, especially for detecting the charger type by software?
>
My understanding is phy/usb_phy as the connection point, will send the notification
to PMIC driver which actually control the charge current, also this will be done in
your common framework, right?
Li Jun
> >
> >>
> >> (2) Change the notifier of usb_phy to be used consistently.
> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c and
> >> phy-gpio-vbus-usb.c were used to send out the connect events, and
> >> phy-ab8500-usb.c also was used to send out the MUSB connect events.
> >> There are no phy drivers will notify 'vbus_draw' information by the
> notifier of usb_phy, which was used consistently now.
> >> Moreover it is difficult to change the notifier of usb_phy to be used
> >> only to communicate the 'vbus_draw' information, since we need to
> >> refactor and test these related phy drivers, power drivers or some
> >> mfd drivers, which is a huge workload.
> >
> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> > matters.
>
> But it did not use the notifier of usb_phy.
>
> > phy-ab8500-usb.c appears to send vbus_draw information.
>
> Users will not use the vbus_draw information send from phy-ab8500-usb.c
>
> >
> > I understand your reluctance to change drivers that you cannot test.
> > An alternative it do change all the
> > atomic_notifier_call_chain(.*notifier,
> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
> > declare the passing of NULL to be deprecated (so hopefully people
> > won't use it in new code).
> > Then any notification callback that expects a current can just ignore
> > calls where the pointer is NULL.
>
> I am afraid if it is enough to send out vbus draw information from USB phy
> driver, for example you will miss super speed (900mA), which need get the
> speed information from gadget driver.
>
> >
> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> > It is the only driver which expects a 'gadget', and it doesn't really
> > need to as it already knows the gadget.
> > The patch below fixes this.
> > With that in place, phy-generic and phy-gpio-vbus-usb can be changed
> > to pass NULL. When we can safely use the notifier to pass vbus_draw
> > information uniformly.
> >
> >>
> >> (3) Still keep charger_type_show() API.
> >> Firstly I think we should combine all charger related information
> >> into one place for users, which is convenient.
> >
> > convenience is very much a secondary issue.
> >
> >> Secondly not only we get charger type from extcon, but also in some
> >> scenarios we can get charger type from USB controller driver, USB
> >> type-c driver, pmic driver, we should also need one place to export the
> charger type.
> >
> > As I have said, all of these sources of information should feed into
> > the extcon.
> >
> > There are ultimately two possible sources of information about the
> > current available from the usb port.
> > One is the physical properties of the cable, such as resistance of ID,
> > any short between D+ and D- etc. Being properties of the cable, they
> > should be reported through the extcon.
> >
> > The other is information gathered during the USB protocol handshake.
> > For USB2, this is the requested current of the profile that the host
> > activates. This should be reported though the USB gadget device.
> >
> > I don't know how USB3 and/or type-C work but I would be surprised if
> > they don't fit into the two cases above. If you think otherwise,
> > please surprise me. I'm always keen to learn.
> >
> > If the extcon reports the type of cable detected, and the gadget
> > reports the result of any negotiation, then that is enough to
> > determine the charger type. It doesn't need to be more convenient than
> that.
>
> If we are all agree we did not need the USB charger, then we can add
> 'current' attribute of USB gadget device.
> Thanks for your suggestion.
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-09 1:50 ` Jun Li
@ 2017-03-09 6:10 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-09 6:10 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi,
On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Tuesday, March 07, 2017 5:39 PM
>> To: NeilBrown <neilb@suse.com>
>> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH <gregkh@linuxfoundation.org>;
>> Sebastian Reichel <sre@kernel.org>; Dmitry Eremin-Solenikov
>> <dbaryshkov@gmail.com>; David Woodhouse <dwmw2@infradead.org>;
>> robh@kernel.org; Jun Li <jun.li@nxp.com>; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >
>> >> Currently the Linux kernel does not provide any standard integration
>> >> of this feature that integrates the USB subsystem with the system
>> >> power regulation provided by PMICs meaning that either vendors must
>> >> add this in their kernels or USB gadget devices based on Linux (such
>> >> as mobile phones) may not behave as they should. Thus provide a
>> standard framework for doing this in kernel.
>> >>
>> >> Now introduce one user with wm831x_power to support and test the usb
>> charger.
>> >> Another user introduced to support charger detection by Jun Li:
>> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> Moreover there may be other potential users will use it in future.
>> >>
>> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
>> >> and usb phy driver, now all were merged. (Thanks for Neil's
>> >> suggestion)
>> >> (1) Have fixed the inconsistencies with USB connector types in extcon
>> >> subsystem by following links:
>> >> https://lkml.org/lkml/2016/12/21/13
>> >> https://lkml.org/lkml/2016/12/21/15
>> >> https://lkml.org/lkml/2016/12/21/79
>> >> https://lkml.org/lkml/2017/1/3/13
>> >>
>> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> introduce USB charger to set PMIC current drawn from USB
>> >> configuration, moreover some 'set_power' callbacks did not implement
>> >> anything to set PMIC current, thus remove them by following links:
>> >> https://lkml.org/lkml/2017/1/18/436
>> >> https://lkml.org/lkml/2017/1/18/439
>> >> https://lkml.org/lkml/2017/1/18/438
>> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
>> >> still used 'set_power' callback to set current, we can remove them in
>> >> future. (I have no platform with enabling these two phy drivers, so I
>> >> can not test them if I converted 'set_power' callback to USB
>> >> charger.)
>> >>
>> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> patchset, and I expalined each issue and may be need discuss again:
>> >> (1) Change all usb phys to register an extcon and to send appropriate
>> notifications.
>> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> phy-omap-otg.c and
>> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
>> >> change all usb phys to register an extcon, since there are no extcon
>> >> device to register for these different phy drivers.
>> >
>> > You don't have to change every driver. You just need to make it easy
>> > and obvious how to change drivers in a consistent coherent way.
>> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
>> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
>> > send notification on that extcon (if it is non-NULL).
>> > e.g. usb_phy_vbus_on() could send an extcon notification.
>> >
>> > Then any phy driver which adds support for setting phy->extcon_dev
>> > appropriately, immediately gets the relevant notifications sent.
>>
>> OK. We can make these extcon related code into phy common part.
>>
>
> Will generic phy need add extcon as well?
Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
be common code.
>
>> >
>> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
>> >> register an extcon, but also for the drivers which can detect USB
>> >> charger type, it may be USB controller driver, USB type-c driver,
>> >> pmic driver, and these drivers may not have an extcon device since
>> >> the internal part can finish the vbus detect.
>> >
>> > Whichever part can detect vbus, the driver for that part must be able
>> > to find the extcon and trigger a notification.
>> > Maybe one part can detect VBUS, another can measure the resistance on
>> > ID and a third can work through the state machine to determine if D+
>> > and D- are shorted together.
>> > Somehow these three need to work together to determine what is
>> plugged
>> > in to the external connection port. Somewhere there much an 'extcon'
>> > device which represents that port and which the three devices can find
>> > and can interact with.
>> > I think it makes sense for the usb_phy to be the connection point.
>> > Each of the devices can get to the phy, and the phy can get to the extcon.
>> > It doesn't matter very much if the usb phy driver creates the extcon,
>> > or if something else creates the extcon and the phy driver performs a
>> > lookup to find it (e.g. based on devicetree info).
>> >
>> > The point is that there is obviously an external physical connection,
>> > and so there should be an 'extcon' device that represents it.
>>
>> Peter & Jun, is it OK for you every phy has one extcon device to receive VBUS
>> notification, especially for detecting the charger type by software?
>>
>
> My understanding is phy/usb_phy as the connection point, will send the notification
> to PMIC driver which actually control the charge current, also this will be done in
> your common framework, right?
Not in USB charger framework. If we are all agree every usb_phy can
register one extcon device, can get correct charger type and send out
correct vbus_draw information, then we don't need USB charger
framework as Neil suggested. So this will be okay for your case
(especially for detecting the charger type by software) ?
>> >
>> >>
>> >> (2) Change the notifier of usb_phy to be used consistently.
>> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
>> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c and
>> >> phy-gpio-vbus-usb.c were used to send out the connect events, and
>> >> phy-ab8500-usb.c also was used to send out the MUSB connect events.
>> >> There are no phy drivers will notify 'vbus_draw' information by the
>> notifier of usb_phy, which was used consistently now.
>> >> Moreover it is difficult to change the notifier of usb_phy to be used
>> >> only to communicate the 'vbus_draw' information, since we need to
>> >> refactor and test these related phy drivers, power drivers or some
>> >> mfd drivers, which is a huge workload.
>> >
>> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
>> > matters.
>>
>> But it did not use the notifier of usb_phy.
>>
>> > phy-ab8500-usb.c appears to send vbus_draw information.
>>
>> Users will not use the vbus_draw information send from phy-ab8500-usb.c
>>
>> >
>> > I understand your reluctance to change drivers that you cannot test.
>> > An alternative it do change all the
>> > atomic_notifier_call_chain(.*notifier,
>> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> > declare the passing of NULL to be deprecated (so hopefully people
>> > won't use it in new code).
>> > Then any notification callback that expects a current can just ignore
>> > calls where the pointer is NULL.
>>
>> I am afraid if it is enough to send out vbus draw information from USB phy
>> driver, for example you will miss super speed (900mA), which need get the
>> speed information from gadget driver.
>>
>> >
>> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
>> > It is the only driver which expects a 'gadget', and it doesn't really
>> > need to as it already knows the gadget.
>> > The patch below fixes this.
>> > With that in place, phy-generic and phy-gpio-vbus-usb can be changed
>> > to pass NULL. When we can safely use the notifier to pass vbus_draw
>> > information uniformly.
>> >
>> >>
>> >> (3) Still keep charger_type_show() API.
>> >> Firstly I think we should combine all charger related information
>> >> into one place for users, which is convenient.
>> >
>> > convenience is very much a secondary issue.
>> >
>> >> Secondly not only we get charger type from extcon, but also in some
>> >> scenarios we can get charger type from USB controller driver, USB
>> >> type-c driver, pmic driver, we should also need one place to export the
>> charger type.
>> >
>> > As I have said, all of these sources of information should feed into
>> > the extcon.
>> >
>> > There are ultimately two possible sources of information about the
>> > current available from the usb port.
>> > One is the physical properties of the cable, such as resistance of ID,
>> > any short between D+ and D- etc. Being properties of the cable, they
>> > should be reported through the extcon.
>> >
>> > The other is information gathered during the USB protocol handshake.
>> > For USB2, this is the requested current of the profile that the host
>> > activates. This should be reported though the USB gadget device.
>> >
>> > I don't know how USB3 and/or type-C work but I would be surprised if
>> > they don't fit into the two cases above. If you think otherwise,
>> > please surprise me. I'm always keen to learn.
>> >
>> > If the extcon reports the type of cable detected, and the gadget
>> > reports the result of any negotiation, then that is enough to
>> > determine the charger type. It doesn't need to be more convenient than
>> that.
>>
>> If we are all agree we did not need the USB charger, then we can add
>> 'current' attribute of USB gadget device.
>> Thanks for your suggestion.
>>
>> --
>> Baolin.wang
>> Best Regards
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-09 6:10 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-09 6:10 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
Hi,
On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Tuesday, March 07, 2017 5:39 PM
>> To: NeilBrown <neilb@suse.com>
>> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH <gregkh@linuxfoundation.org>;
>> Sebastian Reichel <sre@kernel.org>; Dmitry Eremin-Solenikov
>> <dbaryshkov@gmail.com>; David Woodhouse <dwmw2@infradead.org>;
>> robh@kernel.org; Jun Li <jun.li@nxp.com>; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >
>> >> Currently the Linux kernel does not provide any standard integration
>> >> of this feature that integrates the USB subsystem with the system
>> >> power regulation provided by PMICs meaning that either vendors must
>> >> add this in their kernels or USB gadget devices based on Linux (such
>> >> as mobile phones) may not behave as they should. Thus provide a
>> standard framework for doing this in kernel.
>> >>
>> >> Now introduce one user with wm831x_power to support and test the usb
>> charger.
>> >> Another user introduced to support charger detection by Jun Li:
>> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> Moreover there may be other potential users will use it in future.
>> >>
>> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
>> >> and usb phy driver, now all were merged. (Thanks for Neil's
>> >> suggestion)
>> >> (1) Have fixed the inconsistencies with USB connector types in extcon
>> >> subsystem by following links:
>> >> https://lkml.org/lkml/2016/12/21/13
>> >> https://lkml.org/lkml/2016/12/21/15
>> >> https://lkml.org/lkml/2016/12/21/79
>> >> https://lkml.org/lkml/2017/1/3/13
>> >>
>> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> introduce USB charger to set PMIC current drawn from USB
>> >> configuration, moreover some 'set_power' callbacks did not implement
>> >> anything to set PMIC current, thus remove them by following links:
>> >> https://lkml.org/lkml/2017/1/18/436
>> >> https://lkml.org/lkml/2017/1/18/439
>> >> https://lkml.org/lkml/2017/1/18/438
>> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
>> >> still used 'set_power' callback to set current, we can remove them in
>> >> future. (I have no platform with enabling these two phy drivers, so I
>> >> can not test them if I converted 'set_power' callback to USB
>> >> charger.)
>> >>
>> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> patchset, and I expalined each issue and may be need discuss again:
>> >> (1) Change all usb phys to register an extcon and to send appropriate
>> notifications.
>> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> phy-omap-otg.c and
>> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
>> >> change all usb phys to register an extcon, since there are no extcon
>> >> device to register for these different phy drivers.
>> >
>> > You don't have to change every driver. You just need to make it easy
>> > and obvious how to change drivers in a consistent coherent way.
>> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
>> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
>> > send notification on that extcon (if it is non-NULL).
>> > e.g. usb_phy_vbus_on() could send an extcon notification.
>> >
>> > Then any phy driver which adds support for setting phy->extcon_dev
>> > appropriately, immediately gets the relevant notifications sent.
>>
>> OK. We can make these extcon related code into phy common part.
>>
>
> Will generic phy need add extcon as well?
Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
be common code.
>
>> >
>> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
>> >> register an extcon, but also for the drivers which can detect USB
>> >> charger type, it may be USB controller driver, USB type-c driver,
>> >> pmic driver, and these drivers may not have an extcon device since
>> >> the internal part can finish the vbus detect.
>> >
>> > Whichever part can detect vbus, the driver for that part must be able
>> > to find the extcon and trigger a notification.
>> > Maybe one part can detect VBUS, another can measure the resistance on
>> > ID and a third can work through the state machine to determine if D+
>> > and D- are shorted together.
>> > Somehow these three need to work together to determine what is
>> plugged
>> > in to the external connection port. Somewhere there much an 'extcon'
>> > device which represents that port and which the three devices can find
>> > and can interact with.
>> > I think it makes sense for the usb_phy to be the connection point.
>> > Each of the devices can get to the phy, and the phy can get to the extcon.
>> > It doesn't matter very much if the usb phy driver creates the extcon,
>> > or if something else creates the extcon and the phy driver performs a
>> > lookup to find it (e.g. based on devicetree info).
>> >
>> > The point is that there is obviously an external physical connection,
>> > and so there should be an 'extcon' device that represents it.
>>
>> Peter & Jun, is it OK for you every phy has one extcon device to receive VBUS
>> notification, especially for detecting the charger type by software?
>>
>
> My understanding is phy/usb_phy as the connection point, will send the notification
> to PMIC driver which actually control the charge current, also this will be done in
> your common framework, right?
Not in USB charger framework. If we are all agree every usb_phy can
register one extcon device, can get correct charger type and send out
correct vbus_draw information, then we don't need USB charger
framework as Neil suggested. So this will be okay for your case
(especially for detecting the charger type by software) ?
>> >
>> >>
>> >> (2) Change the notifier of usb_phy to be used consistently.
>> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
>> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c and
>> >> phy-gpio-vbus-usb.c were used to send out the connect events, and
>> >> phy-ab8500-usb.c also was used to send out the MUSB connect events.
>> >> There are no phy drivers will notify 'vbus_draw' information by the
>> notifier of usb_phy, which was used consistently now.
>> >> Moreover it is difficult to change the notifier of usb_phy to be used
>> >> only to communicate the 'vbus_draw' information, since we need to
>> >> refactor and test these related phy drivers, power drivers or some
>> >> mfd drivers, which is a huge workload.
>> >
>> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
>> > matters.
>>
>> But it did not use the notifier of usb_phy.
>>
>> > phy-ab8500-usb.c appears to send vbus_draw information.
>>
>> Users will not use the vbus_draw information send from phy-ab8500-usb.c
>>
>> >
>> > I understand your reluctance to change drivers that you cannot test.
>> > An alternative it do change all the
>> > atomic_notifier_call_chain(.*notifier,
>> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> > declare the passing of NULL to be deprecated (so hopefully people
>> > won't use it in new code).
>> > Then any notification callback that expects a current can just ignore
>> > calls where the pointer is NULL.
>>
>> I am afraid if it is enough to send out vbus draw information from USB phy
>> driver, for example you will miss super speed (900mA), which need get the
>> speed information from gadget driver.
>>
>> >
>> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
>> > It is the only driver which expects a 'gadget', and it doesn't really
>> > need to as it already knows the gadget.
>> > The patch below fixes this.
>> > With that in place, phy-generic and phy-gpio-vbus-usb can be changed
>> > to pass NULL. When we can safely use the notifier to pass vbus_draw
>> > information uniformly.
>> >
>> >>
>> >> (3) Still keep charger_type_show() API.
>> >> Firstly I think we should combine all charger related information
>> >> into one place for users, which is convenient.
>> >
>> > convenience is very much a secondary issue.
>> >
>> >> Secondly not only we get charger type from extcon, but also in some
>> >> scenarios we can get charger type from USB controller driver, USB
>> >> type-c driver, pmic driver, we should also need one place to export the
>> charger type.
>> >
>> > As I have said, all of these sources of information should feed into
>> > the extcon.
>> >
>> > There are ultimately two possible sources of information about the
>> > current available from the usb port.
>> > One is the physical properties of the cable, such as resistance of ID,
>> > any short between D+ and D- etc. Being properties of the cable, they
>> > should be reported through the extcon.
>> >
>> > The other is information gathered during the USB protocol handshake.
>> > For USB2, this is the requested current of the profile that the host
>> > activates. This should be reported though the USB gadget device.
>> >
>> > I don't know how USB3 and/or type-C work but I would be surprised if
>> > they don't fit into the two cases above. If you think otherwise,
>> > please surprise me. I'm always keen to learn.
>> >
>> > If the extcon reports the type of cable detected, and the gadget
>> > reports the result of any negotiation, then that is enough to
>> > determine the charger type. It doesn't need to be more convenient than
>> that.
>>
>> If we are all agree we did not need the USB charger, then we can add
>> 'current' attribute of USB gadget device.
>> Thanks for your suggestion.
>>
>> --
>> Baolin.wang
>> Best Regards
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-09 6:10 ` Baolin Wang
@ 2017-03-09 10:34 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-09 10:34 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> Hi,
>
> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> To: NeilBrown <neilb@suse.com>
> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb
> >> charger.
> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> Moreover there may be other potential users will use it in future.
> >> >>
> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> Neil's
> >> >> suggestion)
> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> extcon subsystem by following links:
> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus remove them by
> following links:
> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> current, we can remove them in future. (I have no platform with
> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> converted 'set_power' callback to USB
> >> >> charger.)
> >> >>
> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> appropriate
> >> notifications.
> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> phy-omap-otg.c and
> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> >> change all usb phys to register an extcon, since there are no
> >> >> extcon device to register for these different phy drivers.
> >> >
> >> > You don't have to change every driver. You just need to make it
> >> > easy and obvious how to change drivers in a consistent coherent way.
> >> > For a start you would add a 'struct extcon_dev' to 'struct
> >> > usb_phy', and possibly add or extend some 'static inline's in
> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >> >
> >> > Then any phy driver which adds support for setting phy->extcon_dev
> >> > appropriately, immediately gets the relevant notifications sent.
> >>
> >> OK. We can make these extcon related code into phy common part.
> >>
> >
> > Will generic phy need add extcon as well?
>
> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will be common
> code.
>
I mean the common code need add 'struct extcon_dev' into both 'struct phy' and
'struct usb_phy', right? as some/new usb phy use that generic phy driver.
> >
> >> >
> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> >> register an extcon, but also for the drivers which can detect USB
> >> >> charger type, it may be USB controller driver, USB type-c driver,
> >> >> pmic driver, and these drivers may not have an extcon device since
> >> >> the internal part can finish the vbus detect.
> >> >
> >> > Whichever part can detect vbus, the driver for that part must be
> >> > able to find the extcon and trigger a notification.
> >> > Maybe one part can detect VBUS, another can measure the resistance
> >> > on ID and a third can work through the state machine to determine
> >> > if D+ and D- are shorted together.
> >> > Somehow these three need to work together to determine what is
> >> plugged
> >> > in to the external connection port. Somewhere there much an 'extcon'
> >> > device which represents that port and which the three devices can
> >> > find and can interact with.
> >> > I think it makes sense for the usb_phy to be the connection point.
> >> > Each of the devices can get to the phy, and the phy can get to the
> extcon.
> >> > It doesn't matter very much if the usb phy driver creates the
> >> > extcon, or if something else creates the extcon and the phy driver
> >> > performs a lookup to find it (e.g. based on devicetree info).
> >> >
> >> > The point is that there is obviously an external physical
> >> > connection, and so there should be an 'extcon' device that represents it.
> >>
> >> Peter & Jun, is it OK for you every phy has one extcon device to
> >> receive VBUS notification, especially for detecting the charger type by
> software?
> >>
> >
> > My understanding is phy/usb_phy as the connection point, will send the
> > notification to PMIC driver which actually control the charge current,
> > also this will be done in your common framework, right?
>
> Not in USB charger framework. If we are all agree every usb_phy can register
> one extcon device, can get correct charger type and send out correct
> vbus_draw information, then we don't need USB charger framework as Neil
> suggested. So this will be okay for your case (especially for detecting the
> charger type by software) ?
In my case, charger detection is done by controller driver and I need do charger
type detection internally, and only pass the current draw info via phy which will
send out, this seems ok for me, but I think it will be good if you or someone can
show us an example user based on the design Neil suggested.
Will you work out that common code if this USB charger framework is not needed?
Li Jun
>
> >> >
> >> >>
> >> >> (2) Change the notifier of usb_phy to be used consistently.
> >> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
> >> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c
> >> >> and phy-gpio-vbus-usb.c were used to send out the connect events,
> >> >> and phy-ab8500-usb.c also was used to send out the MUSB connect
> events.
> >> >> There are no phy drivers will notify 'vbus_draw' information by
> >> >> the
> >> notifier of usb_phy, which was used consistently now.
> >> >> Moreover it is difficult to change the notifier of usb_phy to be
> >> >> used only to communicate the 'vbus_draw' information, since we
> >> >> need to refactor and test these related phy drivers, power drivers
> >> >> or some mfd drivers, which is a huge workload.
> >> >
> >> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> >> > matters.
> >>
> >> But it did not use the notifier of usb_phy.
> >>
> >> > phy-ab8500-usb.c appears to send vbus_draw information.
> >>
> >> Users will not use the vbus_draw information send from
> >> phy-ab8500-usb.c
> >>
> >> >
> >> > I understand your reluctance to change drivers that you cannot test.
> >> > An alternative it do change all the
> >> > atomic_notifier_call_chain(.*notifier,
> >> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
> >> > declare the passing of NULL to be deprecated (so hopefully people
> >> > won't use it in new code).
> >> > Then any notification callback that expects a current can just
> >> > ignore calls where the pointer is NULL.
> >>
> >> I am afraid if it is enough to send out vbus draw information from
> >> USB phy driver, for example you will miss super speed (900mA), which
> >> need get the speed information from gadget driver.
> >>
> >> >
> >> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> >> > It is the only driver which expects a 'gadget', and it doesn't
> >> > really need to as it already knows the gadget.
> >> > The patch below fixes this.
> >> > With that in place, phy-generic and phy-gpio-vbus-usb can be
> >> > changed to pass NULL. When we can safely use the notifier to pass
> >> > vbus_draw information uniformly.
> >> >
> >> >>
> >> >> (3) Still keep charger_type_show() API.
> >> >> Firstly I think we should combine all charger related information
> >> >> into one place for users, which is convenient.
> >> >
> >> > convenience is very much a secondary issue.
> >> >
> >> >> Secondly not only we get charger type from extcon, but also in
> >> >> some scenarios we can get charger type from USB controller driver,
> >> >> USB type-c driver, pmic driver, we should also need one place to
> >> >> export the
> >> charger type.
> >> >
> >> > As I have said, all of these sources of information should feed
> >> > into the extcon.
> >> >
> >> > There are ultimately two possible sources of information about the
> >> > current available from the usb port.
> >> > One is the physical properties of the cable, such as resistance of
> >> > ID, any short between D+ and D- etc. Being properties of the
> >> > cable, they should be reported through the extcon.
> >> >
> >> > The other is information gathered during the USB protocol handshake.
> >> > For USB2, this is the requested current of the profile that the
> >> > host activates. This should be reported though the USB gadget device.
> >> >
> >> > I don't know how USB3 and/or type-C work but I would be surprised
> >> > if they don't fit into the two cases above. If you think
> >> > otherwise, please surprise me. I'm always keen to learn.
> >> >
> >> > If the extcon reports the type of cable detected, and the gadget
> >> > reports the result of any negotiation, then that is enough to
> >> > determine the charger type. It doesn't need to be more convenient
> >> > than
> >> that.
> >>
> >> If we are all agree we did not need the USB charger, then we can add
> >> 'current' attribute of USB gadget device.
> >> Thanks for your suggestion.
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
>
>
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-09 10:34 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-09 10:34 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> Hi,
>
> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> > Hi,
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> To: NeilBrown <neilb@suse.com>
> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb
> >> charger.
> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> Moreover there may be other potential users will use it in future.
> >> >>
> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> Neil's
> >> >> suggestion)
> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> extcon subsystem by following links:
> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus remove them by
> following links:
> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> current, we can remove them in future. (I have no platform with
> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> converted 'set_power' callback to USB
> >> >> charger.)
> >> >>
> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> appropriate
> >> notifications.
> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> phy-omap-otg.c and
> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> >> change all usb phys to register an extcon, since there are no
> >> >> extcon device to register for these different phy drivers.
> >> >
> >> > You don't have to change every driver. You just need to make it
> >> > easy and obvious how to change drivers in a consistent coherent way.
> >> > For a start you would add a 'struct extcon_dev' to 'struct
> >> > usb_phy', and possibly add or extend some 'static inline's in
> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >> >
> >> > Then any phy driver which adds support for setting phy->extcon_dev
> >> > appropriately, immediately gets the relevant notifications sent.
> >>
> >> OK. We can make these extcon related code into phy common part.
> >>
> >
> > Will generic phy need add extcon as well?
>
> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will be common
> code.
>
I mean the common code need add 'struct extcon_dev' into both 'struct phy' and
'struct usb_phy', right? as some/new usb phy use that generic phy driver.
> >
> >> >
> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> >> register an extcon, but also for the drivers which can detect USB
> >> >> charger type, it may be USB controller driver, USB type-c driver,
> >> >> pmic driver, and these drivers may not have an extcon device since
> >> >> the internal part can finish the vbus detect.
> >> >
> >> > Whichever part can detect vbus, the driver for that part must be
> >> > able to find the extcon and trigger a notification.
> >> > Maybe one part can detect VBUS, another can measure the resistance
> >> > on ID and a third can work through the state machine to determine
> >> > if D+ and D- are shorted together.
> >> > Somehow these three need to work together to determine what is
> >> plugged
> >> > in to the external connection port. Somewhere there much an 'extcon'
> >> > device which represents that port and which the three devices can
> >> > find and can interact with.
> >> > I think it makes sense for the usb_phy to be the connection point.
> >> > Each of the devices can get to the phy, and the phy can get to the
> extcon.
> >> > It doesn't matter very much if the usb phy driver creates the
> >> > extcon, or if something else creates the extcon and the phy driver
> >> > performs a lookup to find it (e.g. based on devicetree info).
> >> >
> >> > The point is that there is obviously an external physical
> >> > connection, and so there should be an 'extcon' device that represents it.
> >>
> >> Peter & Jun, is it OK for you every phy has one extcon device to
> >> receive VBUS notification, especially for detecting the charger type by
> software?
> >>
> >
> > My understanding is phy/usb_phy as the connection point, will send the
> > notification to PMIC driver which actually control the charge current,
> > also this will be done in your common framework, right?
>
> Not in USB charger framework. If we are all agree every usb_phy can register
> one extcon device, can get correct charger type and send out correct
> vbus_draw information, then we don't need USB charger framework as Neil
> suggested. So this will be okay for your case (especially for detecting the
> charger type by software) ?
In my case, charger detection is done by controller driver and I need do charger
type detection internally, and only pass the current draw info via phy which will
send out, this seems ok for me, but I think it will be good if you or someone can
show us an example user based on the design Neil suggested.
Will you work out that common code if this USB charger framework is not needed?
Li Jun
>
> >> >
> >> >>
> >> >> (2) Change the notifier of usb_phy to be used consistently.
> >> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
> >> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c
> >> >> and phy-gpio-vbus-usb.c were used to send out the connect events,
> >> >> and phy-ab8500-usb.c also was used to send out the MUSB connect
> events.
> >> >> There are no phy drivers will notify 'vbus_draw' information by
> >> >> the
> >> notifier of usb_phy, which was used consistently now.
> >> >> Moreover it is difficult to change the notifier of usb_phy to be
> >> >> used only to communicate the 'vbus_draw' information, since we
> >> >> need to refactor and test these related phy drivers, power drivers
> >> >> or some mfd drivers, which is a huge workload.
> >> >
> >> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
> >> > matters.
> >>
> >> But it did not use the notifier of usb_phy.
> >>
> >> > phy-ab8500-usb.c appears to send vbus_draw information.
> >>
> >> Users will not use the vbus_draw information send from
> >> phy-ab8500-usb.c
> >>
> >> >
> >> > I understand your reluctance to change drivers that you cannot test.
> >> > An alternative it do change all the
> >> > atomic_notifier_call_chain(.*notifier,
> >> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
> >> > declare the passing of NULL to be deprecated (so hopefully people
> >> > won't use it in new code).
> >> > Then any notification callback that expects a current can just
> >> > ignore calls where the pointer is NULL.
> >>
> >> I am afraid if it is enough to send out vbus draw information from
> >> USB phy driver, for example you will miss super speed (900mA), which
> >> need get the speed information from gadget driver.
> >>
> >> >
> >> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
> >> > It is the only driver which expects a 'gadget', and it doesn't
> >> > really need to as it already knows the gadget.
> >> > The patch below fixes this.
> >> > With that in place, phy-generic and phy-gpio-vbus-usb can be
> >> > changed to pass NULL. When we can safely use the notifier to pass
> >> > vbus_draw information uniformly.
> >> >
> >> >>
> >> >> (3) Still keep charger_type_show() API.
> >> >> Firstly I think we should combine all charger related information
> >> >> into one place for users, which is convenient.
> >> >
> >> > convenience is very much a secondary issue.
> >> >
> >> >> Secondly not only we get charger type from extcon, but also in
> >> >> some scenarios we can get charger type from USB controller driver,
> >> >> USB type-c driver, pmic driver, we should also need one place to
> >> >> export the
> >> charger type.
> >> >
> >> > As I have said, all of these sources of information should feed
> >> > into the extcon.
> >> >
> >> > There are ultimately two possible sources of information about the
> >> > current available from the usb port.
> >> > One is the physical properties of the cable, such as resistance of
> >> > ID, any short between D+ and D- etc. Being properties of the
> >> > cable, they should be reported through the extcon.
> >> >
> >> > The other is information gathered during the USB protocol handshake.
> >> > For USB2, this is the requested current of the profile that the
> >> > host activates. This should be reported though the USB gadget device.
> >> >
> >> > I don't know how USB3 and/or type-C work but I would be surprised
> >> > if they don't fit into the two cases above. If you think
> >> > otherwise, please surprise me. I'm always keen to learn.
> >> >
> >> > If the extcon reports the type of cable detected, and the gadget
> >> > reports the result of any negotiation, then that is enough to
> >> > determine the charger type. It doesn't need to be more convenient
> >> > than
> >> that.
> >>
> >> If we are all agree we did not need the USB charger, then we can add
> >> 'current' attribute of USB gadget device.
> >> Thanks for your suggestion.
> >>
> >> --
> >> Baolin.wang
> >> Best Regards
>
>
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-09 10:34 ` Jun Li
@ 2017-03-09 11:22 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-09 11:22 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
On 9 March 2017 at 18:34, Jun Li <jun.li@nxp.com> wrote:
>
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Thursday, March 09, 2017 2:11 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> Hi,
>>
>> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
>> > Hi,
>> >
>> >> -----Original Message-----
>> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> >> Sent: Tuesday, March 07, 2017 5:39 PM
>> >> To: NeilBrown <neilb@suse.com>
>> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
>> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
>> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
>> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
>> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
>> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
>> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
>> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
>> >> <john.stultz@linaro.org>; Charles Keepax
>> >> <ckeepax@opensource.wolfsonmicro.com>;
>> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> >> mainlining@lists.linuxfoundation.org; LKML
>> >> <linux-kernel@vger.kernel.org>
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >> >
>> >> >> Currently the Linux kernel does not provide any standard
>> >> >> integration of this feature that integrates the USB subsystem with
>> >> >> the system power regulation provided by PMICs meaning that either
>> >> >> vendors must add this in their kernels or USB gadget devices based
>> >> >> on Linux (such as mobile phones) may not behave as they should.
>> >> >> Thus provide a
>> >> standard framework for doing this in kernel.
>> >> >>
>> >> >> Now introduce one user with wm831x_power to support and test the
>> >> >> usb
>> >> charger.
>> >> >> Another user introduced to support charger detection by Jun Li:
>> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> >> Moreover there may be other potential users will use it in future.
>> >> >>
>> >> >> 1. Before v19 patchset we've fixed below issues in extcon
>> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
>> >> >> Neil's
>> >> >> suggestion)
>> >> >> (1) Have fixed the inconsistencies with USB connector types in
>> >> >> extcon subsystem by following links:
>> >> >> https://lkml.org/lkml/2016/12/21/13
>> >> >> https://lkml.org/lkml/2016/12/21/15
>> >> >> https://lkml.org/lkml/2016/12/21/79
>> >> >> https://lkml.org/lkml/2017/1/3/13
>> >> >>
>> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> >> introduce USB charger to set PMIC current drawn from USB
>> >> >> configuration, moreover some 'set_power' callbacks did not
>> >> >> implement anything to set PMIC current, thus remove them by
>> following links:
>> >> >> https://lkml.org/lkml/2017/1/18/436
>> >> >> https://lkml.org/lkml/2017/1/18/439
>> >> >> https://lkml.org/lkml/2017/1/18/438
>> >> >> Now only two phy drivers (phy-isp1301-omap.c and
>> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
>> >> >> current, we can remove them in future. (I have no platform with
>> >> >> enabling these two phy drivers, so I can not test them if I
>> >> >> converted 'set_power' callback to USB
>> >> >> charger.)
>> >> >>
>> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> >> patchset, and I expalined each issue and may be need discuss again:
>> >> >> (1) Change all usb phys to register an extcon and to send
>> >> >> appropriate
>> >> notifications.
>> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> >> phy-omap-otg.c and
>> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
>> >> >> change all usb phys to register an extcon, since there are no
>> >> >> extcon device to register for these different phy drivers.
>> >> >
>> >> > You don't have to change every driver. You just need to make it
>> >> > easy and obvious how to change drivers in a consistent coherent way.
>> >> > For a start you would add a 'struct extcon_dev' to 'struct
>> >> > usb_phy', and possibly add or extend some 'static inline's in
>> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
>> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
>> >> >
>> >> > Then any phy driver which adds support for setting phy->extcon_dev
>> >> > appropriately, immediately gets the relevant notifications sent.
>> >>
>> >> OK. We can make these extcon related code into phy common part.
>> >>
>> >
>> > Will generic phy need add extcon as well?
>>
>> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will be common
>> code.
>>
>
> I mean the common code need add 'struct extcon_dev' into both 'struct phy' and
> 'struct usb_phy', right? as some/new usb phy use that generic phy driver.
Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
'struct phy'.
>> >
>> >> >
>> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
>> >> >> register an extcon, but also for the drivers which can detect USB
>> >> >> charger type, it may be USB controller driver, USB type-c driver,
>> >> >> pmic driver, and these drivers may not have an extcon device since
>> >> >> the internal part can finish the vbus detect.
>> >> >
>> >> > Whichever part can detect vbus, the driver for that part must be
>> >> > able to find the extcon and trigger a notification.
>> >> > Maybe one part can detect VBUS, another can measure the resistance
>> >> > on ID and a third can work through the state machine to determine
>> >> > if D+ and D- are shorted together.
>> >> > Somehow these three need to work together to determine what is
>> >> plugged
>> >> > in to the external connection port. Somewhere there much an 'extcon'
>> >> > device which represents that port and which the three devices can
>> >> > find and can interact with.
>> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> > Each of the devices can get to the phy, and the phy can get to the
>> extcon.
>> >> > It doesn't matter very much if the usb phy driver creates the
>> >> > extcon, or if something else creates the extcon and the phy driver
>> >> > performs a lookup to find it (e.g. based on devicetree info).
>> >> >
>> >> > The point is that there is obviously an external physical
>> >> > connection, and so there should be an 'extcon' device that represents it.
>> >>
>> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> receive VBUS notification, especially for detecting the charger type by
>> software?
>> >>
>> >
>> > My understanding is phy/usb_phy as the connection point, will send the
>> > notification to PMIC driver which actually control the charge current,
>> > also this will be done in your common framework, right?
>>
>> Not in USB charger framework. If we are all agree every usb_phy can register
>> one extcon device, can get correct charger type and send out correct
>> vbus_draw information, then we don't need USB charger framework as Neil
>> suggested. So this will be okay for your case (especially for detecting the
>> charger type by software) ?
>
> In my case, charger detection is done by controller driver and I need do charger
> type detection internally, and only pass the current draw info via phy which will
> send out, this seems ok for me, but I think it will be good if you or someone can
> show us an example user based on the design Neil suggested.
> Will you work out that common code if this USB charger framework is not needed?
I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
phy“. Others are already ready if everyone has no complain about
current design, except my one concern. (I am afraid if it is enough to
send out vbus draw information from USB phy driver, for example you
will miss super speed (900mA), which need get the speed information
from gadget driver.)
>> >> >
>> >> >>
>> >> >> (2) Change the notifier of usb_phy to be used consistently.
>> >> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
>> >> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c
>> >> >> and phy-gpio-vbus-usb.c were used to send out the connect events,
>> >> >> and phy-ab8500-usb.c also was used to send out the MUSB connect
>> events.
>> >> >> There are no phy drivers will notify 'vbus_draw' information by
>> >> >> the
>> >> notifier of usb_phy, which was used consistently now.
>> >> >> Moreover it is difficult to change the notifier of usb_phy to be
>> >> >> used only to communicate the 'vbus_draw' information, since we
>> >> >> need to refactor and test these related phy drivers, power drivers
>> >> >> or some mfd drivers, which is a huge workload.
>> >> >
>> >> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
>> >> > matters.
>> >>
>> >> But it did not use the notifier of usb_phy.
>> >>
>> >> > phy-ab8500-usb.c appears to send vbus_draw information.
>> >>
>> >> Users will not use the vbus_draw information send from
>> >> phy-ab8500-usb.c
>> >>
>> >> >
>> >> > I understand your reluctance to change drivers that you cannot test.
>> >> > An alternative it do change all the
>> >> > atomic_notifier_call_chain(.*notifier,
>> >> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> >> > declare the passing of NULL to be deprecated (so hopefully people
>> >> > won't use it in new code).
>> >> > Then any notification callback that expects a current can just
>> >> > ignore calls where the pointer is NULL.
>> >>
>> >> I am afraid if it is enough to send out vbus draw information from
>> >> USB phy driver, for example you will miss super speed (900mA), which
>> >> need get the speed information from gadget driver.
>> >>
>> >> >
>> >> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
>> >> > It is the only driver which expects a 'gadget', and it doesn't
>> >> > really need to as it already knows the gadget.
>> >> > The patch below fixes this.
>> >> > With that in place, phy-generic and phy-gpio-vbus-usb can be
>> >> > changed to pass NULL. When we can safely use the notifier to pass
>> >> > vbus_draw information uniformly.
>> >> >
>> >> >>
>> >> >> (3) Still keep charger_type_show() API.
>> >> >> Firstly I think we should combine all charger related information
>> >> >> into one place for users, which is convenient.
>> >> >
>> >> > convenience is very much a secondary issue.
>> >> >
>> >> >> Secondly not only we get charger type from extcon, but also in
>> >> >> some scenarios we can get charger type from USB controller driver,
>> >> >> USB type-c driver, pmic driver, we should also need one place to
>> >> >> export the
>> >> charger type.
>> >> >
>> >> > As I have said, all of these sources of information should feed
>> >> > into the extcon.
>> >> >
>> >> > There are ultimately two possible sources of information about the
>> >> > current available from the usb port.
>> >> > One is the physical properties of the cable, such as resistance of
>> >> > ID, any short between D+ and D- etc. Being properties of the
>> >> > cable, they should be reported through the extcon.
>> >> >
>> >> > The other is information gathered during the USB protocol handshake.
>> >> > For USB2, this is the requested current of the profile that the
>> >> > host activates. This should be reported though the USB gadget device.
>> >> >
>> >> > I don't know how USB3 and/or type-C work but I would be surprised
>> >> > if they don't fit into the two cases above. If you think
>> >> > otherwise, please surprise me. I'm always keen to learn.
>> >> >
>> >> > If the extcon reports the type of cable detected, and the gadget
>> >> > reports the result of any negotiation, then that is enough to
>> >> > determine the charger type. It doesn't need to be more convenient
>> >> > than
>> >> that.
>> >>
>> >> If we are all agree we did not need the USB charger, then we can add
>> >> 'current' attribute of USB gadget device.
>> >> Thanks for your suggestion.
>> >>
>> >> --
>> >> Baolin.wang
>> >> Best Regards
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-09 11:22 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-09 11:22 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
On 9 March 2017 at 18:34, Jun Li <jun.li@nxp.com> wrote:
>
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Thursday, March 09, 2017 2:11 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> Hi,
>>
>> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
>> > Hi,
>> >
>> >> -----Original Message-----
>> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> >> Sent: Tuesday, March 07, 2017 5:39 PM
>> >> To: NeilBrown <neilb@suse.com>
>> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
>> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
>> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
>> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
>> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
>> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
>> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
>> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
>> >> <john.stultz@linaro.org>; Charles Keepax
>> >> <ckeepax@opensource.wolfsonmicro.com>;
>> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> >> mainlining@lists.linuxfoundation.org; LKML
>> >> <linux-kernel@vger.kernel.org>
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >> >
>> >> >> Currently the Linux kernel does not provide any standard
>> >> >> integration of this feature that integrates the USB subsystem with
>> >> >> the system power regulation provided by PMICs meaning that either
>> >> >> vendors must add this in their kernels or USB gadget devices based
>> >> >> on Linux (such as mobile phones) may not behave as they should.
>> >> >> Thus provide a
>> >> standard framework for doing this in kernel.
>> >> >>
>> >> >> Now introduce one user with wm831x_power to support and test the
>> >> >> usb
>> >> charger.
>> >> >> Another user introduced to support charger detection by Jun Li:
>> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> >> Moreover there may be other potential users will use it in future.
>> >> >>
>> >> >> 1. Before v19 patchset we've fixed below issues in extcon
>> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
>> >> >> Neil's
>> >> >> suggestion)
>> >> >> (1) Have fixed the inconsistencies with USB connector types in
>> >> >> extcon subsystem by following links:
>> >> >> https://lkml.org/lkml/2016/12/21/13
>> >> >> https://lkml.org/lkml/2016/12/21/15
>> >> >> https://lkml.org/lkml/2016/12/21/79
>> >> >> https://lkml.org/lkml/2017/1/3/13
>> >> >>
>> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> >> introduce USB charger to set PMIC current drawn from USB
>> >> >> configuration, moreover some 'set_power' callbacks did not
>> >> >> implement anything to set PMIC current, thus remove them by
>> following links:
>> >> >> https://lkml.org/lkml/2017/1/18/436
>> >> >> https://lkml.org/lkml/2017/1/18/439
>> >> >> https://lkml.org/lkml/2017/1/18/438
>> >> >> Now only two phy drivers (phy-isp1301-omap.c and
>> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
>> >> >> current, we can remove them in future. (I have no platform with
>> >> >> enabling these two phy drivers, so I can not test them if I
>> >> >> converted 'set_power' callback to USB
>> >> >> charger.)
>> >> >>
>> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> >> patchset, and I expalined each issue and may be need discuss again:
>> >> >> (1) Change all usb phys to register an extcon and to send
>> >> >> appropriate
>> >> notifications.
>> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> >> phy-omap-otg.c and
>> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
>> >> >> change all usb phys to register an extcon, since there are no
>> >> >> extcon device to register for these different phy drivers.
>> >> >
>> >> > You don't have to change every driver. You just need to make it
>> >> > easy and obvious how to change drivers in a consistent coherent way.
>> >> > For a start you would add a 'struct extcon_dev' to 'struct
>> >> > usb_phy', and possibly add or extend some 'static inline's in
>> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
>> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
>> >> >
>> >> > Then any phy driver which adds support for setting phy->extcon_dev
>> >> > appropriately, immediately gets the relevant notifications sent.
>> >>
>> >> OK. We can make these extcon related code into phy common part.
>> >>
>> >
>> > Will generic phy need add extcon as well?
>>
>> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will be common
>> code.
>>
>
> I mean the common code need add 'struct extcon_dev' into both 'struct phy' and
> 'struct usb_phy', right? as some/new usb phy use that generic phy driver.
Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
'struct phy'.
>> >
>> >> >
>> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
>> >> >> register an extcon, but also for the drivers which can detect USB
>> >> >> charger type, it may be USB controller driver, USB type-c driver,
>> >> >> pmic driver, and these drivers may not have an extcon device since
>> >> >> the internal part can finish the vbus detect.
>> >> >
>> >> > Whichever part can detect vbus, the driver for that part must be
>> >> > able to find the extcon and trigger a notification.
>> >> > Maybe one part can detect VBUS, another can measure the resistance
>> >> > on ID and a third can work through the state machine to determine
>> >> > if D+ and D- are shorted together.
>> >> > Somehow these three need to work together to determine what is
>> >> plugged
>> >> > in to the external connection port. Somewhere there much an 'extcon'
>> >> > device which represents that port and which the three devices can
>> >> > find and can interact with.
>> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> > Each of the devices can get to the phy, and the phy can get to the
>> extcon.
>> >> > It doesn't matter very much if the usb phy driver creates the
>> >> > extcon, or if something else creates the extcon and the phy driver
>> >> > performs a lookup to find it (e.g. based on devicetree info).
>> >> >
>> >> > The point is that there is obviously an external physical
>> >> > connection, and so there should be an 'extcon' device that represents it.
>> >>
>> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> receive VBUS notification, especially for detecting the charger type by
>> software?
>> >>
>> >
>> > My understanding is phy/usb_phy as the connection point, will send the
>> > notification to PMIC driver which actually control the charge current,
>> > also this will be done in your common framework, right?
>>
>> Not in USB charger framework. If we are all agree every usb_phy can register
>> one extcon device, can get correct charger type and send out correct
>> vbus_draw information, then we don't need USB charger framework as Neil
>> suggested. So this will be okay for your case (especially for detecting the
>> charger type by software) ?
>
> In my case, charger detection is done by controller driver and I need do charger
> type detection internally, and only pass the current draw info via phy which will
> send out, this seems ok for me, but I think it will be good if you or someone can
> show us an example user based on the design Neil suggested.
> Will you work out that common code if this USB charger framework is not needed?
I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
phy“. Others are already ready if everyone has no complain about
current design, except my one concern. (I am afraid if it is enough to
send out vbus draw information from USB phy driver, for example you
will miss super speed (900mA), which need get the speed information
from gadget driver.)
>> >> >
>> >> >>
>> >> >> (2) Change the notifier of usb_phy to be used consistently.
>> >> >> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and
>> >> >> phy-gpio-vbus-usb.c) used the notifier of usb_phy. phy-generic.c
>> >> >> and phy-gpio-vbus-usb.c were used to send out the connect events,
>> >> >> and phy-ab8500-usb.c also was used to send out the MUSB connect
>> events.
>> >> >> There are no phy drivers will notify 'vbus_draw' information by
>> >> >> the
>> >> notifier of usb_phy, which was used consistently now.
>> >> >> Moreover it is difficult to change the notifier of usb_phy to be
>> >> >> used only to communicate the 'vbus_draw' information, since we
>> >> >> need to refactor and test these related phy drivers, power drivers
>> >> >> or some mfd drivers, which is a huge workload.
>> >> >
>> >> > You missed drivers/usb/musb/omap2430.c in you list, but that hardly
>> >> > matters.
>> >>
>> >> But it did not use the notifier of usb_phy.
>> >>
>> >> > phy-ab8500-usb.c appears to send vbus_draw information.
>> >>
>> >> Users will not use the vbus_draw information send from
>> >> phy-ab8500-usb.c
>> >>
>> >> >
>> >> > I understand your reluctance to change drivers that you cannot test.
>> >> > An alternative it do change all the
>> >> > atomic_notifier_call_chain(.*notifier,
>> >> > calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> >> > declare the passing of NULL to be deprecated (so hopefully people
>> >> > won't use it in new code).
>> >> > Then any notification callback that expects a current can just
>> >> > ignore calls where the pointer is NULL.
>> >>
>> >> I am afraid if it is enough to send out vbus draw information from
>> >> USB phy driver, for example you will miss super speed (900mA), which
>> >> need get the speed information from gadget driver.
>> >>
>> >> >
>> >> > The one difficulty with this is drivers/usb/gadget/udc/pxa27x_udc.c
>> >> > It is the only driver which expects a 'gadget', and it doesn't
>> >> > really need to as it already knows the gadget.
>> >> > The patch below fixes this.
>> >> > With that in place, phy-generic and phy-gpio-vbus-usb can be
>> >> > changed to pass NULL. When we can safely use the notifier to pass
>> >> > vbus_draw information uniformly.
>> >> >
>> >> >>
>> >> >> (3) Still keep charger_type_show() API.
>> >> >> Firstly I think we should combine all charger related information
>> >> >> into one place for users, which is convenient.
>> >> >
>> >> > convenience is very much a secondary issue.
>> >> >
>> >> >> Secondly not only we get charger type from extcon, but also in
>> >> >> some scenarios we can get charger type from USB controller driver,
>> >> >> USB type-c driver, pmic driver, we should also need one place to
>> >> >> export the
>> >> charger type.
>> >> >
>> >> > As I have said, all of these sources of information should feed
>> >> > into the extcon.
>> >> >
>> >> > There are ultimately two possible sources of information about the
>> >> > current available from the usb port.
>> >> > One is the physical properties of the cable, such as resistance of
>> >> > ID, any short between D+ and D- etc. Being properties of the
>> >> > cable, they should be reported through the extcon.
>> >> >
>> >> > The other is information gathered during the USB protocol handshake.
>> >> > For USB2, this is the requested current of the profile that the
>> >> > host activates. This should be reported though the USB gadget device.
>> >> >
>> >> > I don't know how USB3 and/or type-C work but I would be surprised
>> >> > if they don't fit into the two cases above. If you think
>> >> > otherwise, please surprise me. I'm always keen to learn.
>> >> >
>> >> > If the extcon reports the type of cable detected, and the gadget
>> >> > reports the result of any negotiation, then that is enough to
>> >> > determine the charger type. It doesn't need to be more convenient
>> >> > than
>> >> that.
>> >>
>> >> If we are all agree we did not need the USB charger, then we can add
>> >> 'current' attribute of USB gadget device.
>> >> Thanks for your suggestion.
>> >>
>> >> --
>> >> Baolin.wang
>> >> Best Regards
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-09 11:22 ` Baolin Wang
@ 2017-03-10 6:30 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-10 6:30 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 9 March 2017 at 18:34, Jun Li <jun.li@nxp.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li <jun.li@nxp.com>
> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> >> > Hi,
> >> >
> >> >> -----Original Message-----
> >> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown <neilb@suse.com>
> >> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
> >> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David
> Woodhouse
> >> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
> >> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> >> <ruslan.bilovol@gmail.com>; Peter Chen
> <peter.chen@freescale.com>;
> >> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John
> >> >> Stultz <john.stultz@linaro.org>; Charles Keepax
> >> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> >> mainlining@lists.linuxfoundation.org; LKML
> >> >> <linux-kernel@vger.kernel.org>
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> >> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >> >>
> >> >> >> (2) Instead of using 'set_power' callback in phy drivers, we
> >> >> >> will introduce USB charger to set PMIC current drawn from USB
> >> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> >> implement anything to set PMIC current, thus remove them by
> >> following links:
> >> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> >> current, we can remove them in future. (I have no platform with
> >> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> >> converted 'set_power' callback to USB
> >> >> >> charger.)
> >> >> >>
> >> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> >> appropriate
> >> >> notifications.
> >> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> >> phy-omap-otg.c and
> >> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can
> >> >> >> not change all usb phys to register an extcon, since there are
> >> >> >> no extcon device to register for these different phy drivers.
> >> >> >
> >> >> > You don't have to change every driver. You just need to make it
> >> >> > easy and obvious how to change drivers in a consistent coherent way.
> >> >> > For a start you would add a 'struct extcon_dev' to 'struct
> >> >> > usb_phy', and possibly add or extend some 'static inline's in
> >> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
> >> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >> >> >
> >> >> > Then any phy driver which adds support for setting
> >> >> > phy->extcon_dev appropriately, immediately gets the relevant
> notifications sent.
> >> >>
> >> >> OK. We can make these extcon related code into phy common part.
> >> >>
> >> >
> >> > Will generic phy need add extcon as well?
> >>
> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
> >> be common code.
> >>
> >
> > I mean the common code need add 'struct extcon_dev' into both 'struct
> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
> driver.
>
> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
> 'struct phy'.
>
> >> >
> >> >> >
> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
> >> >> >> to register an extcon, but also for the drivers which can
> >> >> >> detect USB charger type, it may be USB controller driver, USB
> >> >> >> type-c driver, pmic driver, and these drivers may not have an
> >> >> >> extcon device since the internal part can finish the vbus detect.
> >> >> >
> >> >> > Whichever part can detect vbus, the driver for that part must be
> >> >> > able to find the extcon and trigger a notification.
> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> > resistance on ID and a third can work through the state machine
> >> >> > to determine if D+ and D- are shorted together.
> >> >> > Somehow these three need to work together to determine what is
> >> >> plugged
> >> >> > in to the external connection port. Somewhere there much an
> 'extcon'
> >> >> > device which represents that port and which the three devices
> >> >> > can find and can interact with.
> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> > Each of the devices can get to the phy, and the phy can get to
> >> >> > the
> >> extcon.
> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >
> >> >> > The point is that there is obviously an external physical
> >> >> > connection, and so there should be an 'extcon' device that
> represents it.
> >> >>
> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
> >> >> receive VBUS notification, especially for detecting the charger
> >> >> type by
> >> software?
> >> >>
> >> >
> >> > My understanding is phy/usb_phy as the connection point, will send
> >> > the notification to PMIC driver which actually control the charge
> >> > current, also this will be done in your common framework, right?
> >>
> >> Not in USB charger framework. If we are all agree every usb_phy can
> >> register one extcon device, can get correct charger type and send out
> >> correct vbus_draw information, then we don't need USB charger
> >> framework as Neil suggested. So this will be okay for your case
> >> (especially for detecting the charger type by software) ?
> >
> > In my case, charger detection is done by controller driver and I need
> > do charger type detection internally, and only pass the current draw
> > info via phy which will send out, this seems ok for me, but I think it
> > will be good if you or someone can show us an example user based on the
> design Neil suggested.
> > Will you work out that common code if this USB charger framework is not
> needed?
>
> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others
> are already ready if everyone has no complain about current design, except
Only adding extcon_dev into usb_phy/phy and all others are ready?
My understanding you will also do:
- We need find a central place to send the notification(phy common part).
- If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it.
> my one concern. (I am afraid if it is enough to send out vbus draw
> information from USB phy driver, for example you will miss super speed
> (900mA), which need get the speed information from gadget driver.)
>
Can we handle this in USB(so has super speed information) and just send out
900mA directly?
Li Jun
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-10 6:30 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-10 6:30 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 9 March 2017 at 18:34, Jun Li <jun.li@nxp.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li <jun.li@nxp.com>
> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li <jun.li@nxp.com> wrote:
> >> > Hi,
> >> >
> >> >> -----Original Message-----
> >> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown <neilb@suse.com>
> >> >> Cc: Felipe Balbi <balbi@kernel.org>; Greg KH
> >> >> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David
> Woodhouse
> >> >> <dwmw2@infradead.org>; robh@kernel.org; Jun Li <jun.li@nxp.com>;
> >> >> Marek Szyprowski <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> >> <ruslan.bilovol@gmail.com>; Peter Chen
> <peter.chen@freescale.com>;
> >> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John
> >> >> Stultz <john.stultz@linaro.org>; Charles Keepax
> >> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> >> mainlining@lists.linuxfoundation.org; LKML
> >> >> <linux-kernel@vger.kernel.org>
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> >> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >> >>
> >> >> >> (2) Instead of using 'set_power' callback in phy drivers, we
> >> >> >> will introduce USB charger to set PMIC current drawn from USB
> >> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> >> implement anything to set PMIC current, thus remove them by
> >> following links:
> >> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> >> current, we can remove them in future. (I have no platform with
> >> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> >> converted 'set_power' callback to USB
> >> >> >> charger.)
> >> >> >>
> >> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> >> appropriate
> >> >> notifications.
> >> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> >> phy-omap-otg.c and
> >> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can
> >> >> >> not change all usb phys to register an extcon, since there are
> >> >> >> no extcon device to register for these different phy drivers.
> >> >> >
> >> >> > You don't have to change every driver. You just need to make it
> >> >> > easy and obvious how to change drivers in a consistent coherent way.
> >> >> > For a start you would add a 'struct extcon_dev' to 'struct
> >> >> > usb_phy', and possibly add or extend some 'static inline's in
> >> >> > linux/usb/phy.h to send notification on that extcon (if it is non-NULL).
> >> >> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >> >> >
> >> >> > Then any phy driver which adds support for setting
> >> >> > phy->extcon_dev appropriately, immediately gets the relevant
> notifications sent.
> >> >>
> >> >> OK. We can make these extcon related code into phy common part.
> >> >>
> >> >
> >> > Will generic phy need add extcon as well?
> >>
> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
> >> be common code.
> >>
> >
> > I mean the common code need add 'struct extcon_dev' into both 'struct
> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
> driver.
>
> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
> 'struct phy'.
>
> >> >
> >> >> >
> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
> >> >> >> to register an extcon, but also for the drivers which can
> >> >> >> detect USB charger type, it may be USB controller driver, USB
> >> >> >> type-c driver, pmic driver, and these drivers may not have an
> >> >> >> extcon device since the internal part can finish the vbus detect.
> >> >> >
> >> >> > Whichever part can detect vbus, the driver for that part must be
> >> >> > able to find the extcon and trigger a notification.
> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> > resistance on ID and a third can work through the state machine
> >> >> > to determine if D+ and D- are shorted together.
> >> >> > Somehow these three need to work together to determine what is
> >> >> plugged
> >> >> > in to the external connection port. Somewhere there much an
> 'extcon'
> >> >> > device which represents that port and which the three devices
> >> >> > can find and can interact with.
> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> > Each of the devices can get to the phy, and the phy can get to
> >> >> > the
> >> extcon.
> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >
> >> >> > The point is that there is obviously an external physical
> >> >> > connection, and so there should be an 'extcon' device that
> represents it.
> >> >>
> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
> >> >> receive VBUS notification, especially for detecting the charger
> >> >> type by
> >> software?
> >> >>
> >> >
> >> > My understanding is phy/usb_phy as the connection point, will send
> >> > the notification to PMIC driver which actually control the charge
> >> > current, also this will be done in your common framework, right?
> >>
> >> Not in USB charger framework. If we are all agree every usb_phy can
> >> register one extcon device, can get correct charger type and send out
> >> correct vbus_draw information, then we don't need USB charger
> >> framework as Neil suggested. So this will be okay for your case
> >> (especially for detecting the charger type by software) ?
> >
> > In my case, charger detection is done by controller driver and I need
> > do charger type detection internally, and only pass the current draw
> > info via phy which will send out, this seems ok for me, but I think it
> > will be good if you or someone can show us an example user based on the
> design Neil suggested.
> > Will you work out that common code if this USB charger framework is not
> needed?
>
> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others
> are already ready if everyone has no complain about current design, except
Only adding extcon_dev into usb_phy/phy and all others are ready?
My understanding you will also do:
- We need find a central place to send the notification(phy common part).
- If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it.
> my one concern. (I am afraid if it is enough to send out vbus draw
> information from USB phy driver, for example you will miss super speed
> (900mA), which need get the speed information from gadget driver.)
>
Can we handle this in USB(so has super speed information) and just send out
900mA directly?
Li Jun
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-10 6:30 ` Jun Li
@ 2017-03-10 7:15 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-10 7:15 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port. Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).
That will include these implementation when adding extcon_dev.
> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it.
PMIC can find extcon device by phandle.
>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?
>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-10 7:15 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-10 7:15 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port. Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).
That will include these implementation when adding extcon_dev.
> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to findup it.
PMIC can find extcon device by phandle.
>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?
>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-10 7:15 ` Baolin Wang
@ 2017-03-10 8:27 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-10 8:27 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port. Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by software) ?
> >> >
> >> > In my case, charger detection is done by controller driver and I
> >> > need do charger type detection internally, and only pass the
> >> > current draw info via phy which will send out, this seems ok for
> >> > me, but I think it will be good if you or someone can show us an
> >> > example user based on the
> >> design Neil suggested.
> >> > Will you work out that common code if this USB charger framework is
> >> > not
> >> needed?
> >>
> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> phy“. Others are already ready if everyone has no complain about
> >> current design, except
> >
> > Only adding extcon_dev into usb_phy/phy and all others are ready?
> > My understanding you will also do:
> > - We need find a central place to send the notification(phy common part).
>
> That will include these implementation when adding extcon_dev.
>
OK, thanks.
> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
> API to findup it.
>
> PMIC can find extcon device by phandle.
extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
how PMIC find it by phandle?
>
> >
> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> information from USB phy driver, for example you will miss super
> >> speed (900mA), which need get the speed information from gadget
> >> driver.)
> >>
> >
> > Can we handle this in USB(so has super speed information) and just
> > send out 900mA directly?
>
> From Neil's suggestion, we only have one place to send out current
> information from usb phy, so I have this concern and doubt if we still need
> the USB charger framework.
So if put it in phy/usb_phy, this is a problem, that only one place should have
the infor of both speed and usb state, how about put it at usb_gadget, then,
e.g. send the notification in usb_gadget_vbus_connect()?
Li Jun
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-10 8:27 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-10 8:27 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
Hi
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port. Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by software) ?
> >> >
> >> > In my case, charger detection is done by controller driver and I
> >> > need do charger type detection internally, and only pass the
> >> > current draw info via phy which will send out, this seems ok for
> >> > me, but I think it will be good if you or someone can show us an
> >> > example user based on the
> >> design Neil suggested.
> >> > Will you work out that common code if this USB charger framework is
> >> > not
> >> needed?
> >>
> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> phy“. Others are already ready if everyone has no complain about
> >> current design, except
> >
> > Only adding extcon_dev into usb_phy/phy and all others are ready?
> > My understanding you will also do:
> > - We need find a central place to send the notification(phy common part).
>
> That will include these implementation when adding extcon_dev.
>
OK, thanks.
> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
> API to findup it.
>
> PMIC can find extcon device by phandle.
extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
how PMIC find it by phandle?
>
> >
> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> information from USB phy driver, for example you will miss super
> >> speed (900mA), which need get the speed information from gadget
> >> driver.)
> >>
> >
> > Can we handle this in USB(so has super speed information) and just
> > send out 900mA directly?
>
> From Neil's suggestion, we only have one place to send out current
> information from usb phy, so I have this concern and doubt if we still need
> the USB charger framework.
So if put it in phy/usb_phy, this is a problem, that only one place should have
the infor of both speed and usb state, how about put it at usb_gadget, then,
e.g. send the notification in usb_gadget_vbus_connect()?
Li Jun
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-10 8:27 ` Jun Li
@ 2017-03-10 10:52 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-10 10:52 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
> Hi
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Friday, March 10, 2017 3:15 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >> >
>> >> >> > Will generic phy need add extcon as well?
>> >> >>
>> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
>> >> >> will be common code.
>> >> >>
>> >> >
>> >> > I mean the common code need add 'struct extcon_dev' into both
>> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
>> >> > that generic phy
>> >> driver.
>> >>
>> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
>> >> into 'struct phy'.
>> >>
>> >> >> >
>> >> >> >> >
>> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
>> >> >> >> >> PHY to register an extcon, but also for the drivers which
>> >> >> >> >> can detect USB charger type, it may be USB controller
>> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
>> >> >> >> >> may not have an extcon device since the internal part can finish
>> the vbus detect.
>> >> >> >> >
>> >> >> >> > Whichever part can detect vbus, the driver for that part must
>> >> >> >> > be able to find the extcon and trigger a notification.
>> >> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> >> > resistance on ID and a third can work through the state
>> >> >> >> > machine to determine if D+ and D- are shorted together.
>> >> >> >> > Somehow these three need to work together to determine what
>> >> >> >> > is
>> >> >> >> plugged
>> >> >> >> > in to the external connection port. Somewhere there much an
>> >> 'extcon'
>> >> >> >> > device which represents that port and which the three devices
>> >> >> >> > can find and can interact with.
>> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> >> > Each of the devices can get to the phy, and the phy can get
>> >> >> >> > to the
>> >> >> extcon.
>> >> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >> >
>> >> >> >> > The point is that there is obviously an external physical
>> >> >> >> > connection, and so there should be an 'extcon' device that
>> >> represents it.
>> >> >> >>
>> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
>> >> >> >> to receive VBUS notification, especially for detecting the
>> >> >> >> charger type by
>> >> >> software?
>> >> >> >>
>> >> >> >
>> >> >> > My understanding is phy/usb_phy as the connection point, will
>> >> >> > send the notification to PMIC driver which actually control the
>> >> >> > charge current, also this will be done in your common framework,
>> right?
>> >> >>
>> >> >> Not in USB charger framework. If we are all agree every usb_phy
>> >> >> can register one extcon device, can get correct charger type and
>> >> >> send out correct vbus_draw information, then we don't need USB
>> >> >> charger framework as Neil suggested. So this will be okay for your
>> >> >> case (especially for detecting the charger type by software) ?
>> >> >
>> >> > In my case, charger detection is done by controller driver and I
>> >> > need do charger type detection internally, and only pass the
>> >> > current draw info via phy which will send out, this seems ok for
>> >> > me, but I think it will be good if you or someone can show us an
>> >> > example user based on the
>> >> design Neil suggested.
>> >> > Will you work out that common code if this USB charger framework is
>> >> > not
>> >> needed?
>> >>
>> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
>> >> phy“. Others are already ready if everyone has no complain about
>> >> current design, except
>> >
>> > Only adding extcon_dev into usb_phy/phy and all others are ready?
>> > My understanding you will also do:
>> > - We need find a central place to send the notification(phy common part).
>>
>> That will include these implementation when adding extcon_dev.
>>
>
> OK, thanks.
>
>> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
>> API to findup it.
>>
>> PMIC can find extcon device by phandle.
>
> extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
> how PMIC find it by phandle?
>From my understanding, here we should add one pointer (extcon_dev *),
since usb phy is not one external connect device.
>
>>
>> >
>> >> my one concern. (I am afraid if it is enough to send out vbus draw
>> >> information from USB phy driver, for example you will miss super
>> >> speed (900mA), which need get the speed information from gadget
>> >> driver.)
>> >>
>> >
>> > Can we handle this in USB(so has super speed information) and just
>> > send out 900mA directly?
>>
>> From Neil's suggestion, we only have one place to send out current
>> information from usb phy, so I have this concern and doubt if we still need
>> the USB charger framework.
>
> So if put it in phy/usb_phy, this is a problem, that only one place should have
> the infor of both speed and usb state, how about put it at usb_gadget, then,
> e.g. send the notification in usb_gadget_vbus_connect()?
That is same what USB charger did, from this point, we need USB
charger to send out vbus draw information according to speed and usb
state. But I should listen to other guys suggestion. Peter and Felipe,
what do you think?
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-10 10:52 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-10 10:52 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
> Hi
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Friday, March 10, 2017 3:15 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >> >
>> >> >> > Will generic phy need add extcon as well?
>> >> >>
>> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
>> >> >> will be common code.
>> >> >>
>> >> >
>> >> > I mean the common code need add 'struct extcon_dev' into both
>> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
>> >> > that generic phy
>> >> driver.
>> >>
>> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
>> >> into 'struct phy'.
>> >>
>> >> >> >
>> >> >> >> >
>> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
>> >> >> >> >> PHY to register an extcon, but also for the drivers which
>> >> >> >> >> can detect USB charger type, it may be USB controller
>> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
>> >> >> >> >> may not have an extcon device since the internal part can finish
>> the vbus detect.
>> >> >> >> >
>> >> >> >> > Whichever part can detect vbus, the driver for that part must
>> >> >> >> > be able to find the extcon and trigger a notification.
>> >> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> >> > resistance on ID and a third can work through the state
>> >> >> >> > machine to determine if D+ and D- are shorted together.
>> >> >> >> > Somehow these three need to work together to determine what
>> >> >> >> > is
>> >> >> >> plugged
>> >> >> >> > in to the external connection port. Somewhere there much an
>> >> 'extcon'
>> >> >> >> > device which represents that port and which the three devices
>> >> >> >> > can find and can interact with.
>> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> >> > Each of the devices can get to the phy, and the phy can get
>> >> >> >> > to the
>> >> >> extcon.
>> >> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >> >
>> >> >> >> > The point is that there is obviously an external physical
>> >> >> >> > connection, and so there should be an 'extcon' device that
>> >> represents it.
>> >> >> >>
>> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
>> >> >> >> to receive VBUS notification, especially for detecting the
>> >> >> >> charger type by
>> >> >> software?
>> >> >> >>
>> >> >> >
>> >> >> > My understanding is phy/usb_phy as the connection point, will
>> >> >> > send the notification to PMIC driver which actually control the
>> >> >> > charge current, also this will be done in your common framework,
>> right?
>> >> >>
>> >> >> Not in USB charger framework. If we are all agree every usb_phy
>> >> >> can register one extcon device, can get correct charger type and
>> >> >> send out correct vbus_draw information, then we don't need USB
>> >> >> charger framework as Neil suggested. So this will be okay for your
>> >> >> case (especially for detecting the charger type by software) ?
>> >> >
>> >> > In my case, charger detection is done by controller driver and I
>> >> > need do charger type detection internally, and only pass the
>> >> > current draw info via phy which will send out, this seems ok for
>> >> > me, but I think it will be good if you or someone can show us an
>> >> > example user based on the
>> >> design Neil suggested.
>> >> > Will you work out that common code if this USB charger framework is
>> >> > not
>> >> needed?
>> >>
>> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
>> >> phy“. Others are already ready if everyone has no complain about
>> >> current design, except
>> >
>> > Only adding extcon_dev into usb_phy/phy and all others are ready?
>> > My understanding you will also do:
>> > - We need find a central place to send the notification(phy common part).
>>
>> That will include these implementation when adding extcon_dev.
>>
>
> OK, thanks.
>
>> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
>> API to findup it.
>>
>> PMIC can find extcon device by phandle.
>
> extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via devicetree,
> how PMIC find it by phandle?
>From my understanding, here we should add one pointer (extcon_dev *),
since usb phy is not one external connect device.
>
>>
>> >
>> >> my one concern. (I am afraid if it is enough to send out vbus draw
>> >> information from USB phy driver, for example you will miss super
>> >> speed (900mA), which need get the speed information from gadget
>> >> driver.)
>> >>
>> >
>> > Can we handle this in USB(so has super speed information) and just
>> > send out 900mA directly?
>>
>> From Neil's suggestion, we only have one place to send out current
>> information from usb phy, so I have this concern and doubt if we still need
>> the USB charger framework.
>
> So if put it in phy/usb_phy, this is a problem, that only one place should have
> the infor of both speed and usb state, how about put it at usb_gadget, then,
> e.g. send the notification in usb_gadget_vbus_connect()?
That is same what USB charger did, from this point, we need USB
charger to send out vbus draw information according to speed and usb
state. But I should listen to other guys suggestion. Peter and Felipe,
what do you think?
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-10 10:52 ` Baolin Wang
@ 2017-03-13 1:09 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-13 1:09 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 6:52 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
> > Hi
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Friday, March 10, 2017 3:15 PM
> >> To: Jun Li <jun.li@nxp.com>
> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >> >
> >> >> >> > Will generic phy need add extcon as well?
> >> >> >>
> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> >> will be common code.
> >> >> >>
> >> >> >
> >> >> > I mean the common code need add 'struct extcon_dev' into both
> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
> >> >> > use that generic phy
> >> >> driver.
> >> >>
> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> >> into 'struct phy'.
> >> >>
> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
> >> >> >> >> >> which can detect USB charger type, it may be USB
> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
> >> >> >> >> >> these drivers may not have an extcon device since the
> >> >> >> >> >> internal part can finish
> >> the vbus detect.
> >> >> >> >> >
> >> >> >> >> > Whichever part can detect vbus, the driver for that part
> >> >> >> >> > must be able to find the extcon and trigger a notification.
> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> >> > Somehow these three need to work together to determine
> >> >> >> >> > what is
> >> >> >> >> plugged
> >> >> >> >> > in to the external connection port. Somewhere there much
> >> >> >> >> > an
> >> >> 'extcon'
> >> >> >> >> > device which represents that port and which the three
> >> >> >> >> > devices can find and can interact with.
> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
> point.
> >> >> >> >> > Each of the devices can get to the phy, and the phy can
> >> >> >> >> > get to the
> >> >> >> extcon.
> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
> >> >> >> >> > the extcon, or if something else creates the extcon and
> >> >> >> >> > the phy driver performs a lookup to find it (e.g. based on
> devicetree info).
> >> >> >> >> >
> >> >> >> >> > The point is that there is obviously an external physical
> >> >> >> >> > connection, and so there should be an 'extcon' device that
> >> >> represents it.
> >> >> >> >>
> >> >> >> >> Peter & Jun, is it OK for you every phy has one extcon
> >> >> >> >> device to receive VBUS notification, especially for
> >> >> >> >> detecting the charger type by
> >> >> >> software?
> >> >> >> >>
> >> >> >> >
> >> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> >> > send the notification to PMIC driver which actually control
> >> >> >> > the charge current, also this will be done in your common
> >> >> >> > framework,
> >> right?
> >> >> >>
> >> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> >> can register one extcon device, can get correct charger type
> >> >> >> and send out correct vbus_draw information, then we don't need
> >> >> >> USB charger framework as Neil suggested. So this will be okay
> >> >> >> for your case (especially for detecting the charger type by
> software) ?
> >> >> >
> >> >> > In my case, charger detection is done by controller driver and I
> >> >> > need do charger type detection internally, and only pass the
> >> >> > current draw info via phy which will send out, this seems ok for
> >> >> > me, but I think it will be good if you or someone can show us an
> >> >> > example user based on the
> >> >> design Neil suggested.
> >> >> > Will you work out that common code if this USB charger framework
> >> >> > is not
> >> >> needed?
> >> >>
> >> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> >> phy“. Others are already ready if everyone has no complain about
> >> >> current design, except
> >> >
> >> > Only adding extcon_dev into usb_phy/phy and all others are ready?
> >> > My understanding you will also do:
> >> > - We need find a central place to send the notification(phy common
> part).
> >>
> >> That will include these implementation when adding extcon_dev.
> >>
> >
> > OK, thanks.
> >
> >> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs
> >> > some
> >> API to findup it.
> >>
> >> PMIC can find extcon device by phandle.
> >
> > extcon_dev(not a reference pointer) is directly added in usb_phy/phy,
> > not via devicetree, how PMIC find it by phandle?
>
> From my understanding, here we should add one pointer (extcon_dev *),
> since usb phy is not one external connect device.
Agreed.
>
> >
> >>
> >> >
> >> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> >> information from USB phy driver, for example you will miss super
> >> >> speed (900mA), which need get the speed information from gadget
> >> >> driver.)
> >> >>
> >> >
> >> > Can we handle this in USB(so has super speed information) and just
> >> > send out 900mA directly?
> >>
> >> From Neil's suggestion, we only have one place to send out current
> >> information from usb phy, so I have this concern and doubt if we
> >> still need the USB charger framework.
> >
> > So if put it in phy/usb_phy, this is a problem, that only one place
> > should have the infor of both speed and usb state, how about put it at
> > usb_gadget, then, e.g. send the notification in
> usb_gadget_vbus_connect()?
>
> That is same what USB charger did, from this point, we need USB charger to
> send out vbus draw information according to speed and usb state. But I
> should listen to other guys suggestion. Peter and Felipe, what do you think?
So now the only to do work is to find a common place to send the notification out
(based on gadget speed and sate).
Li Jun
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-13 1:09 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-13 1:09 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Friday, March 10, 2017 6:52 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
> On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
> > Hi
> >
> >> -----Original Message-----
> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> >> Sent: Friday, March 10, 2017 3:15 PM
> >> To: Jun Li <jun.li@nxp.com>
> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
> >> <john.stultz@linaro.org>; Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com>;
> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> >> mainlining@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
> >> >> >> >
> >> >> >> > Will generic phy need add extcon as well?
> >> >> >>
> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> >> will be common code.
> >> >> >>
> >> >> >
> >> >> > I mean the common code need add 'struct extcon_dev' into both
> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
> >> >> > use that generic phy
> >> >> driver.
> >> >>
> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> >> into 'struct phy'.
> >> >>
> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
> >> >> >> >> >> which can detect USB charger type, it may be USB
> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
> >> >> >> >> >> these drivers may not have an extcon device since the
> >> >> >> >> >> internal part can finish
> >> the vbus detect.
> >> >> >> >> >
> >> >> >> >> > Whichever part can detect vbus, the driver for that part
> >> >> >> >> > must be able to find the extcon and trigger a notification.
> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> >> > Somehow these three need to work together to determine
> >> >> >> >> > what is
> >> >> >> >> plugged
> >> >> >> >> > in to the external connection port. Somewhere there much
> >> >> >> >> > an
> >> >> 'extcon'
> >> >> >> >> > device which represents that port and which the three
> >> >> >> >> > devices can find and can interact with.
> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
> point.
> >> >> >> >> > Each of the devices can get to the phy, and the phy can
> >> >> >> >> > get to the
> >> >> >> extcon.
> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
> >> >> >> >> > the extcon, or if something else creates the extcon and
> >> >> >> >> > the phy driver performs a lookup to find it (e.g. based on
> devicetree info).
> >> >> >> >> >
> >> >> >> >> > The point is that there is obviously an external physical
> >> >> >> >> > connection, and so there should be an 'extcon' device that
> >> >> represents it.
> >> >> >> >>
> >> >> >> >> Peter & Jun, is it OK for you every phy has one extcon
> >> >> >> >> device to receive VBUS notification, especially for
> >> >> >> >> detecting the charger type by
> >> >> >> software?
> >> >> >> >>
> >> >> >> >
> >> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> >> > send the notification to PMIC driver which actually control
> >> >> >> > the charge current, also this will be done in your common
> >> >> >> > framework,
> >> right?
> >> >> >>
> >> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> >> can register one extcon device, can get correct charger type
> >> >> >> and send out correct vbus_draw information, then we don't need
> >> >> >> USB charger framework as Neil suggested. So this will be okay
> >> >> >> for your case (especially for detecting the charger type by
> software) ?
> >> >> >
> >> >> > In my case, charger detection is done by controller driver and I
> >> >> > need do charger type detection internally, and only pass the
> >> >> > current draw info via phy which will send out, this seems ok for
> >> >> > me, but I think it will be good if you or someone can show us an
> >> >> > example user based on the
> >> >> design Neil suggested.
> >> >> > Will you work out that common code if this USB charger framework
> >> >> > is not
> >> >> needed?
> >> >>
> >> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> >> phy“. Others are already ready if everyone has no complain about
> >> >> current design, except
> >> >
> >> > Only adding extcon_dev into usb_phy/phy and all others are ready?
> >> > My understanding you will also do:
> >> > - We need find a central place to send the notification(phy common
> part).
> >>
> >> That will include these implementation when adding extcon_dev.
> >>
> >
> > OK, thanks.
> >
> >> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs
> >> > some
> >> API to findup it.
> >>
> >> PMIC can find extcon device by phandle.
> >
> > extcon_dev(not a reference pointer) is directly added in usb_phy/phy,
> > not via devicetree, how PMIC find it by phandle?
>
> From my understanding, here we should add one pointer (extcon_dev *),
> since usb phy is not one external connect device.
Agreed.
>
> >
> >>
> >> >
> >> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> >> information from USB phy driver, for example you will miss super
> >> >> speed (900mA), which need get the speed information from gadget
> >> >> driver.)
> >> >>
> >> >
> >> > Can we handle this in USB(so has super speed information) and just
> >> > send out 900mA directly?
> >>
> >> From Neil's suggestion, we only have one place to send out current
> >> information from usb phy, so I have this concern and doubt if we
> >> still need the USB charger framework.
> >
> > So if put it in phy/usb_phy, this is a problem, that only one place
> > should have the infor of both speed and usb state, how about put it at
> > usb_gadget, then, e.g. send the notification in
> usb_gadget_vbus_connect()?
>
> That is same what USB charger did, from this point, we need USB charger to
> send out vbus draw information according to speed and usb state. But I
> should listen to other guys suggestion. Peter and Felipe, what do you think?
So now the only to do work is to find a common place to send the notification out
(based on gadget speed and sate).
Li Jun
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-13 1:09 ` Jun Li
@ 2017-03-13 8:43 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-13 8:43 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
On 13 March 2017 at 09:09, Jun Li <jun.li@nxp.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Friday, March 10, 2017 6:52 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
>> > Hi
>> >
>> >> -----Original Message-----
>> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> >> Sent: Friday, March 10, 2017 3:15 PM
>> >> To: Jun Li <jun.li@nxp.com>
>> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
>> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
>> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
>> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
>> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
>> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
>> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
>> >> <john.stultz@linaro.org>; Charles Keepax
>> >> <ckeepax@opensource.wolfsonmicro.com>;
>> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> >> mainlining@lists.linuxfoundation.org; LKML
>> >> <linux-kernel@vger.kernel.org>
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >> >> >
>> >> >> >> > Will generic phy need add extcon as well?
>> >> >> >>
>> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
>> >> >> >> will be common code.
>> >> >> >>
>> >> >> >
>> >> >> > I mean the common code need add 'struct extcon_dev' into both
>> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
>> >> >> > use that generic phy
>> >> >> driver.
>> >> >>
>> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
>> >> >> into 'struct phy'.
>> >> >>
>> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
>> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
>> >> >> >> >> >> which can detect USB charger type, it may be USB
>> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
>> >> >> >> >> >> these drivers may not have an extcon device since the
>> >> >> >> >> >> internal part can finish
>> >> the vbus detect.
>> >> >> >> >> >
>> >> >> >> >> > Whichever part can detect vbus, the driver for that part
>> >> >> >> >> > must be able to find the extcon and trigger a notification.
>> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> >> >> > resistance on ID and a third can work through the state
>> >> >> >> >> > machine to determine if D+ and D- are shorted together.
>> >> >> >> >> > Somehow these three need to work together to determine
>> >> >> >> >> > what is
>> >> >> >> >> plugged
>> >> >> >> >> > in to the external connection port. Somewhere there much
>> >> >> >> >> > an
>> >> >> 'extcon'
>> >> >> >> >> > device which represents that port and which the three
>> >> >> >> >> > devices can find and can interact with.
>> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
>> point.
>> >> >> >> >> > Each of the devices can get to the phy, and the phy can
>> >> >> >> >> > get to the
>> >> >> >> extcon.
>> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
>> >> >> >> >> > the extcon, or if something else creates the extcon and
>> >> >> >> >> > the phy driver performs a lookup to find it (e.g. based on
>> devicetree info).
>> >> >> >> >> >
>> >> >> >> >> > The point is that there is obviously an external physical
>> >> >> >> >> > connection, and so there should be an 'extcon' device that
>> >> >> represents it.
>> >> >> >> >>
>> >> >> >> >> Peter & Jun, is it OK for you every phy has one extcon
>> >> >> >> >> device to receive VBUS notification, especially for
>> >> >> >> >> detecting the charger type by
>> >> >> >> software?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > My understanding is phy/usb_phy as the connection point, will
>> >> >> >> > send the notification to PMIC driver which actually control
>> >> >> >> > the charge current, also this will be done in your common
>> >> >> >> > framework,
>> >> right?
>> >> >> >>
>> >> >> >> Not in USB charger framework. If we are all agree every usb_phy
>> >> >> >> can register one extcon device, can get correct charger type
>> >> >> >> and send out correct vbus_draw information, then we don't need
>> >> >> >> USB charger framework as Neil suggested. So this will be okay
>> >> >> >> for your case (especially for detecting the charger type by
>> software) ?
>> >> >> >
>> >> >> > In my case, charger detection is done by controller driver and I
>> >> >> > need do charger type detection internally, and only pass the
>> >> >> > current draw info via phy which will send out, this seems ok for
>> >> >> > me, but I think it will be good if you or someone can show us an
>> >> >> > example user based on the
>> >> >> design Neil suggested.
>> >> >> > Will you work out that common code if this USB charger framework
>> >> >> > is not
>> >> >> needed?
>> >> >>
>> >> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
>> >> >> phy“. Others are already ready if everyone has no complain about
>> >> >> current design, except
>> >> >
>> >> > Only adding extcon_dev into usb_phy/phy and all others are ready?
>> >> > My understanding you will also do:
>> >> > - We need find a central place to send the notification(phy common
>> part).
>> >>
>> >> That will include these implementation when adding extcon_dev.
>> >>
>> >
>> > OK, thanks.
>> >
>> >> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs
>> >> > some
>> >> API to findup it.
>> >>
>> >> PMIC can find extcon device by phandle.
>> >
>> > extcon_dev(not a reference pointer) is directly added in usb_phy/phy,
>> > not via devicetree, how PMIC find it by phandle?
>>
>> From my understanding, here we should add one pointer (extcon_dev *),
>> since usb phy is not one external connect device.
>
> Agreed.
>
>>
>> >
>> >>
>> >> >
>> >> >> my one concern. (I am afraid if it is enough to send out vbus draw
>> >> >> information from USB phy driver, for example you will miss super
>> >> >> speed (900mA), which need get the speed information from gadget
>> >> >> driver.)
>> >> >>
>> >> >
>> >> > Can we handle this in USB(so has super speed information) and just
>> >> > send out 900mA directly?
>> >>
>> >> From Neil's suggestion, we only have one place to send out current
>> >> information from usb phy, so I have this concern and doubt if we
>> >> still need the USB charger framework.
>> >
>> > So if put it in phy/usb_phy, this is a problem, that only one place
>> > should have the infor of both speed and usb state, how about put it at
>> > usb_gadget, then, e.g. send the notification in
>> usb_gadget_vbus_connect()?
>>
>> That is same what USB charger did, from this point, we need USB charger to
>> send out vbus draw information according to speed and usb state. But I
>> should listen to other guys suggestion. Peter and Felipe, what do you think?
>
> So now the only to do work is to find a common place to send the notification out
> (based on gadget speed and sate).
Yes.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-13 8:43 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-13 8:43 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
On 13 March 2017 at 09:09, Jun Li <jun.li@nxp.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Friday, March 10, 2017 6:52 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 10 March 2017 at 16:27, Jun Li <jun.li@nxp.com> wrote:
>> > Hi
>> >
>> >> -----Original Message-----
>> >> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> >> Sent: Friday, March 10, 2017 3:15 PM
>> >> To: Jun Li <jun.li@nxp.com>
>> >> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg
>> >> KH <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>;
>> >> Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> >> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> >> <m.szyprowski@samsung.com>; Ruslan Bilovol
>> >> <ruslan.bilovol@gmail.com>; Peter Chen <peter.chen@freescale.com>;
>> >> Alan Stern <stern@rowland.harvard.edu>; grygorii.strashko@ti.com;
>> >> Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Lee Jones
>> >> <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; John Stultz
>> >> <john.stultz@linaro.org>; Charles Keepax
>> >> <ckeepax@opensource.wolfsonmicro.com>;
>> >> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> >> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> >> mainlining@lists.linuxfoundation.org; LKML
>> >> <linux-kernel@vger.kernel.org>
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 10 March 2017 at 14:30, Jun Li <jun.li@nxp.com> wrote:
>> >> >> >> >
>> >> >> >> > Will generic phy need add extcon as well?
>> >> >> >>
>> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
>> >> >> >> will be common code.
>> >> >> >>
>> >> >> >
>> >> >> > I mean the common code need add 'struct extcon_dev' into both
>> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
>> >> >> > use that generic phy
>> >> >> driver.
>> >> >>
>> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
>> >> >> into 'struct phy'.
>> >> >>
>> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
>> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
>> >> >> >> >> >> which can detect USB charger type, it may be USB
>> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
>> >> >> >> >> >> these drivers may not have an extcon device since the
>> >> >> >> >> >> internal part can finish
>> >> the vbus detect.
>> >> >> >> >> >
>> >> >> >> >> > Whichever part can detect vbus, the driver for that part
>> >> >> >> >> > must be able to find the extcon and trigger a notification.
>> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> >> >> > resistance on ID and a third can work through the state
>> >> >> >> >> > machine to determine if D+ and D- are shorted together.
>> >> >> >> >> > Somehow these three need to work together to determine
>> >> >> >> >> > what is
>> >> >> >> >> plugged
>> >> >> >> >> > in to the external connection port. Somewhere there much
>> >> >> >> >> > an
>> >> >> 'extcon'
>> >> >> >> >> > device which represents that port and which the three
>> >> >> >> >> > devices can find and can interact with.
>> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
>> point.
>> >> >> >> >> > Each of the devices can get to the phy, and the phy can
>> >> >> >> >> > get to the
>> >> >> >> extcon.
>> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
>> >> >> >> >> > the extcon, or if something else creates the extcon and
>> >> >> >> >> > the phy driver performs a lookup to find it (e.g. based on
>> devicetree info).
>> >> >> >> >> >
>> >> >> >> >> > The point is that there is obviously an external physical
>> >> >> >> >> > connection, and so there should be an 'extcon' device that
>> >> >> represents it.
>> >> >> >> >>
>> >> >> >> >> Peter & Jun, is it OK for you every phy has one extcon
>> >> >> >> >> device to receive VBUS notification, especially for
>> >> >> >> >> detecting the charger type by
>> >> >> >> software?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > My understanding is phy/usb_phy as the connection point, will
>> >> >> >> > send the notification to PMIC driver which actually control
>> >> >> >> > the charge current, also this will be done in your common
>> >> >> >> > framework,
>> >> right?
>> >> >> >>
>> >> >> >> Not in USB charger framework. If we are all agree every usb_phy
>> >> >> >> can register one extcon device, can get correct charger type
>> >> >> >> and send out correct vbus_draw information, then we don't need
>> >> >> >> USB charger framework as Neil suggested. So this will be okay
>> >> >> >> for your case (especially for detecting the charger type by
>> software) ?
>> >> >> >
>> >> >> > In my case, charger detection is done by controller driver and I
>> >> >> > need do charger type detection internally, and only pass the
>> >> >> > current draw info via phy which will send out, this seems ok for
>> >> >> > me, but I think it will be good if you or someone can show us an
>> >> >> > example user based on the
>> >> >> design Neil suggested.
>> >> >> > Will you work out that common code if this USB charger framework
>> >> >> > is not
>> >> >> needed?
>> >> >>
>> >> >> I will add a 'struct extcon_dev*' in 'struct usb_phy' and struct
>> >> >> phy“. Others are already ready if everyone has no complain about
>> >> >> current design, except
>> >> >
>> >> > Only adding extcon_dev into usb_phy/phy and all others are ready?
>> >> > My understanding you will also do:
>> >> > - We need find a central place to send the notification(phy common
>> part).
>> >>
>> >> That will include these implementation when adding extcon_dev.
>> >>
>> >
>> > OK, thanks.
>> >
>> >> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs
>> >> > some
>> >> API to findup it.
>> >>
>> >> PMIC can find extcon device by phandle.
>> >
>> > extcon_dev(not a reference pointer) is directly added in usb_phy/phy,
>> > not via devicetree, how PMIC find it by phandle?
>>
>> From my understanding, here we should add one pointer (extcon_dev *),
>> since usb phy is not one external connect device.
>
> Agreed.
>
>>
>> >
>> >>
>> >> >
>> >> >> my one concern. (I am afraid if it is enough to send out vbus draw
>> >> >> information from USB phy driver, for example you will miss super
>> >> >> speed (900mA), which need get the speed information from gadget
>> >> >> driver.)
>> >> >>
>> >> >
>> >> > Can we handle this in USB(so has super speed information) and just
>> >> > send out 900mA directly?
>> >>
>> >> From Neil's suggestion, we only have one place to send out current
>> >> information from usb phy, so I have this concern and doubt if we
>> >> still need the USB charger framework.
>> >
>> > So if put it in phy/usb_phy, this is a problem, that only one place
>> > should have the infor of both speed and usb state, how about put it at
>> > usb_gadget, then, e.g. send the notification in
>> usb_gadget_vbus_connect()?
>>
>> That is same what USB charger did, from this point, we need USB charger to
>> send out vbus draw information according to speed and usb state. But I
>> should listen to other guys suggestion. Peter and Felipe, what do you think?
>
> So now the only to do work is to find a common place to send the notification out
> (based on gadget speed and sate).
Yes.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-13 8:43 ` Baolin Wang
@ 2017-03-14 1:10 ` Jun Li
-1 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-14 1:10 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
... ...
> >> That is same what USB charger did, from this point, we need USB
> >> charger to send out vbus draw information according to speed and usb
> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
> do you think?
Instead of waiting for maintainer's comments on this long discussion, I'd suggest
you directly post the patches for the required change, so they can easily know
what's the conclusion/solution looks like.
Li Jun
> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
>
> Yes.
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-14 1:10 ` Jun Li
0 siblings, 0 replies; 50+ messages in thread
From: Jun Li @ 2017-03-14 1:10 UTC (permalink / raw)
To: Baolin Wang
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches@opensource.wolfsonmicro.com
Hi,
> -----Original Message-----
> From: Baolin Wang [mailto:baolin.wang@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li <jun.li@nxp.com>
> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
> Peter Chen <peter.chen@freescale.com>; Alan Stern
> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
>
... ...
> >> That is same what USB charger did, from this point, we need USB
> >> charger to send out vbus draw information according to speed and usb
> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
> do you think?
Instead of waiting for maintainer's comments on this long discussion, I'd suggest
you directly post the patches for the required change, so they can easily know
what's the conclusion/solution looks like.
Li Jun
> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
>
> Yes.
>
> --
> Baolin.wang
> Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-14 2:03 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-14 2:03 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Marek Szyprowski,
Ruslan Bilovol, Peter Chen, Alan Stern, grygorii.strashko,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
On 14 March 2017 at 09:10, Jun Li <jun.li@nxp.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang@linaro.org]
>> Sent: Monday, March 13, 2017 4:44 PM
>> To: Jun Li <jun.li@nxp.com>
>> Cc: NeilBrown <neilb@suse.com>; Felipe Balbi <balbi@kernel.org>; Greg KH
>> <gregkh@linuxfoundation.org>; Sebastian Reichel <sre@kernel.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov@gmail.com>; David Woodhouse
>> <dwmw2@infradead.org>; robh@kernel.org; Marek Szyprowski
>> <m.szyprowski@samsung.com>; Ruslan Bilovol <ruslan.bilovol@gmail.com>;
>> Peter Chen <peter.chen@freescale.com>; Alan Stern
>> <stern@rowland.harvard.edu>; grygorii.strashko@ti.com; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>; Lee Jones <lee.jones@linaro.org>;
>> Mark Brown <broonie@kernel.org>; John Stultz <john.stultz@linaro.org>;
>> Charles Keepax <ckeepax@opensource.wolfsonmicro.com>;
>> patches@opensource.wolfsonmicro.com; Linux PM list <linux-
>> pm@vger.kernel.org>; USB <linux-usb@vger.kernel.org>; device-
>> mainlining@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
> ... ...
>> >> That is same what USB charger did, from this point, we need USB
>> >> charger to send out vbus draw information according to speed and usb
>> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
>> do you think?
>
> Instead of waiting for maintainer's comments on this long discussion, I'd suggest
> you directly post the patches for the required change, so they can easily know
> what's the conclusion/solution looks like.
That's right, I am creating patches for adding extcon_dev in
phy/usb_phy. Thanks.
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-14 2:03 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-14 2:03 UTC (permalink / raw)
To: Jun Li
Cc: NeilBrown, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse,
robh-DgEjT+Ai2ygdnm+yROfE0A, Marek Szyprowski, Ruslan Bilovol,
Peter Chen, Alan Stern, grygorii.strashko-l0cyMroinI0,
Yoshihiro Shimoda, Lee Jones, Mark Brown, John Stultz,
Charles Keepax,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org
On 14 March 2017 at 09:10, Jun Li <jun.li-3arQi8VN3Tc@public.gmane.org> wrote:
> Hi,
>
>> -----Original Message-----
>> From: Baolin Wang [mailto:baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
>> Sent: Monday, March 13, 2017 4:44 PM
>> To: Jun Li <jun.li-3arQi8VN3Tc@public.gmane.org>
>> Cc: NeilBrown <neilb-IBi9RG/b67k@public.gmane.org>; Felipe Balbi <balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Greg KH
>> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>; Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Dmitry
>> Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; David Woodhouse
>> <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Marek Szyprowski
>> <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>; Ruslan Bilovol <ruslan.bilovol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>;
>> Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>; Alan Stern
>> <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>; grygorii.strashko-l0cyMroinI0@public.gmane.org; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>; Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>;
>> Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>;
>> Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>;
>> patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org; Linux PM list <linux-
>> pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; USB <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; device-
>> mainlining-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org; LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
> ... ...
>> >> That is same what USB charger did, from this point, we need USB
>> >> charger to send out vbus draw information according to speed and usb
>> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
>> do you think?
>
> Instead of waiting for maintainer's comments on this long discussion, I'd suggest
> you directly post the patches for the required change, so they can easily know
> what's the conclusion/solution looks like.
That's right, I am creating patches for adding extcon_dev in
phy/usb_phy. Thanks.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-02-20 8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
` (4 preceding siblings ...)
2017-03-03 2:23 ` NeilBrown
@ 2017-03-14 9:57 ` Lee Jones
2017-03-14 10:39 ` Baolin Wang
5 siblings, 1 reply; 50+ messages in thread
From: Lee Jones @ 2017-03-14 9:57 UTC (permalink / raw)
To: Baolin Wang
Cc: balbi, gregkh, sre, dbaryshkov, dwmw2, robh, jun.li,
m.szyprowski, ruslan.bilovol, peter.chen, stern,
grygorii.strashko, yoshihiro.shimoda.uh, broonie, john.stultz,
neilb, ckeepax, patches, linux-pm, linux-usb, device-mainlining,
linux-kernel
On Mon, 20 Feb 2017, Baolin Wang wrote:
[...]
> drivers/power/supply/wm831x_power.c | 63 +++
> drivers/usb/gadget/Kconfig | 8 +
> drivers/usb/gadget/udc/Makefile | 1 +
> drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
> drivers/usb/gadget/udc/core.c | 19 +-
> include/linux/usb/charger.h | 176 +++++++
> include/linux/usb/gadget.h | 3 +
> include/uapi/linux/usb/charger.h | 31 ++
> 8 files changed, 1165 insertions(+), 1 deletion(-)
> create mode 100644 drivers/usb/gadget/udc/charger.c
> create mode 100644 include/linux/usb/charger.h
> create mode 100644 include/uapi/linux/usb/charger.h
Why have you sent this set to me?
Please be careful when submitting patches, since a lot of us have
enough mail to contend with already.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-14 9:57 ` Lee Jones
@ 2017-03-14 10:39 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-14 10:39 UTC (permalink / raw)
To: Lee Jones
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
NeilBrown, Charles Keepax, patches, Linux PM list, USB,
device-mainlining, LKML
Hi,
On 14 March 2017 at 17:57, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 20 Feb 2017, Baolin Wang wrote:
>
> [...]
>
>> drivers/power/supply/wm831x_power.c | 63 +++
>> drivers/usb/gadget/Kconfig | 8 +
>> drivers/usb/gadget/udc/Makefile | 1 +
>> drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
>> drivers/usb/gadget/udc/core.c | 19 +-
>> include/linux/usb/charger.h | 176 +++++++
>> include/linux/usb/gadget.h | 3 +
>> include/uapi/linux/usb/charger.h | 31 ++
>> 8 files changed, 1165 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/usb/gadget/udc/charger.c
>> create mode 100644 include/linux/usb/charger.h
>> create mode 100644 include/uapi/linux/usb/charger.h
>
> Why have you sent this set to me?
Since you have one ack on patch 4, I think I need CC you. But If you
are not interested in this patchset, I will not CC you next time.
Sorry.
[PATCH v19 4/4] power: wm831x_power: Support USB charger current limit
management
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
.......
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-14 10:39 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-14 10:39 UTC (permalink / raw)
To: Lee Jones
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
NeilBrown, Charles Keepax, patches, Linux PM list, USB
Hi,
On 14 March 2017 at 17:57, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 20 Feb 2017, Baolin Wang wrote:
>
> [...]
>
>> drivers/power/supply/wm831x_power.c | 63 +++
>> drivers/usb/gadget/Kconfig | 8 +
>> drivers/usb/gadget/udc/Makefile | 1 +
>> drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
>> drivers/usb/gadget/udc/core.c | 19 +-
>> include/linux/usb/charger.h | 176 +++++++
>> include/linux/usb/gadget.h | 3 +
>> include/uapi/linux/usb/charger.h | 31 ++
>> 8 files changed, 1165 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/usb/gadget/udc/charger.c
>> create mode 100644 include/linux/usb/charger.h
>> create mode 100644 include/uapi/linux/usb/charger.h
>
> Why have you sent this set to me?
Since you have one ack on patch 4, I think I need CC you. But If you
are not interested in this patchset, I will not CC you next time.
Sorry.
[PATCH v19 4/4] power: wm831x_power: Support USB charger current limit
management
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Sebastian Reichel <sre@kernel.org>
.......
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-14 10:39 ` Baolin Wang
@ 2017-03-14 12:14 ` Lee Jones
-1 siblings, 0 replies; 50+ messages in thread
From: Lee Jones @ 2017-03-14 12:14 UTC (permalink / raw)
To: Baolin Wang
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
NeilBrown, Charles Keepax, patches, Linux PM list, USB,
device-mainlining, LKML
On Tue, 14 Mar 2017, Baolin Wang wrote:
> Hi,
>
> On 14 March 2017 at 17:57, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 20 Feb 2017, Baolin Wang wrote:
> >
> > [...]
> >
> >> drivers/power/supply/wm831x_power.c | 63 +++
> >> drivers/usb/gadget/Kconfig | 8 +
> >> drivers/usb/gadget/udc/Makefile | 1 +
> >> drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
> >> drivers/usb/gadget/udc/core.c | 19 +-
> >> include/linux/usb/charger.h | 176 +++++++
> >> include/linux/usb/gadget.h | 3 +
> >> include/uapi/linux/usb/charger.h | 31 ++
> >> 8 files changed, 1165 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/usb/gadget/udc/charger.c
> >> create mode 100644 include/linux/usb/charger.h
> >> create mode 100644 include/uapi/linux/usb/charger.h
> >
> > Why have you sent this set to me?
>
> Since you have one ack on patch 4, I think I need CC you. But If you
> are not interested in this patchset, I will not CC you next time.
> Sorry.
I Acked one of the patches 9 months ago since it contained an MFD
change.
Yes, if you could drop me from any new submissions, that'd be great,
thanks.
> [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit
> management
>
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Acked-by: Peter Chen <peter.chen@freescale.com>
> Acked-by: Sebastian Reichel <sre@kernel.org>
> .......
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-14 12:14 ` Lee Jones
0 siblings, 0 replies; 50+ messages in thread
From: Lee Jones @ 2017-03-14 12:14 UTC (permalink / raw)
To: Baolin Wang
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
NeilBrown, Charles Keepax, patches, Linux PM list, USB
On Tue, 14 Mar 2017, Baolin Wang wrote:
> Hi,
>
> On 14 March 2017 at 17:57, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 20 Feb 2017, Baolin Wang wrote:
> >
> > [...]
> >
> >> drivers/power/supply/wm831x_power.c | 63 +++
> >> drivers/usb/gadget/Kconfig | 8 +
> >> drivers/usb/gadget/udc/Makefile | 1 +
> >> drivers/usb/gadget/udc/charger.c | 865 +++++++++++++++++++++++++++++++++++
> >> drivers/usb/gadget/udc/core.c | 19 +-
> >> include/linux/usb/charger.h | 176 +++++++
> >> include/linux/usb/gadget.h | 3 +
> >> include/uapi/linux/usb/charger.h | 31 ++
> >> 8 files changed, 1165 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/usb/gadget/udc/charger.c
> >> create mode 100644 include/linux/usb/charger.h
> >> create mode 100644 include/uapi/linux/usb/charger.h
> >
> > Why have you sent this set to me?
>
> Since you have one ack on patch 4, I think I need CC you. But If you
> are not interested in this patchset, I will not CC you next time.
> Sorry.
I Acked one of the patches 9 months ago since it contained an MFD
change.
Yes, if you could drop me from any new submissions, that'd be great,
thanks.
> [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit
> management
>
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> Acked-by: Peter Chen <peter.chen@freescale.com>
> Acked-by: Sebastian Reichel <sre@kernel.org>
> .......
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-07 9:38 ` Baolin Wang
@ 2017-03-28 23:04 ` NeilBrown
-1 siblings, 0 replies; 50+ messages in thread
From: NeilBrown @ 2017-03-28 23:04 UTC (permalink / raw)
To: Baolin Wang
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, Charles Keepax, patches, Linux PM list, USB,
device-mainlining, LKML
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Tue, Mar 07 2017, Baolin Wang wrote:
> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>
>>
>> I understand your reluctance to change drivers that you cannot test.
>> An alternative it do change all the
>> atomic_notifier_call_chain(.*notifier,
>> calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> declare the passing of NULL to be deprecated (so hopefully people won't
>> use it in new code).
>> Then any notification callback that expects a current can just ignore
>> calls where the pointer is NULL.
>
> I am afraid if it is enough to send out vbus draw information from USB
> phy driver, for example you will miss super speed (900mA), which need
> get the speed information from gadget driver.
When the gadget driver determines that 900mA is available, it calls
usb_phy_set_power() which calls the ->set_power() method on the usb_phy.
The usb_phy the uses the notifier to inform all interested parties
that 900mA is available.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-28 23:04 ` NeilBrown
0 siblings, 0 replies; 50+ messages in thread
From: NeilBrown @ 2017-03-28 23:04 UTC (permalink / raw)
To: Baolin Wang
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, Charles Keepax, patches, Linux PM list, USB
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Tue, Mar 07 2017, Baolin Wang wrote:
> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>
>>
>> I understand your reluctance to change drivers that you cannot test.
>> An alternative it do change all the
>> atomic_notifier_call_chain(.*notifier,
>> calls that don't pass a pointer to vbus_draw to pass NULL, and to
>> declare the passing of NULL to be deprecated (so hopefully people won't
>> use it in new code).
>> Then any notification callback that expects a current can just ignore
>> calls where the pointer is NULL.
>
> I am afraid if it is enough to send out vbus draw information from USB
> phy driver, for example you will miss super speed (900mA), which need
> get the speed information from gadget driver.
When the gadget driver determines that 900mA is available, it calls
usb_phy_set_power() which calls the ->set_power() method on the usb_phy.
The usb_phy the uses the notifier to inform all interested parties
that 900mA is available.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
2017-03-28 23:04 ` NeilBrown
@ 2017-03-30 3:16 ` Baolin Wang
-1 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-30 3:16 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining,
LKML
Hi,
On 29 March 2017 at 07:04, NeilBrown <neilb@suse.com> wrote:
> On Tue, Mar 07 2017, Baolin Wang wrote:
>
>> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>>
>>>
>>> I understand your reluctance to change drivers that you cannot test.
>>> An alternative it do change all the
>>> atomic_notifier_call_chain(.*notifier,
>>> calls that don't pass a pointer to vbus_draw to pass NULL, and to
>>> declare the passing of NULL to be deprecated (so hopefully people won't
>>> use it in new code).
>>> Then any notification callback that expects a current can just ignore
>>> calls where the pointer is NULL.
>>
>> I am afraid if it is enough to send out vbus draw information from USB
>> phy driver, for example you will miss super speed (900mA), which need
>> get the speed information from gadget driver.
>
> When the gadget driver determines that 900mA is available, it calls
> usb_phy_set_power() which calls the ->set_power() method on the usb_phy.
> The usb_phy the uses the notifier to inform all interested parties
> that 900mA is available.
That is one possible way. Now we only set vbus draw by
usb_gadget_vbus_draw() after setting config and suspend/resume usb
device. Maybe we can add one condition in usb_gadget_vbus_draw() like:
if (mA >= 500 && gadet->speed >= SUPER_SPEED)
mA = 900;
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
@ 2017-03-30 3:16 ` Baolin Wang
0 siblings, 0 replies; 50+ messages in thread
From: Baolin Wang @ 2017-03-30 3:16 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Mark Brown, John Stultz,
Charles Keepax, patches, Linux PM list, USB, device-mainlining
Hi,
On 29 March 2017 at 07:04, NeilBrown <neilb@suse.com> wrote:
> On Tue, Mar 07 2017, Baolin Wang wrote:
>
>> On 3 March 2017 at 10:23, NeilBrown <neilb@suse.com> wrote:
>>
>>>
>>> I understand your reluctance to change drivers that you cannot test.
>>> An alternative it do change all the
>>> atomic_notifier_call_chain(.*notifier,
>>> calls that don't pass a pointer to vbus_draw to pass NULL, and to
>>> declare the passing of NULL to be deprecated (so hopefully people won't
>>> use it in new code).
>>> Then any notification callback that expects a current can just ignore
>>> calls where the pointer is NULL.
>>
>> I am afraid if it is enough to send out vbus draw information from USB
>> phy driver, for example you will miss super speed (900mA), which need
>> get the speed information from gadget driver.
>
> When the gadget driver determines that 900mA is available, it calls
> usb_phy_set_power() which calls the ->set_power() method on the usb_phy.
> The usb_phy the uses the notifier to inform all interested parties
> that 900mA is available.
That is one possible way. Now we only set vbus draw by
usb_gadget_vbus_draw() after setting config and suspend/resume usb
device. Maybe we can add one condition in usb_gadget_vbus_draw() like:
if (mA >= 500 && gadet->speed >= SUPER_SPEED)
mA = 900;
--
Baolin.wang
Best Regards
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2017-03-30 3:17 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-20 8:51 [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation Baolin Wang
2017-02-20 8:51 ` [PATCH v19 1/4] usb: gadget: Introduce the usb charger framework Baolin Wang
2017-02-20 8:51 ` Baolin Wang
2017-02-20 8:51 ` [PATCH v19 2/4] usb: gadget: Support for " Baolin Wang
2017-02-20 10:08 ` kbuild test robot
2017-02-20 10:08 ` kbuild test robot
2017-02-20 10:18 ` Baolin Wang
2017-02-20 10:18 ` Baolin Wang
2017-02-20 8:51 ` [PATCH v19 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger Baolin Wang
2017-02-20 8:51 ` [PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management Baolin Wang
2017-02-20 8:51 ` Baolin Wang
2017-02-20 10:20 ` kbuild test robot
2017-02-20 10:20 ` kbuild test robot
2017-03-03 2:23 ` [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation NeilBrown
2017-03-03 2:23 ` NeilBrown
2017-03-07 9:38 ` Baolin Wang
2017-03-07 9:38 ` Baolin Wang
2017-03-09 1:50 ` Jun Li
2017-03-09 1:50 ` Jun Li
2017-03-09 6:10 ` Baolin Wang
2017-03-09 6:10 ` Baolin Wang
2017-03-09 10:34 ` Jun Li
2017-03-09 10:34 ` Jun Li
2017-03-09 11:22 ` Baolin Wang
2017-03-09 11:22 ` Baolin Wang
2017-03-10 6:30 ` Jun Li
2017-03-10 6:30 ` Jun Li
2017-03-10 7:15 ` Baolin Wang
2017-03-10 7:15 ` Baolin Wang
2017-03-10 8:27 ` Jun Li
2017-03-10 8:27 ` Jun Li
2017-03-10 10:52 ` Baolin Wang
2017-03-10 10:52 ` Baolin Wang
2017-03-13 1:09 ` Jun Li
2017-03-13 1:09 ` Jun Li
2017-03-13 8:43 ` Baolin Wang
2017-03-13 8:43 ` Baolin Wang
2017-03-14 1:10 ` Jun Li
2017-03-14 1:10 ` Jun Li
2017-03-14 2:03 ` Baolin Wang
2017-03-14 2:03 ` Baolin Wang
2017-03-28 23:04 ` NeilBrown
2017-03-28 23:04 ` NeilBrown
2017-03-30 3:16 ` Baolin Wang
2017-03-30 3:16 ` Baolin Wang
2017-03-14 9:57 ` Lee Jones
2017-03-14 10:39 ` Baolin Wang
2017-03-14 10:39 ` Baolin Wang
2017-03-14 12:14 ` Lee Jones
2017-03-14 12:14 ` Lee Jones
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.