summaryrefslogtreecommitdiff
path: root/rust/helpers/bitmap.c
diff options
context:
space:
mode:
authorKuninori Morimoto <kuninori.morimoto.gx@renesas.com>2025-09-25 05:17:41 +0000
committerMark Brown <broonie@kernel.org>2025-09-25 17:43:29 +0100
commit8c363f61e5bcb92d5e88ca1b47be74be2683b212 (patch)
treeec4fc9d7b481622ccaca00ea8d4473807cb63b6d /rust/helpers/bitmap.c
parentdc7473e6372ee36ff232af10c910ee3a8bad6447 (diff)
ASoC: renesas: msiof: Add note for The possibility of R/L opposite Capture
This driver is assuming MSIOF is used as Clock/Frame Consumer Mode, and there is a case that some Codec (= Clock/Frame Provider) might output Clock/Frame before setup MSIOF. And, MSIOF will capture data without checking SYNC signal Hi/Low (= R/L). This means, if MSIOF RXE bit was set as 1 in case of SYNC signal was Hi (= R) timing, it will start capture data since next SYNC low signal (= L). Because Linux assumes sound data is lined up as R->L->R->L->..., the data R/L might be opposite. The only solution in this case is start CLK/SYNC *after* MSIOF settings, but it depends when and how Codec driver start it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com> Link: https://patch.msgid.link/875xd7yutm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'rust/helpers/bitmap.c')
0 files changed, 0 insertions, 0 deletions