McBSP codec connection

Hi all,

I've just received a C2 and I'm a newbee Beagleboarder !!

In my project, I got a prototype newly designed board with a codec on
it and it has its own circuitry for 12.288MHz clock generation and is
I2C controlled.
So the codec is working in master mode thus the McBSP should work in
slave.

The first question is if that can be done since I've read in some
posts that there are issues with McBSP being in slave mode.
And the second question, is if its there any other codec example that
utilizes both of the free McBSP ports and not just one as the TLW4030,
since in my codec I'll use two stereo I2S I/O connections.

Thank you,
Christos

Hi,

With the original twl4030, the beagle acts as slave and the codec is master

Also, to set the beagle as master is also posible.

I used McBSP3, and for that you will need to do some pinmuxing, since by default the pins are GPIO.

Another thing I had trouble with is the buffer size, McBSP3 is recommended for voice. I couldn`t play anything faster than 16khz.

BR,
Ernesto

Thank you for answering.

But I have to say ...ooops

I need 192KHz on two stereo bidirectional I2S ports.
Are there so low speed limitations to the McBSP ports? Or can we
overcome the problem with some sort of buffer allocation?

Christos

Sorry, I don’t know to answer that with my current knowledge.

I tried at 48khz sample rate and get a lot of underruns, lowered the speed to 16khz and that was the best I could do.

From the OMAP35x TRM:
128 x 32-bit words (512 bytes) for each buffer for transmit/receive operations (McBSP1, 3, 4, 5)
also:
Independent clocking and framing for reception and for transmission up to 48 MHz

So it may be posible, unfortunately it is out of my reach.

-Ernesto

2009/5/25 sv1eia <sv1eia@gmail.com>

Did you utilized a modified version of the TLW4030 codec driver in the
kernel sound sources?
Or a self written code?

I replaced the TWL4030 code with my own. I rewrite the functions according to my needs.

2009/5/25 sv1eia <sv1eia@gmail.com>

Hi Ernesto,

Glad to hear, that you made some progress. Just for my understanding – Is the audio clear and as expected running 16kHz? And did you end up using DMA for filling data into the McBSP? In that case you might be able to avoid the underruns by increasing the DMA access priority for the external memory system (I though do not expect this to be the problem, but you never know :-). At which threshold did you end up requesting a DMA transfer from the McBSP block? And which DMA transfer size/settings are you using?

Best regards

Søren

Ok,

I need to verify a few things before I proceed further.

I did read the TRM and it does not explicitly state what is the
maximum sample rate a McBSP can go but it gives just 'recommendations'
on the usage of each McBSP port.

Nevertheless it mention two conflicting things
1. On 21.2.4.3.1 it is saying that maximum I2S sample rate is 48 KHz
2. But on 2.1.1 it is saying "Clock and frame-synchronization
generation support: – Independent clocking and framing for reception
and for transmission up to 48 MHz" and if I translate it properly it
can have 48000000(2*32bits)=750KHz sampling rate maximum

So someone could point out what i really happening with McBSP maximum
sampling rate

Also McBSP2 has by definition better buffer allocation and I do not
know if that can be changed (probably not).

One more thing.
The TLW4030 driver that is used by many as a template has a 48KHz
maximum sampling rate but the omap aic23 driver has a maximum of 96KHz
so this is another contradiction.

Regarding ISR and DMA handling, it seems that they need to
specifically defined as kernel flags in order for the drivers to be
properly built (and be fast enough without x-runs I guess) but I do
not know what are these flags. I have not yet rebuilded a omap kernel
of my own.

So if someone can give some light to what is going on with McBSP and
specially how this port can have 192KHz I2S sampling rate would be
appreciated since I bought the beagleboard just for its I2S handling
and the low speed mentioned (16KHz) is a very nasty surprise..

Thanks,
Christos

Hi Christos,

Nevertheless it mention two conflicting things
1. On 21.2.4.3.1 it is saying that maximum I2S sample rate is 48 KHz
2. But on 2.1.1 it is saying "Clock and frame-synchronization
generation support: Independent clocking and framing for reception
and for transmission up to 48 MHz" and if I translate it properly it
can have 48000000(2*32bits)=750KHz sampling rate maximum

Maximum clock is 48MHz setting the limitation as outlined in your calculation - The McBSP does AFAIK not really care about sample rates, since it's just transferring serial data. I guess this is why the TRM might be a bit vague only gives indications, since it highly depends on numbers of channels, bits/sample etc....

Also McBSP2 has by definition better buffer allocation and I do not
know if that can be changed (probably not).

The 5KB buffer for McBSP2 is fixed in silicon and can to my knowledge not be changed...

The TLW4030 driver that is used by many as a template has a 48KHz
maximum sampling rate but the omap aic23 driver has a maximum of 96KHz
so this is another contradiction.

I think this difference more relates to the codec than to the McBSP IP - IAC23 being 96kHz compatible for both RX and TX, while TWL4030 only begin 48kHz compatible in both directions - Though supporting 96kHz for playback...

So if someone can give some light to what is going on with McBSP and
specially how this port can have 192KHz I2S sampling rate would be
appreciated since I bought the beagleboard just for its I2S handling
and the low speed mentioned (16KHz) is a very nasty surprise..

I would recommend using DMA transfers initiated from the McBSP IP block, but as stated previously by Ernesto Torres there might still be some work to be done before this is working straight out of the box. Seen from a HW point of view I though don't see any blocking points transferring a 192kHz stereo 16/24-bit signal although I haven't ever tried it...

Good luck
  Søren

Hi Søren,

Thanks for the info.
I'm still learning on the OMAP35x. :slight_smile:

I would recommend using DMA transfers initiated from the McBSP IP block, but as stated previously by Ernesto Torres there might still be some work to be done before this is working straight out of the box. Seen from a HW point of view I though don't see any blocking points transferring a 192kHz stereo 16/24-bit signal although I haven't ever tried it...

Is the DMA code there somewhere (I do not think I see it in omap
tlw4030 driver) in the McBSP codec driver files and it just needs some
compile flags or do we need to write/implement it from scratch
ourselves ?

Christos

I'm still learning on the OMAP35x. :slight_smile:

I think we are hopefully all learning each day :slight_smile:

Is the DMA code there somewhere (I do not think I see it in omap
tlw4030 driver) in the McBSP codec driver files and it just needs some
compile flags or do we need to write/implement it from scratch
ourselves ?

To be honest - I don't know since I have never really dealt with the McBSP
and Linux Audio system/sources myself. Only dealt with McBSP in non-OS and
Symbian-Environment some time ago. My understanding is that Ernesto stated
from scratch with his implementation, but I don't know for sure...

Best regards - Good luck
  Søren

Hi,

Basically I did four changes.

  1. On the beagle board change the use of mcbsp2 to mcbsp3
  2. Since my codec is slave and beagle is master I did a clock division to get the frequency desired.
  3. In the mcbsp change the registers(rcr1, rcr2, xcr1, xcr2) to allow the format you need(delays, transfer bits, msb or lsb first)
  4. Modified the TWL4030 code.

I guess there is a better approach, but I don’t know that much about ALSA drivers, so…

For the TWL4030, I first erased all the content of every function to make a clean start. And now begin to slowly fill each of them using other codecs as reference.I did skip the DAPM part since it is not that important at the beginning.
When recompiling the kernel, will still add the omap asoc support for audio. It will still believe is TWL but it actually will be a modified version with different mcbsp and i2c address.

But regarding the DMA part, I never make a change on those, so I don’t know how it really works.

In the meantime I did some reading on ALSA and ASoC and evidently I
came up with more questions!! :slight_smile:
I'm sorry but ALSA development is quite new to me so there are so many
things that I need to find out.
It is clear now that I need to create a new driver for my codec based
on the ASoC framework.
I studied the files and I have these questions

1.
Where exactly and how do I declare that my new codec will be attached
to the McBSP1 or McBSP3 instead of the McBSP2?
I see this line
  *(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 1; /* McBSP2
*/
in sound/soc/omap/omap3beagle.c
which I guess is for general beagleboard initialization.
If I change this, then TWL4030 will stop working which I do not want
that, I need TWL4030 together with my new codec.
So how do I add another McBSP port and codec driver in the beagleboard
initialization?

2.
I've seen twl4030 file references in various places like drivers\ or
arch\ but please verify with me that the only one that will be copied
for the
new codec driver is the one that resides in sound\soc\codecs\ and
nothing else needs to be replicated

Thnaks,
Christos

1
I believe you need to change this to an array type, there is a similar example looking in another machine driver, the pandora I think, there they use a different way of assigning the McBSPs

2
I only modified what is in the /sound/codec/codecs and all changes were effective

So, Ernesto you changed in
"*(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 1; /*
McBSP2"
the "private_data = 1"
to either "private_data = 0" (for McBSP1)
or "private_data = 2" (for McBSP3)
and you have only your new codec now active and not the TWL4030?

Yes, changed the value of “private_data = 2” (for McBSP3), and I have only active my codec.

svleia, have you been able to get MCBSP3 to work? I am having trouble
with this. I also have an external I2S codec that I would like to
connect to the beagleboard as a slave on McBSP1 or McBSP3.

1. First I set up the uboot pin mux for McBSP3 the same way as MCBSP2:
MUX_VAL(CP(MCBSP1_DX), (IDIS | PTD | DIS | M2)) /*MCBSP3_DX*/\
MUX_VAL(CP(MCBSP1_CLKX), (IEN | PTD | DIS | M2)) /*MCBSP3_CLKX*/\
MUX_VAL(CP(MCBSP1_FSX), (IEN | PTD | DIS | M2)) /*MCBSP3_FSX*/\
MUX_VAL(CP(MCBSP1_DR), (IEN | PTD | DIS | M2)) /*MCBSP3_DR*/\
MUX_VAL(CP(MCBSP1_CLKR), (IDIS | PTD | DIS | M4)) /*GPIO_156*/\
MUX_VAL(CP(MCBSP1_FSR), (IDIS | PTU | EN | M4)) /*GPIO_157*/\
MUX_VAL(CP(MCBSP_CLKS), (IEN | PTU | DIS | M0)) /*McBSP_CLKS*/\

2. Then I changed McBSP2 to McBSP3 in sound/soc/omap/omap3beagle.c:
*(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 2; /* McBSP3
*/

3. To test this, I opened the /dev/audio device and wrote some bytes
to the device while I scoped both the audio out jack and the McBSP3
clock and data lines. I only see stuff come out of the audio out jack
and nothing on McBSP3.

I was expecting the audio jack to be disabled by the omap3beagle.c
change from McBSP2 to McBSP3. Can anyone help me setup and test
McBSP3? I have also tried this with McBSP1 to no avail. Are my
settings correct or do I need to make some other changes. My first
objective is to see that the McBSP3 pins are "alive" before I start
changing the TWL4030 codec driver to match my own as suggested by
Ernesto.

Thanks,
Saladino.

Up to now, there is no advancement yet here.

But you can see this thread a post from "John(USP)" for some more info
on board initialization
http://groups.google.com/group/beagleboard/browse_thread/thread/3d2458e6866c01d5#