2020-04-17 15:33:17

by Matthias Blankertz

[permalink] [raw]
Subject: [PATCH 0/2] ASoC: rsnd: multi-SSI setup fixes

Fix rsnd_dai_call() operations being performed twice for the master SSI
in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI
setups.
The only visible effect of these issues was some "status check failed"
spam when the rsnd_ssi_stop was called, but overall the code is cleaner
now, and some questionable writes to the SSICR register which did not
lead to any observable misbehaviour but were contrary to the datasheet
are fixed.

Mark:
The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI
start/stop in multi-SSI mode" from a few days ago and achieves the same
effect in a simpler fashion, if you would prefer a clean patch series
based on v5.6 drop me a note.

Greetings,
Matthias


Matthias Blankertz (2):
ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
ASoC: rsnd: Fix "status check failed" spam for multi-SSI

sound/soc/sh/rcar/ssi.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)

base-commit: 15a5760cb8b6d5c1ebbf1d2e1f0b77380ab68a82
--
2.26.1


2020-04-17 15:34:46

by Matthias Blankertz

[permalink] [raw]
Subject: [PATCH 1/2] ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent

The master SSI of a multi-SSI setup was attached both to the
RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream.
This is not correct wrt. the meaning of being "parent" in the rest of
the SSI code, where it seems to indicate an SSI that provides clock and
word sync but is not transmitting/receiving audio data.

Not treating the multi-SSI master as parent allows removal of various
special cases to the rsnd_ssi_is_parent conditions introduced in commit
a09fb3f28a60 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode").
It also fixes the issue that operations performed via rsnd_dai_call()
were performed twice for the master SSI. This caused some "status check
failed" spam when stopping a multi-SSI stream as the driver attempted to
stop the master SSI twice.

Signed-off-by: Matthias Blankertz <[email protected]>
---
sound/soc/sh/rcar/ssi.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index d51fb3a39448..9900a4f6f4e5 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -407,7 +407,7 @@ static void rsnd_ssi_config_init(struct rsnd_mod *mod,
* We shouldn't exchange SWSP after running.
* This means, parent needs to care it.
*/
- if (rsnd_ssi_is_parent(mod, io) && !rsnd_ssi_multi_slaves(io))
+ if (rsnd_ssi_is_parent(mod, io))
goto init_end;

if (rsnd_io_is_play(io))
@@ -559,7 +559,7 @@ static int rsnd_ssi_start(struct rsnd_mod *mod,
* EN is for data output.
* SSI parent EN is not needed.
*/
- if (rsnd_ssi_is_parent(mod, io) && !rsnd_ssi_multi_slaves(io))
+ if (rsnd_ssi_is_parent(mod, io))
return 0;

ssi->cr_en = EN;
@@ -582,7 +582,7 @@ static int rsnd_ssi_stop(struct rsnd_mod *mod,
if (!rsnd_ssi_is_run_mods(mod, io))
return 0;

- if (rsnd_ssi_is_parent(mod, io) && !rsnd_ssi_multi_slaves(io))
+ if (rsnd_ssi_is_parent(mod, io))
return 0;

cr = ssi->cr_own |
@@ -620,7 +620,7 @@ static int rsnd_ssi_irq(struct rsnd_mod *mod,
if (rsnd_is_gen1(priv))
return 0;

- if (rsnd_ssi_is_parent(mod, io) && !rsnd_ssi_multi_slaves(io))
+ if (rsnd_ssi_is_parent(mod, io))
return 0;

if (!rsnd_ssi_is_run_mods(mod, io))
@@ -737,6 +737,9 @@ static void rsnd_ssi_parent_attach(struct rsnd_mod *mod,
if (!rsnd_rdai_is_clk_master(rdai))
return;

+ if (rsnd_ssi_is_multi_slave(mod, io))
+ return;
+
switch (rsnd_mod_id(mod)) {
case 1:
case 2:
--
2.26.1

2020-04-19 23:40:45

by Kuninori Morimoto

[permalink] [raw]
Subject: Re: [PATCH 0/2] ASoC: rsnd: multi-SSI setup fixes


Hi Matthias

> Fix rsnd_dai_call() operations being performed twice for the master SSI
> in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI
> setups.
> The only visible effect of these issues was some "status check failed"
> spam when the rsnd_ssi_stop was called, but overall the code is cleaner
> now, and some questionable writes to the SSICR register which did not
> lead to any observable misbehaviour but were contrary to the datasheet
> are fixed.
>
> Mark:
> The first patch kind of reverts my "ASoC: rsnd: Fix parent SSI
> start/stop in multi-SSI mode" from a few days ago and achieves the same
> effect in a simpler fashion, if you would prefer a clean patch series
> based on v5.6 drop me a note.

Nice catch !
For all patches

Acked-by: Kuninori Morimoto <[email protected]>

Thank you for your help !!

Best regards
---
Kuninori Morimoto

2020-04-20 16:38:02

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 0/2] ASoC: rsnd: multi-SSI setup fixes

On Fri, 17 Apr 2020 17:30:15 +0200, Matthias Blankertz wrote:
> Fix rsnd_dai_call() operations being performed twice for the master SSI
> in multi-SSI setups, and fix the rsnd_ssi_stop operation for multi-SSI
> setups.
> The only visible effect of these issues was some "status check failed"
> spam when the rsnd_ssi_stop was called, but overall the code is cleaner
> now, and some questionable writes to the SSICR register which did not
> lead to any observable misbehaviour but were contrary to the datasheet
> are fixed.
>
> [...]

Applied to

broonie/sound.git for-5.7

Thanks!

[1/2] ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
commit: 0c258657ddfe81b4fc0183378d800c97ba0b7cdd
[2/2] ASoC: rsnd: Fix "status check failed" spam for multi-SSI
commit: 54cb6221688660670a2e430892d7f4e6370263b8

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