[Gta04-owner] Power supply for internal USB PHY

NeilBrown neilb at suse.de
Tue Jan 22 12:35:12 CET 2013

On Thu, 17 Jan 2013 10:55:48 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> Hi Neil,
> Am 17.01.2013 um 01:51 schrieb NeilBrown:
> > 
> > Hi Nikolaus,
> > I've been exploring the possibility of enabling "off-mode" for the OMAP3
> > which hopefully will save a bit of power.  It mostly works, however the two
> > USB ports (internal and external) don't survive the transition through off
> > mode yet.
> > 
> > As a result of raising this issue - of the internal USB particularly - on
> > the linux-omap list, it seems that it might be necessary to power-cycle the
> > internal USB transceiver (USB3221).  You can read the thread starting:
> >   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82936.html
> > 
> > particularly
> >  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82970.html
> > and
> >  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83209.html
> > 
> > The best explanation that I can come up with is that when the 'CORE'
> > power-domain of the OMAP3 turns off and  comes back on it loses sync with
> > the USB phy in a way that 'reset' is insufficient to fix and a power-cycle
> > is needed.   Seems strange and I'm not completely certain that this is the
> > case, but the evidence seems to point that way.
> Yes, that would look plausible, but the USB3320 data sheet says:
> "The USB3320 provides a POR circuit that generates an internal reset pulse after the VDD18 supply is stable. After the internal POR goes high and the RESETB pin is high, the USB3320 will release from reset and begin normal ULPI operation as described in Section 5.5.4.
> The ULPI registers will power up in their default state summarized in Table 7.1 when the 1.8V supply is brought up. Cycling the 1.8 volt power supply will reset the ULPI registers to their default states. The RESETB pin can also be used to reset the ULPI registers to their default state (and reset all internal state machines) by bringing the pin low for a minimum of 1 microsecond and then high.
> The Link is not required to assert the RESETB pin. A pull-down resistor is not present on the RESETB pin and therefore the Link must drive the RESETB pin to the desired state at all times (including system start-up) or connect the RESETB pin to VDDIO."
> Therefore no previous state should survive. If it does, it must have to do
> something with the OMAP3 EHCI state machine and the sequence it wakes
> up. Maybe the reset is coming too late or too early? After the EHCI assumes
> that it already has initialized something?
> And this section from the data sheet contains an interesting hint: What
> happens during off-mode on the GPIO 174? Is it actively driven low or floating?
> So it might issue false reset impulses. Especially since the clock is provided
> by the OMAP and is missing in that state. I.e. the state machine may require
> valid clock to be able to reset itself.
> This is something you could try to identify with an oscilloscope by looking at
> R901.

Maybe I should get an oscilloscope one day .... I have a little USB thing
that can measure voltage, but I haven't found an open driver yet :-(

However further investigations have convinced me that this was a false
alarm.  I now have off-mode working and the USB interface survives with no
need to do anything special to the PHY (though there is a rather ugly hack
needed.... but it works!).

> > 
> > So it appears that it would be useful to be able to independently
> > power-cycle the USB phy in much the same way that you can now power-cycle
> > the Modem.
> > 
> > As I say, I'm not completely sure so this isn't yet a "must have" for the
> > GTA04a5, but it could be useful if it isn't too hard.
> > 
> > On a related topic, my reading of the documentation for the USB3221 suggests
> > that the VDD3V3 pin is a power *output*, not a power *input*, whereas the
> > schematics show it wired like an input for the GTA04a[34].  I wouldn't
> > expect this to be a serious problem, but it seems wrong and could possibly
> > cause an unexpected power leakage.
> There is an option to bypass the internal LDO between VBATT and VDD3V3:
> "The USB3320 includes an integrated 3.3V Low Drop Out (LDO) regulator that may optionally be used to generate 3.3V from power applied at the VBAT pin. The voltage on the VBAT pin can range from 3.1 to 5.5V. The regulator dropout voltage is less than 100mV which allows the transceiver to continue USB signaling when the voltage on VBAT drops to 3.1V. The USB transceiver will continue to operate at lower voltages, although some parameters may be outside the limits of the USB specifications. If the user would like to provide a 3.3V supply to the USB3320, the VBAT and VDD33 pins should be connected together as described in Section 5.5.1."
> This means we could have connected VBATT to the battery and leave VDD3V3
> floating. By connecting to our own 3V3 LDO we change almost nothing (except
> that it is really powered down if the TPS65950 is switched completely off).
> Hope this gives at least some hints.

Yes, thanks a lot for your time in explaining hardware to this software
engineer :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130122/9ec6312b/attachment.bin>

More information about the Gta04-owner mailing list