[RFC PATCH 00/10 V3] MXS: Add i.MX28 USB Host driver

[hzpeterchen@gmail.com (Peter Chen)]

>
> > > Dear Peter Chen,
> > >
> > > > On Fri, Apr 20, 2012 at 5:48 PM, Sascha Hauer <s.hauer@pengutronix.de> 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