Future of the HDA driver

Future of the HDA driver

[David Henningsson]

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?

2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the 
door, I might have some time to contribute to the HDA driver...at least 
if not a lot of urgent stuff comes up, and up to the 3.2 merge window or 
so. (Any idea how far away that would be?) Do you think it would make 
sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move 
snd_hda_parse_pin_defcfg there, then add more functions as discovered to 
be useful to more than one autoparser?

3) One thing that has been annoyed me lately is the moving of hp out or 
speaker out to line out, which IMO leads to somewhat messy code. Seen in 
retrospect of course, don't you think it would make more sense to do let 
line_out_pins be "line out" only, and add one more variable primary_out 
that would be initialized as:

primary_out_pins = line_outs ? &line_out_pins : (speaker_outs ? 
&speaker_out_pins : (hp_outs ? &hp_out_pins : NULL))

..and then you could do something like:

#define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == 
&(_auto)->hp_out_pins)

Redoing that will probably require careful reading to avoid regressions 
though...

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

Re: Future of the HDA driver

[Mark Brown]

On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:

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

There's already an audio meeting of some kind scheduled I believe, is
there any need to have another discussion specifically for HDA?

Re: Future of the HDA driver

[David Henningsson]

On 10/03/2011 02:12 PM, Mark Brown wrote:
> On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:
>
>> 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?
>
> There's already an audio meeting of some kind scheduled I believe, is
> there any need to have another discussion specifically for HDA?

Yes, I believe so - I think the other meeting was more about GStreamer 
integration with lower layers? At least that's what I think the 
GStreamer people want to discuss. :-)

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

Re: Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 14:14:35 +0200,
David Henningsson wrote:
> 
> On 10/03/2011 02:12 PM, Mark Brown wrote:
> > On Mon, Oct 03, 2011 at 02:01:00PM +0200, David Henningsson wrote:
> >
> >> 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?
> >
> > There's already an audio meeting of some kind scheduled I believe, is
> > there any need to have another discussion specifically for HDA?
> 
> Yes, I believe so - I think the other meeting was more about GStreamer 
> integration with lower layers? At least that's what I think the 
> GStreamer people want to discuss. :-)

Well, we may hold a generic sound meeting including ASoC.  This is
what I originally thought of.  The topic HD-audio can be sorted there,
too, but I believe this is way too specific and better to be a
separate small meeting, as David suggested.

In addition, Gstreamer guys want a BoF, and this would be a different
topic, concentrated on gstreamer (although HD-audio is greatly
involved).  I haven't heard of the new about gstreamer BoF since the
last announcement, though.  I'm going to ping.


thanks,

Takashi

Re: Future of the HDA driver

[Mark Brown]

On Mon, Oct 03, 2011 at 02:14:35PM +0200, David Henningsson wrote:
> On 10/03/2011 02:12 PM, Mark Brown wrote:

> >There's already an audio meeting of some kind scheduled I believe, is
> >there any need to have another discussion specifically for HDA?

> Yes, I believe so - I think the other meeting was more about
> GStreamer integration with lower layers? At least that's what I
> think the GStreamer people want to discuss. :-)

My understanding had been that we'd just got put on their schedule for
some reason, I've certainly not seen any discussions with them.

Re: Future of the HDA driver

[Takashi Iwai]

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.

> 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the 
> door, I might have some time to contribute to the HDA driver...at least 
> if not a lot of urgent stuff comes up, and up to the 3.2 merge window or 
> so. (Any idea how far away that would be?) Do you think it would make 
> sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move 
> snd_hda_parse_pin_defcfg there, then add more functions as discovered to 
> be useful to more than one autoparser?

The merge window for 3.2 is almost closed now, as 3.1 will come out
today or tomorrow, I suppose.  Such a big change as you suggested in
the above is a 3.3-material, I suppose.

The unification of parsers is a longterm goal.  My plan is to reduce
the rest of Realtek-quirk codes as much as possible in 3.3, try to
clean up / implement the auto-parser for AD codecs, and slowly
starting to the unified parser by moving the pieces to the core
hd-audio code from codec-specific codes.

> 3) One thing that has been annoyed me lately is the moving of hp out or 
> speaker out to line out, which IMO leads to somewhat messy code. Seen in 
> retrospect of course, don't you think it would make more sense to do let 
> line_out_pins be "line out" only, and add one more variable primary_out 
> that would be initialized as:
> 
> primary_out_pins = line_outs ? &line_out_pins : (speaker_outs ? 
> &speaker_out_pins : (hp_outs ? &hp_out_pins : NULL))
> 
> ..and then you could do something like:
> 
> #define hp_is_primary_out(_auto) ((_auto)->primary_out_pins == 
> &(_auto)->hp_out_pins)
> 
> Redoing that will probably require careful reading to avoid regressions 
> though...

