[alsa-devel] [PATCH 1/1] ALC889A chip identification

[Takashi Iwai]

At Fri, 15 May 2009 19:52:55 +0200,
Torben Schulz wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 15 May 2009 07:50:46 +0200,
> > I wrote:
> >> BTW, regarding the strings: basically we can do a better clean-up by
> >> using already existing strings.  For example, make new fields,
> >> hda_codec.vendor_name and hda_codec.chip_name, which points the vendor
> >> id string in hda_codec.c and the chip name string in
> >> snd_hda_codec_preset struct respectively.  Then all PCM name strings
> >> can be created automatically.
> > 
> > The patch is something like below.  It's just compile tested.
> 
> I just applied your patch the latest snapshot and it works
> perfect. My chipset is now identified correctly, so my patch seems
> to be obsolete now, I guess ^^ However, I have three (main)
> questions:
> 
> 1.: What are the next steps now? Will you post your patch again to
> the ML under an own topic or will it stay in this thread?

I already merged to sound git tree below.
    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

The snapshot tarball is:
    ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz

Now please rebase your patches against these.

> 2.: Can I do anything to help bringing your patch into the official
> repository? When will it be part of an official snapshot?

It's done :)

> 3.: Why doesn't hda_codec_preset.patch point to patch_alc883, but to
> patch_alc882 which later redirects to patch_alc883 (see
> patch_realtek.c line 7305 and 16958 (patched version))?

It was a kind of hack.  As codec id shows, it's supposed to be rather
compatible with ALC885.  But, the automatic probing did work better
with alc883-parser at the this hack was introduced.
OTOH, moving all for ALC889A to patch_alc883 is dangerous because we
actually don't know exactly which of ALC885_* model correspond to
ALC889A actually.

Possibly, the hack no longer needed.  But, maybe a better way would be
to merge patch_alc88x() together as a long term solution.

> It's quite essential for me to bring this patch into an official
> snapshot, since a lot of the changes interact with my MacBook3,1
> patch and I would like to diff against a snapshot which includes
> your patch already. (or is this - for some reason - bad style?)

Make a diff against the latest snapshot or GIT tree above please.
Then I'll merge it for the next 2.6.31 kernel.


thanks,

Takashi