N900 modem support in 3.18-rc1
sre at kernel.org
Fri Nov 14 13:57:50 PST 2014
On Fri, Nov 14, 2014 at 09:54:42PM +0200, Ivaylo Dimitrov wrote:
> On 14.11.2014 19:20, Sebastian Reichel wrote:
> >The patch looks ok. It does not cleanup the cmt-speech driver for
> >mainline usage, but it should work. Before adding this driver to the
> >mainline kernel there should be open source userspace support anyway.
> I am aware of that(patch not ready), it's one of the reasons this
> patch still sits on gitorious IMO.
> libcmtspeechdata was opened by Nokia long ago, so I don't understand what
> userspace support (for inclusion of the driver in the mainline kernel that
> is) is needed. see https://gitorious.org/meego-cellular/libcmtspeechdata/source/7f8f3ce357513e4849e1bf6d657980a514529c1a:
ah cool. I assumed, that userland stuff is mostly closed.
> REed pulseaudio modules that use cmtspeech will be ready sooner than later
> (I believe in 2-3 monts from now), see on gitorious how fast we progressed
> with -record and -music modules. Sure, -voice module is way more
> complicated, but lots of it is already opensourced, we just need to figure
> out a couple of DSP algorithms(drc, agc, aec, etc) related to call quality.
> But I don't think the driver should wait for those modules to be REed, they
> can be used as is even now, in their closed form for testing.
It seems there is already cmtspeech code for pulseaudio?
> Unfortunately all my spare time is dedicated to that PA stuff, so
> I simply can't cleanup cmtspeech driver and send a patch for
> upstreaming. (Pavel, what about you?)
If somebody gets audio working with your driver and documents the
steps needed in userland I will take care of upstreaming the driver.
> >Btw. I am aware that this would break existing pulse audio stuff,
> >but wouldn't it make sense to export a V4L2 device instead of the
> >custom /dev/cmt_speech ABI?
> Not to say that I agree with Pali's reply that working userspace should not
> be broken just for the sake of it.
Actually the mainline kernel never implemented that interface, so
there is no regression/break and I don't think introducing userspace
ABI's should be done carelessly - especially when there is also a
> Nokia PA guys did a great job integrating lots of things related to audio
> and honestly, I don't see a reason why should we reinvent the wheel. There
> is lot more behind the scenes than simple PCM streaming (like audio policies
> and routing, sideband audio, speakers protection, etc) and reiplementing all
> this using different API wouldn't worth it IMO.
What has speaker protection to do with the modem interface?
Shouldn't this be two different PA modules?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the linux-arm-kernel