From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Peter Hurley <peter@hurleysoftware.com>,
Frederic Danis <frederic.danis@linux.intel.com>
Cc: linux-serial@vger.kernel.org, linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] Revert "serial: 8250_dma: don't bother DMA with small transfers"
Date: Wed, 30 Sep 2015 17:12:24 +0300 [thread overview]
Message-ID: <1443622344.8361.304.camel@linux.intel.com> (raw)
In-Reply-To: <560BE919.9020803@hurleysoftware.com>
On Wed, 2015-09-30 at 09:52 -0400, Peter Hurley wrote:
> [ + Andy Shevchenko ]
>
> On 09/30/2015 08:46 AM, Frederic Danis wrote:
> > This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb.
>
> Hi Frederic,
>
> It's customary to mail the commit author in patches which revert
> their work.
>
> > This commit prevents from sending "big" file using Bluetooth.
> > When sending a lot of data quickly through the Bluetooth interface,
> > and
> > after a variable amount of data sent, transfer fails with error:
> > kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00
>
> Hmmm, was there any other information regarding why this happened?
Frederic informed us privately about this issue. I tried to hunt the
root cause but mostly (there was one observation but apparently seems
it is not related to this issue) nothing looks wrong.
> Eg., did the driver mistakenly re-order i/o (DMA occurred after PIO)?
I have few tracing dumps which Frederic provides to me, but I couldn't
see such a problem. Maybe I missed it. My commit 9119fba0cfed
introduces interleaved IO (DMA/PIO) which makes it like DMA -> PIO ->
DMA -> ...
> Or, might there be some race condition in the dmaengine driver on
> this
> platform?
There is [1] might be a clue, though I don't think it's directly
related.
[1] http://www.spinics.net/lists/linux-spi/msg01151.html
The change prevents interleaved DMA/PIO IO.
>
> Regards,
> Peter Hurley
>
> > Found on T100TA.
> >
> > After reverting this commit, send works fine for any file size.
> >
> > Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
> > ---
> > drivers/tty/serial/8250/8250_dma.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_dma.c
> > b/drivers/tty/serial/8250/8250_dma.c
> > index 21d01a4..e508939 100644
> > --- a/drivers/tty/serial/8250/8250_dma.c
> > +++ b/drivers/tty/serial/8250/8250_dma.c
> > @@ -80,10 +80,6 @@ int serial8250_tx_dma(struct uart_8250_port *p)
> > return 0;
> >
> > dma->tx_size = CIRC_CNT_TO_END(xmit->head, xmit->tail,
> > UART_XMIT_SIZE);
> > - if (dma->tx_size < p->port.fifosize) {
> > - ret = -EINVAL;
> > - goto err;
> > - }
> >
> > desc = dmaengine_prep_slave_single(dma->txchan,
> > dma->tx_addr + xmit
> > ->tail,
> >
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Peter Hurley
<peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>,
Frederic Danis
<frederic.danis-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] Revert "serial: 8250_dma: don't bother DMA with small transfers"
Date: Wed, 30 Sep 2015 17:12:24 +0300 [thread overview]
Message-ID: <1443622344.8361.304.camel@linux.intel.com> (raw)
In-Reply-To: <560BE919.9020803-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>
On Wed, 2015-09-30 at 09:52 -0400, Peter Hurley wrote:
> [ + Andy Shevchenko ]
>
> On 09/30/2015 08:46 AM, Frederic Danis wrote:
> > This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb.
>
> Hi Frederic,
>
> It's customary to mail the commit author in patches which revert
> their work.
>
> > This commit prevents from sending "big" file using Bluetooth.
> > When sending a lot of data quickly through the Bluetooth interface,
> > and
> > after a variable amount of data sent, transfer fails with error:
> > kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00
>
> Hmmm, was there any other information regarding why this happened?
Frederic informed us privately about this issue. I tried to hunt the
root cause but mostly (there was one observation but apparently seems
it is not related to this issue) nothing looks wrong.
> Eg., did the driver mistakenly re-order i/o (DMA occurred after PIO)?
I have few tracing dumps which Frederic provides to me, but I couldn't
see such a problem. Maybe I missed it. My commit 9119fba0cfed
introduces interleaved IO (DMA/PIO) which makes it like DMA -> PIO ->
DMA -> ...
> Or, might there be some race condition in the dmaengine driver on
> this
> platform?
There is [1] might be a clue, though I don't think it's directly
related.
[1] http://www.spinics.net/lists/linux-spi/msg01151.html
The change prevents interleaved DMA/PIO IO.
>
> Regards,
> Peter Hurley
>
> > Found on T100TA.
> >
> > After reverting this commit, send works fine for any file size.
> >
> > Signed-off-by: Frederic Danis <frederic.danis-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > ---
> > drivers/tty/serial/8250/8250_dma.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/tty/serial/8250/8250_dma.c
> > b/drivers/tty/serial/8250/8250_dma.c
> > index 21d01a4..e508939 100644
> > --- a/drivers/tty/serial/8250/8250_dma.c
> > +++ b/drivers/tty/serial/8250/8250_dma.c
> > @@ -80,10 +80,6 @@ int serial8250_tx_dma(struct uart_8250_port *p)
> > return 0;
> >
> > dma->tx_size = CIRC_CNT_TO_END(xmit->head, xmit->tail,
> > UART_XMIT_SIZE);
> > - if (dma->tx_size < p->port.fifosize) {
> > - ret = -EINVAL;
> > - goto err;
> > - }
> >
> > desc = dmaengine_prep_slave_single(dma->txchan,
> > dma->tx_addr + xmit
> > ->tail,
> >
>
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
next prev parent reply other threads:[~2015-09-30 14:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 12:46 [PATCH] Revert "serial: 8250_dma: don't bother DMA with small transfers" Frederic Danis
2015-09-30 12:46 ` Frederic Danis
2015-09-30 13:52 ` Peter Hurley
2015-09-30 13:52 ` Peter Hurley
2015-09-30 14:12 ` Andy Shevchenko [this message]
2015-09-30 14:12 ` Andy Shevchenko
2015-09-30 20:11 ` Peter Hurley
2015-09-30 20:11 ` Peter Hurley
2015-10-01 8:55 ` Andy Shevchenko
2015-10-01 8:55 ` Andy Shevchenko
2015-10-01 10:44 ` Marcel Holtmann
2015-10-01 10:44 ` Marcel Holtmann
2015-10-06 9:17 ` Frederic Danis
2015-10-06 9:17 ` Frederic Danis
2015-10-06 9:34 ` Greg KH
2015-10-06 9:34 ` Greg KH
2015-10-06 9:48 ` Frederic Danis
2015-10-06 9:48 ` Frederic Danis
2015-10-06 10:22 ` Greg KH
2015-10-06 10:22 ` Greg KH
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=1443622344.8361.304.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=frederic.danis@linux.intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.