[alsa-devel] Update on TLV320AIC3204 Driver

[Mark Brown]

On 15 Jun 2010, at 01:27, Stuart Longland wrote:

> I've started documenting some of this stuff on the ALSA Wiki at
> <http://www.alsa-project.org/main/index.php/DAPM>.  I'm hoping this
> might be a useful resource for others.  Was about to do it on an
> intranet wiki here, but figured it'd be of benefit to others too.

If you're doing this it would be a bit nicer if you could contribute the
documentation to the kernel. The APIs do change over time and the
in tree documentation has a much better chance of being in sync with
what people are actually working with than online documentation
(which may be for a later kernel version with features they can't use),
though it's not been so great recently.

>> SND_SOC_DAPM_SUPPLY can help you here - you can have a conditional
>> supply.

> Is there an example of the supply doing something like this?  I'm
> thinking a mux might be the way to represent it, but it's then a matter
> of getting DAPM to switch the MUX over to the other source when the
> current source gets shut down.

WM8994 does this for the AIF clocks. You can't use a mux since you're not
routing an audio path.

>> Provide a display_register() callback which filters out the undefined
>> registers or otherwise improve the standard functionality.

> I shall look into this... but a thought, is there any merrit in the
> two-file (register select" and "register data") interface to the CODEC
> registers?  The current interface looks great if you want to quickly get
> a register dump, but the solution I have is easily used in scripts.

It's fairly easy to use the existing solution in scripts with a little bit of
filtering (even grep can do a good job) and I have to say I'm concerned
about the idea of production use of this stuff. It's supposed to give the
impression that you're not meant to be using it in production for anything
except pulling diagnostics out.

>> 
>> If the registers are mostly clustered at the starts of pages then an
>> array of pointers to per-page arrays might do the trick.
> 
> As in this?
> 
> 	static u8 aic3204_reg_page0[128];

Yes.

> I wasn't sure how compatible that would be with the rest of ALSA, but I
> might give that a try shortly.

The rest of ALSA shouldn't be able to tell what you're doing, all the
operations which interact with the register cache are provided by your
driver. If it can see what's going on we've got a problem anyway.

>> Please post to the mailing list if you want review - the standard
>> workflow is to provide comments by replying to the patch.

> No problems, I'll post the code to the list in a moment.  Last time I
> tried this it got held for moderation because the email was too big.
> Hence my posting it to a website and linking to it.  I'll post the files
> up in my next email.  When things are a little more mature, I'll post
> the patch for the driver.

This is one of the things that the requirement to CC the maintainers
and other relevant people helps with - it means that they get a copy 
as soon as their mail server takes the message rather than having
to wait for the list.