All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: Mark Brown <broonie@kernel.org>, 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:43:46 +0000	[thread overview]
Message-ID: <938c2a83-8224-60a7-18d2-6a4db6516254@opensource.cirrus.com> (raw)
In-Reply-To: <20201229150635.GP9673@ediswmail.ad.cirrus.com>



On 29/12/2020 15:06, Charles Keepax 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:
>>> On Mon, Dec 28, 2020 at 04:28:07PM +0000, Mark Brown wrote:
>>>> On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
>>>>
>>>>> And more in general AFAIK extcon is sort of deprecated and it is
>>>>> not advised to use it for new code. I would esp. not expect it to
>>>>> be used for new jack-detection code since we already have standard
>>>>> uAPI support for that through sound/core/jack.c .
>>>>
>>>> Has Android been fixed to use the ALSA/input layer interfaces?  That's
>>>> why that code is there, long term the goal was to have ALSA generate
>>>> extcon events too so userspace could fall over to using that.  The basic
>>>> thing at the time was that nobody liked any of the existing interfaces
>>>> (the input layer thing is a total bodge stemming from it having been
>>>> easy to hack in a key for GPIO detection and using ALSA controls means
>>>> having to link against alsa-lib which is an awful faff for system level
>>>> UI stuff) and there were three separate userspace interfaces used by
>>>> different software stacks which needed to be joined together, extcon was
>>>> felt to be a bit more designed and is a superset so that was the
>>>> direction we were heading in.
>>>
>>> Android has been updated to have the option to catch input events
>>> for jack detection now.
>>>
>>> I have always been slightly confused between extcon and the ALSA
>>> jack reporting and have been unsure as to what is the longer term
>>> plan here. I vaguely thought there was a gentle plan to move to
>>> extcon, it is interesting to see Hans basically saying the
>>> opposite that extcon is intended to be paritially deprecated. I
>>> assume you just mean with respect to audio jacks, not other
>>> connector types?
>>
>> No I mean that afaik extcon is being deprecated in general. Extcon
>> is mostly meant for kernel internal use, to allow things like
>> charger-type-detection done by e.g. a fsa micro-usb mux or a
>> Type-C PD controller to be hooked up to the actual charger chip
>> and set the input-current-limit based on this.
>>
> 
> Fascinating thanks for taking the time to write such detailed
> answers. I thought it was mostly intended for user-space usage,
> but I guess I never really thought through that most of this
> stuff you don't really need to know from user-space.
> 
>>> 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).
>>
>> 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 majority of customers for these codecs + Linux were building Android
devices. So compatibility with Android was the most important goal. At
the time this code was written Android used a custom kernel subsystem
called "switch" to report jack events. extcon is basically a cleaner
version of "switch" and the advantage is that they are almost identical
so it was easy to port a mainline extcon driver back into an Android
"switch" driver. Android didn't use input events or ALSA jack events so
one of those drivers would be no use to the majority of users of this
codec at that time. And as Android's "switch" was so similar to extcon,
surely Android would just convert to supporting extcon...? The arizona
extcon driver is a legacy of the way Android did jack detection.

>> 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).
>>
> 
> All reasonable arguments, with Android now supporting input
> events for jacks I guess there would be no need for us to use
> extcon for future devices.
> 
> There is maybe more argument for porting the Arizona code across
> anyways, since for a long time Android didn't properly support extcon
> either. It supported the earlier out of tree switch stuff, extcon
> had a switch compatibility mode, but that didn't actually work I
> think due to android hard coding some sysfs naming or something
> (memory is a little fuzzy on the details was a while ago now).
> 
> I think extcon support was fixed in Android at about the same time
> the support for input events was added. So it might be harmless but
> someone probably needs to go and check the timeline before we go
> changing stuff.
> 
> Thanks,
> Charles
> 

WARNING: multiple messages have this Message-ID (diff)
From: Richard Fitzgerald <rf@opensource.cirrus.com>
To: Charles Keepax <ckeepax@opensource.cirrus.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: Cezary Rojewski <cezary.rojewski@intel.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>,
	Mark Brown <broonie@kernel.org>,
	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:43:46 +0000	[thread overview]
