[PATCH v2 06/13] ASoC: Intel: catpt: PCM operations

[Cezary Rojewski]

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 at intel.com>
>> ---
> 
> ...
> 
>> +
>> +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.