On Wed, May 08, 2019 at 11:16:18AM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > > there is no i2c irq assigned but only ACPI gpio, as far as I checked.

> > You can map through an ACPI GPIO to an interrupt without worrying about
> > the fact that it's mapped as a GPIO in ACPI IIRC - if you can't there's
> > lots of other drivers are going to have issues.

> But what gives a benefit?  It needs more plumbing between codec and
> machine driver.  The i2c probe doesn't give the irq, so you'd need and
> extra stuff to enable the irq in a different route if you'd need to
> implement the handler in the codec driver.

Handling the interrupt entirely within the CODEC driver *reduces* the
coupling between the CODEC and machine drivers, making it more possible
to use the standard set_jack() interface and generic machine drivers
with the CODEC drivers.

Actually looking a little I think you may need some ACPI specific
parsing code in the probe function to look up the GPIO but that should
just be like all the other DMI quirking stuff, hidden in the CODEC
driver.  It's really sad how bad a job Intel have done of making
firmware interfaces for their audio hardware.  I had thought people had
managed to hide all that stuff but I'm not seeing the code right now.

> Actually, my latest patchset already eliminates the exported stuff by
> moving to set_jack callback like some other drivers do.  If you have
> an idea for further simplification / fixes, let me know.

> I haven't submitted because of the merge window.  The patch is found
> at topic/soc-cx2072x-5.2 branch, the commit is
>   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=topic/soc-cx2072x-5.2&id=ca7f4eee5ecbefcf347f5a4984c0a17629360186

I'm on a train with intermittent network connectivity right now (and
getting near to my destination too)...