[Gta04-owner] Modem off

[Dr. H. Nikolaus Schaller]

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:

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

> I get
> 
> 17259 1
> 19401 9
> 21599 13
> 23722 3
> 25886 5
> 34520 1
> 36626 2
> 73162 1
> 
> (over a shorter time period) which shows a mean over 4mA less.  That is a 16%
> improvement in battery life!

Great. 

> 
> I wonder if there are more of these to find...

Yes, there may be more. We should 'fgrep -R omap_mux_init_signal *'

> 
> NeilBrown
> 
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index 3c434498e12e..060d0bc109da 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -107,24 +107,24 @@ static void __init setup_ehci_io_mux(const enum usbhs_omap_port_mode *port_mode)
> 	case OMAP_EHCI_PORT_MODE_PHY:
> 		omap_mux_init_signal("hsusb2_stp", OMAP_PIN_OUTPUT);
> 		omap_mux_init_signal("hsusb2_clk", OMAP_PIN_OUTPUT);
> -		omap_mux_init_signal("hsusb2_dir", OMAP_PIN_INPUT_PULLDOWN);
> -		omap_mux_init_signal("hsusb2_nxt", OMAP_PIN_INPUT_PULLDOWN);
> +		omap_mux_init_signal("hsusb2_dir", OMAP_PIN_INPUT);
> +		omap_mux_init_signal("hsusb2_nxt", OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data0",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data1",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data2",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data3",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data4",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data5",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data6",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		omap_mux_init_signal("hsusb2_data7",
> -			OMAP_PIN_INPUT_PULLDOWN);
> +			OMAP_PIN_INPUT);
> 		break;
> 	case OMAP_EHCI_PORT_MODE_TLL:
> 		omap_mux_init_signal("hsusb2_tll_stp",

BR and thanks for this report!

Nikolaus