Messages in this thread | | | Date | Thu, 12 Apr 2012 22:15:33 +0200 | From | Alessandro Rubini <> | Subject | Re: [PATCH V4 1/3] x86: introduce CONFIG_X86_DEV_DMA_OPS |
| |
Peter Anvin: > I looked over it, and at least this bit seems okay to me. > > Acked-by: H. Peter Anvin <hpa@zytor.com>
Thanks.
> I have to express some concern about where this device may be going, > though.
Well, this CONFIG_X86_DEV_DMA_OPS in particular should not be concerning, as it's just separating out an x86-64 ifdef so it can be used and activated by 32-bit systems as well.
As for "this device", it's an I/O Hub that can be used as main chipset on Atom computers, mainly aimed at the automotive sector. It is a typical ARM SoC with the usual set of internal peripherals, mounted on a bridge between PCIe and AMBA, so the PCIe host can access the SoC peripherals -- and SoC peripherals can DMA to PCIe memory. Actually, some SoC devices work well using the existing amba drivers, with minimal changes that I plan to clean up and submit soon.
The strange DMA requirements here depend on the size limits of the respective windows: SoC devices can only access a 512MB window of the host memory, so we need to take care of this with special options.
The current approach is using swiotlb and it works pretty well, though with a limit of 4MB of swiotlb area. I've been considering use of the DMA zone to this aim: internally I have some half-working thing that resuses the ISA DMA zone for our own aims, raising the DMA limit to 512MB.
Do you think the approach may make sense? I use this basic thing in Kconfig, to rely on GFP_DMA for the rest:
config MAX_DMA_PADDR int default 536870912 if MAX_DMA_PADDR_512M default 16777216
config MAX_DMA_PADDR_512M bool
(actually, we'd benefit from being able to use hex in defaults)
Is this worth exploring, to possibly submit a patch in this direction?
thanks /alessandro
| |