Re: [PATCH 05/16] ASoC: core: Add strobe control

[Kristoffer KARLSSON <kristoffer.karlsson@stericsson.com>]

On 2012-03-13 22:33, Mark Brown wrote:

> On Tue, Mar 13, 2012 at 04:11:32PM +0100, Ola Lilja wrote:
>> From: Kristoffer KARLSSON <kristoffer.karlsson@stericsson.com>
>>
>> Added support for a control that strobes a bit in
>> a register to high then back to low (or the inverse).
>>
>> This is typically useful for hardware that requires
>> strobing a singe bit to trigger some functionality
>> and where exposing the bit in a normal enum control
>> would require the user to first manually set then
>> again unset the bit again for the strobe to trigger.
>>
>> Get/put accessors added.
>>
>> snd_soc_get_enum_strobe
>> snd_soc_put_enum_strobe
>>
>> Also a generic convenience macros added.
>>
>> SOC_ENUM_STROBE
> 
> Based on this description it's hard to see why this control is patterned
> after an enum - why would we have an enumerated control to bounce a
> single register bit on then off?


I originally chose to pattern this control after an enum since enum controls
would allow for exposing such intuitive textual information to the client about
the state of the control for this type of use case.

The idea being that the enum would have two options like ('Ready'/'Apply' or
possibly 'Idle'/'Activate'). Setting 'Apply' would then strobe the bit high
then low and a consecutive read for a client of this control would then return
'Ready' to signify that the hardware is ready for a new strobe push.

I suppose that the control might as well be modeled after a SOC_SINGLE instead.
I noticed that a SOC_SINGLE_EXT with max = 1 would  set element type to BOOLEAN
in snd_soc_info_volsw which I guess also would work just fine for this type of
control.

Do you think that SOC_SINGLE would be a choice to pattern this control from?

Or would you prefer that the control still be textual but more specifically
force only exactly two textual options and not just any generic enum?