From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Thomas Subject: Re: OMAP Audio Date: Wed, 17 Feb 2010 03:43:56 -0700 Message-ID: <4B7BC86C.8040905@mlbassoc.com> References: <4B7AE1AD.7080400@mlbassoc.com> <20100217090339.c11d2e8a.jhnikula@gmail.com> <201002171226.05108.peter.ujfalusi@nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from hermes.mlbassoc.com ([76.76.67.137]:49880 "EHLO mail.chez-thomas.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659Ab0BQKoB (ORCPT ); Wed, 17 Feb 2010 05:44:01 -0500 In-Reply-To: <201002171226.05108.peter.ujfalusi@nokia.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Peter Ujfalusi Cc: ext Jarkko Nikula , OMAP Linux discussion On 02/17/2010 03:26 AM, Peter Ujfalusi wrote: > On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote: >> On Tue, 16 Feb 2010 11:19:25 -0700 >> >> Gary Thomas wrote: >>> I need to connect the OMAP (3530) to a 24bit CODEC. So far >>> my attempts at getting this to go have not gone well. Then >>> >>> I ran across this comment in sound/soc/omap/omap-pcm.c: >>> /* >>> >>> * Note: Regardless of interface data formats supported by OMAP McBSP >>> * or EAC blocks, internal representation is always fixed 16-bit/sample >>> */ >>> >>> Does this mean that this setup is just not supported? even though >>> the hardware can handle it? >> >> Yep, comment is bit misleading but true until some patch will remove >> it. IRCC, the EAC was limited to 16-bit and also there wasn't need and >> HW to test other formats than S16_LE in McBSP DAI. >> >>> Thanks for any pointers or ideas on how to get this going. >> >> I would first start adding support for the S32_LE into omap-pcm.c (DMA >> part). Worth to look this thread: >> >> http://mailman.alsa-project.org/pipermail/alsa-devel/2010-January/024704.ht >> ml >> >> Then add support for this format to the omap-mcbsp.c (link >> configuration part). >> >> Next step would be to add support for the S24_LE on 4-byte boundaries. >> I.e. the DMA is moving 32-bit samples between the memory and McBSP but >> only 24-bits are transferred over the McBSP and codec. > > Hmmm, I think this is a bit more complicated than that at least on OMAP3. > I think the DMA engine should also move 24 bit words. > This is dictated by the McBSP FIFO: it has a notion of word size, and it is > expecting that the DMA engine will move THRESHOLD number of words. So if the > McBSP is configured for 24 bit words, than the DMA word size has to match that. > > Apart from this, the constraint set for the period bytes need to be changed > since as you change the word size in McBSP you will have different amount of > actual bytes for the FIFO (the FIFO size is in words, and the maximum word size > is 32 bit). > Thanks for the help. I'm pretty sure I understand how to change the McBSP code (omap-mcbsp.c) to handle the various formats, but I'm a bit lost in the DMA setup (omap-pcm.c). How do I identify the code/width in omap_pcm_prepare()? Has no one ever used the OMAP/McBSP with data sizes other than 16 bits?? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------