linux-kernel - Re: [PATCH] [RFC] ASoC: OMAP: fix OMAP1510 broken PCM pointer callback

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]

Message-Id: <200906290008.59640.jkrzyszt@tis.icnet.pl>
Date:	Mon, 29 Jun 2009 00:08:59 +0200
From:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
To:	Jarkko Nikula <jhnikula@...il.com>
Cc:	Peter Ujfalusi <peter.ujfalusi@...ia.com>,
	Tony Lindgren <tony@...mide.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] ASoC: OMAP: fix OMAP1510 broken PCM pointer callback

On Sunday 28 June 2009 21:37:32 Jarkko Nikula wrote:
> On Sun, 28 Jun 2009 00:21:05 +0200
> Janusz Krzysztofik <jkrzyszt@....icnet.pl> wrote:
> > This patch tries to work around the problem of broken OMAP1510 PCM
> > playback pointer calculation by replacing DMA function call that
> > incorrectly tries to read the value form DMA hardware with a value
> > computed locally from an already maintained variable
> > omap_runtime_data.period_index.
> >
> > Tested on OMAP5910 based Amstrad Delta (E3) using work in progress
> > ASoC driver.
> >
> > Based on linux-2.6-asoc.git v2.6.31-rc1.
> >
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@....icnet.pl>
> > ---
> > It seems that on OMAP1510, DMA Channel Progress Counter registers
> > (DMA_CPC_CH[0-8]) always contain values derived from DMA channels
> > destination port address, even if constant, and there are no DMA
> > registers available that would follow DMA channels source port
> > address. Because of this limitation, current implementation of
> > omap_get_dma_src_pos() for OMAP1510 is broken and doesn't seem to be
> > easy correctable.
>
> Hi
>
> Before going into workaround, did you try to change function
> omap_get_dma_src_pos to read CSSA_L instead of CPC in
> arch/arm/plat-omap/dma.c that I was speculating in mail below?
>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2009-June/018569.html
>
> While CPC seems to be correct [1], you mentioned before that patch below
> broke the older ALSA driver so it's worth to find out if the problem
> can be corrected by simple one line fix (or two if omap_get_dma_dst_pos
> need to be fixed as well).
>
> http://marc.info/?l=linux-omap&m=121280267705523

Jarkko,

AFAIK, both CSSA_L and CDSA_L DMA registers are static. Loaded by CPU with 16 
LSB of initial source and destination port addresses respectively, they are 
never updated by the DMA engine itself. That's why they can't be used for 
transfer progress indication unless updated by CPU.

The old omap-alsa driver was just updating them, intentionally or not, by 
reprogramming and restarting DMA every PCM period. That's why calculating PCM 
pointers from CSSA_L/CDSA_L worked.

ASoC OMAP driver transfers whole PCM buffer with single DMA transfer, so it 
doesn't need to update DMA source/destination port address after initial 
playback/capture setup, even if restarting DMA, and actually never does this. 
Calculating PCM pointers from CSSA_L/CDSA_L registers without updating them 
every period would then be wrong.

For capture, reading CPC, that follows destination port address progress, just 
works fine (for both old and new driver). For playback, similar hardware 
functionality seems to be missing, so it has to be emulated in software if 
required.

Thanks,
Janusz
--
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/