[Letux-kernel] uart / w1 woes

[Andreas Kemnade]

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.
First check why the uarts do not suspend without users per default like everything
else does.

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

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180924/c8eaec3f/attachment.asc>