From patchwork Tue Jun 9 07:12:41 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 28868 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 n597I6Nq007523 for ; Tue, 9 Jun 2009 07:18:06 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756587AbZFIHR7 (ORCPT ); Tue, 9 Jun 2009 03:17:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755573AbZFIHR7 (ORCPT ); Tue, 9 Jun 2009 03:17:59 -0400 Received: from smtp.nokia.com ([192.100.105.134]:50580 "EHLO mgw-mx09.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754044AbZFIHR6 convert rfc822-to-8bit (ORCPT ); Tue, 9 Jun 2009 03:17:58 -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 n597DKFF003027; Tue, 9 Jun 2009 02:13:52 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:13:15 +0300 Received: from mgw-da01.ext.nokia.com ([147.243.128.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 10:12:45 +0300 Received: from cseresznye.localnet (cseresznye.ntc.nokia.com [172.22.144.108]) by mgw-da01.ext.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n597Cct8026459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 10:12:40 +0300 From: Peter Ujfalusi To: alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Please help in adding ams-delta support to ASoC Date: Tue, 9 Jun 2009 10:12:41 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; i686; ; ) Cc: ext Janusz Krzysztofik , Mark Brown , "linux-omap@vger.kernel.org" , "alsa-devel@vger.kernel.org" References: <4A1BEBE3.8010306@tis.icnet.pl> <20090605224532.GA12995@sirena.org.uk> <200906061942.14276.jkrzyszt@tis.icnet.pl> In-Reply-To: <200906061942.14276.jkrzyszt@tis.icnet.pl> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906091012.41800.peter.ujfalusi@nokia.com> X-OriginalArrivalTime: 09 Jun 2009 07:12:46.0000 (UTC) FILETIME=[B046AB00:01C9E8D1] X-Nokia-AV: Clean Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org Hello Janusz, On Saturday 06 June 2009 20:42:12 ext Janusz Krzysztofik wrote: > I'm not sure how that could happen, but I was wrong with some of those > figures. After looking at the scope several more times I can only confirm > that master clock really runs at 2MHz (0,5µs period). Frame sync is rather > closer to 8kHz (~125µs period) than previously estimated 10kHz, with the > same symmetric (50% fill) shape as before. But bit clock is very different > from what I have seen before. It runs at 2MHz in 9µs long packets (18 > periods), those are repeated every half period of frame sync (~62µs / > 16kHz), ie every frame sync edge, both rising and falling. There is also a > signal present on codec data output: 4µs long packets (8 bits each?) every > ~62µs (16 kHz). I'm kind of bad at visualizing things, is it possible to put somewhere the screenshoot of the scope showing at least one sample? > > Is it possible that the codec speeks I2S, with 8-bit word, 1 word per > frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can > read in modem documentation, this should rather be one 8-bit channel at > 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope > be matched against any format that mcbsp can be set with current code? I have been looking for clues around the net, and it seams that the codec in question has stereo 16 bit format. > > I'm still far from understanding mcbsp, but I wonder what happens if the > bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this > is the cause of dma interrupts not being generated? > Without actual OMAP1510 HW it is really hard to tell what can be the problem. What I would do, if I had a HW: 1) See if the DMA actually was running and it is 'just' about the missing interrupt: break; Than start a playback, and stop it with CTRL+C, see if the two pointers are different... 2) I would I think try to port the 2.6.28 pure ALSA version to the head of l- o, with minimal (only the needed) changes and see if it is still working. I know, this is a long shot, but at least we can be sure, that the problem is in the ASoC McBSP/DMA integration or it is something else. Meanwhile I'll try to locate one OMAP1510 based board to try to help with this issue. --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd->period_index = 0; omap_start_dma(prtd->dma_ch); + printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n", + (unsigned)omap_get_dma_src_pos(prtd->dma_ch)); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n", + (unsigned)omap_get_dma_src_pos(prtd->dma_ch)); prtd->period_index = -1; omap_stop_dma(prtd->dma_ch);