Kernel: 2.4.17
Module: ac97_codec.c
Harware tested: ALC100P and STAC9721/23 codecs
Abstract: Add new ALC, Sigmatel and Cirrus codecs. Changes in the codecs
list to support ranges and if the codec is unknown report it with the name
of the vendor if we can determine it.
Revision of the patch: 2

That's the second version of the patch I sent yesterday.
Alan was right about Cirrus chips, I downloaded the data sheets and is
clear that the 3 LSB are the revision and can have any value.
I also downloaded Sigmatel data sheets and after reading the comments about
the IDs by these three vendors (I started with Avance Logic, now Realtek) is

obvious that the 24 MSB are the vendor ID (of course there are irregular
values because a Redmond company assigns these values ;-) and the chip
number is in the 8 LSB.
Is also clear that various manufacturers choose to reserve some of these
bits for revision numbers.
For these reasons I'm sending a more complex patch. It changes the way
codecs ids are stored. A main list contains the name of the vendor, the id
of the vendor, a mask to filter the revision bits, the number of known
devices from this vendor and a pointer to an array containing the list of
devices.
The array of devices contains the id of the codec, the name and a pointer
to the structure of function-options.
The code first looks for the vendor, if found then looks for the particular
codec. If the codec couldn't be found but we know the manufacturer then the
code assigns the name of the vendor to the "name" field. The code also
assigns to the "type" field the id of the codec *after* filtering the
revision.
Of course the patch is larger but I think it reflects better the reality.
If this approach looks coherent I'll ask for these changes:
1) Add a "char *vendor" field to the ac97_codec structure.
2) Store only the name of the codec in the "name" field, we can reconstruct
a descriptive name latter using vendor+name. I checked and it looks like
the name is only used in ac97_codec (also for debug in i810, but just to
log the name and can be updated).
3) Add a "u32 revision" field to hold the revision of the chip. This value
could be needed by the "ops" functions and is much more clear (type says
the type and revision the revision).

The patch also adds identification for:
"Cirrus Logic CS4201", "Cirrus Logic CS4205", "SigmaTel STAC9750/51",
"SigmaTel STAC9766/67", "SigmaTel STAC9700" and "SigmaTel STAC9711".
[Also for the ones in the first patch "ALC 100/P", "ALC 650" and
"ALC 101"]

Note that I'm not sure about the "ops" for these chips (I only have an
ALC100P) so I left null_ops. That's better than nothing because if the
codec isn't identified the code uses null_ops anyways.
If somebody wants to discuss about what ops functions should be used by
looking in the datasheets I'm available for such a thing.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set@computer.org set@ieee.org
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013