[alsa-devel] hda-compiler, was: hda-verb, hda-analyzer, hda-emu and codecgraph
perex at perex.cz
Tue Jul 27 23:22:06 CEST 2010
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?
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 Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel