From patchwork Thu Sep 11 14:35:43 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Hurley X-Patchwork-Id: 4888471 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 06DE49F32F for ; Thu, 11 Sep 2014 14:39:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4DD9C20254 for ; Thu, 11 Sep 2014 14:38:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 34824200FE for ; Thu, 11 Sep 2014 14:38:49 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XS5Tp-0003N9-4w; Thu, 11 Sep 2014 14:36:13 +0000 Received: from mailout32.mail01.mtsvc.net ([216.70.64.70] helo=n23.mail01.mtsvc.net) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XS5Tm-0003Hy-Q9 for linux-arm-kernel@lists.infradead.org; Thu, 11 Sep 2014 14:36:11 +0000 Received: from h96-61-95-138.cntcnh.dsl.dynamic.tds.net ([96.61.95.138]:37924 helo=[192.168.1.139]) by n23.mail01.mtsvc.net with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1XS5TQ-0002Mh-21; Thu, 11 Sep 2014 10:35:48 -0400 Message-ID: <5411B33F.10405@hurleysoftware.com> Date: Thu, 11 Sep 2014 10:35:43 -0400 From: Peter Hurley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Sebastian Andrzej Siewior , Heikki Krogerus Subject: Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx References: <1410377411-26656-1-git-send-email-bigeasy@linutronix.de> <1410377411-26656-10-git-send-email-bigeasy@linutronix.de> <20140911111721.GB17476@xps8300> <54118AAB.2010205@linutronix.de> <5411967A.6090406@hurleysoftware.com> <54119AAA.9080907@linutronix.de> In-Reply-To: <54119AAA.9080907@linutronix.de> X-Authenticated-User: 990527 peter@hurleysoftware.com X-MT-ID: 8FA290C2A27252AACF65DBC4A42F3CE3735FB2A4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140911_073610_923396_96052FC2 X-CRM114-Status: GOOD ( 19.51 ) X-Spam-Score: 0.0 (/) Cc: tony@atomide.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, balbi@ti.com, linux-serial@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alan Cox X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 09/11/2014 08:50 AM, Sebastian Andrzej Siewior wrote: > On 09/11/2014 02:32 PM, Peter Hurley wrote: >> On 09/11/2014 07:42 AM, Sebastian Andrzej Siewior wrote: >>> I also need a watchdog timer for TX since it seems that on omap3 the >>> DMA engine suddenly forgets to continue with DMA… >> >> One difference I noticed between the omap driver and the 8250 driver is >> the way modem status interrupts are handled. >> >> The omap driver only checks modem status for the UART_IIR_MSI interrupt type. >> The 8250 driver checks modem status at every interrupt (other than NO_INT). >> >> I think the UART_MSR_DCTS bit always reflects that the CTS input has changed >> between reads of the MSR _even if auto CTS is on_. So perhaps the hardware >> is being stopped by uart_handle_cts_change() when auto CTS is on? > > I doubt that. What I see from a timer debug is that the TX-FIFO level > is at 0, the DMA transfer for say 1024 bytes start. > The FIFO is filled to 64bytes and refilled so it doesn't drop below 50. > At the time of the stall I see that the DMA engine has outstanding > bytes which it should transfer and the TX FIFO is empty. If hardware > flow control stops the transfer, I would expect that the DMA engine > still fills the TX-FIFO until 64 and then waits. But it doesn't. > Writing bytes into the FIFO leads to bytes beeing sent (and I see them > on the other side) but the DMA transfer is still on hold. Canceling the > DMA transfer and re-programming the remaining bytes transfers the > remaining bytes. > > The odd thing is that I only triggered it with "less file". It doesn't > happen on regular console interaction or "cat large-file". And it only > triggers on beagle board xm (omap34xx) and I wasn't able to reproduce > it on am335x or dra7. The latter shares the same DMA engine as beagle > board xm. > > I remember also that I disabled the HW/SW float control just to make > sure it is not it. Ok. I do need to find out if omap hardware sets UART_MSR_DCTS when auto CTS is on. Would you mind running the debug patch below with HW flow control on? Regards, Peter Hurley --- >% --- Subject: [DEBUG] serial: does OMAP set UART_LSR_DCTS while autoCTS is on? ** debug patch only ** Signed-off-by: Peter Hurley --- drivers/tty/serial/serial_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 5a78f69..1579a20 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -2783,6 +2783,9 @@ void uart_handle_cts_change(struct uart_port *uport, unsigned int status) uport->icount.cts++; if (tty_port_cts_enabled(port)) { + + WARN_ON_ONCE(uport->flags & UPF_HARD_FLOW); + if (tty->hw_stopped) { if (status) { tty->hw_stopped = 0;