Yeah, the current code is still messy although you cleaned up a lot.
This needs revisited.


thanks,

Takashi

Re: Future of the HDA driver

[David Henningsson]

On 10/03/2011 02:27 PM, 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.

Sorting something out on-site will probably work as well, but I was just 
thinking that a pre-scheduled meeting is less likely to be forgotten or 
missed.

>> 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
>> door, I might have some time to contribute to the HDA driver...at least
>> if not a lot of urgent stuff comes up, and up to the 3.2 merge window or
>> so. (Any idea how far away that would be?) Do you think it would make
>> sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move
>> snd_hda_parse_pin_defcfg there, then add more functions as discovered to
>> be useful to more than one autoparser?
>
> The merge window for 3.2 is almost closed now, as 3.1 will come out
> today or tomorrow, I suppose.  Such a big change as you suggested in
> the above is a 3.3-material, I suppose.

Oh, I always seem to have bad timing :-(

But maybe I can make a 3.2 patch today or tomorrow to make naming of the 
input jacks a little more consistent, right now it's a little different 
between Realtek and Sigmatel/IDT parsers, e g.

> The unification of parsers is a longterm goal.  My plan is to reduce
> the rest of Realtek-quirk codes as much as possible in 3.3, try to
> clean up / implement the auto-parser for AD codecs, and slowly
> starting to the unified parser by moving the pieces to the core
> hd-audio code from codec-specific codes.

Hmm, maybe better to move things to a more generic auto-parser first, 
then the AD auto-parser could be more easily implemented. But I trust 
your judgement on the matter :-)

>> 3) One thing that has been annoyed me lately is the moving of hp out or
>> speaker out to line out, which IMO leads to somewhat messy code. Seen in
>> retrospect of course, don't you think it would make more sense to do let
>> line_out_pins be "line out" only, and add one more variable primary_out
>> that would be initialized as:
>>
>> primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ?
>> &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
>>
>> ..and then you could do something like:
>>
>> #define hp_is_primary_out(_auto) ((_auto)->primary_out_pins ==
>> &(_auto)->hp_out_pins)
>>
>> Redoing that will probably require careful reading to avoid regressions
>> though...
>
> Yeah, the current code is still messy although you cleaned up a lot.
> This needs revisited.

Heh, thanks for the credit, although my contributions are fairly small 
compared to yours :-)

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

Re: Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 15:14:47 +0200,
David Henningsson wrote:
> 
> On 10/03/2011 02:27 PM, 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.
> 
> Sorting something out on-site will probably work as well, but I was just 
> thinking that a pre-scheduled meeting is less likely to be forgotten or 
> missed.

It's fine for me to have a fixed schedule, too.

> >> 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the
> >> door, I might have some time to contribute to the HDA driver...at least
> >> if not a lot of urgent stuff comes up, and up to the 3.2 merge window or
> >> so. (Any idea how far away that would be?) Do you think it would make
> >> sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move
> >> snd_hda_parse_pin_defcfg there, then add more functions as discovered to
> >> be useful to more than one autoparser?
> >
> > The merge window for 3.2 is almost closed now, as 3.1 will come out
> > today or tomorrow, I suppose.  Such a big change as you suggested in
> > the above is a 3.3-material, I suppose.
> 
> Oh, I always seem to have bad timing :-(
> 
> But maybe I can make a 3.2 patch today or tomorrow to make naming of the 
> input jacks a little more consistent, right now it's a little different 
> between Realtek and Sigmatel/IDT parsers, e g.

Yes, such a small fix is welcome, of course.
I merged your patch now.


> > The unification of parsers is a longterm goal.  My plan is to reduce
> > the rest of Realtek-quirk codes as much as possible in 3.3, try to
> > clean up / implement the auto-parser for AD codecs, and slowly
> > starting to the unified parser by moving the pieces to the core
> > hd-audio code from codec-specific codes.
> 
> Hmm, maybe better to move things to a more generic auto-parser first, 
> then the AD auto-parser could be more easily implemented. But I trust 
> your judgement on the matter :-)

This can be started in parallel.  I thought of starting AD-codec
support because it has already the parser for AD1988, but not for
others.  But, it can be judged later dynamically, whether to proceed
the generic code more ahead or first finish the AD-codec parser.

