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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
