Re: Proposed changes to azx/patch_realtek.c

[Takashi Iwai <tiwai@suse.de>]

At Wed, 15 Dec 2004 09:21:25 -0800,
Stephen Warren wrote:
> 
> Hello.
> 
> I'm working on updating the Azalia audio driver (ALC880 codec) to
> support a new PCB with different routing of codec pins to connectors.
> 
> As part of this, I took a look at patch_realtek.c and have a few
> suggestions on how to simplify things.
> 
> As an example of this, I've attached a patch. This isolates and
> knowledge of the "board type" to the patch_alc880 function. All
> decisions based on the board type are made here, and written into
> configuration variables in the spec structure. Then, all other functions
> simply pull values out of the spec structure and use them, so they don't
> have to have a bunch of code that's conditional on board type, which
> could grow unmanageably.
> 
> See the attached patch for this change.

Sorry, your patch can't be applied.  I rewrote the azx and hda_codec
codes largely again, committed to CVS shortly before.  The new code is
a bit better than the older one in this regard.

> Going forward, I'd like to make the following changes:
> 
> 1)
> 
> patch_alc880 fills in the spec structure at run-time. Instead, I'd like
> a set of pre-filled-in structures to be part of the driver, and
> patch_alc880 just initializes codec->spec to point at one (just like it
> currently initializes spec->init_seq to point at a specific list of
> initialization instructions with my patch).
> 
> Benefit: Can support new boards simply by defining a new pre-defined
> data structure and ALC880_xxx enumeration value - no need to actually
> edit code in patch_alc880 for this.

This sounds reasonable.

> 2)
> 
> Unify 880 and 260 support.
> 
> Much of the code for 880 and 260 is very similar - for example,
> alc880_build_controls and alc260_build_controls are the same function,
> except that (if we use just the 880 code) we would hard-code
> spec->build_side_mixer=0 and spec->digital=0, and have to parameterize
> the function by putting a pointer to either alc880_base_mixer or
> alc260_base_mixer into the spec structure.
> 
> Benefit: Identical code for 880 and 260 reduces duplication. Can
> configure differences between codecs/boards just by editing the
> pre-initialized spec structure values.
> 
> I expect to have to define my own xxx_base_mixer function for the PCB
> I'm supporting.

Yes, I thought of that, too.  That's why struct alc_spec is shared
between these codecs.  I left it as it is simply because I have no
test board for ALC260.

Go ahead, clean up as you like ;)


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/