Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: > 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 nothing else, then at least it should be able to tell from the usb phy. But I would be surprised if somebody uses a gadget-only usb controller in a SoC that they use for an android phone or tablet. Most probably it'll be dr_mode==USB_DR_MODE_OTG. >> >> > 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 What do you mean, "currently"? It *should* define what the controller is capable of. Then, the current mode of operation can be either detected from OTGSC or will simply default to HOST or PERIPHERAL, according to dr_mode. IOW, dr_mode is a capability of the controller. > otg_capable stands for whether the controller supports OTG operation It is still redundant as otg_capable = dr_mode == USB_DR_MODE_OTG (same as ci->otg should be). > Eg, for tablet or phone, the dr_mode may be "gadget", but the > otg_capable = 1. No, because dr_mode indicates controller's capability, and not the "current" mode of operation. Why would anyone want to put *that* in a DT? Regards, -- Alex -- 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
