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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 14 Oct 2011 20:36:15 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Barry Song <21cnbao@...il.com>
Cc:	Jassi Brar <jaswinder.singh@...aro.org>,
	linux-kernel@...r.kernel.org, dan.j.williams@...el.com,
	rmk@....linux.org.uk,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>
Subject: Re: [PATCHv5] DMAEngine: Define interleaved transfer request api

On Fri, 2011-10-14 at 22:55 +0800, Barry Song wrote:
> Hi Vinod,
> 
> 2011/10/14 Vinod Koul <vinod.koul@...el.com>:
> > On Fri, 2011-10-14 at 17:21 +0530, Jassi Brar wrote:
> >> On 14 October 2011 13:02, Barry Song <21cnbao@...il.com> wrote:
> >> >
> >> > what if i want a cyclic interleaved transfer? i think the cyclic
> >> > interleaved transfer is what i want for audio dma.
> >> >
> >> ... we need to restore 'bool frm_irq' and add new 'bool cyclic' that
> >> would replay the transfer(i.e, reset dma-pointers to src_start & dst_start)
> >> after 'numf' frames have been transferred.
> > I was thinking more on lines to have this conveyed thru a flag.
> >
> > Anyway I plan to work on merging device_prep_slave_sg and
> > device_prep_cyclic to single API. Think more of device_prep_cyclic as
> > special case with sg length one and flag to tell dmac its cyclic.
> >
> > Similarly here we could use/define this flag to say this transfer is
> > also cyclic in nature and dmac then reloads the list again.
> > That way any prep can be made cyclic in nature by just using this flag.
> >
> > @Barry: Why would you need to use interleaved API for audio?
> 
> At first, audio dma is typically cyclic. if no underflow and overflow
> happens, it will always be running. underflow and overflow will
> trigger the cyclic dma termination.
Yes and you terminate dma. Then prepare will be called again and you
setup DMA again and on trigger start you start DMA again.
No need for interleaving in this case.
> 
> in case audio PCM data is interleaved and saved in dma buffer  as below:
> 
> left (2B)  right (2B)  left (2B)  right (2B)   left (2B)  right (2B)
> left (2B)  right (2B)
> left (2B)  right (2B)  left (2B)  right (2B)   left (2B)  right (2B)
> left (2B)  right (2B)
> left (2B)  right (2B)  left (2B)  right (2B)   left (2B)  right (2B)
> left (2B)  right (2B)
> left (2B)  right (2B)  left (2B)  right (2B)   left (2B)  right (2B)
> left (2B)  right (2B)
> ,,,,
> 
> and some hardwares need two seperate dma channels to tranfer left and
> right audio channel.
> 
> For 1st and 2nd dma channel, they want dma address increases 4bytes
> and transfer 2bytes every line.
> so it looks to me like a cyclic interleaved dma.
Hmmm, do we have sound cards which use this?
Nevertheless for this kind of transfers we would need interleaved cyclic
DMA as well, Do you have such usage? Can you tell me which codec
requires this?


-- 
~Vinod

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