| Message ID | 20220421123803.292063-1-broonie@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: meson: Fix mixer-test issues | expand |
On Thu 21 Apr 2022 at 13:38, Mark Brown <broonie@kernel.org> wrote: > These patches fix event generation issues in the custom controls in the > Meson drivers detected by mixer-test and by inspection once I saw the > pattern in these drivers. Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Thx ! > I'm also seeing other failures due to these > controls having invalid values, eg: > > # # AIU ACODEC SRC.0 value 3 more than item count 3 > > but without documentation I'm not sure how to interpret/fix these - > either the value should be fixed up on startup or there should be an > extra value there (disconnected possibly?). Value 3 is an I2S input from a block we don't support. If we did support it, it would be an hostless DPCM BE to BE link I'm not sure how I would represent this in ASoC TBH :/ At the time, I thought it would be easier (for the users) to leave this value out and not give the false impression that the path was somehow supported. I did not realize it was the reset value nor that it would be a problem. I can add a element to the enum if you think it is better have it regardless of the actual path support. What do you think ? > > Mark Brown (3): > ASoC: meson: Fix event generation for AUI ACODEC mux > ASoC: meson: Fix event generation for AUI CODEC mux > ASoC: meson: Fix event generation for G12A tohdmi mux > > sound/soc/meson/aiu-acodec-ctrl.c | 2 +- > sound/soc/meson/aiu-codec-ctrl.c | 2 +- > sound/soc/meson/g12a-tohdmitx.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > > base-commit: 3123109284176b1532874591f7c81f3837bbdc17
On Thu, Apr 21, 2022 at 03:02:54PM +0200, Jerome Brunet wrote: > On Thu 21 Apr 2022 at 13:38, Mark Brown <broonie@kernel.org> wrote: > > I'm also seeing other failures due to these > > controls having invalid values, eg: > > # # AIU ACODEC SRC.0 value 3 more than item count 3 > > but without documentation I'm not sure how to interpret/fix these - > > either the value should be fixed up on startup or there should be an > > extra value there (disconnected possibly?). > Value 3 is an I2S input from a block we don't support. > If we did support it, it would be an hostless DPCM BE to BE link > I'm not sure how I would represent this in ASoC TBH :/ > At the time, I thought it would be easier (for the users) to leave this > value out and not give the false impression that the path was somehow > supported. > I did not realize it was the reset value nor that it would be a problem. > I can add a element to the enum if you think it is better have it > regardless of the actual path support. What do you think ? I don't have strong feelings TBH - your argument for not supporting it for now makes sense to me and we generally try to avoid changing the hardware defaults. Probably I'd go with changing the default but since it's a valid value in the hardware it's most likely not too bad to leave things as they are for now, though there might be some applications that get confused and explode.
On Thu, 21 Apr 2022 13:38:00 +0100, Mark Brown wrote: > These patches fix event generation issues in the custom controls in the > Meson drivers detected by mixer-test and by inspection once I saw the > pattern in these drivers. I'm also seeing other failures due to these > controls having invalid values, eg: > > # # AIU ACODEC SRC.0 value 3 more than item count 3 > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: meson: Fix event generation for AUI ACODEC mux commit: 2e3a0d1bfa95b54333f7add3e50e288769373873 [2/3] ASoC: meson: Fix event generation for AUI CODEC mux commit: fce49921a22262736cdc3cc74fa67915b75e9363 [3/3] ASoC: meson: Fix event generation for G12A tohdmi mux commit: 12131008fc13ff7f7690d170b7a8f72d24fd7d1e 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