I have the DVI-D cape, and it is a really cool piece. I ordered it directly from Boardzoo.com, 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.
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 boardzoo.com… 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.
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.
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.
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.
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’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.
If the hookup is correct then things should work straight away. You would have probably already sorted this out but http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#Audio_driver_.28McASP.29 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).
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.
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.