All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>,
	Lee Jones <lee.jones@linaro.org>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Jie Yang <yang.jie@linux.intel.com>,
	patches@opensource.cirrus.com, linux-kernel@vger.kernel.org,
	alsa-devel@alsa-project.org
Subject: Re: [PATCH 01/14] mfd: arizona: Add jack pointer to struct arizona
Date: Tue, 29 Dec 2020 16:33:09 +0100	[thread overview]
Message-ID: <07037a8a-1d35-362e-1b82-b73b81f7c6ac@redhat.com> (raw)
In-Reply-To: <20201229150807.GF4786@sirena.org.uk>

Hi,

On 12/29/20 4:08 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
>> On 12/29/20 2:06 PM, Charles Keepax wrote:
> 
>>> I would agree with Mark though that if extcon exists for external
>>> connectors it seems odd that audio jacks would have their own
>>> special way rather than just using the connector stuff.
> 
>> Well as I said above in me experience the extcon code is (was) mostly
>> meant for kernel internal use. The sysfs API is more of a debugging
>> tool then anything else (IMHO).
> 
> No, that's not the case.  extcon is a port of an Android custom API that
> looks very similar to what ended up in mainline, it was also a
> combination of sysfs and uevents but a bit less generic.  It mainly
> existed to provide information to userspace about what was plugged into
> the various ports on devices, things like headphone jacks and the
> pre-USB C multifunction connectors you used to get on phones.

Interesting, I have close to 0 experience with Android userspace
(something which I would like to change one of these days). But I have
encountered a bunch of in-kernel use of extcon on Intel's Android X86
port for Bay and Cherry Trail devices (which I've ported to the mainline)
where extcon was e.g. used with a generic extcon-gpio like driver monitoring
the ID pin and then used by the USB code to detect (through monitoring the
extcon) if the USB port was in host or device/gadget mode.

So it seems that extcon has many different uses by different people...


> In kernel
> use wasn't really a thing for that as far as I can remember.  It's
> become a bit less of a pressing concern for Android with the move to USB
> C and the deprecation of headphone jacks in favour of a combination of
> USB C and Bluetooth but the use case is still there and it's clear that
> none of the audio stuff is currently exactly designed.
> 
> The issues I'm seeing are more to do with nobody working on things, I
> guess mainly due to the change in priorities for Android systems and in
> my case a job change.

Yes extcon definitely could use some TLC, although I do honestly wonder
if just deprecating it would not be better...

>> Also the kernel has support for a lot of sound devices, including
>> many with jack-detection support. Yet a grep for EXTCON_JACK_HEADPHONE
>> over the entire mainline kernel tree shows that only extcon-arizona.c
>> is using it. So given that we have dozens of drivers providing jack
>> functionality through the sound/core/jack.c core and only 1 driver
>> using the extcon interface I believe that the ship on how to export
>> this to userspace has long sailed, since most userspace code will
>> clearly expect the sound/core/jack.c way of doing things to be used.
> 
> The whole purpose of creating sound/core/jack.c is to abstract away the
> userspace interfaces from the drivers, most audio devices shouldn't be
> working with extcon directly just as they shouldn't be creating input
> devices or ALSA controls directly.  The missing bit there is to add
> extcon into jack.c.

So what you are suggesting is making sound/core/jack.c register the
extcon device and then have arizona-extcon.c talk to sound/core/jack.c
and no longer do any extcon stuff itself.

That would make the userspace API experience offered by arizona-extcon
consistent with other drivers with jack-detect capability.

But I do honestly wonder if we really want to use extcon for jack-detect
information reporting. At least in the mainline tree there is only 1
driver supporting this ATM and we are pretty much stuck with 1.
ALSA controls for jack detection as well as 2. input_device which
we already export, there is enough of a userspace dependency on
those that we cannot get rid of those.

So we already export 2 userspace-APIs for this IMHO adding a 3th one is not
really a good idea unless it offers significant benifits which I don't
really see. The input_dev API is simple enough to use that extcon does
not really offer any significant benefits.

But this has turned into a very generic discussion, while all I was
trying to do is make arizona-extcon export the jack-detect info through
the ALSA controls for jack detection.

My current solution to have the machine-driver register a jack and
then share that with the extcon-arizona.c code still seems like the
best/simplest solution to me here.

Unless we go with your plan to make sound/core/jack.c export
an extcon device for all sound-devs registering a jack, and then move
extcon-arizona.c over to using sound/core/jack.c without it doing any
extcon stuff itself. But as discussed I'm really not a fan of exporting
a 3th uAPI for jack-detection for all sound-cards with jack-detect
capability.

> BTW note that the existing arizona extcon driver does provide an input
> device so I'm guesing that whatever userspace you're concerned about is
> one that uses only the ALSA controls for jack detection.

The current extcon-arizona.c code only reports button presses to the
input-device, but I did try also making it report SW_HEADPHONE_INSERT /
SW_MICROPHONE_INSERT / SW_LINEOUT_INSERT too. That patch did work,
but pulseaudio did not respond to this, so it seems that pulse indeed
is reliant on the ALSA controls for jack detection (I did not debug
this further, instead I went with the route of registering a jack
from the machinedriver).

I've tested with
>> Arguably we should/could maybe even drop the extcon part of extcon-arizona.c
>> but I did not do that as I did not want to regress existing userspace
>> code which may depend on this (on specific embedded/android devices).
> 
> I do think pushing things over to extcon is a useful goal, the existing
> interfaces have fairly clear issues that it does actually address.

I don't really see any "fairly clear issues" with the input-device uAPI,
I agree that the ALSA controls can be hard to use, but that is not the
case for the input-device uAPI (*). What are your objections against using
the input-device uAPI ?

Regards,

Hans



*) I agree that it is a bit weird to use the input_device API for this,
but that ship has sailed. We will need to support the input_device API
going forward anyways and given that I see little advantage in adding
the extcon API *on top* of that.


WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
	Charles Keepax <ckeepax@opensource.cirrus.com>,
	alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
	Jie Yang <yang.jie@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 01/14] mfd: arizona: Add jack pointer to struct arizona
Date: Tue, 29 Dec 2020 16:33:09 +0100	[thread overview]
Message-ID: <07037a8a-1d35-362e-1b82-b73b81f7c6ac@redhat.com> (raw)
In-Reply-To: <20201229150807.GF4786@sirena.org.uk>

Hi,

On 12/29/20 4:08 PM, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 02:57:38PM +0100, Hans de Goede wrote:
>> On 12/29/20 2:06 PM, Charles Keepax wrote:
> 
>>> I would agree with Mark though that if extcon exists for external
>>> connectors it seems odd that audio jacks would have their own
>>> special way rather than just using the connector stuff.
> 
>> Well as I said above in me experience the extcon code is (was) mostly
>> meant for kernel internal use. The sysfs API is more of a debugging
>> tool then anything else (IMHO).
> 
> No, that's not the case.  extcon is a port of an Android custom API that
> looks very similar to what ended up in mainline, it was also a
> combination of sysfs and uevents but a bit less generic.  It mainly
> existed to provide information to userspace about what was plugged into
> the various ports on devices, things like headphone jacks and the
> pre-USB C multifunction connectors you used to get on phones.

