ucm2: Add setting LED Mode in SetLED macro

[mstrozek]

Add 'Mode' argument to SetLED macro in order to allow setting a different LED mode. This will allow mute switches with inverted values to control the LEDs with 'follow-route' option instead of default 'follow-mute'.

Update all calls to SetLED with appropriate Mode argument.

[perexg]

Make this argument optional, like:

diff --git a/ucm2/common/ctl/led.conf b/ucm2/common/ctl/led.conf
index f10ad87..9bb7dc5 100644
--- a/ucm2/common/ctl/led.conf
+++ b/ucm2/common/ctl/led.conf
@@ -46,6 +46,13 @@ DefineMacro.SetLED {
                }
        }
        If.1 {
+               Condition {
+                       Type String
+                       Empty "${var:-__Mode}"
+               }
+               True.Define.__Mode "follow-mute"
+       }
+       If.2 {
                Condition { Type AlwaysTrue }
                True.FixedBootSequence [
                        sysw "-/class/sound/ctl-led/${var:__LED}/card${CardNumber}/${var:__Action}:${var:__CtlId}"

so it ends up as one file change. Thank you.

[perexg]

.. also I wonder why this inverted behaviour is required. Usually, it's a sign of a bad Switch implementation in the driver.

[mstrozek]

@perexg Thank you for the suggestion! It's cleaner now when it's optional.

Unfortunately the switches have inverted behaviour because the SDCA driver must comply with MIPI SDCA specification, which explicitly says the Feature Units have to have Mute Controls where 1 = disabled (muted) signal :(

[perexg]

@perexg Thank you for the suggestion! It's cleaner now when it's optional.

Unfortunately the switches have inverted behaviour because the SDCA driver must comply with MIPI SDCA specification, which explicitly says the Feature Units have to have Mute Controls where 1 = disabled (muted) signal :(

Right, but nothing prevents to do an inversion in the SDCA driver for ctl values before they are written to hardware. So user space will see the standard on/off switch.