[alsa-devel] [PATCH v2 1/9] include: platform_data: Platform data header for OMAP4 ASoC audio

[Girdwood, Liam]

On 22 December 2011 17:28, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Thu, Dec 22, 2011 at 03:42:53PM +0000, Liam Girdwood wrote:
>> On Thu, 2011-12-22 at 13:04 +0000, Mark Brown wrote:
>
>> > omap-abe-mcpdm-twl6040 please.  Seriously, just drop the abe - it's not
>> > an optional feature of the OMAP and the names are getting quite long.
>
>> ABE can be an optional feature on OMAP (and quite an important one when
>> it is used). Fwiw, we do have a mixture of users, most use the ABE but
>> some don't, so it's best to specify ABE in the naming to avoid any
>> confusion.
>
> Do you mean to say that there are OMAP4 variants that don't have the
> ABE or that some people choose not to do so for some reason, and unless
> the ABE might not be there shouldn't the driver just support both ABE
> and non-ABE paths anyway?

There nothing stopping drivers from using McBSP/McPDM etc directly
without the ABE as the do in OMAP3. Some people do this direct path
for specific drivers.

 That's what the out of tree systems I've seen
> have done, though the main use of the non-ABE paths has always been
> confirming that issues are in the ABE.

Yep, we do sometimes add the "legacy" or direct DAI paths into ABE
mach drivers as well (but really just for debug purposes). These DAIs
are not used for any other audio use case except sometimes to debug.

Liam