[Gta04-owner] Modem off

Dr. H. Nikolaus Schaller hns at goldelico.com
Tue Nov 12 21:23:23 CET 2013

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.

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

> 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.

> 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).

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

Yes, quite a mess.

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



More information about the Gta04-owner mailing list