From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Proposed changes to azx/patch_realtek.c Date: Wed, 15 Dec 2004 18:31:54 +0100 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: alsa-devel-admin@lists.sourceforge.net Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Stephen Warren Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org 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/