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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
