On 2020-08-11 2:17 PM, Amadeusz Sławiński wrote:
On 8/11/2020 12:00 PM, Cezary Rojewski wrote:
DSP designed for Lynxpoint and Wildcat Point offers no dynamic topology
i.e. all pipelines are already defined within firmware and host is
relegated to allocing stream for predefined pins. This is represented by
'catpt_topology' member.
Implementation covers all available pin types:
- system playback and capture
- two offload streams
- loopback (reference)
- bluetooth playback and capture
PCM DAI operations differentiate between those pins as some (mainly
offload) are to be handled differently - DSP expects wp updates on each
notify_position notification.
System playback has no volume control capability as it is routed to
mixer stream directly. Other primary streams - capture and two offloads
- offer individual volume controls.
Compared to sound/soc/intel/haswell this configures SSP device format
automatically on pcm creation.
Signed-off-by: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>
---
...
+
+static int catpt_set_ctlvol(struct catpt_dev *cdev, u8 stream_id,
long *ctlvol)
+{
+ u32 dspvol;
+ int ret, i;
+
+ if (ctlvol[0] == ctlvol[1]) {
This check seems bit suspicious to me, as CATPT_CHANNELS_MAX is 4 and
you only check 2 of possible values here, while in else part, you loop
over all possible 4 to set them? So there is chance that ctlvol[0] is
equal to ctlvol[1], but ctlvol[2] and ctlvol[3] are different, what
happens then?
Check is simplified as majority of configurations make use of stereo
only. Maybe it shouldn't have been. Will fix in v3.
