linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Loic Poulain <loic.poulain@linaro.org>
To: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	MSM <linux-arm-msm@vger.kernel.org>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH] tty: serial: msm_serial: RX SW/FIFO mode fallback
Date: Tue, 14 Jan 2020 08:55:02 +0100	[thread overview]
Message-ID: <CAMZdPi8ih2LukVsGvG_w2HOSZL9DSbYDmD_U=PTnk96vbE=u8g@mail.gmail.com> (raw)
In-Reply-To: <CAOCk7NrSkaY5xUdA+Q3tCoDv01fVDYpakWmk-RnOuuBKsNN8Jg@mail.gmail.com>

On Mon, 13 Jan 2020 at 20:53, Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote:
>
> On Fri, Jan 10, 2020 at 1:55 AM Loic Poulain <loic.poulain@linaro.org> wrote:
> >
> > During db410c stress test and when the system is low on memory,
> > the UART/console becomes unresponsive and never recover back.
> > This has been narrowed down to the msm_start_rx_dma which does
> > not manage error cases correctly (e.g. dma mapping failure),
> > indeed, when an error happens, dma transfer is simply discarded
> > and so never completed, leading to unconfigured RX path.
> >
> > This patch fixes this issue by switching to SW/FIFO mode in case
> > of DMA issue. This mainly consists in resetting the receiver to
> > apply RX BAM/DMA disabling change and re-enabling the RX level
> > and stale interrupts (previously disabled for DMA transfers).
> >
> > The DMA will be re-enabled once memory is available since the
> > SW/FIFO read function (msm_handle_rx_dm) retries to start dma
> > on completion.
>
> Is there a risk of the same thing occurring in the TX path?

Yes, but the TX case is already handled. If msm_handle_tx_dma fails,
msm_handle_tx_pio is used to directly write the FIFO.

>
> >
> > Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> > ---
> >  drivers/tty/serial/msm_serial.c | 18 +++++++++++++++++-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
> > index 1cbae07..a63b703 100644
> > --- a/drivers/tty/serial/msm_serial.c
> > +++ b/drivers/tty/serial/msm_serial.c
> > @@ -610,7 +610,7 @@ static void msm_start_rx_dma(struct msm_port *msm_port)
> >                                    UARTDM_RX_SIZE, dma->dir);
> >         ret = dma_mapping_error(uart->dev, dma->phys);
> >         if (ret)
> > -               return;
> > +               goto sw_mode;
> >
> >         dma->desc = dmaengine_prep_slave_single(dma->chan, dma->phys,
> >                                                 UARTDM_RX_SIZE, DMA_DEV_TO_MEM,
> > @@ -661,6 +661,22 @@ static void msm_start_rx_dma(struct msm_port *msm_port)
> >         return;
> >  unmap:
> >         dma_unmap_single(uart->dev, dma->phys, UARTDM_RX_SIZE, dma->dir);
> > +
> > +sw_mode:
> > +       /*
> > +        * Switch from DMA to SW/FIFO mode. After clearing Rx BAM (UARTDM_DMEN),
>
> Where does this clear of UARTDM_DMEN occur?

The DMEN clear occurs on DMA RX completion (msm_complete_tx_dma()) and
set on DMA
restart (msm_start_rx_dma). In our case, since DMA start fails, we
just reset the RX path to
effectively apply the SW/FIFO mode.

>
> > +        * receiver must be reset.
> > +        */
> > +       msm_write(uart, UART_CR_CMD_RESET_RX, UART_CR);
> > +       msm_write(uart, UART_CR_RX_ENABLE, UART_CR);
> > +
> > +       msm_write(uart, UART_CR_CMD_RESET_STALE_INT, UART_CR);
> > +       msm_write(uart, 0xFFFFFF, UARTDM_DMRX);
> > +       msm_write(uart, UART_CR_CMD_STALE_EVENT_ENABLE, UART_CR);
> > +
> > +       /* Re-enable RX interrupts */
> > +       msm_port->imr |= (UART_IMR_RXLEV | UART_IMR_RXSTALE);
> > +       msm_write(uart, msm_port->imr, UART_IMR);
> >  }
> >
> >  static void msm_stop_rx(struct uart_port *port)
> > --
> > 2.7.4
> >

Regards,
Loic

  reply	other threads:[~2020-01-14  7:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10  8:58 [PATCH] tty: serial: msm_serial: RX SW/FIFO mode fallback Loic Poulain
2020-01-13 19:53 ` Jeffrey Hugo
2020-01-14  7:55   ` Loic Poulain [this message]
2020-01-14 15:50     ` Jeffrey Hugo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZdPi8ih2LukVsGvG_w2HOSZL9DSbYDmD_U=PTnk96vbE=u8g@mail.gmail.com' \
    --to=loic.poulain@linaro.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).