Message-ID: <AFCDDB4A3EA003429EEF1E7B211FDBBA36EE80C928@EXDCVYMBSTM005.EQ1STM.local>
Date:	Mon, 28 Nov 2011 16:09:47 +0100
From:	Morten CHRISTIANSEN <morten.christiansen@...ricsson.com>
To:	Linus Walleij <linus.walleij@...aro.org>, Greg KH <gregkh@...e.de>
Cc:	NeilBrown <neilb@...e.de>, Arnd Bergmann <arnd@...db.de>,
	"myungjoo.ham@...il.com" <myungjoo.ham@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mike Lockwood <lockwood@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Donggeun Kim <dg77.kim@...sung.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Karl KOMIEROWSKI <karl.komierowski@...ricsson.com>,
	Johan BJORNSTEDT <johan.bjornstedt@...ricsson.com>,
	Daniel WILLERUD <daniel.willerud@...ricsson.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mian Yousaf KAUKAB <mian.yousaf.kaukab@...ricsson.com>,
	Morten CHRISTIANSEN <morten.christiansen@...ricsson.com>
Subject: RE: [RFC PATCH 0/3] introduce: Multistate Switch Class

Hello!

Linus is correct. However some more info might be useful? Feel free to drop off whenever in the more and more detailed explanations! This is a non-trivial issue that has had some effort spent on it already.

SUMMARY: Devices today charge at high current (1.5A) from a dedicated charger and 500mA max from a standard USB port, using the standard MaxPower parameter. It would have been great if devices could also charge at higher current from a host or hub port but that is not really practical due to HW issues, not SW issues. See below. A new USB Power Delivery spec is imminent that might be of interest?

SHORT VERSION OF PREVIOUS EFFORTS:
Using HID for managing USB battery charging current from the host is indeed the correct approach. And a work effort in USB Device Working Group went all the way to "ready for publication" state - and then died (for a number of reasons) some years ago. (Due to IPR reasons I cannot forward the un-released version of the spec.)

I see no reason to revisit the HID approach since it will not get any device support. Even if it was the correct approach.

USB POWER DELIVERY:
Currently there is an ongoing effort for USB power delivery, this might be relevant and useful even if it also allows much higher voltage than 5V. The industry review of the preliminary spec has happened and the spec should be public in a few months.  

http://www.usb.org/press/USB_Power_Delivery_Specification.pdf for press release 

and further details from IDF 2011:
https://intel.wingateweb.com/us11/scheduler/download/download.jsp?E4B2973BCDE53502BEFEB912D75B8DA8=A6B62020AAED1E8D4EDE0D1DA89C386D&B74A4263B8A60B9174A0CE5F9461219F=8BC9EC1D19D07830717163157D635C00


LONGER VERSION: 
The really simplified explanation of the battery charger spec states that a dedicated charger port has D+ and D- short-circuited. The device can detect this and charge at any current up to 1.5A. No enumeration, no traffic etc. And no USB host in the charger! As some originally proposed. Note that other versions of modifying D+/D- in a charger exists, notably in Apple chargers but this is out of scope for this discussion. And obviously all of this is handled in the lower level USB stack down at the physical driver level as there is no point in sending this info further "up" into the SW stack in the device since the charger app is already handling this. Regardless of device OS used.  

In order to charge at higher current from a host (or hub) port a different mechanism is used to detect charging capability without killing USB traffic - something that shorting D+/D- usually does! In practice the device sends a low level pulse on D+ and the host answers with a similar pulse on D-. Giving the device the indication that D+/D- are shorted. While still allowing USB traffic after the initial charger detection has taken place. 

However there are very few if any host ports that support this. And even if a few hub chips have been launched this has not caught on. One problem with the host port is that the user expects that all ports will allow higher current charging. The hub's problem is to ensure that a 7-8A power supply instead of the standard 2.5A power supply is connected. And why would people want to pay extra for this hub capability anyway? Same applies to the host; the host will have to upgrade the 3-4 USB ports from 500mA each to 1.5A each. Not nice! And it will also have to continue to supply 5-6A on the 5V Vbus power supply when in standby since once a port has been detected as a charger port the charger capability cannot be revoked unless Vbus is removed, killing the device etc. And not allowing the power supply to meet the standby current requirements that now apply at least in the European Union. 

So the approach with new commands (using HID) to allow the host to read battery status on each device and intelligently decide which port - if any - and at any time - has higher current capability than the standard 500mA - and even programmable 500 - 1500mA current - is indeed the right approach. But "dead" as briefly described above.

I can provide more information if needed. But would advise you to follow up on the USB power delivery specification effort first.

BR Morten Christiansen, Siv.Ing
Principal System Designer, Datacom USB
ST-Ericsson R&D Grimstad, Norway

-----Original Message-----
From: Linus Walleij [mailto:linus.walleij@...aro.org] 
Sent: 28. november 2011 14:04
To: Greg KH
Cc: NeilBrown; Arnd Bergmann; myungjoo.ham@...il.com; linux-kernel@...r.kernel.org; Mike Lockwood; Arve Hjønnevåg; Kyungmin Park; Donggeun Kim; Grant Likely; Karl KOMIEROWSKI; Johan BJORNSTEDT; Daniel WILLERUD; Dmitry Torokhov; Mian Yousaf KAUKAB; Morten CHRISTIANSEN
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Mon, Nov 28, 2011 at 8:27 AM, Greg KH <gregkh@...e.de> wrote:
> On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
>>
>>  My own thought is that this deserves a new device class which allows 
>> easy
>>  hook-up of in-kernel signalling using notifications and which can be
>>  exported as input devices in much the same way the 'gpio' devices 
>> can be
>>  exported via gpio_keys.  The switch could also optionally be 
>> exported through
>>  sysfs much like gpio can be exported through sysfs.
>
> That might also work, but again, odds are the HID spec already defines 
> this type of "switch", so why recreate it as a different type of device?

I think both yes and no, but I will stand corrected.

When you plug it into a host, I guess your device will negotiate power withdrawal from the host as anything else, no matter what device or interface classes it presents.

However in the other case I am under the impression that devices supporting EPS http://en.wikipedia.org/wiki/Common_External_Power_Supply
Or the "battery charging specification"
http://www.usb.org/developers/devclass_docs/batt_charging_1_1.zip
do so in their Phy transceiver drivers, say e.g.
drivers/usb/otg/ab8500-usb.c in our case. This is sometime called a "chinese charger" or "dedicated charger". It's just appearing on the micro-USB port, it doesn't enumerate and the OS driver does not talk to it. I think it notifies the transceiver by short-circuiting D+ and D- and the transceiver/phy driver may in many cases notify charging circuitry and userspace that it's been plugged in (switch uevent, cable insertion input event or whatever we come up with).

So no, I don't think HID defines this, it's defined in a physical layer spec, and the interfaces to OS:es are transciever/phy-custom.

I've CC:ed Morten who was part of writing the charging spec so he can correct me if I'm saying the wrong thing.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists