Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp723109ybt; Fri, 10 Jul 2020 10:40:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8zIIPC6kngfI88Ug2EqbPD58jmT6KDfjwG4CaQqlnm8m+bR55rfoOtvN9+oKKTgqtsGpF X-Received: by 2002:a50:f149:: with SMTP id z9mr79968444edl.167.1594402824035; Fri, 10 Jul 2020 10:40:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594402824; cv=none; d=google.com; s=arc-20160816; b=UgqkXOthAzTqawGpDAlHgto4wbl+BgdL9Fa4DfMXuHT7JVlNSyTp+Js3eZQjv2yizZ 5Ias4+HwFPtXjLBvJXnwEYcmMHqp11rmKbAYRc0JRQi0Qnp2pKzqQL/NLTMML3umUFhq cnDriKIEqLAOgLot55BBcwd115W5/orvg3sDA2thcwEYnlF8WQmqJhzKEjLfcCKa65Cv 2gDLTGxM9zwNU928cqU1Xf5b2YGySLydyBCGg23vfdv58r5820l5fizXN71K9qBtF0jA iOfCkK+/zkBM1PAswjSSflQbawJj5v3/zTy+mY1WlDNeTXXLmUAe0oFxP0rR+uhGZMQB l4YA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=lXuUczWFNlwPKehZIWXn30gRWiLBJgbemeVZ6SnUAcc=; b=R/Edn3PTfokUdNdJrZ1j9e7jeUnfCaeEPt9JKKUTB7ft4RFXKVkJztk/z/AICBdvYF FOG7OwDaM55NY/ddtFyNHcK7pSsrcn0VOYUD7Q2V+p6ZYiUBbnpd1FNrIp2mFBuxuxPQ vFDiH2HQCXED07usTYsrdWjfjJKFwPBHi/B+NbBtyIQfQcBCmFz7fouj77wWJC5Jx6Dq pnIfyi4SKJyJSk54V7hT1+r8sNindvBz9DztaQVBtwrlk2tkbBsrUNu4tkvLsMLdXMKt gT42q7MpZWE+bCdgTLUP3Zg0n3VqM8eTayWdwqN7Vaks1HY5OZIzaQoZLjSTRJUGgy55 Jqgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=H+fQVcht; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si4252585eja.81.2020.07.10.10.40.00; Fri, 10 Jul 2020 10:40:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=H+fQVcht; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbgGJRja (ORCPT + 99 others); Fri, 10 Jul 2020 13:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726872AbgGJRja (ORCPT ); Fri, 10 Jul 2020 13:39:30 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 192FAC08C5DC for ; Fri, 10 Jul 2020 10:39:30 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id s9so7358879ljm.11 for ; Fri, 10 Jul 2020 10:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lXuUczWFNlwPKehZIWXn30gRWiLBJgbemeVZ6SnUAcc=; b=H+fQVchtOQTAtj7qP/IRP93a2MdhdzCX+kqk9bAncYdhLuiymqoDTbVFJDni8bdQpW bnkmCwDyWeEU0Op/y1KIcZ2rsMu0mVcT3G48Ow4qQw8E9PMNaJYfexIG1RlD8Tpvf9VU MfU7LXYx4m5hygDtLlzwEm+bMw8uFlgaP7fOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lXuUczWFNlwPKehZIWXn30gRWiLBJgbemeVZ6SnUAcc=; b=Y1c/DDkTJqCdywW9ub0XxA54qbbdkszRHeXVKNIKPRsc5TKZ0gW+/xTpxizEfZbrtT pLFNXVFAdDNhpmAY/rxi+E+hHhuSCZkpjr0ccoOTgJhGIiE8ZU6q0Qyvrrb1rhjATXQy pmeWokaxnA704tN5yIIkGG09vEDddQ9Ng+p8HWsa231/oz86uTG+2uorYKSU1PCzYPR/ WllGWRt6LpixbbdIDaICa/ltq18+U9531fEbBv4j1u03SdwgFtTstis/8g0635NQdQ7z d3DRM4tCcdZJGH7OLwlbzdSfGWoPoW8jjUGIY162dzDE1pvseu7VOK3Gh43SGVFq0iFn uusA== X-Gm-Message-State: AOAM530FZxRvvsUjFCs3NthzaKcETrzWe0We/VLbR5gqOHCJ9tFefST9 /mw811nt9XduS9jfkt/CXpvR273WAG4= X-Received: by 2002:a2e:2c18:: with SMTP id s24mr32073027ljs.291.1594402767815; Fri, 10 Jul 2020 10:39:27 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id g22sm2381091lfb.43.2020.07.10.10.39.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jul 2020 10:39:26 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id q4so7413582lji.2 for ; Fri, 10 Jul 2020 10:39:26 -0700 (PDT) X-Received: by 2002:a2e:b0ed:: with SMTP id h13mr30489580ljl.250.1594402765997; Fri, 10 Jul 2020 10:39:25 -0700 (PDT) MIME-Version: 1.0 References: <20200626200033.1528052-1-dianders@chromium.org> <20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid> In-Reply-To: <20200626125844.1.I8546ecb6c5beb054f70c5302d1a7293484212cd1@changeid> From: Evan Green Date: Fri, 10 Jul 2020 10:38:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] serial: qcom_geni_serial: Make kgdb work even if UART isn't console To: Douglas Anderson Cc: Greg Kroah-Hartman , daniel.thompson@linaro.org, Akash Asthana , Stephen Boyd , kgdb-bugreport@lists.sourceforge.net, linux-arm-msm , sumit.garg@linaro.org, Vivek Gautam , Andy Gross , Bjorn Andersson , Jiri Slaby , LKML , linux-serial@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 26, 2020 at 1:01 PM Douglas Anderson wrote: > > The geni serial driver had the rather sketchy hack in it where it > would adjust the number of bytes per RX FIFO word from 4 down to 1 if > it detected that CONFIG_CONSOLE_POLL was enabled (for kgdb) and this > was a console port (defined by the kernel directing output to this > port via the "console=" command line argument). > > The problem with that sketchy hack is that it's possible to run kgdb > over a serial port even if it isn't used for console. > > Let's avoid the hack by simply handling the 4-bytes-per-FIFO word case > for kdb. We'll have to have a (very small) cache but that should be > fine. > > A nice side effect of this patch is that an agetty (or similar) > running on this port is less likely to drop characters. We'll > have roughly 4 times the RX FIFO depth than we used to now. > > NOTE: the character cache here isn't shared between the polling API > and the non-polling API. That means that, technically, the polling > API could eat a few extra bytes. This doesn't seem to pose a huge > problem in reality because we'll only get several characters per FIFO > word if those characters are all received at nearly the same time and > we don't really expect non-kgdb characters to be sent to the same port > as kgdb at the exact same time we're exiting kgdb. > > ALSO NOTE: we still have the sketchy hack for setting the number of > bytes per TX FIFO word in place, but that one is less bad. kgdb > doesn't have any problem with this because it always just sends 1 byte > at a time and waits for it to finish. The TX FIFO hack is only really > needed for console output. In any case, a future patch will remove > that hack, too. > > Signed-off-by: Douglas Anderson > --- > > drivers/tty/serial/qcom_geni_serial.c | 80 ++++++++++++++++++--------- > 1 file changed, 55 insertions(+), 25 deletions(-) > > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c > index 0300867eab7a..4610e391e886 100644 > --- a/drivers/tty/serial/qcom_geni_serial.c > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -103,11 +103,13 @@ > #define DEFAULT_IO_MACRO_IO2_IO3_MASK GENMASK(15, 4) > #define IO_MACRO_IO2_IO3_SWAP 0x4640 > > -#ifdef CONFIG_CONSOLE_POLL > -#define CONSOLE_RX_BYTES_PW 1 > -#else > -#define CONSOLE_RX_BYTES_PW 4 > -#endif > +struct qcom_geni_private_data { > + /* NOTE: earlycon port will have NULL here */ > + struct uart_driver *drv; > + > + u32 poll_cached_bytes; > + unsigned int poll_cached_bytes_cnt; > +}; > > struct qcom_geni_serial_port { > struct uart_port uport; > @@ -129,6 +131,8 @@ struct qcom_geni_serial_port { > int wakeup_irq; > bool rx_tx_swap; > bool cts_rts_swap; > + > + struct qcom_geni_private_data private_data; > }; > > static const struct uart_ops qcom_geni_console_pops; > @@ -264,8 +268,9 @@ static bool qcom_geni_serial_poll_bit(struct uart_port *uport, > unsigned int baud; > unsigned int fifo_bits; > unsigned long timeout_us = 20000; > + struct qcom_geni_private_data *private_data = uport->private_data; > > - if (uport->private_data) { > + if (private_data->drv) { > port = to_dev_port(uport, uport); > baud = port->baud; > if (!baud) > @@ -331,23 +336,42 @@ static void qcom_geni_serial_abort_rx(struct uart_port *uport) > } > > #ifdef CONFIG_CONSOLE_POLL > + > static int qcom_geni_serial_get_char(struct uart_port *uport) > { > - u32 rx_fifo; > + struct qcom_geni_private_data *private_data = uport->private_data; > u32 status; > + u32 word_cnt; > + int ret; > + > + if (!private_data->poll_cached_bytes_cnt) { > + status = readl(uport->membase + SE_GENI_M_IRQ_STATUS); > + writel(status, uport->membase + SE_GENI_M_IRQ_CLEAR); > > - status = readl(uport->membase + SE_GENI_M_IRQ_STATUS); > - writel(status, uport->membase + SE_GENI_M_IRQ_CLEAR); > + status = readl(uport->membase + SE_GENI_S_IRQ_STATUS); > + writel(status, uport->membase + SE_GENI_S_IRQ_CLEAR); > > - status = readl(uport->membase + SE_GENI_S_IRQ_STATUS); > - writel(status, uport->membase + SE_GENI_S_IRQ_CLEAR); > + status = readl(uport->membase + SE_GENI_RX_FIFO_STATUS); > + word_cnt = status & RX_FIFO_WC_MSK; > + if (!word_cnt) > + return NO_POLL_CHAR; > > - status = readl(uport->membase + SE_GENI_RX_FIFO_STATUS); > - if (!(status & RX_FIFO_WC_MSK)) > - return NO_POLL_CHAR; > + if (word_cnt == 1 && (status & RX_LAST)) I forget how the partial word snapping works. Are you sure you want word_cnt == 1? I see qcom_geni_serial_handle_rx() looks at RX_LAST independently as long as word_cnt != 0. I'm worried the hardware allows one FIFO entry with say 2 bytes in it and RX_LAST set, but then also piles new stuff in the FIFO behind it, so that word_cnt can be >1. Also I mostly reviewed the change on Gerrit, they seemed to be the same. In this case it was easier to understand the indentation changes. If there were gotchas between the Gerrit version and this patch, let me know. -Evan