From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/23] intel_sst: Save audio state across D3 on Medfield
Date: Tue, 3 May 2011 22:39:26 +0100 [thread overview]
Message-ID: <20110503213925.GA7453@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110503222903.4200a6bd@lxorguk.ukuu.org.uk>
On Tue, May 03, 2011 at 10:29:03PM +0100, Alan Cox wrote:
> I see the problem - Mark Brown took a patch in staging via the ASoC tree
> which clashes with this.
> fa880004682cf0d10e7a7c71dc8d56bbd67ac3d5
> which is not only a staging patch but also breaks compilation of the code
> because the sst_drv_ctx symbol isn't even exported or visible to the
> intelmid module, which suggests it wasn't even compile tested.
I am assured that this patch is essential to build with the Intel
drivers that are currently upstream in ASoC, though I've not personally
verified that. I'd not be surprised if the tests whoever submitted it
did had only been done with the module built in, though I'd have
expected whatever tests people do on -next to pick that up since x86
seems to be a popular target there.
> In general we have a bigger problem here, the ASoC driver appears to be
> violating rule #1 of staging - nothing outside of staging should be using
> or depending upon staging code in the first place.
To recap the previous discussion: staging is just not in the slightest
bit viable for ASoC stuff, code that does anything non-trivial is going
to get broken between releases. Especially with something like this
where the drivers are for unreleased hardware that has no current end
users it's just not a problem for the core if drivers do stuff like this
so long as they don't do anything visibly bad or cause problems for the
people who do build test whatever architecture is affected.
next prev parent reply other threads:[~2011-05-03 21:39 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 16:31 [PATCH 00/23] Intel SST driver update Alan Cox
2011-05-03 16:31 ` [PATCH 01/23] intel_sst: Save audio state across D3 on Medfield Alan Cox
2011-05-03 17:42 ` Greg KH
2011-05-03 21:29 ` Alan Cox
2011-05-03 21:39 ` Mark Brown [this message]
2011-05-03 21:53 ` Alan Cox
2011-05-03 22:02 ` Greg KH
2011-05-03 22:26 ` Mark Brown
2011-05-03 22:32 ` Greg KH
2011-05-03 22:59 ` Alan Cox
2011-05-03 23:06 ` Greg KH
2011-05-04 8:57 ` Mark Brown
2011-05-10 20:01 ` Greg KH
2011-05-03 16:32 ` [PATCH 02/23] intel_sst: MSIC codec power optimisation Alan Cox
2011-05-03 16:58 ` Mark Brown
2011-05-03 17:02 ` Alan Cox
2011-05-03 17:02 ` Mark Brown
2011-05-03 16:32 ` [PATCH 03/23] intel_sst: fix unload bugs Alan Cox
2011-05-03 16:32 ` [PATCH 04/23] intel_sst: ignore IRQ when suspended Alan Cox
2011-05-03 16:32 ` [PATCH 05/23] intel_sst: Line out support Alan Cox
2011-05-03 16:32 ` [PATCH 06/23] intel_sst: parameter tuning ioctl Alan Cox
2011-05-03 16:33 ` [PATCH 07/23] intel_sst: DMIC routing Alan Cox
2011-05-03 16:33 ` [PATCH 08/23] intel_sst: rework jack implementation Alan Cox
2011-05-03 16:33 ` [PATCH 09/23] intel_sst: Set de-bounce time Alan Cox
2011-05-03 16:33 ` [PATCH 10/23] intel_sst: Enable recording via HS_MIC Alan Cox
2011-05-03 16:33 ` [PATCH 11/23] intel_sst: Enable recording via DMIC Alan Cox
2011-05-03 16:34 ` [PATCH 12/23] intel_sst: Headphone Automute support Alan Cox
2011-05-03 16:34 ` [PATCH 13/23] intel_sst: move jack detection related configs to init time Alan Cox
2011-05-03 16:34 ` [PATCH 14/23] sst: return correct output/input device id Alan Cox
2011-05-03 16:34 ` [PATCH 15/23] intel_sst: make sure the sst_drop_stream() get called when needed Alan Cox
2011-05-03 16:35 ` [PATCH 16/23] intel_sst: MRST can only do mono recording Alan Cox
2011-05-03 16:35 ` [PATCH 17/23] intel_sst: MRST can only do 16bit recording Alan Cox
2011-05-03 16:35 ` [PATCH 18/23] intel_sst: intelmid_v2_control: correct jack event type Alan Cox
2011-05-03 16:37 ` [PATCH 19/23] intel_sst: fix runtime pm issue Alan Cox
2011-05-03 16:38 ` [PATCH 20/23] sst: set default output and input device Alan Cox
2011-05-03 16:38 ` [PATCH 21/23] intel_sst: add Master Volume Alan Cox
2011-05-03 16:43 ` [PATCH 22/23] sst: internal speaker needs setting a GPIO line Alan Cox
2011-05-03 16:43 ` [PATCH 23/23] intel_sst: fix output noises when it's not in playback Alan Cox
2011-05-03 17:15 ` [PATCH 00/23] Intel SST driver update Mark Brown
2011-05-03 18:36 ` Alan Cox
2011-05-03 18:40 ` Mark Brown
2011-05-03 20:27 ` Alan Cox
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=20110503213925.GA7453@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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