From: Alessandro Rubini <ru@gnudd.com>
To: akpm@linux-foundation.org, fujita.tomonori@lab.ntt.co.jp,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, linux-kernel@vger.kernel.org
Cc: giancarlo.asnaghi@st.com, maddalena.brattoli@st.com,
alan@linux.intel.com
Subject: a question on DMA and remapping
Date: Fri, 18 Nov 2011 00:30:59 +0100 [thread overview]
Message-ID: <20111117233059.GA659@mail.gnudd.com> (raw)
Hello.
This goes to the maintainers of x86::asm/dma-mapping.h and lib/swiotlb.c,
with Cc: to involved people.
I have an Intel evaluation board with the ST IO-Hub called STA2X11 and
I'm working to port the STA2X11 drivers to mainstream. The code is
currently on sourceforge. Since the device is based on a PCI-Amba
bridge, all DMA addresses are different from CPU addresses, even for
normal PCI devices, like EHCI.
Unfortunately, the current patch is changing 3 inlines to external
functions. They are dma_capable, phys_to_dma, dma_to_phys -- which
actually are only used in swiotlb.c .
I thought about the following two approaches towards a clean port:
- using dma_supported(), which relies on dev->dma_ops->dma_supported
and adding phys_to_dma and dma_to_phys to the dma operations. In
the new fields, the default NULL may be used to select the current
behaviour in an inline function.
- copying lib/swiotlb.c to my own file, which will be almost
identical to the existing one but for a few lines.
The former approach will have some tiny overhead on all users, besides
messing with dma_capable and dma_allowed, possibly introducing bugs in
some corner cases (but the current situation is quite messy, may I
say...)
The latter approach means code duplication, which is bad. Although
maybe over time I may be able to shrink the current swiotlb.c to a
much smaller snippet. I tend to prefer this one, but I'm not sure if
it's acceptable.
Any feedback is welcome. Thanks in advance.
/alessandro
next reply other threads:[~2011-11-17 23:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 23:30 Alessandro Rubini [this message]
2011-11-17 23:47 ` a question on DMA and remapping Andrew Morton
2011-11-22 23:00 ` Alan Cox
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=20111117233059.GA659@mail.gnudd.com \
--to=ru@gnudd.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=giancarlo.asnaghi@st.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maddalena.brattoli@st.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.