> > > > Dear Peter Chen, > > > > > > > On Fri, Apr 20, 2012 at 5:48 PM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > > >> btw /wrt USB Gadget etc -- how does the > > > > >> drivers/usb/gadget/fsl_udc_core.c and drivers/usb/gadget/ci13xxx_* fit > > > > >> into the big picture? We're gonna use the ci13xxx stuff for Gadget on > > > > >> mx28, correct? Then how does fsl_udc_core.c fit in? > > > > > > > > > > From what I have been told by a collegue the ci13xxx driver works > > > > > better, and from what I have seen the code looks better. So I think mxs > > > > > should use it. i.MX can then use it later aswell. We won't need the > > > > > fsl_udc_core driver anymore then. > > > > > > > > Oh, I find I lost many discussions using company email. > > > > From the function and quality level, fsl_udc_core.c is absolutely the > > > > best one for all > > > > i.mx SoCs, as both internal and upstream fsl code use it. > > > > > > Internally though, it looks like crap. > > > > +1 on this. > > +1 > Your guys all consider ci13xxx is better than fsl_udc_core.c, can you list some reasons? Or just because it can compatible with your prefer OTG structure (like msm_otg.c)? >From my point, I also admit OTG structure like msm_otg.c is good one and we can follow it at i.mx USB structure. > > We also made some tests with some gadget devices. IMHO we had troubles > with gadget_zero and testusb on the fsl_udc_core.c. I think the testusb > results should help to decide which is the most stable implementation. > ci13xxx one is no problem? Have you checked why it failed at fsl_udc_core.c? > > > > > > Also, ci13xxx and fsl_usb_core is duplicated stuff, correct? > > > > Yes. > > > > > > > > > I will check with IC guys to see if i.mx's controller is compatible > > > > with CI13412. > > > > If fsl's compatible with CI13412, then mxs can try to use ci13xxx_udc.c to > > > > see if there are any problems, If no problems with kinds of testing, > > > > we can switch all i.mx SoC to ci13xxx_udc.c. > > > > > > Sascha, did you need to patch this ci13xxx somehow to get it running on MXS ? Or > > > what was it that said he got it somehow running? > > > > It basically works out of the box. I think we have some patches for this > > driver, maybe michael can comment on this. > > Yes, i have some smaller bugfix patches hanging around. I will send them > to the linux-usb mailinglist until the next week. Additionaly i have > some platform gluecode and a platform-support patch for the driver but you > probably have the same. > > The ci13xxx_udc_driver has a flags element, which has to be set > appropriate to the used platform. On the mx23 for example we only were > able to get all testusb results correct, when the option > CI13XXX_DISABLE_STREAMING was set. In the OTG case the option > CI13XXX_REGS_SHARED is mandatory. I have checked with IC guys, but they doesn't know something like "CI13412" stands for. Yes, current many ARM SoC use chipidea SoC, besides, - ci13xxx_udc - fsl_usb_core - langwell_udc marvell and Tegra are also use this. I have no maintain experiences on abstract one IP driver from kinds of SoC venders, if one SoC platform finds problem at ci13xxx_udc core, and submit the patch, it needs to verify at all SoC platforms, it may increase difficulty for review process and maintenance. besides, in case this bug-fix is not compatible across kinds of SoC vendors, how to do? just add the fix at SoC vendor layer's code like ci13xxx_msm.c? -- BR, 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
