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.
Mark,
I'm not familiar with the concept of an audio hub, but is it something like a codec that can have 'slave' codecs connected to it (like in cascade fashion)? Do we have any audio hub CODEC already in SoC to use as a reference?
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.
If the ABE is considered as a separate CODEC, then it should have its own DAIs for the connection with the processor, even it the codec itself resides in the processor. What about the client CODECs? They will also have their DAIs which should be connected to the physical outputs of ABE (McPDM, McBSP, ...), and that confuses me. AFAIK, SoC allows to have multiple CODECs attached to the same processor, but not a CODEC connected to the output of another CODEC.
-Misa