[Letux-kernel] uart / w1 woes

H. Nikolaus Schaller hns at goldelico.com
Mon Sep 24 17:55:54 CEST 2018


Hi,

> Am 24.09.2018 um 17:24 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> On Mon, 24 Sep 2018 10:55:45 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> 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)?
>> 
> yes.
> 
>> 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.
>> 
> just for couriosity: how do you achieve that? Well that is not top priority
> to check that.

There is no special code for that. To my understanding it is a side-effect of
serdev.

I think there was some discussion for the gnss subsystem using serdev.

As far as I understand keeping the serdev node permanently open is sufficient.

We can't have go it to suspend because it might not wake up fast enough and that
would break power state detection of the GPS chip.

> First check why the uarts do not suspend without users per default like everything
> else does.

Yes, that is more important.

If then the w2sg driver breaks because of unexpected runtime pm we have some more
bug to fix...

> 
>> 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 it is a bug somewhere. I guess understanding that gains valuable knowledge
> about kernel and soc structure.

it is imho part of the hwmods and the driver for ti clocks and DT.

> If I do not find it, I will report it to linux-omap
> mailinglist.
> 
>>> 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 :)
>> 
> well, of course he is. But usually everyone who forwards a patch adds a
> signed-off-by. So here the process seems a bit different.

Exceptions rule the world :)

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/cb809df3/attachment-0001.asc>


More information about the Letux-kernel mailing list