[alsa-devel] hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

At Tue, 27 Jul 2010 18:33:48 +0200,
David Henningsson wrote:
> 
> 2010-07-27 17:47, Takashi Iwai skrev:
> > At Tue, 27 Jul 2010 17:33:32 +0200,
> > David Henningsson wrote:
> >>
> >> 2010-07-27 16:57, Jaroslav Kysela skrev:
> >>> A little off topic: hda-compiler . I'm playing with an idea to have the
> >>> hda-intel driver behaviour description (patches) in a firmware file.
> >>
> >> There seem to be more than one thought in that area. Recently there has
> >> been some discussion (at least on Ubuntu Developer Summit) whether the
> >> device-tree[1] structure could be used in this area as well.
> >> Since we would then have separate device-tree files, we could update
> >> them independent of the kernel.
> > 
> > Did it come from Andy?  I've heard the idea to use OF from Grant in
> > the last year, and yes, this is feasible.  But I'm not sure how much
> > gain we'd get in the end.
> 
> I'm not sure who took the initial initiative, but more than one seem to
> be interested.
> Anyway, the goal is to make maintenance easier, and especially to be
> able to update a small quirk, somewhat independent of the kernel.
> 
> > For new devices, except for a few ones like AD or Conexant, we usually
> > write the generic tree parser so that BIOS information can be parsed
> > dynamically.  If BIOS information is broken or insufficient, we can
> > add some hints for correction, via sysfs for debugging or statically
> > in the code for production.  
> 
> So you would prefer BIOS overrides (pin configs etc) to writing new models?

Yes, sort of.

> Would you say the entire "model" infrastructure is, or should be,
> deprecated?

The model infrastructure itself can be used for pin config or special
verb overrides.  It's just a way to select the specific fix.

> > And the rest of the problem is very
> > specific to devices, and requires often some quirks in the parser
> > itself.  So, in this scenario, there is little room OF can help.
> > We'd like rather to avoid the static data, no matter in which form.
> 
> Whether that is SSID -> Model mappings or quirks for correcting the
> BIOS, it seems unavoidable with static data to me?

What I mention as "static data" is the bunch of arrays for model-
specific mixer elements, init verb definitions and unsol handlers.
Most of codes in the huge patch_realtek.c are these.
They can be absorbed well in the generic mode once when the correct
setups are given.

> > Meanwhile, the deployment of OF can be helpful if we move the whole
> > parser stuff to the user-space and push the parsed/compiled tree info
> > into the kernel (i.e. "firmware").  In such a case, OF representation
> > can be more flexible; and the kernel has already the infrastructure.
> 
> So move half of the kernel code into userspace? Are you suggesting that
> user-space gets a NID-tree, like in the codec-proc file, and returns
> back init verbs, controls, etc?

Yes.

> I'm not experienced enough to foresee all the consequences of such a
> massive rewriting.

Heh, this is indeed a massive rewrite, and actually too radical.
If this is really a way to go, we should work in parallel, maintaining
the current code while developing the completely new code-base.

For example, we can rewrite the driver structure based on a HD-audio
bus driver with individual codec drivers on it instead of monolithic
PCI driver.  But, this will can change the card-based device
organization in the current way, so the change in the user-space would
be visible --> regarded as a regression for some people.
Another reason I didn't step into this direction, so far.


thanks,

Takashi