Re: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Govindraj.R [120511 02:45]:
> From: "Govindraj.R"
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> #else
> -static void omap_serial_fill_default_pads(struct omap_board_data *bdata) {}
> +static void __init omap_serial_check_wakeup(struct omap_board_data *bdata
> + struct omap_uart_state *uart) {}
> #endif
There's a comma missing here that breaks CONFIG_OMAP_MUX is not set here ^^^.
I've updated the patch to add it.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Kevin Hilman [120523 16:15]: > "Govindraj.R" writes: > > > From: "Govindraj.R" > > > > The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of > > default uart pads) removed default uart pads that where getting populated > > and which was making rx pin wakeup capable. If uart pads were used in > > different mode by any other module then it would fail since the default > > pads took over all the uart pins forcefully. With removal of default pads > > the rx_pad wakeup for console uart while waking up from off mode is broken. > > > > Utilise the mux api available to probe the availability of mux pins > > in uart mode and probe for availability of uart pin in mux mode0 > > if uart is available as uart pin itself then configure rx pin > > as wakeup capable. > > > > This patch itself doesn't cater to all boards. Boards using uart rx wakeup > > mechanism should ensure the usage of omap_serial_init_port by configuring > > required uart ports and pass necessary mux data, till then this probing of > > uart pins can cater to enabling of rx pad wakeup to most of the boards. > > > > This patch can also throw some boot warning from _omap_mux_get_by_name > > if pin is requested for availability is not present while dynamically > > probing > > the uart pins availability such boot warnings can be addressed only when > > board > > files are patched with omap_serial_init_port calls passing the right pads > > needed for a given port. > > > > Discussion Threads for reference: > > http://www.spinics.net/lists/linux-omap/msg69859.html > > http://www.spinics.net/lists/linux-omap/msg68659.html > > > > Cc: Felipe Balbi > > Cc: Kevin Hilman > > Cc: Russ Dill > > Cc: Tony Lindgren > > Cc: Paul Walmsley > > Cc: Ameya Palande > > Signed-off-by: Govindraj.R > > Tony, it's up to you if you're OK with this mux interface, but I can at > least confirm that this gets runtime PM + UART wakeups working again on > the boards I tried: 3530/Overo, 3430/n900, 3530/OMAP3EVM. OK good to hear. Patch looks good to me, applying into fixes branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
"Govindraj.R" writes: > From: "Govindraj.R" > > The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of > default uart pads) removed default uart pads that where getting populated > and which was making rx pin wakeup capable. If uart pads were used in > different mode by any other module then it would fail since the default > pads took over all the uart pins forcefully. With removal of default pads > the rx_pad wakeup for console uart while waking up from off mode is broken. > > Utilise the mux api available to probe the availability of mux pins > in uart mode and probe for availability of uart pin in mux mode0 > if uart is available as uart pin itself then configure rx pin > as wakeup capable. > > This patch itself doesn't cater to all boards. Boards using uart rx wakeup > mechanism should ensure the usage of omap_serial_init_port by configuring > required uart ports and pass necessary mux data, till then this probing of > uart pins can cater to enabling of rx pad wakeup to most of the boards. > > This patch can also throw some boot warning from _omap_mux_get_by_name > if pin is requested for availability is not present while dynamically probing > the uart pins availability such boot warnings can be addressed only when board > files are patched with omap_serial_init_port calls passing the right pads > needed for a given port. > > Discussion Threads for reference: > http://www.spinics.net/lists/linux-omap/msg69859.html > http://www.spinics.net/lists/linux-omap/msg68659.html > > Cc: Felipe Balbi > Cc: Kevin Hilman > Cc: Russ Dill > Cc: Tony Lindgren > Cc: Paul Walmsley > Cc: Ameya Palande > Signed-off-by: Govindraj.R Tony, it's up to you if you're OK with this mux interface, but I can at least confirm that this gets runtime PM + UART wakeups working again on the boards I tried: 3530/Overo, 3430/n900, 3530/OMAP3EVM. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
