[Kernel] OMAP5 ABE (Audio Back End) and Pyra Prototype V3
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:
>> 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
>> 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
I just pushed the firmware to
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
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...
More information about the Kernel