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

[Guan Xuetao]

> -----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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/