Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp282902rwj; Thu, 22 Dec 2022 02:48:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXt07soX1lJP2b0qWeQ9aAbb1i+aO2dln+lWcbZyOUYWFXc+WnSKdrnmPGDXtTH7W43EwkX4 X-Received: by 2002:a17:907:8a16:b0:7c1:458b:a947 with SMTP id sc22-20020a1709078a1600b007c1458ba947mr5899159ejc.26.1671706134648; Thu, 22 Dec 2022 02:48:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671706134; cv=none; d=google.com; s=arc-20160816; b=M6ym4r7VpJAksV9syari6C2kaCyPeyJWQez9vRaR+mfznlFjd6RQTXFz98P03wGkbX qD+ND+SxgpJ2ENCELweNUWeEl1EGoDagQAg62wkD1bOp3q5ltTBT4py+62Dgky3uIEyI CkiWeyx3KqH2HEcNyrz/gQ7db3VpEj/UOSise/rmcRYtLiirtMD8gRzpznzpkWtv/R+0 4alyuZtXZnqRramNQ7DXPhLEfqZ5ehVLyQRjo4H5K0p2FTcBBtZ9zspH+9KuYvqAvMi7 nKaQKQSyUrTHxUrCncIt570WtJsoYolewCFMnGzpWSYWsjVdmoeuYePqXkIkj1A0lHiE Wb8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=wGknEY04EsUKLZJj3Yapbd+Qg2F0ZKyA+VTS8vhFn8M=; b=vvsH0tzO8xG6A+ZopGK0z0cfuKXRI+vXmUkaFEbQs32WYwtdfosL3lzeEoQvHrMmnW 3F3klmZr0Hbxa3EHRBQO/lSUt+rLG4wgxSDoUKTmjrBS1eZM5h4ii/hGLREuPCgtL1Pa rC9xuDk3R/QTdUJK/HMlQ1ITPdkh6NvRyP9Y+uWEtJpnGZ5VRq+0TiX1Cra24bPwFEMd 4gcVlO1pTPs1tOEhC4D2M5iSeThGGHxlRI0TBohkc18kQlepXeuxphbMRJeoP6NQhSMn EDekrhXA3qsFrjIDCO4UHAuG4/6Ftos03CWuqyCFzLBwS7QzVoPff2G7/KUW4SSw5pDs 28yw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PoCwBwtc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id di22-20020a170906731600b007ae5ccae236si254965ejc.90.2022.12.22.02.47.48; Thu, 22 Dec 2022 02:48:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PoCwBwtc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235039AbiLVKaX (ORCPT + 67 others); Thu, 22 Dec 2022 05:30:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235225AbiLVKaU (ORCPT ); Thu, 22 Dec 2022 05:30:20 -0500 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5A40D1FCF7; Thu, 22 Dec 2022 02:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671705019; x=1703241019; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Rbzof44+EtrdYScW9KjRxHkIGR0ZtgJFbtkIuoytGKc=; b=PoCwBwtcO185hqvPbW60HJsWuCiNCRYw6jsg4jgsQwCXwyO4WKkv0yXk nHuKA0137PU0bpOZV0+bFWC9W9kFl3c2oLWgyzcRVUs3mHUQ8WHbGqAv/ xuk2Ufxkwi9vgaV7o9SUrI7RVgIFJ4u9IWmnGtxRg6W27JmxXZ+rxPrRb DaLNmarThN4xZoUh2Kw/lZcLJY0SyzZGP+NPyTLZbzAZs5trk7VcntPbd ++ADwBIOZfacrPbRLOISvdPPAMP1yQcRUt2TjVGg2mmA4DhIcBD5Hac4S +vjCOgXFCre89gFvbmmasQPxENs2B98AzdKwhHyI8qZkE9jWcVM9WRWE4 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10568"; a="347239118" X-IronPort-AV: E=Sophos;i="5.96,265,1665471600"; d="scan'208";a="347239118" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2022 02:30:18 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10568"; a="720268696" X-IronPort-AV: E=Sophos;i="5.96,265,1665471600"; d="scan'208";a="720268696" Received: from lardelea-mobl1.ger.corp.intel.com ([10.251.219.104]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2022 02:30:16 -0800 Date: Thu, 22 Dec 2022 12:30:14 +0200 (EET) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Richard Leitner cc: "David R. Piegdon" , linux-tegra@vger.kernel.org, Dmitry Osipenko , Mikko Perttunen , Nicolas Chauvet , Jiri Slaby , Greg Kroah-Hartman , linux-serial , LKML Subject: Re: [PATCH] serial8250 on tegra hsuart: recover from spurious interrupts due to tegra2 silicon bug In-Reply-To: Message-ID: References: <4676ea34-69ce-5422-1ded-94218b89f7d9@p23q.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 Nov 2022, Richard Leitner wrote: > Hi, > > On Fri, Jul 13, 2018 at 11:32:42AM +0000, David R. Piegdon wrote: > > Hi, > > a while back I sent a few mails regarding spurious interrupts in the > > UARTA (hsuart) block of the Tegra2 SoC, when using the 8250 driver for > > it instead of the hsuart driver. After going down a pretty deep > > debugging/testing hole, I think I found a patch that fixes the issue. So > > far testing in a reboot-cycle suggests that the error frequency dropped > > from >3% of all reboots to at least <0.05% of all reboots. Tests > > continue to run over the weekend. > > > > The patch below already is a second iteration; the first did not reset > > the MCR or contain the lines below '// clear interrupts'. This resulted > > in no more spurious interrupts, but in a few % of spurious interrupts > > that were recovered the UART block did not receive any characters any > > more. So further resetting was required to fully reacquire operational > > state of the UART block. > > > > I'd love any comments/suggestions on this! > > I'd like to follow up on this ancient patch as we are using it > successfully for a few years with different kernel versions on a > tegra20 SOM (tamonten) now and I'm currently cleaning up our tree. > > David, have you done any work in regarding this issue since 2018? > > What would be needed to get this solution mainline? It seems that the code would belong to ->handle_irq() rather than 8250_core. Do the affected device belong under 8250_tegra.c? If they do, then just create .handle_irq for it and detect this condition there after call to serial8250_handle_irq(). > The recipient of this mail are from the initial thread [1] and > a current get_maintainers.pl run. > > regards;rl > > [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/4676ea34-69ce-5422-1ded-94218b89f7d9@p23q.org/ > > > > > Cheers, > > > > David > > > > diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c > > index e8819aa20415..1d76eebefd4e 100644 > > --- a/drivers/tty/serial/8250/8250_core.c > > +++ b/drivers/tty/serial/8250/8250_core.c > > @@ -140,6 +140,38 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id) > > "serial8250: too much work for irq%d\n", irq); > > break; > > } > > + > > +#ifdef CONFIG_ARCH_TEGRA_2x_SOC > > + if (!handled && (port->type == PORT_TEGRA)) { > > + /* > > + * Fix Tegra 2 CPU silicon bug where sometimes > > + * "TX holding register empty" interrupts result in a > > + * bad (metastable?) state in Tegras HSUART IP core. > > + * Only way to recover seems to be to reset all > > + * interrupts as well as the TX queue and the MCR. > > + * But we don't want to loose any outgoing characters, > > + * so only do it if the RX and TX queues are empty. > > + */ > > + unsigned char lsr = port->serial_in(port, UART_LSR); serial_lsr_in(), make sure you take the port's lock btw. > > + const unsigned char fifo_empty_mask = > > + (UART_LSR_TEMT | UART_LSR_THRE); > > + if (((lsr & (UART_LSR_DR | fifo_empty_mask)) == > > + fifo_empty_mask)) { uart_lsr_tx_empty(lsr) && !(lsr & UART_LSR_DR) fifo_empty_mask can be dropped. -- i. > > + port->serial_out(port, UART_IER, 0); > > + port->serial_out(port, UART_MCR, 0); > > + serial8250_clear_and_reinit_fifos(up); > > + port->serial_out(port, UART_MCR, up->mcr); > > + port->serial_out(port, UART_IER, up->ier); > > + // clear interrupts > > + serial_port_in(port, UART_LSR); > > + serial_port_in(port, UART_RX); > > + serial_port_in(port, UART_IIR); > > + serial_port_in(port, UART_MSR); > > + up->lsr_saved_flags = 0; > > + up->msr_saved_flags = 0; > > + } > > + } > > +#endif > > } while (l != end); > > > > spin_unlock(&i->lock); >