Serial port RTPM/Suspend issues

Serial port RTPM/Suspend issues

[Bastian Hecht]

Hi,

when going to suspend-to-mem on my Armadillo board with runtime power
management enabled my serial line outputs garbage.
I found 3 ways to make it work:
 - use the bootarg no_console_suspend
 - add the flag CLK_ENABLE_ON_INIT to the SCIF.1 clock in
mach-shmobile/clock-r8a7740.c
 - remove the power domain association to A3SP in mach-shmobile/setup-r8a7740.c

The obvious difference I can observe is that without any of these
methods, the clocks are halted dynamically before shutdown and
reenabled before serial_console_write() is used.
I tried to skip the stopping of the sci.1 MSTP bit in
drivers/sh/clk/cpg.c to simulate the working behaviour but without
success.
During resume I verified that sh_clk_mstp_enable() is called before
serial_console_write() is used. Furter I check the MSTP bit before
each write or read. I played around with adding a udelay(100) after
enabling the clocks. No success.
The A3SP power domain is not shut down during this process (.gov
     = &pm_domain_always_on_gov).

This all looks like the solution lies on a silver plate, but I can't see it.

Any quick hints?

I tested on Simon's topic/all+next branch with the armadillo defconfig.

Cheers,

 Bastian

Re: Serial port RTPM/Suspend issues

[Bastian Hecht]

> Hi,
>
> when going to suspend-to-mem on my Armadillo board with runtime power
> management enabled my serial line outputs garbage.
> I found 3 ways to make it work:
>  - use the bootarg no_console_suspend
>  - add the flag CLK_ENABLE_ON_INIT to the SCIF.1 clock in
> mach-shmobile/clock-r8a7740.c
>  - remove the power domain association to A3SP in mach-shmobile/setup-r8a7740.c
>
> The obvious difference I can observe is that without any of these
> methods, the clocks are halted dynamically before shutdown and
> reenabled before serial_console_write() is used.
> I tried to skip the stopping of the sci.1 MSTP bit in
> drivers/sh/clk/cpg.c to simulate the working behaviour but without
> success.
> During resume I verified that sh_clk_mstp_enable() is called before
> serial_console_write() is used. Furter I check the MSTP bit before
> each write or read. I played around with adding a udelay(100) after
> enabling the clocks. No success.
> The A3SP power domain is not shut down during this process (.gov
>      = &pm_domain_always_on_gov).
>
> This all looks like the solution lies on a silver plate, but I can't see it.
>
> Any quick hints?
>
> I tested on Simon's topic/all+next branch with the armadillo defconfig.
>
> Cheers,
>
>  Bastian

To avoid confusion, let me add: Garbage is produced when waking, not
in the shutdown process.

Re: Serial port RTPM/Suspend issues

[Paul Mundt]

On Tue, Mar 12, 2013 at 03:50:42PM +0100, Bastian Hecht wrote:
> To avoid confusion, let me add: Garbage is produced when waking, not
> in the shutdown process.

I assume this is just data left in the FIFO that hasn't been drained that
comes back in an undefined state due to losing the clock?

Re: Serial port RTPM/Suspend issues

[Bastian Hecht]

2013/3/12 Paul Mundt <lethal@linux-sh.org>:
> On Tue, Mar 12, 2013 at 03:50:42PM +0100, Bastian Hecht wrote:
>> To avoid confusion, let me add: Garbage is produced when waking, not
>> in the shutdown process.
>
> I assume this is just data left in the FIFO that hasn't been drained that
> comes back in an undefined state due to losing the clock?

The port hangs after printing a couple of dozens of characters. The
system itself seems stable - I can log into it using ssh.
Does this fit with your theory?

By the way I am using a shallow sleep to test it. Just cpu_do_idle().

Re: Serial port RTPM/Suspend issues

[Paul Mundt]

