today I did some research (before I've seen this thread's new posts :-) ), and came do similar conclusions as in the thread referenced above..

The usb part of twl4030/omap3430 is handled using musb_hrdc module. Aaccording to omap3 reference manual, omap3430 is a implementation of the musb_hrdc "standard", thus the universal driver is used - and we can assume from that, that nokia didn't probably do any special tricks to the omap3 platform...

Unfortunately, the proposed host-setting solution, using

echo host > /sys/devices/platform/musb_hdrc/mode

won't work here, because of the ID pin not being attached to usb port of n900 (this disables autodetection usb mode) - and maybe because of other stuff too..

From what I've found, I think that forcing the usb controller into hostmode isn't possible with current kernel either.

HOWEVER:

The musb_hdrc module registers a file /proc/driver/musb_hdrc , that contains some debug info. By echoing misc. stuff into that file, one can change some settings of the controller.

For example

echo H > /proc/driver/musb_hdrc

stands for "request host mode". And

echo h > /proc/driver/musb_hdrc

for "cancel host mode" request...

The code for this can be found in kernel source code:

kernel-source/drivers/usb/musb/musb_procfs.c (lines 590-699)

Didn't try, whether this works - and it probably won't.

HOWEVER2

The current implementation of musb_hrdc doesn't use the TESTMODE register bit MUSB_TEST_FORCE_HOST .... This should put the controller into hostmode, no matter how the ID pin is connected (text from omap3430 documentation):

The Force Host test mode enables the user to instruct the core to operate in Host mode, regardless of
whether it is actually connected to any peripheral i.e. the state of the CID input and the LINESTATE and
HOSTDISCON signals are ignored. (While in this mode, the state of the HOSTDISCON signal can be read
from bit 7 of the DevCtl register.)

This mode, which is selected by setting bit 7 within the Testmode register, allows implementation of the
USB TEST_FORCE_ENABLE (7.1.20). It can also be used for debugging PHY problems in hardware.

While the FORCE_HOST bit remains set, the core will enter Host mode when the Session bit is set and
remain in Host mode until the Session bit is cleared even if a connected device is disconnected during the
session. The operating speed while in this mode is determined for the setting of the FORCE_HS and
FORCE_FS bits of the Testmode register in Section 23.1.4.11.


I didn't find any useful sysfile to control the TESTMODE register from current kernel, so I suppose a kernel recompile is required (as musb_hrdc isn't compiled as a module), with the following added to the musb_proc_write function switch:

(PS, maybe also some option to set MUSB_TEST_FORCE_HS/FS should be added)

and after that

echo M > /proc/driver/musb_hdrc

should force controller to work in host mode... Didn't test it, don't now whether it'll work (e.g. with the proposed powered-hub workaround).. Hope someone will test this (and the previous H/h parameter) - I myself currently don't have enough time to play with it, and no custom usb cable...

Just recompiled and flashed a kernel with the changes above, unfortunately doing an
for me had no effect whatsoever.

Not even any useful dmesg output? Shame

Nope... Nothing. I even added a printk to verify that it was being called, and it was.

in that case the debugging will be a little harder, I guess... wish I had some more knowledge about electric circuits... cb22, if you have some time left, you could also try some combinations of

echo host > /sys/devices/platform/musb_hdrc/mode
echo H > /proc/driver/musb_hdrc
echo M > /proc/driver/musb_hdrc

... or also adding the FORCE_FS/FORCE_HS options to the switch (and testing that)...

did you try this with powered hub? it's possible, that we won't get any power from n900 itself...

maybe the echo M > ... isn't enough - the controller may be switched to host mode, but for some reason, the host mode information isn't propagated back to the musb_hdrc driver (does it show "host" somewhere in the sys files?)..

Hmm, just tried all of those and the FORCE_FS/FORCE_HS options, all seem to have no effect. Also, plugging the phone into a computer still works as normal.

oh well, I guess we will need beagleboard or something - to debug what exactly is happening with the usb bus, when connected... crap.. ;-(

wouldn't be bad to have some nokia developer to tell us, how's it connected internally - and spare us some time...

beagleboard has a pile of patches for musb http://cgit.openembedded.org/cgit.cg...ap-2.6.29/musb I don't know though if otg host mode is working on the beagleboard with that kernel.

My point is that even if some kind of off-spec host mode is supported by hardware, the driver may still be broken and/or the hardware may be buggy and require workarounds.

FYI, by default the kernel has hubs disabled. However IIRC at sufficient debug verbosity you might get an error message when you connect the hub if the hub is detected. Recompiling the kernel can get around that.

Possible you can reach
Felipe Balbi <felipe.balbi@nokia.com>

Recently he sent many patches about musb and OTG mode:

[RFC/PATCH 0/5] usb transceiver notifier
RFC/PATCH 1/5 - usb: otg: add notifier support
[RFC/PATCH 3/5] usb: musb: add support for ulpi block [RFC/PATCH 4/5] usb: musb: isp1704: add registers from isp1704
[RFC/PATCH 5/5] usb: musb: musb supports otg notifier

--

Patched what, Maemo? If so, that would be awesome. And, perhaps only one of us should email him No need to piss him off!