On 12/01/2015 06:32 PM, Charles Keepax wrote:
The siggen widget type doesn't really require its own special handling. It can be handled identically to a mic widget, ie. it is a source of a signal and causes things to power up when an output is connected.
Additionally, several places (cs42l52, cs42l56, wm8962, arizona_haptics) tie siggens in to the input framework and the pattern for this is usually to use snd_soc_dapm_enable_pin/disable_pin on the siggen widget. However, as siggen widgets present as always on (the power check always returns 1), this leads to some odd interactions with DAPM. Enabling/disabling the widget then connecting it to a path works as expected, however once in a path enabling the widget has no effect. dapm_widget_set_power will return immediately as the current power state of the widget will return 1, meaning we never check peer power states. Treating the widget as a mic widget causes the expected behaviour in all cases.
Sounds sensible, but I'd keep the siggen type and just change the power_check callback. snd_soc_dapm_mic widgets are a bit special in that they also influence how input and output widgets behave, we don't want the same behavior for siggen widgets, since siggen widgets are internal to CODEC while mic widgets are usually external.