sof-soundwire: cs42l43-spk: Correct PlaybackPCM and routing

[ujfalusi]

For speaker the correct PCM device to use is "hw:${CardId},2", the "hw:${CardId},0" is for headset playback.

Adjust the routing as well since with :0,2 the DP6RX1/2 needs to be selected for the speaker.

[charleskeepax]

This needs to be reverted, we need to share the playback device for now as many laptops don't have the bandwidth to support all the interfaces on the device separately and as the two interfaces are marked as conflicting in the UCM they can't be used simultaneously anyway. Well or we need to update the topology to reduce the bit width of each of the streams such that there is enough space on the bus.

[charleskeepax]

We do need to split out the two mic interfaces, as we have several laptop where only one of them is used, but for now we have to keep the two playback ones combined.

[ujfalusi]

This needs to be reverted, we need to share the playback device for now as many laptops don't have the bandwidth to support all the interfaces on the device separately and as the two interfaces are marked as conflicting in the UCM they can't be used simultaneously anyway. Well or we need to update the topology to reduce the bit width of each of the streams such that there is enough space on the bus.

As you said, applications using UCM will not attempt to open the :0,0 and the :0,2 at the same time as they are marked conflicting. That would take care of preserving the bandwidth for playback, no?

It is just odd to see the "Jack Out" used for Speaker from the available list of PCMs:

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofsoundwire [sof-soundwire], device 0: Jack Out (*) []
card 0: sofsoundwire [sof-soundwire], device 2: Speaker (*) []
card 0: sofsoundwire [sof-soundwire], device 31: Deepbuffer Jack Out (*)

[perexg]

Also note that the driver should handle the hardware constraints correctly. If there's no enough bandwidth, the open syscall for the PCM device which consumes more than allowed bandwidth should return -EBUSY error.

[charleskeepax]

Ok well you both know a lot more about this UCM stuff than I, so hopefully its good. I will push a patch shortly to fix the mic inputs as well since we needed to do that to support systems with host attached dmics anyway.

If there's no enough bandwidth, the open syscall for the PCM device which consumes more than allowed bandwidth should return -EBUSY error.

Can open return -EBUSY here? I guess it can in the case the bus is totally full, although I would imagine that is quite rare. More often it would just need to constraint the hw_params? Open doesn't know how much bandwidth the stream will want to consume, so has to wait until hw_params to find out?