linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Problem with non aligned DMA in usbnet on ARM
Date: Wed, 11 Aug 2010 23:47:29 +0100	[thread overview]
Message-ID: <20100811224729.GD827@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <4C632217.9000608@gmail.com>

On Thu, Aug 12, 2010 at 12:20:07AM +0200, Martin Fuzzey wrote:
> [Gary, you forgot to copy -usb and netdev so adding them again to try to
> keep this thread joined up]
> 
> Russell King - ARM Linux wrote:
> > On Wed, Aug 11, 2010 at 08:54:27AM -0700, Gary King wrote:
> >   
> >> I sent a patch to the list about 2 weeks ago that added support to
> >> DMA bounce to bounce for misaligned buffers. We have a similar
> >> problem with URB alignment for usbnet on Tegra's HCD:
> >> http://lists.arm.linux.org.uk/lurker/message/20100729.005746.b43fa1d9.en.html
>
> Nice to know someone else has the same problem :)
> What is the Tegra hcd?
> I can't find it in the kernel sources.
> 
> > We don't want to add support for this to DMA bounce.  DMA bounce is already
> > a pain in the backside and causes its own set of problems - please let it
> > die a long slow but quite death.
> >
> > If you want to see the kind of pain dmabounce causes, look at this long
> > standing and as yet unsolved bug:
> >
> >   http://bugzilla.kernel.org/show_bug.cgi?id=7760
>
> Well I don't know the dmabounce code but why is using it likely to cause
> OOM problems (at least why more so than copying the buffer in the HCD or
> the usb core).

The problem in that bug appears to be that there's soo much pressure on
the first 64MB of memory that we run out of sufficiently large blocks
of memory to be able to satisfy the requirements to do DMA bouncing via
the dmabounce code.  I don't think anyone got to the bottom of why the
DMA zone was exhausted first before the DMA32 zone ran out of pages.

However, as something using dma_map_single/dma_map_page has to return a
contiguous buffer, we do need to use high order allocations for them - a
driver on the other hand can make a decision about whether its possible
to break up the buffer into smaller (and therefore easier to allocate)
buffers.

> In both cases there will be two copies of the buffer in
> memory which could I agree be a problem in memory constrained systems.
> But if we _do_ want to accept unaligned buffers from usb drivers I can't
> see  a way round that.

One thing we have done in the past (eg, SMC91x network driver on PXA) is
to PIO the first couple of bytes to the device, and DMA the remainder -
the DMA can't do non-word aligned start addresses.  This gives us the
benefit of being able to deal with buffers containing IP packets without
copying them, while preserving the performance of using DMA.

  reply	other threads:[~2010-08-11 22:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-11  9:41 Problem with non aligned DMA in usbnet on ARM Martin Fuzzey
2010-08-11  9:54 ` Russell King - ARM Linux
2010-08-11 10:11   ` Martin Fuzzey
2010-08-11 15:04     ` Greg KH
2010-08-11 16:08       ` Martin Fuzzey
2010-08-11 17:42         ` Greg KH
2010-08-11 19:07           ` Martin Fuzzey
2010-08-11 20:13             ` Greg KH
2010-08-11 22:31               ` Martin Fuzzey
2010-08-12 17:01                 ` Matthieu CASTET
2010-08-11 19:10           ` Oliver Neukum
2010-08-11  9:59 ` Matthieu CASTET
2010-08-11 11:38   ` Martin Fuzzey
2010-08-11 15:54     ` Gary King
2010-08-11 20:35       ` Russell King - ARM Linux
2010-08-11 22:20         ` Martin Fuzzey
2010-08-11 22:47           ` Russell King - ARM Linux [this message]
2010-08-12 17:08           ` Matthieu CASTET
2010-08-13 10:06             ` Martin Fuzzey
2010-08-13 10:58               ` Oliver Neukum
2010-08-13 13:42                 ` David Brownell
2010-08-13 13:53                   ` Oliver Neukum

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=20100811224729.GD827@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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).