Broken UART I/O wakeups on v3.4-rc4+

Broken UART I/O wakeups on v3.4-rc4+

[Paul Walmsley]

Govindraj,

After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+: 
UART: Fix incorrect population of default uart pads"), the kernel does not 
return from static suspend when off-mode is enabled upon an incoming 
serial character.

The following steps reproduce the problem:

echo 1 > /debug/pm_debug/enable_off_mode
echo mem > /sys/power/state
(send a serial character after suspend is entered)

(N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to 
wake the system at this point.)

Could you please fix this?  We probably aren't too far from the v3.5 merge 
window opening, so there isn't much time to fix it.


thanks

- Paul

Broken UART I/O wakeups on v3.4-rc4+

[Paul Walmsley]

Govindraj,

After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+: 
UART: Fix incorrect population of default uart pads"), the kernel does not 
return from static suspend when off-mode is enabled upon an incoming 
serial character.

The following steps reproduce the problem:

echo 1 > /debug/pm_debug/enable_off_mode
echo mem > /sys/power/state
(send a serial character after suspend is entered)

(N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to 
wake the system at this point.)

Could you please fix this?  We probably aren't too far from the v3.5 merge 
window opening, so there isn't much time to fix it.


thanks

- Paul

Re: Broken UART I/O wakeups on v3.4-rc4+

[Raja, Govindraj]

On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Govindraj,
>
> After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+:
> UART: Fix incorrect population of default uart pads"), the kernel does not
> return from static suspend when off-mode is enabled upon an incoming
> serial character.
>
> The following steps reproduce the problem:
>
> echo 1 > /debug/pm_debug/enable_off_mode
> echo mem > /sys/power/state
> (send a serial character after suspend is entered)
>
> (N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to
> wake the system at this point.)
>

The same is discussed in this thread as in here:
http://www.spinics.net/lists/linux-omap/msg68659.html

> Could you please fix this?  We probably aren't too far from the v3.5 merge
> window opening, so there isn't much time to fix it.

okay, one possible solution is to probe pins dynamically
and make rx wakeup capable which myself and Tony
discussed and came up with this patch [1]

or to add rx wakeup pad support for each board,
based on uart used as console.

--
Thanks,
Govindraj.R

[1]: http://www.spinics.net/lists/linux-omap/msg67822.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Broken UART I/O wakeups on v3.4-rc4+

[Raja, Govindraj]

On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Govindraj,
>
> After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+:
> UART: Fix incorrect population of default uart pads"), the kernel does not
> return from static suspend when off-mode is enabled upon an incoming
> serial character.
>
> The following steps reproduce the problem:
>
> echo 1 > /debug/pm_debug/enable_off_mode
> echo mem > /sys/power/state
> (send a serial character after suspend is entered)
>
> (N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to
> wake the system at this point.)
>

The same is discussed in this thread as in here:
http://www.spinics.net/lists/linux-omap/msg68659.html

> Could you please fix this? ?We probably aren't too far from the v3.5 merge
> window opening, so there isn't much time to fix it.

okay, one possible solution is to probe pins dynamically
and make rx wakeup capable which myself and Tony
discussed and came up with this patch [1]

or to add rx wakeup pad support for each board,
based on uart used as console.

--
Thanks,
Govindraj.R

[1]: http://www.spinics.net/lists/linux-omap/msg67822.html

Re: Broken UART I/O wakeups on v3.4-rc4+

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 898 bytes --]

On Tue, 8 May 2012, Raja, Govindraj wrote:

> On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> >
>
> The same is discussed in this thread as in here: 
> http://www.spinics.net/lists/linux-omap/msg68659.html

OK.

> > Could you please fix this?  We probably aren't too far from the v3.5 merge
> > window opening, so there isn't much time to fix it.
> 
> okay, one possible solution is to probe pins dynamically
> and make rx wakeup capable which myself and Tony
> discussed and came up with this patch [1]
> 
> or to add rx wakeup pad support for each board,
> based on uart used as console.

