hda-verb, hda-analyzer, hda-emu and codecgraph

hda-verb, hda-analyzer, hda-emu and codecgraph

[David Henningsson]

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.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

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.


thanks,

Takashi

Re: hda-verb, hda-analyzer, hda-emu and codecgraph

[Jaroslav Kysela]

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.

 					Jaroslav

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

Re: hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

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

Re: hda-verb, hda-analyzer, hda-emu and codecgraph

[Jaroslav Kysela]

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.

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

 					Jaroslav

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

Re: hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

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

hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[David Henningsson]

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.

I'll go to plumbers in November, could this be something to discuss at
that conference?

[1] http://www.devicetree.org

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[Takashi Iwai]

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

Re: hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[David Henningsson]

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?
Would you say the entire "model" infrastructure is, or should be,
deprecated?

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

> 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?
I'm not experienced enough to foresee all the consequences of such a
massive rewriting.


-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: 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

Re: hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph

[Jaroslav Kysela]

On Tue, 27 Jul 2010, Takashi Iwai wrote:

>>> 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 thought about the user space parsing, but I would see rather a simple 
limited special purpose bytecode interpreter in the HDA driver in the 
first state and an one-shot compiler. The bytecode can be eighter static 
(read from a firmware file using a lookup scheme based on SSIDs, BIOS pin 
setups etc.) and later, we may eventually create a complicated user space 
solution (bytecode generator).

Note that for handling unsolicited events, the description of behaviour 
(may be dynamic - based on actual nid state) should be available. The 
bytecode interpreter solution is ideal for both  static and dynamic 
behaviour description. Ideally, everything in patch_* files should be 
rewritten to use the bytecode interpreter (including auto sections).

If we design a special high-level language and a compiler generating the 
bytecode for the driver, we can describe hw <-> ALSA mapping on fewer 
lines and also we can drastically reduce the possibility to introduce an 
error like in C.

 				Jaroslav

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