mbox series

[v1,0/2] ASoC/tda998x: Fix reporting of nonexistent capture streams

Message ID 20221130184644.464820-1-broonie@kernel.org (mailing list archive)
Headers show
Series ASoC/tda998x: Fix reporting of nonexistent capture streams | expand

Message

Mark Brown Nov. 30, 2022, 6:46 p.m. UTC
The recently added pcm-test selftest has pointed out that systems with
the tda998x driver end up advertising that they support capture when in
reality as far as I can see the tda998x devices are transmit only.  The
DAIs registered through hdmi-codec are bidirectional, meaning that for
I2S systems when combined with a typical bidrectional CPU DAI the
overall capability of the PCM is bidirectional.  In most cases the I2S
links will clock OK but no useful audio will be returned which isn't so
bad but we should still not advertise the useless capability, and some
systems may notice problems for example due to pinmux management.

This is happening due to the hdmi-codec helpers not providing any
mechanism for indicating unidirectional audio so add one and use it in
the tda998x driver.  It is likely other hdmi-codec users are also
affected but I don't have those systems to hand.

Mark Brown (2):
  ASoC: hdmi-codec: Allow playback and capture to be disabled
  drm: tda99x: Don't advertise non-existent capture support

 drivers/gpu/drm/i2c/tda998x_drv.c |  2 ++
 include/sound/hdmi-codec.h        |  4 ++++
 sound/soc/codecs/hdmi-codec.c     | 30 +++++++++++++++++++++++++-----
 3 files changed, 31 insertions(+), 5 deletions(-)


base-commit: f0c4d9fc9cc9462659728d168387191387e903cc

Comments

Russell King (Oracle) Dec. 2, 2022, 1:55 p.m. UTC | #1
On Wed, Nov 30, 2022 at 06:46:42PM +0000, Mark Brown wrote:
> The recently added pcm-test selftest has pointed out that systems with
> the tda998x driver end up advertising that they support capture when in
> reality as far as I can see the tda998x devices are transmit only.  The
> DAIs registered through hdmi-codec are bidirectional, meaning that for
> I2S systems when combined with a typical bidrectional CPU DAI the
> overall capability of the PCM is bidirectional.  In most cases the I2S
> links will clock OK but no useful audio will be returned which isn't so
> bad but we should still not advertise the useless capability, and some
> systems may notice problems for example due to pinmux management.
> 
> This is happening due to the hdmi-codec helpers not providing any
> mechanism for indicating unidirectional audio so add one and use it in
> the tda998x driver.  It is likely other hdmi-codec users are also
> affected but I don't have those systems to hand.
> 
> Mark Brown (2):
>   ASoC: hdmi-codec: Allow playback and capture to be disabled
>   drm: tda99x: Don't advertise non-existent capture support
> 
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 ++
>  include/sound/hdmi-codec.h        |  4 ++++
>  sound/soc/codecs/hdmi-codec.c     | 30 +++++++++++++++++++++++++-----
>  3 files changed, 31 insertions(+), 5 deletions(-)

Looks sane.

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Thanks.
Mark Brown Dec. 4, 2022, 5:04 p.m. UTC | #2
On Wed, 30 Nov 2022 18:46:42 +0000, Mark Brown wrote:
> The recently added pcm-test selftest has pointed out that systems with
> the tda998x driver end up advertising that they support capture when in
> reality as far as I can see the tda998x devices are transmit only.  The
> DAIs registered through hdmi-codec are bidirectional, meaning that for
> I2S systems when combined with a typical bidrectional CPU DAI the
> overall capability of the PCM is bidirectional.  In most cases the I2S
> links will clock OK but no useful audio will be returned which isn't so
> bad but we should still not advertise the useless capability, and some
> systems may notice problems for example due to pinmux management.
> 
> [...]

Applied to

   broonie/sound.git for-next

Thanks!

[1/2] ASoC: hdmi-codec: Allow playback and capture to be disabled
      commit: f77a066f4ed307db93aafee621e2683c3bda98ce
[2/2] drm: tda99x: Don't advertise non-existent capture support
      commit: a04f1c81316d27e140c3df5561e5ef87794cd4bc

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