* a question on DMA and remapping
@ 2011-11-17 23:30 Alessandro Rubini
2011-11-17 23:47 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Alessandro Rubini @ 2011-11-17 23:30 UTC (permalink / raw)
To: akpm, fujita.tomonori, tglx, mingo, hpa, x86, linux-kernel
Cc: giancarlo.asnaghi, maddalena.brattoli, alan
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: a question on DMA and remapping
2011-11-17 23:30 a question on DMA and remapping Alessandro Rubini
@ 2011-11-17 23:47 ` Andrew Morton
2011-11-22 23:00 ` Alan Cox
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2011-11-17 23:47 UTC (permalink / raw)
To: Alessandro Rubini
Cc: fujita.tomonori, tglx, mingo, hpa, x86, linux-kernel,
giancarlo.asnaghi, maddalena.brattoli, alan
On Fri, 18 Nov 2011 00:30:59 +0100
Alessandro Rubini <ru@gnudd.com> wrote:
> 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.
Sounds OK. swiotlb.c isn't exactly super-fast code anyway.
> - copying lib/swiotlb.c to my own file, which will be almost
> identical to the existing one but for a few lines.
Don't do that ;)
> 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.
Generalising the existing code to cover more cases isn't a bad thing to
do. Others might be able to use it, and they surely won't be able to
use any cloned-and-owned swiotlb.c.
Please do carefully docment the new interfaces so others can understand
why they exist and can use them successfully.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: a question on DMA and remapping
2011-11-17 23:47 ` Andrew Morton
@ 2011-11-22 23:00 ` Alan Cox
0 siblings, 0 replies; 3+ messages in thread
From: Alan Cox @ 2011-11-22 23:00 UTC (permalink / raw)
To: Andrew Morton
Cc: Alessandro Rubini, fujita.tomonori, tglx, mingo, hpa, x86,
linux-kernel, giancarlo.asnaghi, maddalena.brattoli
> Generalising the existing code to cover more cases isn't a bad thing
> to do. Others might be able to use it, and they surely won't be able
> to use any cloned-and-owned swiotlb.c.
If you look on the kernel list there has also been some discussion and
work recently towards removing a lot of the duplication between the
iommu devices.
I think really you need to be an actual iommu instance because in
reality you are. Trying to fudge it any other way breaks the moment
someone tries to do a device to device DMA transfer because your
bus/phys mapping seen from your device and the bus/phys mapping seen
from another device into your device do not match as I understand it.
Alan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-11-22 22:48 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-17 23:30 a question on DMA and remapping Alessandro Rubini
2011-11-17 23:47 ` Andrew Morton
2011-11-22 23:00 ` Alan Cox
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.