[Gta04-owner] Modem off

NeilBrown neilb at suse.de
Sun Nov 10 23:09:47 CET 2013


On Sun, 10 Nov 2013 14:23:22 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 
> Am 09.11.2013 um 05:12 schrieb NeilBrown:
> 
> > On Fri, 8 Nov 2013 15:49:50 +0100 Andreas Kemnade <andreas at kemnade.info>
> > wrote:
> > 
> >> On Fri, 8 Nov 2013 14:07:13 +1100
> >> NeilBrown <neilb at suse.de> wrote:
> >> 
> >>> On Tue, 5 Nov 2013 15:02:34 +0100 Andreas Kemnade <andreas at kemnade.info>
> >>> wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> On Tue, 5 Nov 2013 08:51:26 +0100
> >>>> Radek Polak <psonek2 at seznam.cz> wrote:
> >>>> 
> >>>>> On Monday, November 04, 2013 11:09:27 PM Andreas Kemnade wrote:
> >>>>>> Hi,
> >>>>>> 
> >>>>>> On Sat, 2013-09-21 at 08:19 +1000, NeilBrown wrote:
> >>>>>>> I've experimented with "rmmod ehci_hcd" just before suspend, and
> >>>>>>> "modprobe" on resume, but so far that has just caused a mess.
> >>>>>>> I've looked at the code, and it is rather complex.
> >>>>>>> It has also changed a lot in 3.10.  So I'm going to defer exploring this
> >>>>>>> more until I start on 3.10+ again, probably in a couple of weeks.
> >>>>>> 
> >>>>>> In 3.12 I get also around 15mA more current in suspend with modem off.
> >>>>>> than with modem on. (suspend does not work reliable with that kernel for
> >>>>>> me and I have 60mA/85mA current consumption)
> >>>>>> 
> >>>>>> In 3.7 with enabled modem
> >>>>>> doing "echo ehci-omap.0 >unbind" in
> >>>>>> /sys/bus/platform/drivers/ehci-omap
> >>>>>> also increases current. (I get 40mA then)
> >>>>>> doing "echo echi-omap.0 >bind"
> >>>>>> decreases it again to around 20mA.
> >>>>>> That is also strange.
> >>>>>> 
> >>>> btw: what is different in doing rmmod/modprobe and doing the unbind/bind?
> >>> 
> >>> There should be no difference.
> >>> Both 'modprobe' and 'bind' will run the 'probe' function of the driver.
> >>> Both 'rmmod' and 'unbind' will run the 'remove' function.
> >>> 
> >> 
> >> Hmm, there might be a difference. The order of things being called is
> >> different. If we use unbind/bind
> >> and have ehci-hcd compiled in, the probe function is called earlier. 
> >>> [...]
> >>> This is at least very clear evidence that the USB port together with the
> >>> transceiver account for a substantial portion of the power usage.
> >>> 
> >>> Figuring out why and fixing it is a somewhat different story....
> >>> 
> >> Hmm, that is taming another usb phy. Should it be more difficult than
> >> the otg one? I think I know what I will do the next days...
> >> 
> > 
> > I look forward to hearing of your results.
> > Meanwhile, here is a result that turned out more effective than I expected....
> > 
> > I've automated some parts of my power-usage-monitoring a bit more.  With my
> > phone running normally with USB enabled etc with my current 3.7 kernel, the
> > average-current-over-5-minutes frequency histogram looks like:
> > 
> > 23727 44
> > 25884 120
> > 28056 31
> > 30207 6
> > 32358 1
> > 36684 1
> > 51699 1
> > 75488 1
> > 
> > First number is a current in uA.  Second it the number of 5 minute periods
> > when the average was within 1mA of that number.
> > 
> > So most often I get 26mA  plus or minus 2.1mA
> > 
> > But now to my interesting result.  I noticed that the OMAP3 pins which
> > drive the internal USB were configured with PULLDOWN, even though they are
> > bi-directional pins.
> 
> Maybe the pull-down was thought as a safety measure.
> 
> I think we did discuss such an idea some time ago.
> 
> >  With the patch below which disconnects the pull-down
> > resistors
> 
> That is interesting that the kernel code is tampering with the pinmux.
> I thought that there was a rule that u-boot should take care of and there
> is no pull-down. It enables only a pullup on the HSUSB2_STP line:

I hadn't heard of that rule, but the current kernel certainly doesn't abide
by it.  There are lots of pinmux settings.  With devicetree you even get
messages at boot time for any device which doesn't have pinmux configured!

As HSUSB2_STP is configures as an output (IDIS), so any pullup will be
ignored!

> 
> http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=u-boot/board/goldelico/gta04/gta04.h;hb=HEAD

I had a look for other lines that might have unnecessary pull up/down and was
a bit perplexed by MMC1_DAT[4-7].
The GTA04 schematic says that there aren't connected and that they aren't
available on the DM3730.  The TRM seems to support this.
But linux on my GTA04A4 seems to know about MMC1_DAT[4-7] pins.  Maybe it is
a slightly different model?
Anyway this uboot file is configuring them as inputs.  The TRM seems to
suggest that outputs is better for power usage when pins are unused.
The "INPUT-ENABLE" but powers on an amplifier for the incoming signal.  So
keeping INPUT-ENABLE off should save a tiny bit of power.

Do you know anything more about these pins than I do?

I tried removing all the pull up from the MMC pins and the device still
worked but power consumption was much worse !

Also - the TRM says  that MMC clock needs to be configured as inputs via
PAD_CONF (so sort of loop back thing that I don't understand).  Linux does
configure it that way, but uboot does only for MMC2, not for MMC1.

I find this all quite esoteric.  Some strange rules and some strange results
from changing things.

But it gives me some new things to play with :-)

NeilBrown

-------------- 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/20131111/ef34031c/attachment.bin>


More information about the Gta04-owner mailing list