From patchwork Thu Mar 20 23:47:52 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 26783 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pb0-f72.google.com (mail-pb0-f72.google.com [209.85.160.72]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 2C740202E0 for ; Thu, 20 Mar 2014 23:50:16 +0000 (UTC) Received: by mail-pb0-f72.google.com with SMTP id jt11sf4044206pbb.3 for ; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :reply-to:mime-version:content-type:content-disposition:user-agent :sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe; bh=PDZpixo/qLGOsFf9y5ClHImfDr9Fod6UUuwAPZDhWRE=; b=HPkZWwYEag2g5rZ9Nl1CsvZbHxhLEWKi0kFLTGce/IRsTh5LWC56qhS9JJ4jrvXe5V xIvslKjf6jrBYqfidByD6hI7Sz9WBeo4hiw+O9UsRTs0+lvoh/U0pnBcviukXCgSoJSV gElnkcUGuO9oiMkNAOltgXeAd4iGDUvrt15EryLwl1jy0yr8mMzY8CjuWmoXvT4f6W22 yeO9VyQgxEtsjbl3j7qvI/LJW+cFIMeZiB+XaZ3ofADDNt0Fc+BbLYOuo33ELl2MOWgv KgJoOpMR3jgF7Oql5ddGzuzpMOX2Y+R7TxoW6Xf/Gi6rxzyz2pDYz6OmOUGd51F36+Mu CxHw== X-Gm-Message-State: ALoCoQmM6df/Ly+nmxJkUiStgIax1WDF86jGwGl72VYd5IHv9uGZbzJdp759N6LkZ2qKYgraxdXi X-Received: by 10.66.121.136 with SMTP id lk8mr18044496pab.34.1395359415407; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.91.120 with SMTP id y111ls461508qgd.0.gmail; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) X-Received: by 10.220.133.80 with SMTP id e16mr35673516vct.13.1395359415242; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx.google.com with ESMTPS id yv5si773345veb.26.2014.03.20.16.50.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 16:50:15 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.169 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.220.169; Received: by mail-vc0-f169.google.com with SMTP id ik5so1856082vcb.14 for ; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) X-Received: by 10.58.162.168 with SMTP id yb8mr14870379veb.9.1395359415112; Thu, 20 Mar 2014 16:50:15 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.78.9 with SMTP id i9csp426992vck; Thu, 20 Mar 2014 16:50:14 -0700 (PDT) X-Received: by 10.68.254.5 with SMTP id ae5mr50683787pbd.83.1395359413531; Thu, 20 Mar 2014 16:50:13 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id si7si2388028pbc.441.2014.03.20.16.50.13; Thu, 20 Mar 2014 16:50:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-serial-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759697AbaCTXuM (ORCPT + 2 others); Thu, 20 Mar 2014 19:50:12 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:40686 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759695AbaCTXuL (ORCPT ); Thu, 20 Mar 2014 19:50:11 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id s2KNndnj002027; Thu, 20 Mar 2014 18:49:39 -0500 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id s2KNndup004258; Thu, 20 Mar 2014 18:49:39 -0500 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.174.1; Thu, 20 Mar 2014 18:49:39 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id s2KNnckP006626; Thu, 20 Mar 2014 18:49:39 -0500 Date: Thu, 20 Mar 2014 18:47:52 -0500 From: Felipe Balbi To: Russell King CC: Linux Kernel Mailing List , , Linux ARM Kernel Mailing List , Greg KH , Muralidharan Karicheri Subject: UART 8250 and HW Flow Control Message-ID: <20140320234752.GA26964@saruman.home> Reply-To: MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-serial-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-serial@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: balbi@ti.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.220.169 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , Hi Russell, long ago you wrote a patch (see below) which converted TI16C750 flow control quirk into a capability flag followed by a fifosize check. I've tried to fully understand the rationale behind that commit and, specifically why 32 bytes. If I understood correctly the problem is that RTS goes low as soon as FIFO Trigger Level is reached which means that if the far end isn't fast enough, it might miss our Request To Send. But then, this causes a problem for UARTs with small FIFOs. I mean, if the far end _does_ use auto-CTS, then we could enable auto-RTS in our side, but that commit prevents that unless we patch that check. Right now we're dealing with a use case which is using a BT device over UART at 3Mbaud and the UART on the SoC has 16 bytes of FIFO (it's a 16550a compatible UART). Our first (quickest, dirtiest, crappiest) option is to just change 32 into 16 get it over with. HW Flow Control gets enabled and everybody is happy, soon after that "what ifs" started to pop :-) I wonder if a better (albeit with impact to performance, probably) approach would be to patch tty_{un,}throttle() so that we don't write an ammount >= FIFO_TRIGGER_LEVEL in affected UARTs, but that doesn't sound very nice either, or does it ? Do you have any extra insider's information about the reason for that patch and/or any suggestions on how to patch it in a better way ? I know it's an old commit (took it from historic Linux tree) but worth asking anyway. commit 1ad14ded82602e3753c724ce4647b44faf4dc658 Author: Russell King Date: Tue Oct 19 16:37:05 2004 +0100 [SERIAL] Convert TI16C750 flow control into a port capability. Add UART_CAP_AFE, and use this to enable TI16C750 flow control, but only if we have 32 bytes or more of FIFO. diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 6e2e62d..7e63a7f 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -210,7 +210,7 @@ static const struct serial8250_config uart_config[] = { .tx_loadsz = 64, .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 | UART_FCR7_64BYTE, - .flags = UART_CAP_FIFO | UART_CAP_SLEEP, + .flags = UART_CAP_FIFO | UART_CAP_SLEEP | UART_CAP_AFE, }, [PORT_STARTECH] = { .name = "Startech", @@ -1584,11 +1584,14 @@ serial8250_set_termios(struct uart_port *port, struct termios *termios, } /* - * TI16C750: hardware flow control and 64 byte FIFOs. When AFE is - * enabled, RTS will be deasserted when the receive FIFO contains - * more characters than the trigger, or the MCR RTS bit is cleared. + * MCR-based auto flow control. When AFE is enabled, RTS will be + * deasserted when the receive FIFO contains more characters than + * the trigger, or the MCR RTS bit is cleared. In the case where + * the remote UART is not using CTS auto flow control, we must + * have sufficient FIFO entries for the latency of the remote + * UART to respond. IOW, at least 32 bytes of FIFO. */ - if (up->port.type == PORT_16750) { + if (up->capabilities & UART_CAP_AFE && up->port.fifosize >= 32) { up->mcr &= ~UART_MCR_AFE; if (termios->c_cflag & CRTSCTS) up->mcr |= UART_MCR_AFE; diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h index bbf767d..dcf5859 100644 --- a/drivers/serial/8250.h +++ b/drivers/serial/8250.h @@ -47,6 +47,7 @@ struct serial8250_config { #define UART_CAP_FIFO (1 << 8) /* UART has FIFO */ #define UART_CAP_EFR (1 << 9) /* UART has EFR */ #define UART_CAP_SLEEP (1 << 10) /* UART has IER sleep */ +#define UART_CAP_AFE (1 << 11) /* MCR-based hw flow control */ #undef SERIAL_DEBUG_PCI