On 05/27/2015 06:22 AM, Dylan Reid wrote:
On Tue, May 26, 2015 at 1:14 PM, Mark Brown broonie@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?
Ideally we'd have a binding which is generic enough to cover not only audio jacks but be a bit more generic. I think Laurent already has some thoughts on how such a binding should look like.
- Lars