[alsa-devel] What is correct way to put conditional stuff in ASoC codec driver?

[Ashish Chavan]

On Thu, 2011-06-30 at 22:07 +0530, Mark Brown wrote:
> On Thu, Jun 30, 2011 at 06:16:30PM +0530, Ashish Chavan wrote:
> 
> Please fix your mailer to word wrap at less than 80 columns so your mail
> is legible.

Oops! I thought I already have it set in my evolution. Thanks for
pointing it out.

> 
> > Our final goal is to pull in all missing features from this custom
> > driver in to existing mainline driver. I have already created few
> > patches for basic functions but I am bit confused at one point. Some
> > of the features supported by this codec have inter dependency, e.g.
> > ALC can be used only if NOISE SUPRESSION is disabled.  So ideally, all
> > controls related to ALC should be either disabled or not added at all,
> > if NOISE SUPRESSION to be used. There are few other features having
> > similar kind of dependency.
> 
> You'd need to implement custom controls for the relevant enables which
> check to see what is currently enabled and prevents enables if there
> are conflicts.  You should do this dynamically and I'd expect that only
> the enables actually need to check anything, adjusting parameters for
> things that aren't active is usually no problem.

I see. That means it's ok to allow setting up values of five band
equalizers even when overall equalizer functionality is disabled.
Can you point me to any existing code that has such custom control(s)
which need to check for similar conditions? I am sure that many existing
codecs would have this kind of inter dependent functions.

> > I just want to know what is the correct way to handle this in ASoC
> > codec driver?  Looking at the existing codec drivers, it seems that
> > having conditional defines is not common here. As We just want to
> > support static configuration of such features, is it a good idea to
> > add sub menu options in driver's Kconfig to enable/disable such
> > features and use them within code?
> 
> Compile time selection is completely uinacceptable for Linux in general,
> please see the coding style and development model stuff in Documentation
> for discussion of the motivations for this.

Yes, guessed this. In fact that's why I posted the query here :-)