On 05/26/2015 10:14 PM, Mark Brown wrote: [...]
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.
Sorry, I overlooked something which lead to a bit of misunderstanding. I though that the gpio-audio-jack driver also sets up the DAPM pins for the jack, based on that patch 4 removes the DAPM jack pin setup from tegra_max98090 driver. This would have resulted in a weired dependency chain where the gpio-audio-jack driver sets references DAPM pins by name which belong to the audio fabric that references the gpio-audio-jack node as its jack detection chip. But the driver doesn't actually do that so there is no real implicit dependency to the audio-fabric in the binding itself and it is all internal to the implementation. So that is OK.
I'm still a bit uncomfortable with mixing up jacks and jack detection logic. For the GPIO based jack detection logic this isn't that bad since we could argue that the DT node represents the jack. But I'm a bit afraid that this sets a precedence and we'll soon see bindings where the description of the jack becomes part of the description of the jack detection chip or CODEC. And the component or CODEC driver is responsible for registering the jack.
And the other problem is how do we match up DAPM widgets to a jack. This is functionality from the tegra_max98090 driver that is lost in this series.
- Lars