At Tue, 27 Jul 2010 16:07:31 +0200 (CEST), Jaroslav Kysela wrote:

On Tue, 27 Jul 2010, Takashi Iwai wrote:

...

At Tue, 27 Jul 2010 13:31:16 +0200, David Henningsson wrote:

...

Hi Takashi,

Do you plan to make hda-verb, hda-analyzer, hda-emu and/or codecgraph a part of alsa-tools/alsa-utils/pyalsa in the future?

I'm asking because I would like to know if it makes sense to package them separately for Debian.

I can put hda-emu to alsa-tools if anyone wants. This is a really small code. (But I didn't put it because I didn't want to 100 times bigger auto-tools stuff for it :)

But, hda-emu doesn't suit with alsa-tools category. It's a tool to be built with the latest (or the version to be tested) sound kernel tree. So, it's not much worth to package.

hda-analyzer is already in alsa.git. I guess it depends on Jaroslav.

What about an idea to move all hda related stuff to new git repository like alsa-hda-tools ? It will make packaging more easy with uniform name and developers will find all recent stuff at one place.

Well, hda-emu shouldn't be packaged together, so I'd like to keep it separately. So, what else? hda-verb and hda-analyzer? hda-verb hasn't been updated since long time ago :)

Takashi

At Tue, 27 Jul 2010 16:57:44 +0200 (CEST), Jaroslav Kysela wrote:

On Tue, 27 Jul 2010, Takashi Iwai wrote:

...

At Tue, 27 Jul 2010 16:07:31 +0200 (CEST), Jaroslav Kysela wrote:

...

On Tue, 27 Jul 2010, Takashi Iwai wrote:

...

At Tue, 27 Jul 2010 13:31:16 +0200, David Henningsson wrote:

...

Hi Takashi,

Do you plan to make hda-verb, hda-analyzer, hda-emu and/or codecgraph a part of alsa-tools/alsa-utils/pyalsa in the future?

I'm asking because I would like to know if it makes sense to package them separately for Debian.

I can put hda-emu to alsa-tools if anyone wants. This is a really small code. (But I didn't put it because I didn't want to 100 times bigger auto-tools stuff for it :)

But, hda-emu doesn't suit with alsa-tools category. It's a tool to be built with the latest (or the version to be tested) sound kernel tree. So, it's not much worth to package.

hda-analyzer is already in alsa.git. I guess it depends on Jaroslav.

What about an idea to move all hda related stuff to new git repository like alsa-hda-tools ? It will make packaging more easy with uniform name and developers will find all recent stuff at one place.

Well, hda-emu shouldn't be packaged together, so I'd like to keep it

I would just put the hda-emu to repo for reference and access. The packaging is different thing.

Well, people would package it anyway, and I don't want it :) (The original question came up because David wanted packaging, see?)

...

separately. So, what else? hda-verb and hda-analyzer? hda-verb hasn't been updated since long time ago :)

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. This file would contain an indexing against the hw identification and will contain instruction like:

32-bit (size and instruction) 16-bit - instruction code 16-bit - instruction size in 32-bit words

Possible instructions examples:

0x00010001 0x00000010 - attach beep device for NID 0x10 0x00020003 <nid> <verb> <param> - hda_verb initialization

Instruction blocks:

• hw initialization and controls, PCMs + etc. allocation (patch callback)
• function blocks - control info/get/put callbacks, unsolicited events

Variables, arrays:

• instructions to set/fetch information
• instructions to allocate and manage arrays

It's just a rough idea - many things must be designed and thinked out. But we need a compiler from an easy readable text syntax to generate these "firmware" files - hda-compiler.

I've implemented a similar thing years ago. It worked somehow, but the rate of development of new hardware codec chips was much higher than adapting the code. In the end, it was far easier to write the code in the kernel, so it got sent to a graveyard.

A tricky part is the implementation of strange mixer elements like bind_mixer and the handling of unsolicited events. The former can be avoided (e.g. by using vmaster). The latter requires a closure (or whatever you call), and this wasn't always trivial.

Such a thing is lovely, and stimulating for hacking. But, at the same time, it's a bit hard to maintain because we'll face bugs now in multiple layers (interpreter/parser in kernel, compiler, and the firmware code itself).

Anyway, if this can be implemented in a moderate amount of code in the kernel side and if we have decent user-space tools, it'd be nice to have, indeed.

thanks,

Takashi

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.

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. 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.

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.

thanks,

Takashi

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