From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup Date: Tue, 5 Jun 2012 04:08:19 -0700 Message-ID: <20120605110818.GN12766@atomide.com> References: <1336655139-8908-1-git-send-email-govindraj.raja@ti.com> <1336729242-16168-1-git-send-email-govindraj.raja@ti.com> <87likize4t.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:35276 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752951Ab2FELIW (ORCPT ); Tue, 5 Jun 2012 07:08:22 -0400 Content-Disposition: inline In-Reply-To: <87likize4t.fsf@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Kevin Hilman Cc: "Govindraj.R" , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Felipe Balbi , Russ Dill , Paul Walmsley , Ameya Palande * 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Tue, 5 Jun 2012 04:08:19 -0700 Subject: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup In-Reply-To: <87likize4t.fsf@ti.com> References: <1336655139-8908-1-git-send-email-govindraj.raja@ti.com> <1336729242-16168-1-git-send-email-govindraj.raja@ti.com> <87likize4t.fsf@ti.com> Message-ID: <20120605110818.GN12766@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * 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