On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote:
> >> 
> >> I'd say, in the core driver:
> >>   1) get dr_mode from platform data
> >>   2) only if that's DR_MODE_UNKNOWN (iirc), read DCCPARAMS, since it's
> >>   not guaranteed to work across all chipideas;
> >>   3) if dr_mode == OTG or dr_mode == UNKNOWN and DCCPARAMS has both DC
> >>   and HC, set ci->otg, which determines if we can access otgsc
> >>   4) if dr_mode == DUAL_ROLE, don't set ci->otg.
> >> 
> >> Do you see any problems with this?
> >
> > How to know vbus status if dr_mode == gadget, we need to indicate connection
> > and disconnection?
> 
> We don't. Do we need to indicate vbus session valid for gadget only
> devices?

Of course, eg,, how android phone know it connects to pc or not?
> 
> > if dr_mode == DUAL_ROLE, do we support ID switch? How can we know ID which
> > ID pins connects to controller?
> 
> In this case we can support gpio-based or debugfs file-based role
> switching.
> 
> > I think we need to split the relationship between dr_mode and OTG capable
> > to cover this problem, eg, using another platform data to indicate if
> > the controller supports OTG or not, since now we can't know if the 
> > controller
> > supports OTG or not from registers. And only OTG capable device can access
> > OTGSC.
> 
> So that's what dr_mode already does in my suggestion above, isn't it?
> dr_mode != OTG => no OTG; why do we need another platform field for?

dr_mode stands for which controller operation mode currently 
otg_capable stands for whether the controller supports OTG operation

Eg, for tablet or phone, the dr_mode may be "gadget", but the otg_capable = 1.

> >
> > Do you agree you convert DT right now, seems Felipe insists on it?
> 
> You mean, move phy to the core instead of passing the pointer and such?
> Yes, we should *carefully* do that.

That is PHY, dr_mode was core's platform data or DT node entries.
struct ci13xxx_imx_data will not allocated by chipidea driver, it
will be allocated by driver core, every platform needs to change.

-- 

Best Regards,
Peter Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to