[alsa-devel] [PATCH RFC 000/112] HD-audio generic parser improvements

[Jaroslav Kysela]

Date 8.1.2013 14:20, Takashi Iwai wrote:
> At Tue, 08 Jan 2013 14:03:23 +0100,
> Jaroslav Kysela wrote:
>>
>> Date 8.1.2013 12:37, Takashi Iwai wrote:
>>> Hi,
>>>
>>> this is a large series of patches to implement the really generic
>>> HD-audio codec parser usable for various codecs.  It's based on the
>>> Realtek codec parser, so I started hacking patch_realtek.c for more
>>> generalization and improvements.  Then it's merged to the existing
>>> generic parser code, hda_generic.c, and let Realtek parser just uses
>>> this new parser code.  In the end, patch_realtek.c contains only
>>> the device specific fixups and the call of generic parser functions.
>>
>> Great step forward. Thanks.
>>
>> In my opinion, it would be great to handle all fixups in some "user
>> space" compatible mode. I mean, do not use the C code for fixups, but
>> use an universal description code which can be loaded from the user
>> space probably as ASCII text (firmware like behaviour), too. This code
>> can be buildin to the kernel modules in a default version. I don't mean
>> the current implemented patch processing, but full codec initialization.
>> I think that it may be last change to bring the HDA code to more
>> maintenable state. Just an idea to avoid further HDA code rewrites which
>> happen periodically. And now (with your rewrite) it's really good time
>> to propose also this change.
> 
> Well, most of required fixups are corrections of the wrong BIOS
> information and/or the missing information like some extra flags.
> They can be well covered by the current "patch" firmware.  And we
> can build this text into the kernel driver as a default database
> instead of hard-coded C array (although I'm not sure whether this will
> give so much benefit).
> 
> The rest is some exceptions where some real codes are required.  This
> can't be expressed in a static form.  And any byte-code interpreter in
> the driver is a bad idea, and it doesn't make the whole maintenance
> scheme easier...

I believe that a good compromise might be implemented. The special cases
can be also part of the parser having configurable values if possible,
so the whole codec description can be static.

The discussion seems to reach another point: One parser handling all
possible information or multiple parsers overriding the generic one
(actual state)?

>> Please, provide the GIT URL with these changes.
> 
> Yep, already posted.

Got it. Thanks.

					Jaroslav


-- 
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.