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>] [day] [month] [year] [list]
Date:	Thu, 16 May 2013 02:18:40 +0000 (GMT)
From:	Jingoo Han <jg1.han@...sung.com>
To:	Tomasz Figa <t.figa@...sung.com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	Heiko St?bner <heiko@...ech.de>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Dan Williams <djbw@...com>, Vinod Koul <vinod.koul@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Jingoo Han <jg1.han@...sung.com>
Subject: Re: [RFC 2/4] dma: add dmaengine driver for Samsung s3c24xx SoCs

On Tuesday, May 14, 2013 11:22 PM Tomasz Figa wrote:
> 
> Hi Linus, Heiko,
> 
> On Tuesday 14 of May 2013 14:47:19 Linus Walleij wrote:
> > On Sat, May 11, 2013 at 1:31 PM, Heiko St?bner <heiko@...ech.de> wrote:
> > > Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
> > > with numerous virtual channels being mapped to a lot less physical ones.
> > > The driver therefore borrows a lot from the amba-pl08x driver in this
> > > regard. Functionality-wise the driver gains a memcpy ability in addition
> > > to the slave_sg one.
> > >
> > > The driver currently only supports the "newer" SoCs which can use any
> > > physical channel for any dma slave. Support for the older SoCs where
> > > each channel only supports a subset of possible dma slaves will have to
> > > be added later.
> > >
> > > Tested on a s3c2416-based board, memcpy using the dmatest module and
> > > slave_sg partially using the spi-s3c64xx driver.
> > >
> > > Signed-off-by: Heiko Stuebner <heiko@...ech.de>
> >
> > So have I understood correctly if I assume that *some* S3C
> > variants, i.e. this: arch/arm/mach-s3c64xx/dma.c
> > have a vanilla, unmodified, or just slightly modified
> > PL08x block, while this DMAC is something probably based on
> > the PL08x where some ASIC engineer has had a good time hacking
> > around in the VHDL code to meet some feature requirements.
> > Correct? Or plausible guess?
> >
> > Exactly *how* far away from the pl08x hardware is it?
> 
> AFAIK the DMAC of S3C24xx is completely different from PL08x. I think Heiko
> just meant that it uses similar concepts, like virtual channels.

Yes, right.
the DMAC of S3C24xx is completely different from PL08x.
As Heiko mentioned, the DMAC of S3C24xx is 'home grown' as other IPs of S3C24xx.

Best regards,
Jingoo Han

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