> >> 3) One thing that has been annoyed me lately is the moving of hp out or
> >> speaker out to line out, which IMO leads to somewhat messy code. Seen in
> >> retrospect of course, don't you think it would make more sense to do let
> >> line_out_pins be "line out" only, and add one more variable primary_out
> >> that would be initialized as:
> >>
> >> primary_out_pins = line_outs ?&line_out_pins : (speaker_outs ?
> >> &speaker_out_pins : (hp_outs ?&hp_out_pins : NULL))
> >>
> >> ..and then you could do something like:
> >>
> >> #define hp_is_primary_out(_auto) ((_auto)->primary_out_pins ==
> >> &(_auto)->hp_out_pins)
> >>
> >> Redoing that will probably require careful reading to avoid regressions
> >> though...
> >
> > Yeah, the current code is still messy although you cleaned up a lot.
> > This needs revisited.
> 
> Heh, thanks for the credit, although my contributions are fairly small 
> compared to yours :-)

I expect more codes will come up from you in near future ;)


thanks,

Takashi

Re: Future of the HDA driver

[Jaroslav Kysela]

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.

Re: Future of the HDA driver

[David Henningsson]

On 10/03/2011 04:04 PM, Jaroslav Kysela wrote:
> 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.

Ok, looking forward to meeting you!

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

In general I like the idea of moving the codec stuff to userspace, 
because that opens up for post-release updates where distributions can 
fix things without having to release an entire kernel.

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

Hmm. I'm not a kernel veteran, but I wonder how well received this will 
be in the wider community. I'm a little sceptic to the additional step 
this will be when it comes to bootstrapping a Linux system, or that you 
need to fix a bug in the userspace code. An extra dependency on a 
compiler. Debugging the interpreter and all that, which must also be 
reasonably easy to understand and maintain. Having a low entrance for 
new contributors is important, and I'm a little worried that this will 
be worse with the suggested implementation.

Also, what about code size here, will the sum of firmware + kernel code 
exceed the current kernel code size?

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

Well, having a well working HDA driver for both current and future 
codecs and controllers is very important and from time to time I'll be 
able to contribute moderately. So whatever is decided upon will be my 
focus of contributions personally.

Also, what do you think is the time frame for having something like this 
in mainline kernel?

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

Re: Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 16:04:46 +0200,
Jaroslav Kysela wrote:
> 
> 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.

Good to hear!

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

As David already wrote, moving a big stuff into user-space is nice in
one side.  I fully agree, too.  And, the techniques you described in
the above sounds pretty interesting, makes me curious about the
detailed implementation.  But, it's a different question whether this
would be accepted as the standard.

First off, the biggest concern in this approach is the extra step user
need.  In general, moving configuration to user-space from the device
driver tends to fail.  You might remember the attempt of em28xx
TV-tuner driver, or such examples.  It's mostly because the extra step 
and lost sync of code control from the kernel tree lead to more
burden for users, even for distros.

Another big concern is that you'll run a native code in kernel-space.
Such a support is unlikely welcome into the kernel tree, no matter how
you say it must be safe.

Lastly, there is no much need of specific "firmware" nowadays in most
cases.  The most of the parser code can be shared by each codec, and
the difference between codec drivers would become minimum in the end.
If so, there is no need for loading some codes dynamically.  You can
simply use a module as of now.

Anyway, the technique sounds interesting, as mentioned, so let's keep
discussions.


thanks,

Takashi

Re: Future of the HDA driver

[Jaroslav Kysela]

Date 3.10.2011 17:42, Takashi Iwai wrote:
> At Mon, 03 Oct 2011 16:04:46 +0200,
> Jaroslav Kysela wrote:
>>
>> 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.
> 
> Good to hear!
> 
>> 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.
> 
> As David already wrote, moving a big stuff into user-space is nice in
> one side.  I fully agree, too.  And, the techniques you described in
> the above sounds pretty interesting, makes me curious about the
> detailed implementation.  But, it's a different question whether this
> would be accepted as the standard.
> 
> First off, the biggest concern in this approach is the extra step user
> need.  In general, moving configuration to user-space from the device
> driver tends to fail.  You might remember the attempt of em28xx
> TV-tuner driver, or such examples.  It's mostly because the extra step 
> and lost sync of code control from the kernel tree lead to more
> burden for users, even for distros.

I read the lwn artice about the em28xx driver and this is a bit
different example.

> Another big concern is that you'll run a native code in kernel-space.
> Such a support is unlikely welcome into the kernel tree, no matter how
> you say it must be safe.

Yes, it is for the linux kernel list discussion what the native means
and what kind of userspace <-> kernel space interaction is allowed. For
example, the BPF JIT landed to the current 3.x kernels.

