[Kernel] OMAP5 ABE (Audio Back End) and Pyra Prototype V3

Peter Ujfalusi peter.ujfalusi at ti.com
Tue Mar 18 10:01:14 CET 2014


On 03/18/2014 10:11 AM, Dr. H. Nikolaus Schaller wrote:
>> It is a blob, yes. It contains the AESS binary and it also contains additional
>> information like audio controls, routes, etc.
>> In a same way as most WiFi cards have Firmware we need to load the DSP code to
>> the AESS to be able to use it.
>>
>> The code to support AESS is not yet upstream. It has dependency on ASoC
>> Dynamic Firmware.
> 
> Ok! I think we will needs some time until we have the Pyra hardware to
> test things. So maybe mainline will be 3.16 or 3.18 when the Pyra is finalized.

I hope the AESS support will be upstream by that time. I do have dependencies
like I mentioned the ASoC dynamic firmware. Other thing for OMAP5 is the
Palmas clock driver (twl6040's clock is coming from Palmas usually).


>> I'm maintaining the AESS support (only OMAP4 is tested, OMAP5 should not be
>> hard to get it working) here:
>> https://gitorious.org/omap-audio/linux-audio
>> The branch 'next-bnw/ti-audio-next-3.13' is the latest rebase I did, I'm
>> planning to do this for the 3.14 as well soon.
>> The base-bnw/* branches are just topic branches and they are merged to form
>> the next-bnw/* snapshots and also my personal working branch:
>> peter/topic/ti-audio-next-bnw-wip (which is the same as the 3.13 snapshot
>> currently).
>>
>> The firmware is not in there, I think I'm going to place it and push that as well.
> 
> Yes, tracing the firmware is a little difficult. There appears to be an Ubuntu
> package.

I just pushed the firmware to
git://gitorious.org/omap-audio/linux-audio.git base-bnw/aess-firmware
and
git://gitorious.org/omap-audio/linux-audio.git next-bnw/ti-audio-next_3.13

it is the firmware/omap-aess-adfw.bin

This is a new firmware, I have fixed couple of long standing bugs with it and
one should not mix up the firmwares.
As a sidenote: Ubuntu is using the old version of FW and AESS/ABE code while
the code I have in gitorious went through several clean up rounds and stuff.
The whole code layout is different, etc.

>>> This means:
>>> * if we want to use the ABE (to save power while playing sound or phoning
>>> around) we must use the TWL604x
>>
>> Also AESS helps with resampling, routing, mixing. With McPDM/twl6040 (no AESS)
>> for example if you want to play audio to the speaker (or line-out) you need to
>> play 4 channel audio and place the stereo data to channel 3 and 4. Channel 1
>> and 2 is going to Headset/Earpiece.
>> With AESS you would have separate PCM for this so you do not need to care
>> about this. There are other things as well, but can not recall them all.
>>
>>> * if we don't use it we maybe can use the McASP for I2S
>>
>> Note that McASP is only TX, it can not receive data. It also lacks AFIFO which
>> can cause audio underruns when the system is stressed...
> 
> Oh, that is good to know! So we will only have 3 McBSPs we need for
> * Audio codec (speaker/line)
> * Modem
> * Bluetooth (headset)
> * FM radio

If you only plan to have FM transmitter than:
McASP - FM tx
McBSP1,2,3 - codec, modem, BT

and you do not need AESS.

Oh, one more note about McASP. We do not have driver upstream for it. Android
have omap-mcasp driver (used in Galaxy Nexus for S/PDIF on the dock). The main
issue with the OMAP4/5 McASP is that I do not have HW where I could test it.
In theory however the davinci-mcasp driver can be reused. The IP is derived
from there, only some features are missing (RX, AFIFO).

> So we have to sacrifice one. Unless we can use the McPDM interface for Audio
> codec.

I hope you do not need to make too big compromises. I try to upstream the
needed parts for audio on time so you will be able to utilize it. But it is
good to have backup plan...

-- 
Péter


More information about the Kernel mailing list