[alsa-devel] [PATCH] ASoC: mxs-saif: check BUSY bit in hw_params() only if not mclk_in_use
If something else, typically a codec, has enabled mclk, the BUSY bit may be set when hw_params() is called without this being an error. This check thus causes intermittent failures to configure the sound device when used in such a manner. Fix this by making the test conditional on !saif->mclk_in_use.
Signed-off-by: Mans Rullgard mans@mansr.com --- sound/soc/mxs/mxs-saif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index a6c7b8d87cd2..13631003cb7c 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -418,7 +418,7 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, }
stat = __raw_readl(saif->base + SAIF_STAT); - if (stat & BM_SAIF_STAT_BUSY) { + if (!saif->mclk_in_use && (stat & BM_SAIF_STAT_BUSY)) { dev_err(cpu_dai->dev, "error: busy\n"); return -EBUSY; }
On Wed, Feb 03, 2016 at 01:18:20PM +0000, Mans Rullgard wrote:
If something else, typically a codec, has enabled mclk, the BUSY bit may be set when hw_params() is called without this being an error. This check thus causes intermittent failures to configure the sound device when used in such a manner. Fix this by making the test conditional on !saif->mclk_in_use.
Please remember to CC the maintainers for the driver when sending patches.
Mark Brown broonie@kernel.org writes:
On Wed, Feb 03, 2016 at 01:18:20PM +0000, Mans Rullgard wrote:
If something else, typically a codec, has enabled mclk, the BUSY bit may be set when hw_params() is called without this being an error. This check thus causes intermittent failures to configure the sound device when used in such a manner. Fix this by making the test conditional on !saif->mclk_in_use.
Please remember to CC the maintainers for the driver when sending patches.
I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed to know who the maintainers are if they're not listed in MAINTAINERS?
On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote:
Mark Brown broonie@kernel.org writes:
Please remember to CC the maintainers for the driver when sending patches.
I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed to know who the maintainers are if they're not listed in MAINTAINERS?
By looking at people working on the driver in git and the authors listed in the driver (get_maintainer --git will do most of this for you, though you do have to think about false positives). As previously advised this is not something that can be fully automated, you need to think about who you are sending things to and why.
Mark Brown broonie@kernel.org writes:
On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote:
Mark Brown broonie@kernel.org writes:
Please remember to CC the maintainers for the driver when sending patches.
I CCd everybody scripts/get_maintainers.pl suggested. How am I supposed to know who the maintainers are if they're not listed in MAINTAINERS?
By looking at people working on the driver in git and the authors listed in the driver (get_maintainer --git will do most of this for you, though you do have to think about false positives). As previously advised this is not something that can be fully automated, you need to think about who you are sending things to and why.
Most files have been touched by many people. I thought the entire point of the MAINTAINERS file was to remove the guesswork from choosing where to send patches. Apparently sound/ has rules of its own.
On Fri, Feb 05, 2016 at 01:43:22PM +0000, Måns Rullgård wrote:
Mark Brown broonie@kernel.org writes:
By looking at people working on the driver in git and the authors listed in the driver (get_maintainer --git will do most of this for you, though you do have to think about false positives). As previously advised this is not something that can be fully automated, you need to think about who you are sending things to and why.
Most files have been touched by many people. I thought the entire point of the MAINTAINERS file was to remove the guesswork from choosing where to send patches. Apparently sound/ has rules of its own.
No, this is true in general for the kernel - I'm just repeating SubmittingPatches to you here. Most individual drivers don't have a specific entry in MAINTAINERS and it's probably not worth the bother trying to get it completely 100% accurate. MAINTAINERS is there to be helpful and to have things like lists and git hanging off it but it's not the be all and end all of everything, it still generates false positives (consider how many ASoC patches Jaroslav has reviewed for example) and false negatives. No automated system is going to be perfect, at some point you're going to need to think.
The patch
ASoC: mxs-saif: check BUSY bit in hw_params() only if not mclk_in_use
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
From 436e056c4ba368f13a5709a5a4a7f26fc238a5a6 Mon Sep 17 00:00:00 2001
From: Mans Rullgard mans@mansr.com Date: Wed, 3 Feb 2016 13:18:20 +0000 Subject: [PATCH] ASoC: mxs-saif: check BUSY bit in hw_params() only if not mclk_in_use
If something else, typically a codec, has enabled mclk, the BUSY bit may be set when hw_params() is called without this being an error. This check thus causes intermittent failures to configure the sound device when used in such a manner. Fix this by making the test conditional on !saif->mclk_in_use.
Signed-off-by: Mans Rullgard mans@mansr.com Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/mxs/mxs-saif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index c866ade..cd04eb7e 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -408,7 +408,7 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream, }
stat = __raw_readl(saif->base + SAIF_STAT); - if (stat & BM_SAIF_STAT_BUSY) { + if (!saif->mclk_in_use && (stat & BM_SAIF_STAT_BUSY)) { dev_err(cpu_dai->dev, "error: busy\n"); return -EBUSY; }
participants (2)
-
Mans Rullgard -
Mark Brown