Re: [PATCH v2] serial: omap: Add support for optional wake-up

[Kevin Hilman <khilman@linaro.org>]

Tony Lindgren <tony@atomide.com> writes:

> With the recent pinctrl-single changes, omaps can treat
> wake-up events from deeper idle states as interrupts.
>
> There's a separate "io chain" controller on most omaps
> that stays enabled when the device hits off-idle and the
> regular interrupt controller is powered off.
>
> Let's add support for the optional second interrupt for
> wake-up events. And then serial-omap can manage the
> wake-up interrupt from it's runtime PM calls to avoid
> spurious interrupts during runtime.
>
> Note that the wake interrupt is board specific as it
> uses the UART RX pin, and for omap3, there are six pin
> options for UART3 RX pin.
>
> Also Note that the legacy platform based booting handles
> the wake-ups in the legacy mux driver and does not need to
> pass the wake-up interrupt to the driver.
>
> And finally, to pass the wake-up interrupt in the dts file,
> either interrupt-map or the pending interrupts-extended
> property needs to be passed. It's probably best to use
> interrupts-extended when it's available.
>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> Reviewed-by: Roger Quadros <rogerq@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> ---
>
> Updated to simplify based on the review comments.
>
> Greg, care to queue this for v3.13 if not too late?
>
> This removes a dependency for omaps for having runtime
> PM working with serial port using device tree, so we
> can start moving to device tree only booting for omap3
> for v3.14.

A bunch of DT boot failures on OMAP3 platforms with latest mainline were
bisected down to this patch.  Boot results here:
http://lists.linaro.org/pipermail/kernel-build-reports/2013-November/000954.html

This doesn't seem to properly handle the OMAP3 case where we have DT
nodes, but no reg or interrupts properties since they're still using
hwmod.

The problems seems to be because these OMAP3 platforms don't list any
interrupts in their DTS files for the UARTs, but a quick hack at adding
interrupts to omap3.dtsi didn't help either so something else is going
on.

This patch should probably be reverted until it gets broader testing.

Kevin