How to properly disable VBUS generation in MUSB driver on OMAP3?

Bernie,

Above patch would not start the Vbus during bootup time so if any device is connected during bootup then it would not get detected.We would certainly require Vbus for usb devices connected to OMAP3 to get detected and work properly. Current linux musb driver switces off the Vbus whenever any device is disconnected and thus we require to enable the Vbus by writting into Session bit of DevCtl register. There are two ways of doing this,

1. echo F > /proc/driver/musb

2. echo 1> /sys/devices/platform/musb_hdrc/srp

Can you provide more information on what are you actually looking for ?

Regards,
Ajay

Ajay said:

Current linux musb driver switces off the Vbus whenever any device is disconnected and thus we require to enable the Vbus by writting into Session bit of DevCtl register. There are two ways of doing this,

1. echo F > /proc/driver/musb

2. echo 1> /sys/devices/platform/musb_hdrc/srp

Does this imply that the only place the VBUS is ever turned on is at power up? This is good, as I would be interested in disabling anywhere that VBUS is enabled, but only the turning on of the actual VBUS voltage from the TPS56950, leaving the rest of the USB operation in place.

Ajay said:

Can you provide more information on what are you actually looking for ?

Basically I am looking for a way to disable the TPS65950 VBUS voltage from driving in software while keeping the USB driver functional.

The reason this is desired is the TPS65950 charge pump for the VBUS rail can only provide ~100mA, but in the application at hand greater current is required.

To achieve this an external 5v supply is being placed on the VBUS rail, so the VBUS rail should be available and allowing attached devices to be detected properly. The TPS65950 VBUS would be redundant at this point, so preventing the USB driver from turning it on would prevent both the power overhead and switching noise of having it active and not being drawn upon.

>> Does this imply that the only place the VBUS is ever turned on is at power up?

Whenever SESSION bit is set in devctl register and at that point ID pin is grounded (mini-A plug, host mode) then Vbus will be switched on by PHY.

I think another way to is to disable the USB Vbus regulators on TPS device so that even if PHY tries to switch on the Vbus there is no voltage to create any conflict with external source.

Regards,
Ajay

Ajay said:

Whenever SESSION bit is set in devctl register and at that point ID pin is grounded (mini-A plug, host mode) then Vbus will be switched on by PHY.

Is this something that happens in the USB driver somewhere, or is this something that is happening automatically in hardware? I was under the impression the USB driver would have to make an I2C access to the TPS65950 at some point to activate the VBUS charge pump, but I have not come across the code that does it yet.

Ajay said:

I think another way to is to disable the USB Vbus regulators on TPS device so that even if PHY tries to switch on the Vbus there is no voltage to create any conflict with external source.

This is exactly what I would like to happen, but looking at the TPS65950 specific code (which all seems to call it TWL4030) I could not find an obvious place to disable the VBUS activation. I assume you are proposing a software disabling of the VBUS charge pump on the TPS?

Bernie Thompson said:

This is exactly what I would like to happen, but looking at the TPS65950 specific code (which all seems to call it TWL4030) I could not find an obvious place to disable the VBUS activation. I assume you are proposing a software disabling of the VBUS charge pump on the TPS?

It is my impression at this point that some of this is controlled through the phy interface as defined by the ULPI specification, and not through the I2C.  This is what makes this fairly confusing to work with is there are two ways to access the same registers.

Cliff

>>Is this something that happens in the USB driver somewhere, or is this something that is happening automatically in hardware

yes it happens automatically.

>>I have not come across the code that does it yet.

you can refer drivers/usb/otg/twl4030-usb.c file for tps65950 (aka, TWL4030) usb controls.

>> I could not find an obvious place to disable the VBUS activation.

i think you can try disabling stuff in twl4030_usb_ldo_init() function.

Regards,
ajay

Ajay said:

you can refer drivers/usb/otg/twl4030-usb.c file for tps65950 (aka, TWL4030) usb controls.

I took a look in there, but without success, nothing in that file seems to directly relate to enabling or disabling the VBUS rail, though it does have code related to other power initialization. The only way that it is enabling or disabling the TPS65950 VBUS charge pump is if it does not use the same naming conventions for registers that the TPS65950 TRM does, and thus I could not find the connection. In particular I do not see any reference to the DRVVBUS bit from the OTG_CTRL register, which appears to be the definitive bit the TPS65950 uses to control the supply of the VBUS charge pump.

