Thread (12 messages) 12 messages, 5 authors, 2011-01-22

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help