From: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: Future of the HDA driver
Date: Mon, 03 Oct 2011 16:04:46 +0200 [thread overview]
Message-ID: <4E89C0FE.1070001@perex.cz> (raw)
In-Reply-To: <s5haa9is1jd.wl%tiwai@suse.de>
Date 3.10.2011 14:27, Takashi Iwai wrote:
> At Mon, 03 Oct 2011 14:01:00 +0200,
> David Henningsson wrote:
>>
>> Hi Takashi etc,
>>
>> 1) I think it would make sense to have a designated time and room for a
>> "future of HDA" discussion in Prague. We could e g discuss input jacks
>> as kcontrols, and exposing routing to user space, as IIRC Mark Brown was
>> suggestion earlier. What do you think?
>
> Sure, we can hold a meeting spontaneously, as this would be for
> smaller group. The sound BoF isn't exactly scheduled at all yet.
> I don't know how many guys will be there, so I thought it can be
> managed spontaneously by announcing on the message board there or so.
I'll be there (LinuxCon), so you may count me in.
To this topics: For some months, I play with an idea to move the whole
HDA configuration stuff outside the kernel and leave in kernel just
mandatory things like the HDA controller code and a library with
functions for the user space code.
Because it's a bit nonsense to start with something totaly new when we
have a good C codebase with hw descriptions. I looked around the net for
a simple, small C compiler and it seems that TCC (www.tinycc.org) is
ideal for this purpose.
I created own instruction 32/64-bit set (C optimized) and I'm now at the
point that I can compile the HDA code to this instruction set with
special TCC version and I have a simple disassembler to figure the
compilation/linking issues.
The ELF loader and instruction parser is also quite complete. but a lot
of work is missing especially to create the in-kernel library for all
stuff which is required from the codec description code (kcontrol,
procfs interface etc.). Also, the codec specific source code should not
use some in-kernel things directly, but via macros or in-line helpers.
The end result should be "one universal kernel driver and firmware files
describing the codecs". The possibility to compile the codec specific
source code directly in the kernel should be retained and the source
code between build-in driver codes and firmware codes should be shared.
I hope that you like this idea like me. All opinions are welcome. We may
discuss this idea in Prague. I can post my work somewhere for further
discussion or collaborative development.
Jaroslav
--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
next prev parent reply other threads:[~2011-10-03 14:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 12:01 Future of the HDA driver David Henningsson
2011-10-03 12:12 ` Mark Brown
2011-10-03 12:14 ` David Henningsson
2011-10-03 12:31 ` Takashi Iwai
2011-10-03 12:34 ` Mark Brown
2011-10-03 12:27 ` Takashi Iwai
2011-10-03 13:14 ` David Henningsson
2011-10-03 15:31 ` Takashi Iwai
2011-10-03 14:04 ` Jaroslav Kysela [this message]
2011-10-03 15:05 ` David Henningsson
2011-10-03 15:42 ` Takashi Iwai
2011-10-04 8:56 ` Jaroslav Kysela
2011-10-04 16:33 ` David Henningsson
2011-10-04 19:31 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E89C0FE.1070001@perex.cz \
--to=perex@perex.cz \
--cc=alsa-devel@alsa-project.org \
--cc=david.henningsson@canonical.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).