Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755878AbbGTIAm (ORCPT ); Mon, 20 Jul 2015 04:00:42 -0400 Received: from metis.ext.pengutronix.de ([92.198.50.35]:42970 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755687AbbGTIAj convert rfc822-to-8bit (ORCPT ); Mon, 20 Jul 2015 04:00:39 -0400 From: Juergen Borleis Organization: Pengutronix e.K. To: Peter Hurley Subject: Re: [PATCH v3] serial: mxs-auart: keep the AUART unit in reset state when not in use Date: Mon, 20 Jul 2015 10:04:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) Cc: linux-kernel@vger.kernel.org, Stefan Wahren , "Greg Kroah-Hartman" , Jiri Slaby , linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de References: <1437032458-8577-1-git-send-email-jbe@pengutronix.de> <55A8FEAE.9010502@hurleysoftware.com> In-Reply-To: <55A8FEAE.9010502@hurleysoftware.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <201507201004.02646.jbe@pengutronix.de> X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: jbe@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4882 Lines: 131 Hi Peter, On Friday 17 July 2015 15:10:06 Peter Hurley wrote: > On 07/16/2015 03:40 AM, Juergen Borleis wrote: > > Whenever the UART device driver gets closed from userland, the driver > > disables the UART unit and then stops its clock to save power. > > > > The bit which disabled the UART unit is described as: > > > > "UART Enable. If this bit is set to 1, the UART is enabled. Data > > transmission and reception occurs for the UART signals. When the > > UART is disabled in the middle of transmission or reception, it > > completes the current character before stopping." > > > > The important part is the "it completes the current character". Whenever > > a reception is ongoing when the UART gets disabled (including the clock > > off) the statemachine freezes and "remembers" this state on the next > > open() and re-enabling of the unit's clock. > > > > In this case we end up receiving an additional bogus character > > immediately. > > > > The solution in this change is to move the AUART unit into its reset > > state on close() and only release it from its reset state on the next > > open(). > > > > Signed-off-by: Juergen Borleis > > --- > > > > Notes: > > v3: > > - missing newline added to an error message > > > > v2: > > - rename mxs_auart_do_reset() to mxs_auart_keep_reset() to better > > reflect what it really does > > - adapt the delay in mxs_auart_keep_reset() to wait for the reset of > > the AURAT unit to what is used in mxs_auart_reset() > > The function names and semantics are not clear. See below. > > > - typo fixed > > > > drivers/tty/serial/mxs-auart.c | 38 > > ++++++++++++++++++++++++++++++-------- 1 file changed, 30 insertions(+), > > 8 deletions(-) > > > > diff --git a/drivers/tty/serial/mxs-auart.c > > b/drivers/tty/serial/mxs-auart.c index 13cf773..135ee6c 100644 > > --- a/drivers/tty/serial/mxs-auart.c > > +++ b/drivers/tty/serial/mxs-auart.c > > @@ -858,6 +858,30 @@ static void mxs_auart_reset(struct uart_port *u) > > writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_CLR); > > } > > > > +static void mxs_auart_keep_reset(struct uart_port *u) > > +{ > > + int i; > > + u32 reg; > > + > > + reg = readl(u->membase + AUART_CTRL0); > > + /* if already in reset state, keep it untouched */ > > + if (reg & AUART_CTRL0_SFTRST) > > + return; > > + > > + writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_CLR); > > + writel(AUART_CTRL0_SFTRST, u->membase + AUART_CTRL0_SET); > > + > > + for (i = 0; i < 10000; i++) { > > + reg = readl(u->membase + AUART_CTRL0); > > + /* reset is finished when the clock is gated */ > > + if (reg & AUART_CTRL0_CLKGATE) > > + return; > > + udelay(3); > > + } > > + > > + dev_err(u->dev, "Failed to reset the unit.\n"); > > +} > > + > > static int mxs_auart_startup(struct uart_port *u) > > { > > int ret; > > @@ -867,7 +891,10 @@ static int mxs_auart_startup(struct uart_port *u) > > if (ret) > > return ret; > > > > - writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_CLR); > > + /* reset the unit if not aleady done */ > > + mxs_auart_keep_reset(u); > > Why is this performing a soft-reset on open now? Didn't > mxs_auart_shutdown() already leave it in this state? The probe function let the device left without reset. That is why I do a reset here (which is skipped if the device is already in reset state). > Because if you're performing a soft-reset deliberately as part of the > initial condition, you make no mention of that in the changelog. If I switch the device into the reset state immediately after the probe function has finished, I could skip this additional reset. > > + /* bring it out of reset now */ > > + mxs_auart_reset(u); > > mxs_auart_reset() is really not resetting but simply performing a block > enable. Isn't there a generic block enable for the iMX.2x SoCs? (Maybe > there should be) > > The names of these functions don't match expected operations of startup(). > Start up should be enabling the device, not keeping it in reset. > > And "keep reset" immediately followed by "reset" makes no sense. mxs_auart_reset() is a bad name from the beginning. But I just wanted to keep this change small and only change things that are really required. I will try with a V4. Regards, Juergen -- Pengutronix e.K.                              | Juergen Borleis             | Linux Solutions for Science and Industry      | Phone: +49-5121-206917-5128 | Peiner Str. 6-8, 31137 Hildesheim, Germany    | Fax:   +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/