ASoC: soc-pcm: Preserve hw parameters from components in dpcm_runtime_setup_fe

[ujfalusi]

Component drivers can prepare snd_pcm_hardware struct based on the hardware capabilities which information should not be discarded.

Only touch the rates, channels_max and formats if they were left to 0, otherwise keep the provided configuration intact for the parameter cross checking decision.

[ujfalusi]

In essence this patch extends
083a25b ("ASoC: soc-pcm: fix hw->formats cleared by soc_pcm_hw_init() for dpcm")
to cover rates, rate_max and channels_max as well.

With IPC4 and 5.1 equipment (audio extractor) on HDMI:

./alsa_conformance_test/alsa_conformance_test -P hw:0,3 --dev_info_only
...
available channels: 2 4 6
...

With stereo:

./alsa_conformance_test/alsa_conformance_test -P hw:0,3 --dev_info_only
...
available channels: 2
...

With 7.1:

./alsa_conformance_test/alsa_conformance_test -P hw:0,3 --dev_info_only
...
available channels: 2 4 6 8
...

With IPC3 with stereo, 5.1 or 7.1:

./alsa_conformance_test/alsa_conformance_test -P hw:0,3 --dev_info_only
...
available channels: 2
...

[ujfalusi]

I will send this upstream for comments early next week, but I wanted to ask here opinions also.

[kv2019i]

Very good addition again!

Minor style nit, but upstream kernel is full of this "true/false in caller" usages, so it's probably just me.

[kv2019i]

Again, not a huge fan of these boolean parameters. The calling side readability suffers. Maybe soc_pcm_init_preserve_config() that hides the "true" case?

[ujfalusi]

or do this without a function, inline of dpcm_runtime_setup_fe()

[ujfalusi]

Changes since v1:

• move the change local to dpcm_runtime_setup_fe()

[singalsu]

Worked OK in my test with HDA topology with all formats enabled.

[ujfalusi]

We will get this back from upstream if accepted, closing it here.