From patchwork Fri Sep 21 17:59:59 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 1492911 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id C79E93FCFC for ; Fri, 21 Sep 2012 18:37:39 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TF84o-00041d-DI; Fri, 21 Sep 2012 18:35:46 +0000 Received: from eu1sys200aog104.obsmtp.com ([207.126.144.117]) by merlin.infradead.org with smtps (Exim 4.76 #1 (Red Hat Linux)) id 1TF84j-0003zT-3u for linux-arm-kernel@lists.infradead.org; Fri, 21 Sep 2012 18:35:42 +0000 Received: from beta.dmz-eu.st.com ([164.129.1.35]) (using TLSv1) by eu1sys200aob104.postini.com ([207.126.147.11]) with SMTP ID DSNKUFyzcgboZ/Tte8yZ5g0CldWgGzjDP7Rv@postini.com; Fri, 21 Sep 2012 18:35:40 UTC Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 71B92212; Fri, 21 Sep 2012 18:00:11 +0000 (GMT) Received: from relay1.stm.gmessaging.net (unknown [10.230.100.17]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DE0A14EDA; Fri, 21 Sep 2012 18:00:10 +0000 (GMT) Received: from exdcvycastm003.EQ1STM.local (alteon-source-exch [10.230.100.61]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exdcvycastm003", Issuer "exdcvycastm003" (not verified)) by relay1.stm.gmessaging.net (Postfix) with ESMTPS id 3CF6924C2C0; Fri, 21 Sep 2012 20:00:01 +0200 (CEST) Received: from steludxu4075.lud.stericsson.com (10.230.100.153) by smtp.stericsson.com (10.230.100.1) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 21 Sep 2012 20:00:10 +0200 From: Linus Walleij To: , Greg Kroah-Hartman , Russell King , Alan Cox Subject: [PATCH] RFC: serial: pl011: allow very high baudrates Date: Fri, 21 Sep 2012 19:59:59 +0200 Message-ID: <1348250399-5651-1-git-send-email-linus.walleij@stericsson.com> X-Mailer: git-send-email 1.7.11.3 MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -4.2 (----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-4.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium trust [207.126.144.117 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Linus Walleij , Guillaume Jaunet , Par-Gunnar Hjalmdahl , Anmar Oueja , Matthias Locher , Rajanikanth HV , Christophe Arnal , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org From: Linus Walleij The ST Microelectronics variant of the PL011 is capable of supporting very high non-standard baud rates, even above 4 Mbps. Mostly this works, but when we try to use 4050000 baud, the code in tty_termios_encode_baud_rate(), which is called from uart_get_baud_rate() will do some fuzzy matching and "snap" the baudrate to 4000000 baud, which happens to be in the baud_table[]. However there is an encouraging comment from Alan Cox above the tty_termios_input_baud_rate() function stating that device drivers should use ->c_[io]speed directly as they are updated. I tried this, but that requires the driver to handle a few odd cases such as when the ->c_ispeed and ->c_ospeed differs, or when they are both send it as 0 (which happens a lot in the kernel) so that would require pushing a lot of duplicate code into the driver to get the same behaviour. Here I take a middle-ground approach: if the baud rate of ->c_ispeed and ->c_ospeed differs, or if either of them is zero, I still call the uart_get_baud_rate() function, but root the baudrate to what the block can handle at max. Cc: Par-Gunnar Hjalmdahl Signed-off-by: Guillaume Jaunet Signed-off-by: Christophe Arnal Signed-off-by: Matthias Locher Signed-off-by: Rajanikanth HV Signed-off-by: Linus Walleij --- After discussing with Alan and Russell I still don't feel this is the right solution, but it demonstrates Russell's point of how intelligence (here just some checking of ->c_[io]speed, but you get the point) is moved out of the serial/tty core and out into the drivers if we do this. Maybe a new function is needed in the serial core, one that will just call out to serial and tty like this if the c_[io]speed differs or either is zero? --- drivers/tty/serial/amba-pl011.c | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index cb9f694..778a6a5 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -1492,18 +1492,36 @@ pl011_set_termios(struct uart_port *port, struct ktermios *termios, struct uart_amba_port *uap = (struct uart_amba_port *)port; unsigned int lcr_h, old_cr; unsigned long flags; - unsigned int baud, quot, clkdiv; + unsigned int max_baud, baud, quot; if (uap->vendor->oversampling) - clkdiv = 8; + max_baud = port->uartclk / 8; else - clkdiv = 16; + max_baud = port->uartclk / 16; /* - * Ask the core to calculate the divisor for us. + * For "zero" speeds or in the case where in and output + * speed differs, fall back on using the serial core to + * determine applicable baudrate. */ - baud = uart_get_baud_rate(port, termios, old, 0, - port->uartclk / clkdiv); + if ((termios->c_ispeed != termios->c_ospeed) || + (termios->c_ispeed == 0) || + (termios->c_ospeed == 0)) + baud = uart_get_baud_rate(port, termios, old, 0, + max_baud); + else { + /* + * Else we just use the requested speed from + * termios. But we sanity check it so as not to + * exceed hardware limits. + */ + baud = termios->c_ospeed; + if (baud > max_baud) + baud = max_baud; + } + dev_dbg(uap->port.dev, "c_ispeed: %u, c_ospeed: %u, " + "max_baud: %u, resulting baud rate %u bps\n", + termios->c_ispeed, termios->c_ospeed, max_baud, baud); if (baud > port->uartclk/16) quot = DIV_ROUND_CLOSEST(port->uartclk * 8, baud);