Peter Chen <peter.c...@freescale.com> 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. > - 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? > 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. > Let me know your opinion about these two problems and your plan for them. > Thanks. Regards, -- Alex -- 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
