Chen Peter-B29397 <B29397@xxxxxxxxxxxxx> writes: > > >> > By the way, why not return directly when it sees a id change interrupt >> > at ci_irq? >> >> Technically, OTGSC is independent from host or device mode, so I assume >> there is a possibility of other device or host related interrupts >> arriving at the same time. > But your controller mode is still not changed as it will be done at work queue. > So, it may some unexpected interrupt, even you have not handled, as the status > is not cleared, it will come soon. You mean, it will fire again as the interrupt source is still active? >> I do call hw_device_reset(..., USBMODE_CM_DC) in udc_start *unless* the >> SHARED flag is set by the platform (currently, msm does that). The >> SHARED flag basically means that we have other driver(s) taking care of >> some of the functionality, like controller reset. In case of msm it's >> done by msm_otg.c. If we expand ci_hdrc to handle otg properly, there >> won't be a need for that (and the separate otg and ehci drivers). >> > Oh, yes, hw_device_reset is here. It is my careless. > > So, it is better only switch device driver to chipidea now, > for otg and host, it is somehow incomplete at current chipidea architecture. > Do you think so? I think that we should first make sure that the chipidea driver has all the functionality you need (think suspend/resume, or whatever udc functionality is missing from the chipidea driver still) before you switch to chipidea driver. There is probably enough time for that before the 3.6 merge window. As for the otg, it depends on how much of the actual otg you need -- I think the proper otg support in this driver will come with the otg framework change. So far it is nowhere near complete, of course. 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
