* David Brownell <[EMAIL PROTECTED]> [080904 17:35]:
> Breaking this up into digestible chunks ...
>
> This one for USB gadget. I'll send parts of this upstream now,
> that seems simplest.
>
> I'll review the patch for ehci-omap separately, when it's submitted.
> ISTR already commenting that the Kconfig stuff should become a
> platform_data issue. Until that's all resolved, there's not a
> real point to more focussed review.
OK, once it's submitted to linux-usb, I'll drop it from l-o.
> I'll let Felipe deal with the MUSB stuff.
Sounds like the MUSB fixes are already queued up.
> The 15xx() bits in the OHCI glue seem fine, I'll send them too.
Thanks.
> - Dave
>
>
>
> On Wednesday 03 September 2008, Tony Lindgren wrote:
> > --- a/drivers/usb/gadget/Kconfig 2008-09-01 11:13:34.000000000 -0700
> > +++ b/drivers/usb/gadget/Kconfig 2008-09-03 11:19:58.000000000 -0700
> > @@ -297,7 +297,7 @@
> > config USB_GADGET_OMAP
> > boolean "OMAP USB Device Controller"
> > depends on ARCH_OMAP
> > - select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
> > + select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 ||
> > MACH_OMAP_H4_OTG
>
> fine ...
>
> > help
> > Many Texas Instruments OMAP processors have flexible full
> > speed USB device controllers, with support for up to 30
> > diff -Nru --exclude-from=/home/tmlind/src/dontdiff-tony
> > /home/tmlind/src/kernel/linux-2.6/drivers/usb/gadget/omap_udc.c
> > ./drivers/usb/gadget/omap_udc.c
> > --- a/drivers/usb/gadget/omap_udc.c 2008-09-01 11:13:35.000000000 -0700
> > +++ b/drivers/usb/gadget/omap_udc.c 2008-09-03 11:32:56.000000000 -0700
> > @@ -2313,6 +2313,13 @@
> >
> > tmp = omap_readl(OTG_REV);
> > if (cpu_is_omap24xx()) {
> > + /*
> > + * REVISIT: Not clear how this works on OMAP2. trans
> > + * is ANDed to produce bits 7 and 8, which might make
> > + * sense for USB_TRANSCEIVER_CTRL on OMAP1,
> > + * but with CONTROL_DEVCONF, these bits have something to
> > + * do with the frame adjustment counter and McBSP2.
> > + */
>
> ok ... the FAC is, ISTR, there to support hardware synch
> with isochronous data streams. Linux doesn't use it now.
>
>
> > ctrl_name = "control_devconf";
> > trans = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
> > } else {
> > @@ -2597,7 +2604,9 @@
> > * and ignored for PIO-IN on newer chips
> > * (for more reliable behavior)
> > */
> > - if (!use_dma || cpu_is_omap15xx() || cpu_is_omap24xx())
> > + if ((!use_dma && (addr & USB_DIR_IN))
> > + || machine_is_omap_apollon()
> > + || cpu_is_omap15xx())
>
> NAK. The Apollon-specific bit should be done some other way,
> and whatever silicon issue it's covering up is not specific to
> that board ...
>
> There is however an issue here. The PIO-IN comment stopped
> matching the hardware at some point...
>
I've dropped this from l-o tree, did not change the comments.
> > dbuf = 0;
> >
> > switch (maxp) {
> > @@ -2687,7 +2696,7 @@
> > udc->gadget.name = driver_name;
> >
> > device_initialize(&udc->gadget.dev);
> > - dev_set_name(&udc->gadget.dev, "gadget");
> > + strcpy (udc->gadget.dev.bus_id, "gadget");
>
> As was previously commented: this regression is a merge goof. NAK.
>
> > udc->gadget.dev.release = omap_udc_release;
> > udc->gadget.dev.parent = &odev->dev;
> > if (use_dma)
>
>
This was already dropped yesterday.
Great, that only leaves the echi-omap patch then! Thanks for your help.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