>From the security perspective, the loading of the firmware files with
the interpreted bytecode can be handled in exactly same way as the
native kernel modules. If someone creates a broken native kernel module,
it has the same impact as a broken interpreted code, but the interpreter
can detect the failure (when the interpreter is properly written) and
terminate the bytecode processing.

> Lastly, there is no much need of specific "firmware" nowadays in most
> cases.  The most of the parser code can be shared by each codec, and
> the difference between codec drivers would become minimum in the end.
> If so, there is no need for loading some codes dynamically.  You can
> simply use a module as of now.

I meant to move all codec (patch/quirk) codes outside the kernel space.
Ideally, only the HDA PCM interface and basic verb I/O should be in the
kernel, all other things (PCM assignment, kcontrol creation and
handling, unsolicited event handling, HDMI handling etc.) might be moved
outside. Basically, only hda_intel.c and some portions of hda_codec.c
should be in the kernel.

> Anyway, the technique sounds interesting, as mentioned, so let's keep
> discussions.

I created a wiki page
http://www.alsa-project.org/main/index.php/HDA_UserSpace which tries to
gather all major information for further discussions. I will release
some code in few days.

					Jaroslav

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

Re: Future of the HDA driver

[David Henningsson]

On 10/04/2011 10:56 AM, Jaroslav Kysela wrote:
> Date 3.10.2011 17:42, Takashi Iwai wrote:
>> At Mon, 03 Oct 2011 16:04:46 +0200,
>> Jaroslav Kysela wrote:
>>>
>>> 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.
>>
>> Good to hear!
>>
>>> 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.
>>
>> As David already wrote, moving a big stuff into user-space is nice in
>> one side.  I fully agree, too.  And, the techniques you described in
>> the above sounds pretty interesting, makes me curious about the
>> detailed implementation.  But, it's a different question whether this
>> would be accepted as the standard.
>>
>> First off, the biggest concern in this approach is the extra step user
>> need.  In general, moving configuration to user-space from the device
>> driver tends to fail.  You might remember the attempt of em28xx
>> TV-tuner driver, or such examples.  It's mostly because the extra step
>> and lost sync of code control from the kernel tree lead to more
>> burden for users, even for distros.
>
> I read the lwn artice about the em28xx driver and this is a bit
> different example.

I also read it, and it makes me concerned about something. If/when this 
solution is deployed, do we risk that codec vendors - that now submit 
kernel patches - instead start giving out precompiled firmware files? If 
that would happen, it would be a great loss IMO.

>> Another big concern is that you'll run a native code in kernel-space.
>> Such a support is unlikely welcome into the kernel tree, no matter how
>> you say it must be safe.
>
> Yes, it is for the linux kernel list discussion what the native means
> and what kind of userspace<->  kernel space interaction is allowed. For
> example, the BPF JIT landed to the current 3.x kernels.
>
>  From the security perspective, the loading of the firmware files with
> the interpreted bytecode can be handled in exactly same way as the
> native kernel modules. If someone creates a broken native kernel module,
> it has the same impact as a broken interpreted code, but the interpreter
> can detect the failure (when the interpreter is properly written) and
> terminate the bytecode processing.

IIRC, module loading can be disabled and is used by some security people 
to harden the kernel. Do they now lose that possibility of hardening, or 
are you suggesting they disable firmware file loading as well? Or would 
that disable the audio function completely?

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

Re: Future of the HDA driver

[Takashi Iwai]

At Mon, 03 Oct 2011 14:27:34 +0200,
Takashi Iwai wrote:
> 
> > 2) With Ubuntu 11.10 in a "Freeze" state and PulseAudio 1.0 out the 
> > door, I might have some time to contribute to the HDA driver...at least 
> > if not a lot of urgent stuff comes up, and up to the 3.2 merge window or 
> > so. (Any idea how far away that would be?) Do you think it would make 
> > sense to split hda_codec.c into hda_codec.c and hda_autoparser.c, move 
> > snd_hda_parse_pin_defcfg there, then add more functions as discovered to 
> > be useful to more than one autoparser?
> 
> The merge window for 3.2 is almost closed now, as 3.1 will come out
> today or tomorrow, I suppose.  Such a big change as you suggested in
> the above is a 3.3-material, I suppose.

Looks like rc9 might be released before final, so we have still
a little bit of time left.  But I don't want too drastic change at
this moment, at least, for 3.2-merge.

Of course, I can keep any more radical changes in a devel branch and
merge back later once after 3.2 merge is closed.  That's why there are
master and for-next branches in sound git tree.  So, don't worry about
the schedule.  The patches won't be lost.


Takashi