[Gta04-owner] Modem off

Tue Nov 12 23:46:32 CET 2013

On Tue, 12 Nov 2013 21:23:23 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 
> Am 10.11.2013 um 23:09 schrieb NeilBrown:
> 
> > 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!
> 
> I think it came as a suggestion from TI when they started to write kernels for the
> OMAP3430 EVM and the BeagleBoard.
> 
> But that is some years ago and others may not have followed it. Not all code
> developed for OMAP3 support was accepted upstream...
> 
> So this rule may be outdated and no longer common practice.
> 
> > 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?
> 
> Well, the OMAP3530 and DM3730 are interchangeable and the kernels are universal.
> 
> So the kernel may try to support the OMAP3530 although it could know that it is running
> on a DM3730.
> 
> Generally, there are 4bit (micro-SD) cards and 8-bit cards (or eMMC with 8bit interface).
> So the MMC controller module inside the SoC knows about 8 potential bits but only 4
> are available with 1.8/3.3V level shifters and drivers. So switching to 8-bit mode will fail.
> 
> > 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.
> 
> Yes, that is a good hint.

I tried reconfiguring sdmmc1_dat[4-7] as outputs.  Power-usage went up quite
a lot.  There is clearly plenty that I still don't understand.

> 
> Or should these pins be set (or left) in Safe Mode? This essentially disables the I/O pad
> (drivers and input level detector).

That would be worth trying.

> 
> > 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 !
> 
> That is indeed unexpected. Especially because we have external hardware pull-ups.

Hmm.. There are external hardware pulls to VMMC1.
If this regulator gets turned off during suspend (which I hope it does but
would need to check) ... then I wonder what happens.

> 
> > 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.
> 
> Does it keep the config or does it explicitly disable the loopback? MMC1 is already configured
> by the BootROM or the OMAP could not boot from MMC. Therefore UBoot may just leave it
> as it was already initialized, while the kernel enforced some setting (because it does
> not know how it was booted).

The MUX table in uboot includes:

  MUX_VAL(CP(MMC1_CLK),		(IDIS | PTU | EN  | M0)) /*MMC1_CLK*/\

and

  MUX_VAL(CP(MMC2_CLK),		(IEN  | PTU | EN  | M0)) /*GPIO_130 -> MMC2_CLK*/\

so it explicitly sets both of them, one as input, one as not-input.
The kernel then over-rides this.

Thanks,
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/20131113/e0493fc7/attachment-0001.bin>