This being said, there must be some external way that the VBUS rail is getting enabled which I am not yet familiar with (i.e. through ULPI PHY interface as Cliff suggests). This seems to be something we would need to narrow down with the TPS folks.

Ajay said:

i think you can try disabling stuff in twl4030_usb_ldo_init() function.

This is the first place I had looked as well, but after tracing down the register accesses it is making here, these seem to relate more to an initialization for the internal power supplies of the USB PHY inside the TPS65950, the VBUS charge pump appears to be a separate unit which is not activated here.

Thank you for your help with this Ajay.

Doing some more looking in the code that my original patch touches, this seems to be registers defined by the Mentor Graphics MUSBMHDRC IP (MUSB_DEVCTL_*, etc).  I suspect that writes to these registers trigger transactions that go out over the ULPI interface.  Unless we can get documentation for the MUSB registers, or TI can provide information on how to do this, I don't see how we can ever figure this out? We can likely access the TPS registers over the I2C interface, but I really need a way to keep the supply from ever being turned on, yet keep the MUSB Host portion functioning.

Can TI provide some more details on the MUSB registers, or continue to dig into a solution for this?

Thanks,
Cliff

Hi Cliff,

I would like to know if you find a solution into your problem?. If yes, can you share it how did you do it?. I have a similar problem of yours and still looking how to solve it.

Regards,

John

Hi John,

I should have some additional documentation soon, so once I get that I'll know a little better what is involved, and try to update this thread.

Cliff

Any progress on that subject?

I'm  struggling with the opposite task, we require the VBus generation to be always on, because we abuse it for other purpose.

I can switch it on by setting bit 5 (DRVVBUS) in register OTG_CTRL_SET. But it seems that later the USB driver interferes and switches off VBus by another way. I detected an access to VUSB1V8_DEV_GRP to be correlating, and patched the driver to skip this. However, the voltage still gets switched off and I see no I2C access nearby.

In the datasheet, I find no clue about the TPS65950 automatically handling VBus, the block diagrams show no switch between the charge pump and the VBus pin, unless I'm mistaken.

Any ideas?

Jörg

Jorg,

For the Vbus to be always ON make sure that SESSION bit is alwasy set to '1' in mentor controller register DEVCTL register.

Regards,

Ajay

Thanks for your suggestion.

I've tried it, patched the driver to always set MUSB_DEVCTL_SESSION when writing to MUSB_DEVCTL, but it didn't help.

That register is in my OMAP, not the PMIC. First I thought that the switch command may get conveyed across the OMAP-to-PMIC power management I2C bus, but I don't measure anything there. My conclusion is that the PMIC shuts off VBus by itself, not being (directly) instructed. So I'd need to prevent that, if possible.

Meanwhile I experimented with the OTG ID pin. When pulling it low, VBus stays. I don't know yet if that'll interfere with USB operation, we need the gadget mode.

Jörg

In gadget mode Vbus will be provided by host and also ID pin should be left open in gadget mode. it seems you are looking for something like self powered gadget and so host should not provide any power. In this case also ID pin should be open and Vbus applied externally. I don;t think that ULPI interface between OMAP and PMIC should be used to switch on the Vbus which is only done for host mode operation.

Ajay

Thanks, but this it not exactly the direction. My point is not "self powered gadget", I need gadget mode and VBus still on because it's abused to power something different, unrelated to USB. We tried to save a step up converter by abusing VBus. It is generating 5V which we don't have anywhere else on the board.

Maybe I'm looking for the impossible, because the PMIC outsmarts me. From the datasheet, I don't see such automatic behaviour. Further experiments with the OTG ID pin were disappointing, holding it low doesn't work along with USB gadget.

Jörg

Has there been any further progress on a solution for this problem?

We have similar situation: VBUS at the connector is connected to another 5V supply. The VBUS on the 65930 is not connected. Using the patch from Cliff to prevent MUSB_DEVCTL_SESSION from being written does turn the charge pump off, but this prevents any connection from being made. It seems to be all or nothing.

Craig

Cliff,

Did you ever get to the additional documentation you needed for this issue?  Were you able to disable the internal charge pump and connect the OTG_VBUS to the external 500mA charge pump reliably?  Any guidance you can provide would be greatly appreciated.  

Thanks,

Brad