ASoC: hdmi-codec: restore HDMI-IN capture broken by #430#487
Open
smazurov wants to merge 2 commits into
Open
Conversation
commit f77a066 upstream. Currently the hdmi-codec driver always registers both playback and capture capabilities but for most systems there's no actual capture capability, usually HDMI is transmit only. Provide platform data which allows the users to indicate what is supported so that we don't end up advertising things to userspace that we can't actually support. In order to avoid breaking existing users the flags in platform data are a bit awkward and specify what should be disabled rather than doing the perhaps more expected thing and defaulting to not supporting capture. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20221130184644.464820-2-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> [smazurov@gmail.com: backported to Armbian linux-rockchip rk-6.1-rkr5.1. This restores upstream behavior that was lost when commit 78c67d9 ("ASoC: hdmi-codec: disable capture for HDMI-TX to fix mono audio", PR armbian#430) added an unconditional zeroing of daidrv[].capture.channels_min and channels_max in hdmi_codec_probe(). That zeroing was intended to silence a PulseAudio mono-audio symptom on RK3576 NanoPi HDMI-TX boards, but the same hdmi-audio-codec child device is registered by rk_hdmirx (HDMI-IN) on every RK3588 board with HDMI input, so the unconditional zeroing also killed the HDMI-IN capture PCM (zero-stream registration, card 1 absent from arecord -l, /proc/asound/pcm line ends in a bare colon). This patch removes that unconditional zeroing and replaces it with the upstream per-instance no_i2s_playback / no_i2s_capture / no_spdif_* flags. Drivers that need the original PulseAudio workaround (the RK3576 HDMI-TX case) can opt back in by setting hdmi_codec_pdata.no_i2s_capture = 1 explicitly. rk_hdmirx leaves the flags unset and capture survives. Reported in https://forum.armbian.com/topic/56884-hdmi-input-audio-not-working-with-the-last-bsp-kernel/ . Bisect on Orange Pi 5 Ultra: linux-image-vendor-rk35xx 25.8.2 works, 26.2.1 broken; offending commit is 78c67d9.] Tested-by: Stepan Mazurov <smazurov@gmail.com> Signed-off-by: Stepan Mazurov <smazurov@gmail.com>
commit e041a2a upstream. Currently only one stream is supported. This isn't usally a problem until you have a multi codec audio card. Because the audio card will run startup and shutdown on both capture and playback streams. So if your hdmi-codec only support either playback or capture. Then ALSA can't open for playback and capture. This patch will ignore if startup and shutdown are called with a non supported stream. Thus, allowing an audio card like this: +-+ cpu1 <--@-| |-> codec1 (HDMI-CODEC) | |<- codec2 (NOT HDMI-CODEC) +-+ Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk> Link: https://lore.kernel.org/r/20230309065432.4150700-2-emas@bang-olufsen.dk Signed-off-by: Mark Brown <broonie@kernel.org> [smazurov@gmail.com: rebased onto Armbian linux-rockchip rk-6.1-rkr5.1 which carries an additional tx_dlp early-return in both hdmi_codec_startup and hdmi_codec_shutdown (introduced by commit e22dfe2, "ASoC: hdmi-codec: Add support for HDMI-TX DLP"). The new has_playback / has_capture guard from this upstream commit is added immediately AFTER the tx_dlp guard, so both mechanisms compose: tx_dlp short-circuits HDMI-TX DLP capture paths, has_capture/has_playback short-circuits unsupported-direction calls on codecs that advertise the no_i2s_* flags from the companion patch. Companion to the no_i2s_capture restoration. Both are needed together; without this patch ALSA can still hit "Only one simultaneous stream supported!" on multi-codec cards where the HDMI-codec advertises only one direction.] Tested-by: Stepan Mazurov <smazurov@gmail.com> Signed-off-by: Stepan Mazurov <smazurov@gmail.com>
smazurov
force-pushed
the
fix/hdmi-codec-restore-capture
branch
from
d54e982 to
2f2652f
Compare
Member
|
I'll verify this commit on my NanoPi M5 soon |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR #430 fixed mono audio on RK3576 NanoPi HDMI-TX boards by unconditionally zeroing
daidrv[].capture.channels_min/maxinhdmi_codec_probe(). However, the samehdmi-audio-codecchild device is registered byrk_hdmirx(HDMI-IN) on every RK3588 board with HDMI input, so the unconditional zeroing also killed the HDMI-IN capture PCM:/proc/asound/cardsbut has zero capture streamsarecord -l/proc/asound/pcmline ends in a bare colonBisected on Orange Pi 5 Ultra:
linux-image-vendor-rk35xx25.8.2 works, 26.2.1 broken.Also reported independently on Radxa Rock 5 ITX: https://forum.armbian.com/topic/56884-hdmi-input-audio-not-working-with-the-last-bsp-kernel/
Changes
Commit 1 — backport of upstream
f77a066f4ed3(Mark Brown):no_i2s_playback,no_i2s_capture,no_spdif_playback,no_spdif_captureflags tohdmi_codec_pdatark_hdmirxleaves flags unset so capture survivesCommit 2 — backport of upstream
e041a2a55058(Emil Svendsen):hdmi_codec_startup/shutdownsilently return 0 for unsupported stream directionstx_dlpearly-return guard (commite22dfe2e)Test plan
arecord -lshows HDMI-IN capture device after patcharecord -D hw:1,0 -f S16_LE -r 48000 -c 2captures audio from HDMI sourceno_i2s_capture = 1should behave identically to the old zeroing) - I can't do this as I dont have access to rk3576