Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: > On Thu, Mar 14, 2013 at 12:31:38PM +0200, Alexander Shishkin wrote: >> Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: >> >> > Hi Alex and all, >> > >> > Currently, we have two problems to block chipidea driver coming >> > development. >> > >> > As there are so many chipidea versions, we impossible to collect >> > all to make a decision, it is better to cover most of the cases, >> > and using device tree (or platform data) to cover exceptions >> > if they exist. >> > >> > 1. USB Mode Problem >> > How can we decide USB mode (gadget, host and otg) at driver, and >> > how to read OTGSC register? Below is my pinion. >> > >> > - We get gadget or host support from CAP_DCCPARAMS(DCCPARAMS_DC or DCCPARAMS_HC), >> > If both DCCPARAMS_DC and DCCPARAMS_HC are 1, then the mode is "otg". >> > If DCCPARAMS_DC = 1 and DCCPARAMS_HC = 0, the mode is "gadget". >> > If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 1, the mode is "host". >> > If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 0, prompt an error >> > and try to get it from DT. >> > >> > - Override the value using DT, please do not consider too much between >> > dule_role and otg. We just consider all controllers which supports host >> > and gadget at the same time as otg device. The exception may not be existed >> > or be too long to use. >> >> The mips platform support patchset that Svetoslav is doing is for such a >> device. In any case, I see no reason to not support all the possible >> devices. > > Oh, I find Svetoslav's patch, and know the situation. > >> >> > - For how to read OTGSC register, we need another flag to indicate >> > it is otg capable (DCCPARAMS_DC = 1 and DCCPARAMS_HC = 1), if it is >> > otg capable, read OTGSC is allowed. Here, OTG capable device can work >> > as gadget only mode. >> >> 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? > 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? >> > 2. Chipidea Core Driver DT Support >> > I agree we move some core things, like vbus, operation_mode, phy to core >> > driver using DT. But for clock, it is better still exist at glue >> > layer, clock is input for chipidea core, chipidea core doesn't need >> > to know its clock from IC point. Like clock, the wakeup setting, low >> > power sequence are platform specific, they are designed by individual >> > companies. >> >> Hmm, if the clock is external to chipidea, I guess it should be ok to >> keep it in the platform code as long as it is entirely contained in the >> platform code, that is, no awkward passing *clk pointers to the core and >> back. > > 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. 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
