[Letux-kernel] uart / w1 woes

H. Nikolaus Schaller hns at goldelico.com
Mon Sep 24 10:55:45 CEST 2018


Hi,

> Am 24.09.2018 um 07:58 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> here is a short summary of issues I know with uarts:
> root at gta04:~# cat /sys/bus/platform/devices/4806c000.serial/power/runtime_status
> active

that is UART2 (/dev/ttyO1)

> root at gta04:~# cat /sys/bus/platform/devices/4806a000.serial/power/runtime_status
> active

and UART1 (/dev/ttyO0)?

I assume you do not have serdev configured. If you have and the w2sg driver, it
is part of its principle to keep uart1 active.

uart2 (bluetooth) may not be configured.

> 
> They are both active, without any user of them. This was discussed on linux-omap
> if I remember correctly, but I have to check the result.
> 
> not lets tell them that they should power down after 3 seconds of non-usage
> root at gta04:~# echo 3000 >/sys/bus/platform/devices/4806a000.serial/power/autosuspend_delay_ms
> root at gta04:~# echo 3000 >/sys/bus/platform/devices/4806c000.serial/power/autosuspend_delay_ms
> 
> check wether these mechanisms are actually enabled
> root at gta04:~# cat /sys/bus/platform/devices/4806a000.serial/power/control
> auto
> root at gta04:~# cat /sys/bus/platform/devices/4806c000.serial/power/control
> auto
> 
> check the result:
> root at gta04:~# cat /sys/bus/platform/devices/4806a000.serial/power/runtime_status
> suspended
> root at gta04:~# cat /sys/bus/platform/devices/4806c000.serial/power/runtime_status
> suspended
> 
> So what is the effect of this:
> We can stop the last user of the CORE_48M_FCLK,
> so it can also power down. At least that is the case with no modules loaded.

Ah, ok. No modules loaded.

> 
> If I am doing that with the other uarts as well, I can also remove some user of the PER_48M_FCLK.
> 
> So what is the effect of this:
> I have seen idle currents down to 30mA, without actual system suspend.

Ok, that would be close to the 20mA in suspend.

> And there is a side effect:
> omap_hdq stops working, so battery current reading fails.

That would be not so nice...

> Probably it does
> not declare required clocks/resources properly (also CORE_48M_FCLK but via CORE_12M_FCLK).
> 
> So I had to do a bit morecomplicated script, which includes rmmod omap_hdq and
> modprobe omap_hdq which omap_hdq also dislikes. For the removal problem of
> omap_hdq I have sumbitted a patch.
> 
> Lets hope that the patch is addressed correct. The last commit to omap_hdq
> contains things like this:
> 
>> Acked-by: Evgeniy Polyakov <zbr at ioremap.net>
>> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> 
> no Signed-off-by maintainer.

Well, Greg is chief-maintainer :)

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180924/195dcb8e/attachment.asc>


More information about the Letux-kernel mailing list