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@xxxxxxxxxxxx> 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
------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
