On Tue, Sep 01, 2009 at 09:27:30PM -0500, hari n wrote:
Proposal
On OMAP4, audio codec functionality is spread between ABE of OMAP4 and the companion analog audio chip. The interface between the ABE and Phoenix audio chip is proprietary McPDM interface. The proposal is to combine both ABE and Phoenix into a codec driver. OMAP4 ABE
Combining the two seems like it's asking for trouble further along the line. While it's likely that a lot of board designs will use the reference design combination of devices there will inevitably be some systems that want to do something different for whatever reason. If that affects the connections between the two parts of the system then there will be problems for a unified driver.
Otherwise the rest of your design looks good.
sound/soc/codecs/abe-twl6030.c: This is the codec driver interface file for OMAP4 audio. It defines the codec DAIs for the HIFI, voice and Vibra subdevices. Handles the configuration of Phoenix companion chip using i2c control interface. Handles the initialization and configuration of ABE. All codec related widget controls are also handled in this file. Both, digital (ABE) and analog (twl6030) widgets will be contained in this same driver.
Having the ABE as a CODEC does seem like a sensible approach - indeed, there are a number of audio hub CODECs on the market with a very similar feature set to the ABE.
Questions
How to handle routing of digital audio from ABE to external devices like Bluetooth/FM connectivity devices which are usually connected using McBSP interfaces?. In these scenarios, we need another DAI between the ABE (platform codec) and an external codec.
ABE(platform Codec (Digital) -----> Phoenix audio codec | | +--> BT/FM codec
This is the sort of issue I'm talking about above which is helped by explicitly representing all the DAIs in the system. With the DAIs visible it should just become a case of hooking up the links between the devices in the usual ASoC fashion.