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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 22 Jan 2011 10:17:16 +0800
From:	"Guan Xuetao" <guanxuetao@...c.pku.edu.cn>
To:	"'Jesse Barnes'" <jbarnes@...tuousgeek.org>
Cc:	<sfr@...b.auug.org.au>, "'Arnd Bergmann'" <arnd@...db.de>,
	<gregkh@...e.de>, <dmitry.torokhov@...il.com>, <dtor@...l.ru>,
	<rubini@...l.unipv.it>, <linux-arch@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-fbdev@...r.kernel.org>,
	<linux-next@...r.kernel.org>
Subject: RE: Request for unicore32 architecture codes to merge into linux-next



> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@...tuousgeek.org]
> Sent: Friday, January 21, 2011 3:42 AM
> To: Guan Xuetao
> Cc: sfr@...b.auug.org.au; Arnd Bergmann; gregkh@...e.de; dmitry.torokhov@...il.com; dtor@...l.ru; rubini@...l.unipv.it; linux-
> arch@...r.kernel.org; linux-kernel@...r.kernel.org; linux-fbdev@...r.kernel.org; linux-next@...r.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" <guanxuetao@...c.pku.edu.cn> 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@...c.pku.edu.cn>
> > ---
> 
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/