From patchwork Mon Jun 29 06:37:58 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 32888 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n5T6dBuS010586 for ; Mon, 29 Jun 2009 06:39:11 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751695AbZF2GjF (ORCPT ); Mon, 29 Jun 2009 02:39:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753325AbZF2GjF (ORCPT ); Mon, 29 Jun 2009 02:39:05 -0400 Received: from smtp.nokia.com ([192.100.105.134]:59671 "EHLO mgw-mx09.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751695AbZF2GjD convert rfc822-to-8bit (ORCPT ); Mon, 29 Jun 2009 02:39:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5T6baFd001039; Mon, 29 Jun 2009 01:38:11 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:38:02 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 09:38:01 +0300 Received: from cseresznye.localnet (cseresznye.ntc.nokia.com [172.22.144.108]) by mgw-da02.ext.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n5T6btUS030477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 09:37:56 +0300 From: Peter Ujfalusi To: ext Janusz Krzysztofik Subject: Re: [PATCH] [RFC] ASoC: OMAP: fix OMAP1510 broken PCM pointer callback Date: Mon, 29 Jun 2009 09:37:58 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; i686; ; ) Cc: Jarkko Nikula , Tony Lindgren , "alsa-devel@alsa-project.org" , "linux-omap@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <200906280021.05931.jkrzyszt@tis.icnet.pl> <20090628223732.53954402.jhnikula@gmail.com> <200906290008.59640.jkrzyszt@tis.icnet.pl> In-Reply-To: <200906290008.59640.jkrzyszt@tis.icnet.pl> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906290937.58786.peter.ujfalusi@nokia.com> X-OriginalArrivalTime: 29 Jun 2009 06:38:02.0490 (UTC) FILETIME=[26AB45A0:01C9F884] X-Nokia-AV: Clean Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Monday 29 June 2009 01:08:59 ext Janusz Krzysztofik wrote: > > 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. Hmmm, I had taken a look at the 2.4.21 kernel sources, which I have laying around in my disk from an old project which used OMAP1510. The OSS audio code does use the CPC register for determining the DMA progress both for playback and recording. I know that the audio was working OK on that board, since we had doom running there. The difference that I can see is that the OSS code also configured the CCR:SYNC(4:0) bits as well. Looking at the DMA_CPC register description in the OMAP1510 TRM: it list two cases on how it behaves and both require the DMA_CCR:SYNC != 0... The current DMA code for OMAP1510 just plain ignores the DMA_CCR:SYNC for some reason. Can you try the following patch: iff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 7fc8c04..38874e4 100644 ccr = dma_read(CCR2(lch)); Than can you print out in case of playback both the destination and source addresses supplied to the DMA, than in the pointer callback also print out the value returned by the omap_get_dma_src_pos function to see if this actually helps? Acked-by: Peter Ujfalusi --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count, ccr &= ~(1 << 5); if (sync_mode == OMAP_DMA_SYNC_FRAME) ccr |= 1 << 5; + if (dma_trigger) + ccr |= dma_trigger & 0x1f; dma_write(ccr, CCR(lch));