Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello Mr. Schlunk,

Unfortunately, in order to use the audio output a new sound "board/driver" needs to be written and added to the kernel/sound/soc/davinci section of the linux kernel for the Industrial I/O board. We have started on an effort to provide the audio device drivers, but the work is not yet complete. As soon as we have something tested, we'll publish it. I apologize for the inconvenience.

-Mike

Hi Mike,

Thank you for the information.

Once the drivers exist -- would you know what API I should probably be using -- e.g. ALSA or OSS or just fopening the device?

Also, so we can plan things a bit better on our end, is there any shot you might have a rough guesstimate on how long it might be till those drivers are ready (i.e. are we talking a couple of weeks or couple of months or what)?

Thanks,
Otmar

Hi Otmar,

The API will be ALSA.

My best guess would be something mid-October. We'll try to bump it up on the priority list here.

-Mike

We're at the point where we are now developing audio code for our app. What is the status of the audio drivers for the MityDSP? Even if it's not complete, we could use some example code to help speed our configuration efforts. I have a TI driver package designed for other OMAP CPUs, but what I really need now are the Platform and Machine driver files, if those are available. That would save me a lot of time.

The MityDSP-L138 (really, the OMAP-L138 or AM1808) uses (primarily) the McASP to support audio. McASP drivers are included in the linux kernel. The linux kernel will also support audio over I2S and SPI devices, but I do not have experience setting those up.

We have included support for the line out interface for the DSD1791 chip on the Industrial I/O in the most recent version of the kernel. The interface supports basic ALSA outputs (e.g., aplay or using gstreamer with the alsasink output will function). On the industrial I/O board, you must use a Revision C board for it to function, or a modification (a jumper) must be made on the revision B board to route a clock line to the AHCLKX pin of the OMAP and you'll need to make a simple patch to the kernel to alter the audio data pin. The industrial I/O board does not provide the SPI connections to the DSD1791, so it must be used in it's power up default configuration.

If you are working on audio for your own hardware configuration, there is support available in the kernel for interfacing to the tlv320aic3x audio driver (both output and microphone input) as was done in the TI OMAP-L138 EVM module. However, you will need to update the software to include support for the "mityomapl138" machine type and deal with any pin-out changes, etc. The region of interest in the kernel software is located in the sound/soc/davinci directory. Check out davinvi-evm.c. This is the file that would need modification to define sound support for your custom board.

Not sure if this answers your question, but I hope it sheds some light on the issue.

This helps point the way. I'll let you know when I have additional questions.

Looks like I should check out both the McASP and AIC3 modules to see how they can be adapted to what I'm trying to do. Thanks.

I've built the kernel with alsa sound and the tlv320aic3x driver as a loadable module. When I load the module I see "116 alsa" in /proc/devices and "crw-rw---- 1 root audio 116,33 ... timer" in /dev/snd. I see tlv320aic3x show up in /sys/module. I don't see
any other devices or anything in /sys that looks like a place to send the sound; so I've missed something like a uboot, mknod
or insmod but I'm not sure what.

You've loaded the driver, but have you instantiated the board / device (the McASP device in the board-mityomapl138.c file to marry the device instance to the driver)?

I'm not an ALSA framework expert, here is how we have tested an Alsa port of the industrial I/O board:

The first way was to use the ASLA play utility and a simple .wav file:

root@mitydsp # opkg install alsa-utils alsa-utils-aplay
root@mitydsp # aplay -D hw:0,0 test.wav

We have also tested using the basic gstreamer package and the audio test source (as well as the mad plugin to stream mp3's).

root@mitydsp # opkg install gstreamer gst-plugin-alsa gst-plugin-audiotestsrc
root@mitydsp # gst-launch audiotestsrc ! alsasink

-Mike

Still stuck on the sound. I looked at the davinci-evm.c and the 3x is called out in that file, however, the Kconfig in that directory doesn't allow the mityomap as an option to allow that file to be compiled. In fact it calls out a variety of other MACH_
configurations not MACH_MITYOMAPL138. So that file doesn't compile under the current allowable configurations for the kernel. I've also been in the board-mityomapl138.c file. I put a printk into da8xx_register_mcasp and confirmed that it is getting called.
I don't know whether you have a later version of the kernel/config. What is up under the "Files" tab is the 6/25/2010 version of the kernel (put up there 7/27). I've retried 'git' a couple more times. It still stalls and eventually times out with less than 2% of the files downloaded; so keeping up-to-date that way isn't viable.

Hi Dennis,

Regarding the audio driver, it sounds like you have a pretty solid handle on the code. The bottom line is, you will need to actually modify the kernel code in the sound directory (KConfig, and the davinci-evm.c file) to enable support for the MACH_MITYOMAPL138 board type and build in the drivers by extending the checks using mach_is_mityomapl138() type macros. You have created a new "board type" (a mityomapl138 with a tlv320aic3x chip configuration), so the default drivers don't know about it. CL could modify the code, but we don't have any hardware to test it on (our Industrial I/O card uses a DSD1791 chip).

You should also ensure that the correct pins (pinmux-wise, and Tx/Rx-wsise) are configured in the board-mityomapl138.c file for the McASP. If you are using different Tx/Rx pins then the default ones in the code, you'll need to update those as well.

I'm not sure why you are struggling to download the git kernel repository, we've had other folks succeed with it. Our server is not on a huge backbone, though, so that or the path between our server and your machine might be slow.

Another approach to syncing up would be to clone the arago repository or the linux-davinci repository and then add ours as a secondary remote and then fetch. Probably more than 90% of the code in the clone at support.criticallink.com is common to the base linux kernel, so the git fetch would only grab the delta objects and should be much faster. E.G.:

user@foo# git clone git://arago-project.org/git/projects/linux-omapl1.git
user@foo# git remote add cl git://support.criticallink.com/home/git/linux-davinci.git
user@foo# git fetch cl
user@goo# git branch -a

Then if you want to get the critical link master branch to your local branch "cl-master", you would checkout like:

user@goo# git checkout -b cl-master cl/master

Hope this helps. Apologies about the speed of our server.

-Mike

Well, most of the git problem seems to be at our end. Some router close to us seems to be traffic shaping us to zero bandwidth.

I'm having trouble with the kernel. I've edited the sound/soc/davinci/Kconfig, added the new "type". I didn't go for a new board type I just set up a "CONFIG_DAVINCI_AIC3X" variable. I added that variable to .config. Everytime I run make...menuconfig it gets removed. I really am not strong on how "menuconfig" modifies the .config file. I've tried also adding the definition to mityomapl138_defconf and include/config/auto.conf. It still disappears from the .config. I've grep'ed the entire kernel tree for CONFIG_MACH_MITYOMAPL138 and I don't see any obvious place I should be putting my definition. I could edit the sound Kconfig to use CONFIG_MACH_MITYOMAPL138, but I'd prefer to be a little more honest in my configuration files. What do I need to do to say the ...AIC3X definition is allowed in the .config file?

Please ignore the previous, incredibly stupid question. My mistake is not realizing that it's the stuff in the Kconfig's that goes into the .config with the prefix CONFIG_ added. I need to change the Kconfig's, not the .config.