Message-ID: <938c2a83-8224-60a7-18d2-6a4db6516254@opensource.cirrus.com> (raw)
In-Reply-To: <20201229150635.GP9673@ediswmail.ad.cirrus.com>



On 29/12/2020 15:06, Charles Keepax 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:
>>> On Mon, Dec 28, 2020 at 04:28:07PM +0000, Mark Brown wrote:
>>>> On Mon, Dec 28, 2020 at 02:16:04PM +0100, Hans de Goede wrote:
>>>>
>>>>> And more in general AFAIK extcon is sort of deprecated and it is
>>>>> not advised to use it for new code. I would esp. not expect it to
>>>>> be used for new jack-detection code since we already have standard
>>>>> uAPI support for that through sound/core/jack.c .
>>>>
>>>> Has Android been fixed to use the ALSA/input layer interfaces?  That's
>>>> why that code is there, long term the goal was to have ALSA generate
>>>> extcon events too so userspace could fall over to using that.  The basic
>>>> thing at the time was that nobody liked any of the existing interfaces
>>>> (the input layer thing is a total bodge stemming from it having been
>>>> easy to hack in a key for GPIO detection and using ALSA controls means
>>>> having to link against alsa-lib which is an awful faff for system level
>>>> UI stuff) and there were three separate userspace interfaces used by
>>>> different software stacks which needed to be joined together, extcon was
>>>> felt to be a bit more designed and is a superset so that was the
>>>> direction we were heading in.
>>>
>>> Android has been updated to have the option to catch input events
>>> for jack detection now.
>>>
>>> I have always been slightly confused between extcon and the ALSA
>>> jack reporting and have been unsure as to what is the longer term
>>> plan here. I vaguely thought there was a gentle plan to move to
>>> extcon, it is interesting to see Hans basically saying the
>>> opposite that extcon is intended to be paritially deprecated. I
>>> assume you just mean with respect to audio jacks, not other
>>> connector types?
>>
>> No I mean that afaik extcon is being deprecated in general. Extcon
>> is mostly meant for kernel internal use, to allow things like
>> charger-type-detection done by e.g. a fsa micro-usb mux or a
>> Type-C PD controller to be hooked up to the actual charger chip
>> and set the input-current-limit based on this.
>>
> 
> Fascinating thanks for taking the time to write such detailed
> answers. I thought it was mostly intended for user-space usage,
> but I guess I never really thought through that most of this
> stuff you don't really need to know from user-space.
> 
>>> 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).
>>
>> 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 majority of customers for these codecs + Linux were building Android
devices. So compatibility with Android was the most important goal. At
the time this code was written Android used a custom kernel subsystem
called "switch" to report jack events. extcon is basically a cleaner
version of "switch" and the advantage is that they are almost identical
so it was easy to port a mainline extcon driver back into an Android
"switch" driver. Android didn't use input events or ALSA jack events so
one of those drivers would be no use to the majority of users of this
codec at that time. And as Android's "switch" was so similar to extcon,
surely Android would just convert to supporting extcon...? The arizona
extcon driver is a legacy of the way Android did jack detection.

>> 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).
>>
> 
> All reasonable arguments, with Android now supporting input
> events for jacks I guess there would be no need for us to use
> extcon for future devices.
> 
> There is maybe more argument for porting the Arizona code across
> anyways, since for a long time Android didn't properly support extcon
> either. It supported the earlier out of tree switch stuff, extcon
> had a switch compatibility mode, but that didn't actually work I
> think due to android hard coding some sysfs naming or something
> (memory is a little fuzzy on the details was a while ago now).
> 
> I think extcon support was fixed in Android at about the same time
> the support for input events was added. So it might be harmless but
> someone probably needs to go and check the timeline before we go
> changing stuff.
> 
> Thanks,
> Charles
> 

  parent reply	other threads:[~2020-12-29 16:44 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 [this message]
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
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=938c2a83-8224-60a7-18d2-6a4db6516254@opensource.cirrus.com \
    --to=rf@opensource.cirrus.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=hdegoede@redhat.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.