RE: Request for unicore32 architecture codes to merge into linux-next
From: Guan Xuetao <hidden>
Date: 2011-01-22 02:17:53
Also in:
linux-arch, linux-fbdev, lkml
-----Original Message----- From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org] Sent: Friday, January 21, 2011 3:42 AM To: Guan Xuetao Cc: sfr@canb.auug.org.au; Arnd Bergmann; gregkh@suse.de; dmitry.torokhov@gmail.com; dtor@mail.ru; rubini@cvml.unipv.it; linux- arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-next@vger.kernel.org Subject: Re: Request for unicore32 architecture codes to merge into linux-next On Sun, 16 Jan 2011 01:00:31 +0800 "Guan Xuetao" [off-list ref] wrote:quoted
Hi, I want to merge unicore32 repo into linux-next tree, the position is (unicore32 branch): git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git Signed-off-by: Guan Xuetao <redacted> ---Took a quick look at the PCI parts, looks like you have a pretty big DMA restriction.
Yes, only 128MB low memory could be used as dma space for pci devices.
You could provide your own dma map ops and make the allocator a bit smarter about where it gets memory (preferentially allocating from the DMA'able region, which you could hide). Or do you find that swiotlb does ok in general?
Swiotlb works well. For almost all functions are provided by IPs inside the SoC, the dma function is used mainly through amba/axi bus, not pci bus.
Other than that you had pretty tiny bits of enabling code, I assume they work on your platform (config space access & setup, etc.).
Yes.
-- Jesse Barnes, Intel Open Source Technology Center
Thanks Jesse Guan Xuetao