Interesting, I have close to 0 experience with Android userspace
(something which I would like to change one of these days). But I have
encountered a bunch of in-kernel use of extcon on Intel's Android X86
port for Bay and Cherry Trail devices (which I've ported to the mainline)
where extcon was e.g. used with a generic extcon-gpio like driver monitoring
the ID pin and then used by the USB code to detect (through monitoring the
extcon) if the USB port was in host or device/gadget mode.

So it seems that extcon has many different uses by different people...


> In kernel
> use wasn't really a thing for that as far as I can remember.  It's
> become a bit less of a pressing concern for Android with the move to USB
> C and the deprecation of headphone jacks in favour of a combination of
> USB C and Bluetooth but the use case is still there and it's clear that
> none of the audio stuff is currently exactly designed.
> 
> The issues I'm seeing are more to do with nobody working on things, I
> guess mainly due to the change in priorities for Android systems and in
> my case a job change.

Yes extcon definitely could use some TLC, although I do honestly wonder
if just deprecating it would not be better...

>> Also the kernel has support for a lot of sound devices, including
>> many with jack-detection support. Yet a grep for EXTCON_JACK_HEADPHONE
>> over the entire mainline kernel tree shows that only extcon-arizona.c
>> is using it. So given that we have dozens of drivers providing jack
>> functionality through the sound/core/jack.c core and only 1 driver
>> using the extcon interface I believe that the ship on how to export
>> this to userspace has long sailed, since most userspace code will
>> clearly expect the sound/core/jack.c way of doing things to be used.
> 
> The whole purpose of creating sound/core/jack.c is to abstract away the
> userspace interfaces from the drivers, most audio devices shouldn't be
> working with extcon directly just as they shouldn't be creating input
> devices or ALSA controls directly.  The missing bit there is to add
> extcon into jack.c.

So what you are suggesting is making sound/core/jack.c register the
extcon device and then have arizona-extcon.c talk to sound/core/jack.c
and no longer do any extcon stuff itself.

That would make the userspace API experience offered by arizona-extcon
consistent with other drivers with jack-detect capability.

But I do honestly wonder if we really want to use extcon for jack-detect
information reporting. At least in the mainline tree there is only 1
driver supporting this ATM and we are pretty much stuck with 1.
ALSA controls for jack detection as well as 2. input_device which
we already export, there is enough of a userspace dependency on
those that we cannot get rid of those.

So we already export 2 userspace-APIs for this IMHO adding a 3th one is not
really a good idea unless it offers significant benifits which I don't
really see. The input_dev API is simple enough to use that extcon does
not really offer any significant benefits.

But this has turned into a very generic discussion, while all I was
trying to do is make arizona-extcon export the jack-detect info through
the ALSA controls for jack detection.

My current solution to have the machine-driver register a jack and
then share that with the extcon-arizona.c code still seems like the
best/simplest solution to me here.

Unless we go with your plan to make sound/core/jack.c export
an extcon device for all sound-devs registering a jack, and then move
extcon-arizona.c over to using sound/core/jack.c without it doing any
extcon stuff itself. But as discussed I'm really not a fan of exporting
a 3th uAPI for jack-detection for all sound-cards with jack-detect
capability.

> BTW note that the existing arizona extcon driver does provide an input
> device so I'm guesing that whatever userspace you're concerned about is
> one that uses only the ALSA controls for jack detection.

The current extcon-arizona.c code only reports button presses to the
input-device, but I did try also making it report SW_HEADPHONE_INSERT /
SW_MICROPHONE_INSERT / SW_LINEOUT_INSERT too. That patch did work,
but pulseaudio did not respond to this, so it seems that pulse indeed
is reliant on the ALSA controls for jack detection (I did not debug
this further, instead I went with the route of registering a jack
from the machinedriver).

I've tested with
>> Arguably we should/could maybe even drop the extcon part of extcon-arizona.c
>> but I did not do that as I did not want to regress existing userspace
>> code which may depend on this (on specific embedded/android devices).
> 
> I do think pushing things over to extcon is a useful goal, the existing
> interfaces have fairly clear issues that it does actually address.

I don't really see any "fairly clear issues" with the input-device uAPI,
I agree that the ALSA controls can be hard to use, but that is not the
case for the input-device uAPI (*). What are your objections against using
the input-device uAPI ?

Regards,

Hans



*) I agree that it is a bit weird to use the input_device API for this,
but that ship has sailed. We will need to support the input_device API
going forward anyways and given that I see little advantage in adding
the extcon API *on top* of that.


  reply	other threads:[~2020-12-29 15:34 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27 21:12 [PATCH 00/14] MFD/extcon/ASoC: Add support for Intel Bay Trail boards with WM5102 codec Hans de Goede
2020-12-27 21:12 ` Hans de Goede
2020-12-27 21:12 ` [PATCH 01/14] mfd: arizona: Add jack pointer to struct arizona Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-28 12:21   ` Mark Brown
2020-12-28 12:21     ` Mark Brown
2020-12-28 13:16     ` Hans de Goede
2020-12-28 13:16       ` Hans de Goede
2020-12-28 16:28       ` Mark Brown
2020-12-28 16:28         ` Mark Brown
2020-12-29 13:06         ` Charles Keepax
2020-12-29 13:06           ` Charles Keepax
2020-12-29 13:57           ` Hans de Goede
2020-12-29 13:57             ` Hans de Goede
2020-12-29 15:06             ` Charles Keepax
2020-12-29 15:06               ` Charles Keepax
2020-12-29 15:15               ` Mark Brown
2020-12-29 15:15                 ` Mark Brown
2020-12-29 15:40                 ` Hans de Goede
2020-12-29 15:40                   ` Hans de Goede
2020-12-29 16:51                   ` Richard Fitzgerald
2020-12-29 16:51                     ` Richard Fitzgerald
2020-12-30 11:04                     ` Hans de Goede
2020-12-30 11:04                       ` Hans de Goede
2020-12-30 11:23                       ` Richard Fitzgerald
2020-12-30 11:23                         ` Richard Fitzgerald
2020-12-30 12:01                         ` Hans de Goede
2020-12-30 12:01                           ` Hans de Goede
2020-12-30 13:16                     ` Mark Brown
2020-12-30 13:16                       ` Mark Brown
2020-12-29 16:43               ` Richard Fitzgerald
2020-12-29 16:43                 ` Richard Fitzgerald
2020-12-29 15:08             ` Mark Brown
2020-12-29 15:08               ` Mark Brown
2020-12-29 15:33               ` Hans de Goede [this message]
2020-12-29 15:33                 ` Hans de Goede
2020-12-30 13:38                 ` Mark Brown
2020-12-30 13:38                   ` Mark Brown
2021-01-01 13:24                   ` Hans de Goede
2021-01-01 13:24                     ` Hans de Goede
2020-12-27 21:12 ` [PATCH 02/14] mfd: arizona: Add MODULE_SOFTDEP("pre: arizona_ldo1") Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 11:40   ` Charles Keepax
2020-12-29 11:40     ` Charles Keepax
2020-12-27 21:12 ` [PATCH 03/14] mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-28  1:21   ` kernel test robot
2020-12-28  1:21     ` kernel test robot
2020-12-28  1:21   ` [RFC PATCH] mfd: arizona: ldoena_gpios can be static kernel test robot
2020-12-28  1:21     ` kernel test robot
2020-12-28 14:14   ` [PATCH 03/14] mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI Andy Shevchenko
2020-12-28 14:14     ` Andy Shevchenko
2021-01-16 14:46     ` Hans de Goede
2021-01-16 14:46       ` Hans de Goede
2020-12-28 22:11   ` kernel test robot
2020-12-28 22:11     ` kernel test robot
2020-12-28 22:29   ` kernel test robot
2020-12-28 22:29     ` kernel test robot
2020-12-27 21:12 ` [PATCH 04/14] mfd: arizona: Allow building arizona MFD-core as module Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 12:00   ` Charles Keepax
2020-12-29 12:00     ` Charles Keepax
2021-01-11 19:12     ` Hans de Goede
2021-01-11 19:12       ` Hans de Goede
2020-12-27 21:12 ` [PATCH 05/14] extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-27 21:12 ` [PATCH 06/14] extcon: arizona: Fix various races on driver unbind Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 12:10   ` Charles Keepax
2020-12-29 12:10     ` Charles Keepax
2020-12-27 21:12 ` [PATCH 07/14] extcon: arizona: Fix modalias Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 12:10   ` Charles Keepax
2020-12-29 12:10     ` Charles Keepax
2020-12-27 21:12 ` [PATCH 08/14] extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call Hans de Goede
2020-12-27 21:12   ` [PATCH 08/14] extcon: arizona: Fix flags parameter to the gpiod_get("wlf, micd-pol") call Hans de Goede
2020-12-29 12:12   ` [PATCH 08/14] extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call Charles Keepax
2020-12-29 12:12     ` Charles Keepax
2020-12-27 21:12 ` [PATCH 09/14] extcon: arizona: Add arizona_set_extcon_state() helper Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 12:57   ` Charles Keepax
2020-12-29 12:57     ` Charles Keepax
2020-12-27 21:12 ` [PATCH 10/14] extcon: arizona: Also report jack state through snd_soc_jack_report() Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-28 14:16   ` Andy Shevchenko
2020-12-28 14:16     ` Andy Shevchenko
2020-12-27 21:12 ` [PATCH 11/14] extcon: arizona: Use ASoC jack input-device when available Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-27 21:12 ` [PATCH 12/14] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2021-01-11 17:52   ` Pierre-Louis Bossart
2021-01-11 17:52     ` Pierre-Louis Bossart
2020-12-27 21:12 ` [PATCH 13/14] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-29 13:58   ` Charles Keepax
2020-12-29 13:58     ` Charles Keepax
2021-01-11 17:54     ` Pierre-Louis Bossart
2021-01-11 17:54       ` Pierre-Louis Bossart
2021-01-16 16:49     ` Hans de Goede
2021-01-16 16:49       ` Hans de Goede
2020-12-27 21:12 ` [PATCH 14/14] ASoC: Intel: bytcr_wm5102: Add jack detect support Hans de Goede
2020-12-27 21:12   ` Hans de Goede
2020-12-28 14:19 ` [PATCH 00/14] MFD/extcon/ASoC: Add support for Intel Bay Trail boards with WM5102 codec Andy Shevchenko
2020-12-28 14:19   ` Andy Shevchenko
2021-01-11 18:54   ` Hans de Goede
2021-01-11 18:54     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07037a8a-1d35-362e-1b82-b73b81f7c6ac@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=cw00.choi@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=patches@opensource.cirrus.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=yang.jie@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.