From patchwork Wed Jun 10 10:53:42 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 29250 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 n5AAt3Oo016084 for ; Wed, 10 Jun 2009 10:55:03 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753069AbZFJKy7 (ORCPT ); Wed, 10 Jun 2009 06:54:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753481AbZFJKy7 (ORCPT ); Wed, 10 Jun 2009 06:54:59 -0400 Received: from smtp.nokia.com ([192.100.122.233]:64282 "EHLO mgw-mx06.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753069AbZFJKy6 convert rfc822-to-8bit (ORCPT ); Wed, 10 Jun 2009 06:54:58 -0400 Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n5AArdM8024063; Wed, 10 Jun 2009 13:54:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 13:53:47 +0300 Received: from mgw-da01.ext.nokia.com ([147.243.128.24]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 13:53:46 +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 n5AArfGj013797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 13:53:42 +0300 From: Peter Ujfalusi To: ext Janusz Krzysztofik Subject: Re: [alsa-devel] Please help in adding ams-delta support to ASoC Date: Wed, 10 Jun 2009 13:53:42 +0300 User-Agent: KMail/1.11.4 (Linux/2.6.29-gentoo-r5; KDE/4.2.4; i686; ; ) Cc: "linux-omap@vger.kernel.org" , "alsa-devel@vger.kernel.org" References: <4A1BEBE3.8010306@tis.icnet.pl> <200906101112.32635.peter.ujfalusi@nokia.com> <200906101227.39856.jkrzyszt@tis.icnet.pl> In-Reply-To: <200906101227.39856.jkrzyszt@tis.icnet.pl> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906101353.43411.peter.ujfalusi@nokia.com> X-OriginalArrivalTime: 10 Jun 2009 10:53:46.0409 (UTC) FILETIME=[BA824190:01C9E9B9] X-Nokia-AV: Clean Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote: > Not only this. AFAICS, there is no way of specifying single phase stereo > (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)). > Isn't this required for correct DSP_A/DSP_B support? Sure it is possible: format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK; wpf = channels = params_channels(params); switch (channels) { case 2: if (format == SND_SOC_DAIFMT_I2S) { /* Use dual-phase frames */ regs->rcr2 |= RPHASE; regs->xcr2 |= XPHASE; /* Set 1 word per (McBSP) frame for phase1 and phase2 */ wpf--; regs->rcr2 |= RFRLEN2(wpf - 1); regs->xcr2 |= XFRLEN2(wpf - 1); } case 1: case 4: /* Set word per (McBSP) frame for phase1 */ regs->rcr1 |= RFRLEN1(wpf - 1); regs->xcr1 |= XFRLEN1(wpf - 1); break; default: /* Unsupported number of channels */ return -EINVAL; } wpf = channels == 2, format is not I2S --> RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), RFRLEN1(2 - 1), XFRLEN1(2 - 1) > > > But you should be able to use the playback with the current ASoC. > > Definitelly yes. I am aware that the above limitations have nothing to do > with the main problem, as with current mcbsp code I should always be able > to get some kind of noise at least using one of supported formats, as far > as clocking is set up correctly. > > > --- 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)); > > > > ccr = dma_read(CCR2(lch)); > > Applied, sorry, did not help (with capture, unlike playback, set up for > internal clocking for as much device isolation as possible). I would have guessed this, since even when the DMA was not HW synced, it did not sent a single bit to the McBSP DXR1 register... Just out of curiosity, can you try this one as well: basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101) With this, if McBSP is operating correctly you should be seeing this pattern going to the codec. If it does, than we have some problems with the McBSP/DMA cooperation, if this pattern is not seen on the bus, than the McBSP is not shifting data out for some reason. > > > I would expected that by just copying (I know that there are other things > > involved) the old ALSA arm directory to the latest kernel and compiling > > it should be working... It seams I was wrong. > > Anyway, if you find porting one or another framework, back or forward, > helpfull in any way, just let me know, I can try. I'm not sure if it could prove anything at the end. There are - I think - other moving parts, which can break things. > > Thanks, > Janusz --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: if (!mcbsp_data->active++) omap_mcbsp_start(mcbsp_data->bus_id); + omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0xdb55); break;