Oh well, sounds like UART I/O wakeups are going to be broken in v3.4 :-(

Do you have a patch ready for Tony to queue for v3.5 to fix this?  From 
the above thread, it looks like Tony had some remaining comments to be 
addressed on your patch.


- Paul

Broken UART I/O wakeups on v3.4-rc4+

[Paul Walmsley]

On Tue, 8 May 2012, Raja, Govindraj wrote:

> On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> >
>
> The same is discussed in this thread as in here: 
> http://www.spinics.net/lists/linux-omap/msg68659.html

OK.

> > Could you please fix this? ?We probably aren't too far from the v3.5 merge
> > window opening, so there isn't much time to fix it.
> 
> okay, one possible solution is to probe pins dynamically
> and make rx wakeup capable which myself and Tony
> discussed and came up with this patch [1]
> 
> or to add rx wakeup pad support for each board,
> based on uart used as console.

Oh well, sounds like UART I/O wakeups are going to be broken in v3.4 :-(

Do you have a patch ready for Tony to queue for v3.5 to fix this?  From 
the above thread, it looks like Tony had some remaining comments to be 
addressed on your patch.


- Paul

Re: Broken UART I/O wakeups on v3.4-rc4+

[Tony Lindgren]

* Raja, Govindraj <govindraj.raja@ti.com> [120508 02:17]:
> On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Govindraj,
> >
> > After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+:
> > UART: Fix incorrect population of default uart pads"), the kernel does not
> > return from static suspend when off-mode is enabled upon an incoming
> > serial character.
> >
> > The following steps reproduce the problem:
> >
> > echo 1 > /debug/pm_debug/enable_off_mode
> > echo mem > /sys/power/state
> > (send a serial character after suspend is entered)
> >
> > (N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to
> > wake the system at this point.)
> >
> 
> The same is discussed in this thread as in here:
> http://www.spinics.net/lists/linux-omap/msg68659.html
> 
> > Could you please fix this?  We probably aren't too far from the v3.5 merge
> > window opening, so there isn't much time to fix it.
> 
> okay, one possible solution is to probe pins dynamically
> and make rx wakeup capable which myself and Tony
> discussed and came up with this patch [1]

This would be good for the v3.5 merge window.
 
> or to add rx wakeup pad support for each board,
> based on uart used as console.

This should be still done too to avoid bootloader dependency
for setting up the serial ports.

Regards,

Tony
 
> [1]: http://www.spinics.net/lists/linux-omap/msg67822.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Broken UART I/O wakeups on v3.4-rc4+

[Tony Lindgren]

* Raja, Govindraj <govindraj.raja@ti.com> [120508 02:17]:
> On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >
> > Govindraj,
> >
> > After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 ("ARM: OMAP2+:
> > UART: Fix incorrect population of default uart pads"), the kernel does not
> > return from static suspend when off-mode is enabled upon an incoming
> > serial character.
> >
> > The following steps reproduce the problem:
> >
> > echo 1 > /debug/pm_debug/enable_off_mode
> > echo mem > /sys/power/state
> > (send a serial character after suspend is entered)
> >
> > (N.B., on the BeagleBoard, the GPIO-connected "USER" button can be used to
> > wake the system at this point.)
> >
> 
> The same is discussed in this thread as in here:
> http://www.spinics.net/lists/linux-omap/msg68659.html
> 
> > Could you please fix this? ?We probably aren't too far from the v3.5 merge
> > window opening, so there isn't much time to fix it.
> 
> okay, one possible solution is to probe pins dynamically
> and make rx wakeup capable which myself and Tony
> discussed and came up with this patch [1]

This would be good for the v3.5 merge window.
 
> or to add rx wakeup pad support for each board,
> based on uart used as console.

This should be still done too to avoid bootloader dependency
for setting up the serial ports.

Regards,

Tony
 
> [1]: http://www.spinics.net/lists/linux-omap/msg67822.html