From: Alan Cox <alan@linux.intel.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: greg@kroah.com, alsa-devel@alsa-project.org, lrg@slimlogic.co.uk
Subject: Re: [PATCH] sst: Intel SST audio driver
Date: Mon, 4 Oct 2010 10:04:24 +0100 [thread overview]
Message-ID: <20101004100424.4e5cf40c@linux.intel.com> (raw)
In-Reply-To: <20101003201943.GA31764@opensource.wolfsonmicro.com>
> IIRC at least one version had a split where the ALSA integration stuff
> was separated out from the underlying DSP interface code - that was
> pretty helpful since it helps focus on the ALSA specifics.
Yes but that split is no longer there once the clean up patches sit on
top because they weren't put together as separate bits. This is exactly
the sort of reason I want to get it in staging.
> > Agreed, although gstreamer is pretty good at that it would save
> > work if it can be partly generic. It's not trivial however because
> > the offload
>
> Plus the fact that not everyone is using gstreamer at the application
> level :/
>
> > interface with suitable firmware loaded does things other than PCM
> > and you have very firmware specific interfaces for configuring
> > those.
>
> We ought to be able to come up with something for the core streaming
> stuff, though. Like I say, it's just a nice to have though.
I would have thought PCM at least was also going to have some kind of
common structure.
> I do have some nervousness about the concept of staging for embedded
> stuff since I worry that inclusion in staging can send the wrong
> message to vendors but that's a completely separate issue to this
> driver.
Noted. But I'll point you at the SEP driver which did get bogged down
for ages for reasons I can't really go into publically, and we
therefore pulled out of staging.
Alan
next prev parent reply other threads:[~2010-10-04 9:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 16:21 [PATCH] sst: Intel SST audio driver Alan Cox
2010-10-02 23:06 ` Mark Brown
[not found] ` <20101003112244.488282fd@linux.intel.com>
2010-10-03 20:30 ` Mark Brown
2010-10-04 9:04 ` Alan Cox [this message]
2010-10-04 23:49 ` Mark Brown
2010-10-17 9:02 ` Takashi Iwai
2010-10-17 10:36 ` Mark Brown
2010-10-17 11:14 ` Takashi Iwai
2010-10-17 16:18 ` Mark Brown
2010-10-17 21:36 ` Takashi Iwai
2010-10-17 22:11 ` Mark Brown
2010-10-18 6:14 ` Takashi Iwai
2010-10-18 7:20 ` Mark Brown
2010-10-18 7:49 ` Pavel Hofman
2010-10-18 8:10 ` Takashi Iwai
2010-10-18 10:34 ` Alan Cox
2010-10-18 13:19 ` Takashi Iwai
2010-10-18 11:07 ` Liam Girdwood
2010-10-18 10:24 ` Alan Cox
2010-10-19 0:16 ` Mark Brown
2010-10-05 15:48 ` Staging: sst: add " Greg KH
[not found] <mailman.1.1287309601.23450.alsa-devel@alsa-project.org>
2010-10-17 10:46 ` [PATCH] sst: " Koul, Vinod
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=20101004100424.4e5cf40c@linux.intel.com \
--to=alan@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=greg@kroah.com \
--cc=lrg@slimlogic.co.uk \
/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).