On 03/14/2013 11:31 AM, 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. > >> - 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 + get dr_mode from DT. > 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. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachment:
signature.asc
Description: OpenPGP digital signature
