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.
I'll let Felipe deal with the MUSB stuff.
The 15xx() bits in the OHCI glue seem fine, I'll send them too.
- 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...
> 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)
--
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
