Beaglebone on kernel 3.2.0 running davinci McASP driver and the DVI-D cape

I have built a 3.2.0 kernel with the davinci McASP driver up and running on my beaglebone A3.
(I can make it available if anyone wants it).

I want sound out so next step is a codec or the DVI-D cape if/when available.

Does anyone have experience with the DVI-D cape ?

Thnx much,



The DVI-D Cape has no audio on it. The audio version It has not been scheduled for production at the moment. It is very low on the list at the moment.


I have the DVI-D cape, and it is a really cool piece. I ordered it directly from, and I bet if you sweet talk them they’ll send you one with all the audio parts populated on the board. I haven’t messed with trying to get the audio working, and I doubt it is exposed to the SOC by the EEPROM. I found a driver for the codec IC in the Angstrom sources, but again, I haven’t tested it. I’d like to see your McASP driver, if you’re willing to share…

I can confirm that the video portion of the cape works extremely well under both Angstrom and Ubuntu.

Best regards,

I’m happy to share… I am going to move the McASP signals first though… I will add the code to reconfig the pins, in the driver, likly
When I’m finished, I’ll put the bzipped tree on my FTP site.

I’ll check out… does the cape have a codec on it… if so which one?
I generated 4 but there are many to choose from…

I found a codec chip from TI, and was going to do my own cape… if the DVI-D cape has a codec, I can abandon that effort.


I’d like to get a look at the McASP driver code if possible. I’ve got a fair bit of experience working with I2S codecs and I’ve got a few on prototypes sitting around that could easily be wired up to the Beaglebone. I just didn’t have any luck getting I2S out of the Beaglebone with the old kernel when I first started poking at it a few months ago.


According to the schematic, which can be found at:

The codec IC is a TLV320AIC3106

and full information about it can be found at:

and I think this package may be a driver for it, but like I said earlier, I haven’t tried it yet:

Best regards,


Hi folks,

Ok… has my 3.2.0 kernel and tool chain the beaglebone and ARM-Tools directories

Also see the README-beaglebone


Awesome. Thanks for the code, I’ll post my results with it once I get a chance to compile it. Right now my DVI-D cape’s EEPROM is not exposing the audio ICs to the Sitara. You can see the contents at:

I’ll post the revised EEPROM muxes once I can confirm that it works. Still have to lift that pesky pin 7 on the EEPROM (HIeu, if you read this I promise not to screw it up)… Then I’ll give your kernel a whirl.

Thanks again,


Grabbed your code and toolchain. Kernel built fine (after I built a mkImage from the u-boot git) and I’ve gotten it running on my Beaglebone.

Looking through the dmesg though I don’t see that ALSA installs a device associated with the McASP - all I see in the device list is:

ALSA device list:
#0: Dummy 1
#1: Loopback 1
#2: Virtual MIDI Card 1

So if your modified McASP code is in there it doesn’t seem to be registering it as a usable device. I’ll dig around in the source and try to understand it better - perhaps it’s named differently, or the setup code bails out when it doesn’t find a codec on the other end of the I2C command port.

Suggestions welcome,


There is no codec yet…

ALSA gave a stack of errors on my sound app till I added the mcasp driver. Now, no errors and alsamixer runs abeit incorrectly…
Progress in angstroms :slight_smile:

I should have the new kernel soon… and my cape will be in Wednesday :slight_smile:


Without a cape that connects the McASP code to a device - e.g. audio chip+codec IC, you shouldn’t see anything in dmesg. It may be in your kernel, but without something to talk to, it isn’t terribly useful.

Kernel code is well on the way.

Received the cape…

No codec on it!

…I need to populate it myself :((


OK, I did it, finally. I cut pin 7, and I edited the eeprom code to include the muxes for the audio parts. You can check out the mux configuration at:

And I used the beaglebone-pinmux-tool to create a shell script to write the new muxes to the DVI-D cape:

A word to the wise would be to verify the muxes I used before burning these settings to your own hardware. It works for me, YMMV. Now I’m off to try some kernels. I can see in dmesg that things should mostly work, but the sd card I used has a fairly recent build of Ubuntu 11.10, and I haven’t even looked in the kernel tree to see if the drivers are there. I’ve also got an Angstrom card to try. And I’ll create a card for the SouthCoast kernel, and try that too.

On a related note, has anyone tried the ChipSee LCD cape:

I looks as though it has some cool features, and it appears there’s an option for capacitive touch.

Best regards,
Blake Morgan

Update… I have the mcasp probe code running rc==0 and I’m working to setup the P9 pins to mcasp 0.

There were issues to getting this far and may be more before it’s finished :slight_smile:

I’ll try to post it soon.

Also, CircuitCo is shipping me a DVID cape with a codec on it… :slight_smile:


I’ve been trying to figure this out. I’ve got the part about the code and mcasp kinda sorted out, but how the mcasp ties into the Cortex has me in circles. I think the divinci mcasp driver is insufficient because the pin out is different enough compared to the sitara. I’m guessing that the sound should be generated not by the arm CPU, but by the neon bits.

I have no idea how to do that, but I’m reading a lot of reference manuals.


Different in what way?

If the hookup is correct then things should work straight away. You would have probably already sorted this out but would be a good place to get an idea on what sort of changes are needed when trying to use a different mcasp. (Replace TI81xx with AM335x when you are going through the doc).

Great news. Looking forward to any code / patches you may have available.


The mcasp setup is totally wrong in the lowest level kernel setup. My new changes correct that. Secondly the pins must be reprogrammed to match the DVID schematic… which I’m actively
working on now. Thirdly, there are likely some I2C signals needed for the TLV320AIC2106 codec, I think… That’s ahead for me.


Thank you for the link. That clears up a bunch of loose ends for me.

Best regards,

Hi folks,

I’ve completed my work.

Up on our is…


This kernel tree has a running Davinci mcasp probe function which calls
a Bone P9 pin reassignment function. The pins 25, 28, 29, 31 & 41 now
correspond to the DVI-D schematic’s TLV320AIC3106 signal requirements.
I2C did not need changing, as it was correct to begin with.