On Wed, Dec 02, 2009 at 11:36:51AM +0100, Balbi Felipe (Nokia-D/Helsinki) wrote:
This will allow us to conserve some power by shutting down
musb when it's not in use. We can also have less problems
while dealing with usb charger detection if we:
sysfs_notify(tranceiver->kobj, NULL, "vbus");
echo 1 > /sys/devices/platform/musb_hdrc/wakeup (??? example only)
detect_usb_charger();
a little problem here:
if we have a transceiver which we can use i2c or some other bus to
control it (like twl family) we can trigger charger before even powering
musb. But if we have a transceiver which we can only use ulpi (like
isp170x family) we need to power musb in order to have access to musb's
ulpi block.
Then things start to become a little bit more complicated. In case we
have i2c bus, we don't have to power musb and we could trigger charger
detection as a response to the vbus irq from transceiver. On the other
hand, in case of isp1707-like transceivers, we couldn't use the irq as
an input for triggering the charger detection. At least not in a clean
way which I can think of.
If you guys have any idea, I'd be glad to hear, but currently I really
don't know what to do. Here's a preliminary patch for charger detection
on the i2c case, not using the irq:
NOT-YET-Signed-off-by: Felipe Balbi <felipe.balbi@xxxxxxxxx>
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index bd9883f..19ae4f2 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -622,6 +622,15 @@ static int twl4030_set_suspend(struct otg_transceiver *x, int suspend)
return 0;
}
+static int twl4030_detect_charger(struct otg_transceiver *x)
+{
+ /*
+ * FIXME implement this one correctly!!!
+ */
+
+ return 0;
+}
+
static int twl4030_set_peripheral(struct otg_transceiver *x,
struct usb_gadget *gadget)
{
@@ -675,6 +684,10 @@ static int __devinit twl4030_usb_probe(struct platform_device *pdev)
twl->otg.set_host = twl4030_set_host;
twl->otg.set_peripheral = twl4030_set_peripheral;
twl->otg.set_suspend = twl4030_set_suspend;
+ twl->otg.supports_charger = pdata->supports_charger;
+ twl->otg.detect_charger = pdata->supports_charger ?
+ twl4030_detect_charger : NULL;
+
twl->usb_mode = pdata->usb_mode;
twl->asleep = 1;
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 3c1a029..df26924 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -404,6 +404,7 @@ enum twl4030_usb_mode {
struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
+ unsigned supports_charger:1;
};
struct twl4030_ins {
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 52bb917..169d97c 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -64,6 +64,11 @@ struct otg_transceiver {
u8 default_a;
enum usb_otg_state state;
+ /* true if this transceiver can detect a usb charger
+ * according to USB Battery Charging Spec
+ */
+ unsigned supports_charger:1;
+
struct usb_bus *host;
struct usb_gadget *gadget;
@@ -104,6 +109,8 @@ struct otg_transceiver {
/* start or continue HNP role switch */
int (*start_hnp)(struct otg_transceiver *otg);
+ /* kicks charger detection */
+ int (*detect_charger)(struct otg_transceiver *otg);
};
@@ -203,6 +210,12 @@ otg_start_srp(struct otg_transceiver *otg)
return otg->start_srp(otg);
}
+static inline int
+otg_detect_charger(struct otg_transceiver *otg)
+{
+ if (otg->detect_charger && otg->supports_charger)
+ return otg->detect_charger(otg);
+}
/* for OTG controller drivers (and maybe other stuff) */
extern int usb_bus_start_enum(struct usb_bus *bus, unsigned port_num);
--
if we follow this, we could make musb (??) export a "charger" sysfs
entry and whenever userland sees the vbus irq (which is also exported to
userland) it would then read "charger", that would trigger the charger
detection and return 0 or 1... This still doesn't seem right as we
could/should be using the power supply interface for that (??). Should
then musb have the power supply interface ? Doesn't sound right to me...
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
