linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: bcm43xx-dev@lists.berlios.de
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: 30 bits DMA and ppc
Date: Sun, 30 Oct 2005 15:03:55 +1100	[thread overview]
Message-ID: <1130645036.29054.229.camel@gaston> (raw)

Hi !

I was thinking about the best ways to deal with the 30 bits limitation
of the Broadcom chips for DMA on PowerMacs. No emergency there, we still
need to have a working bcm43xx driver and the developpement can be done
with <= 1Gb of RAM, but it will have to be addressed at one point as we
are getting closer to something that is useable :)

I will not implement something like GFP_DMA, I think. It just sucks too
much...

However, what I can do is have the architecture code reserve a pool of
memory at boot if the machine main RAM is bigger than 1Gb, to use for
bounce-buffering. On the G5 with more than 2Gb, this is even easier
since I already have to blow away a 16Mb page for use by the IOMMU, but
the IOMMU only uses 2Mb in there, so I have about 14Mb that I could
re-use for that. On 32 bits machine, I can just reserve something early
during boot.

Now, how to actually make use of that pool. One way is to hack something
specific inside the bcm43xx driver. The pool can then be easily cut in
regions: the descriptor rings buffers, and 2 pools, one for Rx and one
for Tx. The allocation inside of those pools can be done as simple ring
buffer too due to the inherently ordered processing of packets.

However, the above would require arch specific hacks, and would only
work for one card in the system (too bad if you plug a cardbus one).

Another possibility that might be more interesting is to use swiotlb.
This is a somewhat generic bounce-buffering implementation of the DMA
mapping routines that is used by ia64 and x86_64 when no IOMMU is
available. It will automatically do nothing if the address fits the DMA
mask so it shouldn't add much overhead to other drivers and would "make
things work" transparently. In addition, for G5s with more than 2Gb of
RAM (which have an iommu), I could modify the iommu code to take into
account the DMA mask when allocating DMA virtual space. (The later would
have a slight risk of failure, but I doubt it will happen in practice,
as it would mean one has more than 1Gb of pending DMA at a given point
in time).

I tend to prefer the later solution ...

Anybody with strong disagreement with using swiotlb on PPC ? The choice
of wether to allocate RAM for it at boot and how much can be done per
platform and based on the amount of real RAM (for example, on pmac, I
suppose I would only allocate some if the physical RAM is more than 1Gb
since that's the limitation of those Broadcom chips and I don't see any
other potential user for it).

Besides, it may end up being useful for some crappy embedded stuffs (no
name here :)

Ben.
 

             reply	other threads:[~2005-10-30  4:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-30  4:03 Benjamin Herrenschmidt [this message]
2005-10-30  8:47 ` [Bcm43xx-dev] 30 bits DMA and ppc Michael Buesch
2005-10-30 17:59 ` Olof Johansson
2005-10-30 21:14   ` Benjamin Herrenschmidt
2005-10-30 21:35     ` Olof Johansson
2005-10-30 21:41       ` Benjamin Herrenschmidt
2005-10-30 22:02         ` Olof Johansson
2005-10-31  0:35 ` exception vectors Ingmar
2005-10-31  2:17   ` Benjamin Herrenschmidt
2005-10-31  2:28   ` Hollis Blanchard
2005-10-31  9:58     ` Ingmar
2005-11-01  1:46       ` Olof Johansson
2005-11-01  8:28         ` Ingmar

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=1130645036.29054.229.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=linuxppc-dev@ozlabs.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).