USB mode set (2.6.37 / da850)

I believe the function da8xx_musb_set_mode will be called. Just through a bit of indirection.

da8xx.c: da8xx_musb_set_mode()
da8xx.c: da8xx_ops.set_mode=da8xx_musb_set_mode()
musb_core.h: musb_platform_set_mode() calls function pointer set_mode()
musb_core.c: calls musb_platform_set_mode()

Between 2.6.33 and 2.6.37, better support for OTG was added. That meant the the USB port could be Host, Device or both. Your kernel config is probably default to both. The role of the port is determined at runtime. I think you want to fix the role to Device at boot. You need to configure to kernel to Peripheral. With DVSDK 03.21 aka linux-2.6.37 I use these menuconfig settings for USB Device only:

Device Drivers
 USB support
  <*> Inventra Highspeed Dual Role Controller (Ti, ADI, ...)
  <*> DA8xx/OMAP-L1x
        Driver Mode (USB Peripheral (gadget stack))  --->
  <*> USB Gadget Support  --->
        USB Peripheral Controller (Inventra HDRC USB Peripheral (Ti

The config setting should result in the CFGCHIP2_FORCE_DEVICE bit being used.

Hi Norman,

musb_core.c: calls musb_platform_set_mode(), through musb_mode_store routine, and below that routine I see:
static DEVICE_ATTR(mode, 0644, musb_mode_show, musb_mode_store); 
I do not see nor understand how this mode attribute is called and where... I also tried with debug print to check if ot is really called and found that there is no printing.

I have configured the gadget like this (from psp guide):

Configuring for Gadget

	Device Drivers --->
    		USB support --->
        		< > Support for Host-side USB
        		<*> Inventra Highspeed Dual Role Controller (TI, ...)
				(*)USB Peripheral (gadget stack)
         

When required to support Ethernet gadget choose the following

	Device Drivers --->       
		USB support --->
			USB Gadget Support --->
				<*> USB Gadget Drivers (Ethernet Gadget (with CDC Ethernet support)) 

But as I said, when checking CFGCHIP2 bits, I see that CFGCHIP2_FORCE_DEVICE bits are not set at all (there are zeros in the relevant mode bits)

If you have any more ideas please tell me,

Best Regards,

Ran

You are right. That code is only called if accessed though sysfs. I think the driver selects the mode based upon the USB cable or by pull ups/downs (VBus)?. Not a HW guy. The force feature is not used. The mode may be restricted to either host or device. In my case, I see this on bootup

musb-hdrc musb-hdrc: USB Peripheral mode controller at fee00000 using DMA, IRQ 58

In the other modes, you would see "Host" or "OTG". The default mode is set in "arch/arm/mach-davinci/usb.c". For Device mode, CONFIG_USB_MUSB_PERIPHERAL needs to be defined in the kernel config. Check your ".config" for "CONFIG_USB_MUSB_PERIPHERAL=y". Linux Kconfig makes it really difficult to map the config value to the menuconfig entry.

Hi Norman,

What I don't yet understand is how the driver set the relevant mode bits(2 bits) in register CFGCHIP2_FORCE_DEVICE.
even if it is in HW it should in that way or another be detected so that the relevant bits will be set, otherwise it will not function (and that's my case I suppose), when I only change this 2 bits to peripheral (now they show zero) it all works well. So I try to figure out where it is set, and maybe then I will understand why it is not done in my case using this TI's PSP (2.6.37).

I checked my .config, and it has CONFIG_USB_MUSB_PERIPHERAL=y

Thank you for your time !

Ran

I think to support OTG in 2.6.37, the CFGCHIP2 force bits are not used. Mode selection is made externally. I don't think the force bit are status bits. The current mode won't be reflected in the force bits.

SPRUFM9H, USB 2.0 User's Guide

USB0_ID
USB0 operating mode identification pin. For OTG mode or device only mode of operation,
do NOT connect the USB0_ID pin, that is, leave the pin floating. For host only mode of
operation, connect the USB0_ID pin to ground via a 0 ohm resistor or connect the pin
directly to ground.

USB0_VBUS
5 volt input that signifies that VBUS is connected. The OTG section of the PHY can also
pull-up/pull-down on this signal for HNP and SRP. For device or host only mode of
operation, pull-up this pin to 5V with an external 1K ohm resistor. For host mode of
operation, pull-up the USB power signal on the USB connector to 5V also. For mixed
host/device mode of operation, tie this to the charge pump.

I believe one of the USB connector should be tied to one of those signals. In 2.6.33, OTG is not supported and the mode was forced in software. On my OMAP-L137 EVM from Spectrum Digital, gadgets work under 2.6.18, 2.6.33, and 2.6.37. I assume that my board is doing all that ID or VBUS stuff.

yes, I'm quite sure the mode bits are not status, since only when I change these bits the detection of connecting and disconnecting the ethernet cable from pc to board is detected in the kernel.

So the question is still left open: where in the kernel code, the mode bits are being set to the desired mode (peripheral or host for example) ? In the 2.6.33 kernel I know where the mode bits are set, bit I don't yet know where it is done in 2.6.37...

Best Regards,

Ran

might it be that the cable I connected is not the right one ? But when forcing of bits is done, everything works perfect.

Ran

With CFGCHIP2 mode bits are zero, this means the USB controller automatically figures out the role from the VBUS or ID. The CFGCHIP2 mode bits need never be manually set by code. I think that the 2.6.37 driver assumes the HW has been wired properly to setup the role, Host, Device ro OTG. The 2.6.33 driver overrode the HW and forced the mode.

I suspect your board is not wired up for OTG. Linux 2.6.37 does not seem to accomodate such situations with a software mode force. I think you might have to port the 2.6.33 force code over to 2.6.37. The question becomes where and what in the 2..6.37 code to modify.

Hi Norman,

I think you are right about that.
I try to figure how where and how to change the code to fit such case.

Anyway, as I understand the code cannot assume that it is OTG, as is now. Am I right about that ?

Ran

I believe so...but I am guessing that 2.6.37 assumes an OTG with a "HW force". Hopefully some Linux USB experts can confirm or refute. Are you using a custom board? Maybe you can patch the HW instead.

Yes, it is a custom board.

The HW board engineer said it does not support OTG (it is only device mode), so patching the HW is probably not acceptible here.

Is it bug in 2.6.37 that it does not support device mode or something else is wrong here in my configuration ? 

I think maybe the key to solve this issue is when I understand the meaning of the relevant bits named " USB0OTGMODE USB2.0 OTG subsystem mode". 
from OMAP-L138 reference guide: 

Table 11-47. Chip Configuration 2 Register (CFGCHIP2) Field Descriptions

14-13 USB0OTGMODE USB2.0 OTG subsystem mode.
0 No override. PHY drive signals to controller based on its comparators for VBUS and ID pins.
1h Override phy values to force USB host operation.
2h Override phy values to force USB device operation.
3h Override phy values to force USB host operation with VBUS low.