On 05/27/2015 06:22 AM, Dylan Reid wrote:
On Tue, May 26, 2015 at 1:14 PM, Mark Brown <broonie@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
