Re: [RFC 0/5] Add a gpio jack device

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2405 bytes --]

On Wed, May 27, 2015 at 01:12:51PM +0200, Lars-Peter Clausen wrote:
> On 05/26/2015 10:14 PM, Mark Brown wrote:

> >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.

Ah, yes - that would indeed have been bad.

> 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.

Yes, we do need to make it *the* binding for a jack when things are put
into DT.  Hopefully that's fairly easy to police, and if we can get some
detection drivers using a binding that works with a jack object (ideally
with helpers) then that will provide positive examples too.

> 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.

That is going to be an issue when we start hooking things up isn't it.
Off the top if my head if we define some standard set of widgets that
get created then it just becomes another device for the machine to route
to/from (which is the logical extension of making it an auxdev).

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]