Subject: RE: Request for unicore32 architecture codes to merge into linux-next

From: "Guan Xuetao" <[email-masked]>
Date: Sat, 22 Jan 2011 10:17:16 +0800

> -----Original Message-----
> From: Jesse Barnes [mailto:[email-masked]]
> Sent: Friday, January 21, 2011 3:42 AM
> To: Guan Xuetao
> Cc: [email-masked]; Arnd Bergmann; [email-masked]; [email-masked]; [email-masked]; [email-masked]; linux-
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Sun, 16 Jan 2011 01:00:31 +0800
> "Guan Xuetao" <[email-masked]> wrote:
> 
> > 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 <[email-masked]>
> > ---
> 
> 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