Thread (41 messages) 41 messages, 9 authors, 2016-04-24

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

From: Felipe Balbi <hidden>
Date: 2016-03-31 06:20:19
Also in: lkml

Hi,

Baolin Wang [off-list ref] writes:
[ text/plain ]
On 30 March 2016 at 19:24, Felipe Balbi [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
quoted
quoted
quoted
Seems you don't want to guarantee charger type detection is done
before gadget connection(pullup DP), right?
I see you call usb_charger_detect_type() in each gadget usb
state
changes.

I am not sure I get your point correctly, please correct me if I
misunderstand you.
We need to check the charger type at every event comes from the
usb gadget state changes or the extcon device state changes, which
means a new charger plugin or pullup.
According to usb charger spec, my understanding is you can't do
real charger detection procedure *after* gadget _connection_(pullup
DP), also I don't
Why can not? Charger detection is usually from PMIC.
Charger detection process will impact DP/DM line state, see usb
charger spec v1.2 for detail detection process, section 4.6.3 says:

"A PD is allowed to *disconnect* and repeat the charger detection
process multiple times while attached. The PD is required to wait for
a time of at least TCP_VDM_EN max between disconnecting and restarting
the charger detection process."

As Peter mentioned, the charger detection should happen between VBUS
detection and gadget pull up DP for first plug in case. So when&after
gadget connect (pullup DP), you should already know the charger type.
Make sense. In our company's solution, charger detection can be done by
hardware from PMIC at first, then it will not affect the DP/DM line when
gadget starts to enumeration.
I see, charger type detection is done automatically by PMIC when VBUS
is detected in your case, you just assume the process is complete
assuming this finishes before gadget starts is a bad idea. It would've
been much more robust to delay usb_gadget_connect() until we KNOW
charger detection has completed.
It is hardware action to detect the charger type quickly. It actually
*gets* the charger type and does not means *detect* charger type in
'usb_charger_detect_type()' function. Maybe I need to change the
function name as 'usb_charger_get_type()'.
yes.
If some udc drivers want to detect charger type in
'gadget->ops->get_charger_type()' callback, they should avoid
impacting DP/DM line state at the right gadget state. Thanks.
they shouldn't detect is get_type(), the semantics doesn't work. If, at
some point, we have to do SW detection of the charger, then a new
->charger_detect() method will have to be added.

-- 
balbi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help