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? if dr_mode == DUAL_ROLE, do we support ID switch? How can we know ID which ID pins connects to controller? 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. > > > 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? -- 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