On Tue, Mar 12, 2013 at 04:31:57PM +0100, Bastian Hecht wrote:
> 2013/3/12 Paul Mundt <lethal@linux-sh.org>:
> > On Tue, Mar 12, 2013 at 03:50:42PM +0100, Bastian Hecht wrote:
> >> To avoid confusion, let me add: Garbage is produced when waking, not
> >> in the shutdown process.
> >
> > I assume this is just data left in the FIFO that hasn't been drained that
> > comes back in an undefined state due to losing the clock?
> 
> The port hangs after printing a couple of dozens of characters. The
> system itself seems stable - I can log into it using ssh.
> Does this fit with your theory?
> 
There are two theories really, residual FIFO data or baud rate generation
issues. Your dozens of characters thing seems to support the former,
given the FIFO size -- the latter would more likely generate a lot more
spew.

> By the way I am using a shallow sleep to test it. Just cpu_do_idle().

Can you see how it goes booting with nohlt? We have seen issues between
BL bit and sleep interactivity before.

Re: Serial port RTPM/Suspend issues

[Bastian Hecht]

Hi Paul,

2013/3/12 Paul Mundt <lethal@linux-sh.org>:
> On Tue, Mar 12, 2013 at 04:31:57PM +0100, Bastian Hecht wrote:
>> 2013/3/12 Paul Mundt <lethal@linux-sh.org>:
>> > On Tue, Mar 12, 2013 at 03:50:42PM +0100, Bastian Hecht wrote:
>> >> To avoid confusion, let me add: Garbage is produced when waking, not
>> >> in the shutdown process.
>> >
>> > I assume this is just data left in the FIFO that hasn't been drained that
>> > comes back in an undefined state due to losing the clock?
>>
>> The port hangs after printing a couple of dozens of characters. The
>> system itself seems stable - I can log into it using ssh.
>> Does this fit with your theory?
>>
> There are two theories really, residual FIFO data or baud rate generation
> issues. Your dozens of characters thing seems to support the former,
> given the FIFO size -- the latter would more likely generate a lot more
> spew.

Ok I dumped the output into a file and realized that the garbage is
just one line but this contains 7343 characters - so a bit more than a
couple of dozens.

>> By the way I am using a shallow sleep to test it. Just cpu_do_idle().
>
> Can you see how it goes booting with nohlt? We have seen issues between
> BL bit and sleep interactivity before.

nohlt didn't improve things.

Re: Serial port RTPM/Suspend issues

[Bastian Hecht]

2013/3/13 Bastian Hecht <hechtb@gmail.com>:
> Hi Paul,
>
> 2013/3/12 Paul Mundt <lethal@linux-sh.org>:
>> On Tue, Mar 12, 2013 at 04:31:57PM +0100, Bastian Hecht wrote:
>>> 2013/3/12 Paul Mundt <lethal@linux-sh.org>:
>>> > On Tue, Mar 12, 2013 at 03:50:42PM +0100, Bastian Hecht wrote:
>>> >> To avoid confusion, let me add: Garbage is produced when waking, not
>>> >> in the shutdown process.
>>> >
>>> > I assume this is just data left in the FIFO that hasn't been drained that
>>> > comes back in an undefined state due to losing the clock?
>>>
>>> The port hangs after printing a couple of dozens of characters. The
>>> system itself seems stable - I can log into it using ssh.
>>> Does this fit with your theory?
>>>
>> There are two theories really, residual FIFO data or baud rate generation
>> issues. Your dozens of characters thing seems to support the former,
>> given the FIFO size -- the latter would more likely generate a lot more
>> spew.
>
> Ok I dumped the output into a file and realized that the garbage is
> just one line but this contains 7343 characters - so a bit more than a
> couple of dozens.
>
>>> By the way I am using a shallow sleep to test it. Just cpu_do_idle().
>>
>> Can you see how it goes booting with nohlt? We have seen issues between
>> BL bit and sleep interactivity before.
>
> nohlt didn't improve things.

Ok I found out that the SUB clock gets turned off when all depending
devices are off. And skipping the shut down of the SUB clock let's the
sci.1 survive.