usb0->usb1 in 2.6.37-rc8-d4

Hello Robert,

Not poked yet, but FYI, usb0 got joined by a usb1 network interface in
the latest 2.6.37-rc8-d4 build, which seems to have been caused by
building in Ethernet "gadget" support. That particular module got
initialized first and grabbed usb0. Was it your intention to build this
in or have it as a loadable module?

Jon.

Hi Jon,

Yeap, that's expected.. (now that the modules builds again, it early
2.6.37-rc's it was broken, so i had enabled a serial port instead...)

It serves two purpose's.

At one time there was a bug in the musb/otg layer where it wouldn't
power-on/probe devices unless one module was built-in.. There are init
work a rounds, but that doesn't work if you rootfs is on a usb device
behind the otg port.. I think this is not needed anymore, and will be
testing it this week..

nfs rootfs mounts over musb/otg.. (this is for the old Bx/Cx boards..
as with the xM we got a real port so it's best to use that..)

Let me know if you see any other issues with, i'm moving this kernel
version to my stable branch over this next week.. It's been pretty
solid for me..

Regards,

Seems ok so far. I'm building my own kernels now for xM aswell, the pure
mainline 2.6.37-rc8 builds and boots just fine, however it looks as if
you've some specific USB fixes in the patch you are applying in yours.

Can you tell me which tree is that patch (patch-2.6.37-rc8-d4.diff.gz)
based upon (I assume it is just from a git tree?), and does it contain a
lot more than USB fixes for this platform? I'll take it apart later, but
if you happen to reply before then, it'll save me doing so :slight_smile:

Jon.

By which I mean whatever GPIO hack is being done must be part of a patch
that I can't see in my regular omap git tree either. But it's late, and
I'll probably find this in the morning :slight_smile:

Jon.

Like this one: http://www.spinics.net/lists/linux-omap/msg41619.html ?

Yea. In fact, it's just this bit that is needed:

+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ } else {
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ }

I have a kernel running with that now. What I'm interested in is where
it came from - not who sent the patch, but which tree Robert is pulling
from, since this is not in the regular omap tree I have here.

Thanks,

Jon.

Like this one: http://www.spinics.net/lists/linux-omap/msg41619.html ?

Yea. In fact, it's just this bit that is needed:

+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ } else {
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ }

I have a kernel running with that now. What I'm interested in is where
it came from - not who sent the patch, but which tree Robert is pulling
from, since this is not in the regular omap tree I have here.

Hi Jon,

That's would be my tree/patchset..

It's mostly just dev board tweaks, things already posted to linux-omap
for the next kernel, and then a big sgx kernel module patchset...

https://code.launchpad.net/~beagleboard-kernel/+junk/2.6.37-devel

Regards,