[alsa-devel] [RFC 0/5] Add a gpio jack device

[Dylan Reid]

On Tue, May 26, 2015 at 1:14 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, May 26, 2015 at 08:43:34PM +0200, Lars-Peter Clausen wrote:
>> On 05/25/2015 07:15 PM, Mark Brown wrote:
>
>> >I think it solves the 90% case well enough for simple-card (which is to
>> >the main target user here) and the situation with jack detection is
>> >already fragmented enough that we're not likely to make things
>> >that much worse.  Though now I think about it just taking the gpio out
>> >of the device name would help with binding reuse for other users.
>
>> Yea, but 90% of those 90% are already covered by the existing bindings. The
>
> I'm not sure what this thing with "yea" is (I've seen some other people
> use it too) but the normal word is "yes"...
>
>> existing simple-card bindings and driver support GPIO based jack detection,
>> albeit not as flexible as this. But we don't actually gain that much with
>
> Huh, so they do.  Ugh.
>
>> >Yes, this is the complete solution - and it's not an audio specific
>> >thing either, there's a reasonable case to be made for saying that that
>> >this should be resolved in extcon rather than in any one consumer
>> >subsystem.
>
>> If the bindings are good it doesn't really matter which framework eventually
>> picks them up, but in this case the bindings are awfully ASoC specific and
>> leak a lot of the shortcomings of the current implementation.
>
> Could you expand on the abstraction problems you see please?  It looks
> like a fairly direct mapping of GPIOs to a jack to me (like I say I
> don't see having GPIOs directly on the jack object as a problem - having
> to create a separate node to put the GPIOs in doesn't seem to solve
> anything) and we're not likely to have enough GPIOs to make the usual
> problems with lists of values too severe.
>
> The only things that concerned me particularly were the name (which I
> did agree on once you mentioned it) and the use of a bitmask to describe
> what's being reported but it's hard to think of anything much better
> than that.

Is just "audio-jack" too generic?  There are a lot of audio jacks that
wouldn't be described by this binding, such as those reported by the
227e or 5650.  The original goal here was to describe a jack that has
one or more gpios, each representing a particular type of device being
attached.  This doesn't overlap with the binding for a jack that is
handled by a headset detect chip.  Does this seem like the right goal,
or is there a benefit to having an "audio-jack" binding that tries to
cover all different types of jacks?

Thanks for taking the time to think about this.

Dylan