OMAP Audio

OMAP Audio

[Gary Thomas]

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?

Thanks for any pointers or ideas on how to get this going.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: OMAP Audio

[Jarkko Nikula]

On Tue, 16 Feb 2010 11:19:25 -0700
Gary Thomas <gary@mlbassoc.com> 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.html

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.


-- 
Jarkko

Re: OMAP Audio

[Peter Ujfalusi]

On Wednesday 17 February 2010 09:03:39 ext Jarkko Nikula wrote:
> On Tue, 16 Feb 2010 11:19:25 -0700
> 
> Gary Thomas <gary@mlbassoc.com> 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).

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP Audio

[Gary Thomas]

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<gary@mlbassoc.com>  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
------------------------------------------------------------

Re: OMAP Audio

[Peter Ujfalusi]

On Wednesday 17 February 2010 12:43:56 ext Gary Thomas wrote:
> 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<gary@mlbassoc.com>  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()?

After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data 
types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit 
packed format.
I would go with a trial and error method and find it out how it is working...

> Has no one ever used the OMAP/McBSP with data sizes other than 16 bits??

At least I can not recall. I have had a plan to add support for these, but it 
got delayed and delayed ;)

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP Audio

[Gary Thomas]

On 02/17/2010 04:17 AM, Peter Ujfalusi wrote:
> On Wednesday 17 February 2010 12:43:56 ext Gary Thomas wrote:
>> 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<gary@mlbassoc.com>   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()?
>
> After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data
> types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit
> packed format.
> I would go with a trial and error method and find it out how it is working...
>
>> Has no one ever used the OMAP/McBSP with data sizes other than 16 bits??
>
> At least I can not recall. I have had a plan to add support for these, but it
> got delayed and delayed ;)
>

How about sending padded data (24 bits in 32) which is what my
CODEC wants anyway?  Would this be easier to set up?  How?

(Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
need to be moving 24 or 32 bit chunks)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: OMAP Audio

[Jarkko Nikula]

On Wed, 17 Feb 2010 05:01:53 -0700
Gary Thomas <gary@mlbassoc.com> wrote:

> > After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data
> > types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit
> > packed format.
> > I would go with a trial and error method and find it out how it is working...
> >
So it looks that the memory representation must be 32-bit.

> How about sending padded data (24 bits in 32) which is what my
> CODEC wants anyway?  Would this be easier to set up?  How?
> 
> (Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
> need to be moving 24 or 32 bit chunks)
> 
Internal representation and link configuration are separate things:

DMA <-> McBSP rx/tx reg <- [FIFO] -> McBSP receiver/transmitter

As Peter found, due the DMA and McBSP FIFO, the DMA configuration must
be 32-bit. But I suppose the McBSP receiver/ransmitter could be
configured to transmit only 24-bits.

The OMAP35x Applications Processor Multi-Channel Buffered Serial Port
(McBSP) TRM (SPRUFD1C) seems to have some examples for different data
lengths than internal word length. Worth to look and try with trial and
error method using oscilloscope :-)


-- 
Jarkko

Re: OMAP Audio

[Gary Thomas]

On 02/17/2010 10:45 AM, Jarkko Nikula wrote:
> On Wed, 17 Feb 2010 05:01:53 -0700
> Gary Thomas<gary@mlbassoc.com>  wrote:
>
>>> After looking at the TRM of OMAP, the sDMA has support for 8, 16 and 32 bit data
>>> types. So I'm not really sure how to configure McBSP and sDMA in case of 24 bit
>>> packed format.
>>> I would go with a trial and error method and find it out how it is working...
>>>
> So it looks that the memory representation must be 32-bit.
>
>> How about sending padded data (24 bits in 32) which is what my
>> CODEC wants anyway?  Would this be easier to set up?  How?
>>
>> (Again, I'm a bit fuzzy on how to tell omap_pcm_prepare that I
>> need to be moving 24 or 32 bit chunks)
>>
> Internal representation and link configuration are separate things:
>
> DMA<->  McBSP rx/tx reg<- [FIFO] ->  McBSP receiver/transmitter
>
> As Peter found, due the DMA and McBSP FIFO, the DMA configuration must
> be 32-bit. But I suppose the McBSP receiver/ransmitter could be
> configured to transmit only 24-bits.
>
> The OMAP35x Applications Processor Multi-Channel Buffered Serial Port
> (McBSP) TRM (SPRUFD1C) seems to have some examples for different data
> lengths than internal word length. Worth to look and try with trial and
> error method using oscilloscope :-)

Thanks.  I'd really like to understand how to set things up to generate
the data I see in TRM:
   Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding bits at ‘0’.

This matches my CODEC.  Any clues?

BTW, I was able to set things up for 32 bit PCM data, based on
the email thread you pointed at.  Still need the funky 24 bit
stuff though.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP Audio

[Mark Brown]

On Wed, Feb 17, 2010 at 10:51:11AM -0700, Gary Thomas wrote:

> Thanks.  I'd really like to understand how to set things up to generate
> the data I see in TRM:
>   Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding bits at ?0?.
>
> This matches my CODEC.  Any clues?

Does your CODEC actually need the padding bits to be zero?  What you're
describing sounds an awful lot like 32 bit data that just has the LSB
ignored.

Re: OMAP Audio

[Gary Thomas]

On 02/17/2010 10:56 AM, Mark Brown wrote:
> On Wed, Feb 17, 2010 at 10:51:11AM -0700, Gary Thomas wrote:
>
>> Thanks.  I'd really like to understand how to set things up to generate
>> the data I see in TRM:
>>    Figure 21-11 shows an example with 24 bits data (MSB first) and 8 padding bits at ?0?.
>>
>> This matches my CODEC.  Any clues?
>
> Does your CODEC actually need the padding bits to be zero?  What you're
> describing sounds an awful lot like 32 bit data that just has the LSB
> ignored.

I don't think it matters.  The real problem is how to get 24 bits
of data aligned to the right place in the 32 bit frame.  TRM implies
that the hardware can do this, I've just not figured out the magic...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

RE: OMAP Audio

[Stehle, Vincent]

Gary Thomas:
> I don't think it matters.  The real problem is how to get 24 bits
> of data aligned to the right place in the 32 bit frame.  TRM implies
> that the hardware can do this, I've just not figured out the magic...

Hi,

I asked a colleague, who worked on OMAP3 McBSP silicon validation. She told me that in your case, you will need to send 32 bits of data and that you will have to pad your data beforehand in software.

Best regards,

--
Vincent Stehlé

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html