> -----Original Message----- > From: Jesse Barnes [mailto:jbarnes@xxxxxxxxxxxxxxxx] > Sent: Friday, January 21, 2011 3:42 AM > To: Guan Xuetao > Cc: sfr@xxxxxxxxxxxxxxxx; Arnd Bergmann; gregkh@xxxxxxx; dmitry.torokhov@xxxxxxxxx; dtor@xxxxxxx; rubini@xxxxxxxxxxxxx; linux- > arch@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-fbdev@xxxxxxxxxxxxxxx; linux-next@xxxxxxxxxxxxxxx > Subject: Re: Request for unicore32 architecture codes to merge into linux-next > > On Sun, 16 Jan 2011 01:00:31 +0800 > "Guan Xuetao" <guanxuetao@xxxxxxxxxxxxxxx> 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 <gxt@xxxxxxxxxxxxxxx> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
