Hi all,
Here is v4 of my series to rework the arizona codec jack-detect support
to use the snd_soc_jack helpers instead of direct extcon reporting.
This is a resend with some extra *-by tags collected and with the extcon
folks added to the "To:" list, which I somehow missed with the original
v4 posting, sorry.
This is done by reworking the extcon driver into an arizona-jackdet
library and then modifying the codec drivers to use that directly,
replacing the old separate extcon child-devices and extcon-driver.
This brings the arizona-codec jack-detect handling inline with how
all other ASoC codec driver do this. This was developed and tested on
a Lenovo Yoga Tablet 1051L with a WM5102 codec.
This was also tested by Charles Keepax, one of the Cirrus Codec folks.
This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
support for Intel Bay Trail boards with WM5102 codec" series and there
are various interdependencies between the patches in this series.
Lee Jones, the MFD maintainer has agreed to take this series upstream
through the MFD tree and to provide an immutable branch for the ASoC
and extcon subsystems to merge.
Mark and extcon-maintainers may we have your ack for merging these
through the MFD tree ?
Regards,
Hans
Hans de Goede (13):
mfd: arizona: Drop arizona-extcon cells
extcon: arizona: Fix some issues when HPDET IRQ fires after the jack
has been unplugged
extcon: arizona: Fix various races on driver unbind
extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol")
call
extcon: arizona: Always use pm_runtime_get_sync() when we need the
device to be awake
ASoC/extcon: arizona: Move arizona jack code to
sound/soc/codecs/arizona-jack.c
ASoC: arizona-jack: Move jack-detect variables to struct arizona_priv
ASoC: arizona-jack: Use arizona->dev for runtime-pm
ASoC: arizona-jack: convert into a helper library for codec drivers
ASoC: arizona-jack: Use snd_soc_jack to report jack events
ASoC: arizona-jack: Cleanup logging
ASoC: arizona: Make the wm5102, wm5110, wm8997 and wm8998 drivers use
the new jack library
ASoC: Intel: bytcr_wm5102: Add jack detect support
MAINTAINERS | 3 +-
drivers/extcon/Kconfig | 8 -
drivers/extcon/Makefile | 1 -
drivers/mfd/arizona-core.c | 20 -
sound/soc/codecs/Makefile | 2 +-
.../soc/codecs/arizona-jack.c | 577 +++++++-----------
sound/soc/codecs/arizona.h | 44 ++
sound/soc/codecs/wm5102.c | 12 +-
sound/soc/codecs/wm5110.c | 12 +-
sound/soc/codecs/wm8997.c | 14 +-
sound/soc/codecs/wm8998.c | 9 +
sound/soc/intel/boards/bytcr_wm5102.c | 28 +-
12 files changed, 325 insertions(+), 405 deletions(-)
rename drivers/extcon/extcon-arizona.c => sound/soc/codecs/arizona-jack.c (76%)
--
2.29.2
When the jack is partially inserted and then removed again it may be
removed while the hpdet code is running. In this case the following
may happen:
1. The "JACKDET rise" or ""JACKDET fall" IRQ triggers
2. arizona_jackdet runs and takes info->lock
3. The "HPDET" IRQ triggers
4. arizona_hpdet_irq runs, blocks on info->lock
5. arizona_jackdet calls arizona_stop_mic() and clears info->hpdet_done
6. arizona_jackdet releases info->lock
7. arizona_hpdet_irq now can continue running and:
7.1 Calls arizona_start_mic() (if a mic was detected)
7.2 sets info->hpdet_done
Step 7 is undesirable / a bug:
7.1 causes the device to stay in a high power-state (with MICVDD enabled)
7.2 causes hpdet to not run on the next jack insertion, which in turn
causes the EXTCON_JACK_HEADPHONE state to never get set
This fixes both issues by skipping these 2 steps when arizona_hpdet_irq
runs after the jack has been unplugged.
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Charles Keepax <[email protected]>
Tested-by: Charles Keepax <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
---
drivers/extcon/extcon-arizona.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index aae82db542a5..f7ef247de46a 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -601,7 +601,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
struct arizona *arizona = info->arizona;
int id_gpio = arizona->pdata.hpdet_id_gpio;
unsigned int report = EXTCON_JACK_HEADPHONE;
- int ret, reading;
+ int ret, reading, state;
bool mic = false;
mutex_lock(&info->lock);
@@ -614,12 +614,11 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
}
/* If the cable was removed while measuring ignore the result */
- ret = extcon_get_state(info->edev, EXTCON_MECHANICAL);
- if (ret < 0) {
- dev_err(arizona->dev, "Failed to check cable state: %d\n",
- ret);
+ state = extcon_get_state(info->edev, EXTCON_MECHANICAL);
+ if (state < 0) {
+ dev_err(arizona->dev, "Failed to check cable state: %d\n", state);
goto out;
- } else if (!ret) {
+ } else if (!state) {
dev_dbg(arizona->dev, "Ignoring HPDET for removed cable\n");
goto done;
}
@@ -667,7 +666,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
gpio_set_value_cansleep(id_gpio, 0);
/* If we have a mic then reenable MICDET */
- if (mic || info->mic)
+ if (state && (mic || info->mic))
arizona_start_mic(info);
if (info->hpdet_active) {
@@ -675,7 +674,9 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
info->hpdet_active = false;
}
- info->hpdet_done = true;
+ /* Do not set hp_det done when the cable has been unplugged */
+ if (state)
+ info->hpdet_done = true;
out:
mutex_unlock(&info->lock);
--
2.29.2
On 2/4/21 8:24 PM, Hans de Goede wrote:
> Hi all,
>
> Here is v4 of my series to rework the arizona codec jack-detect support
> to use the snd_soc_jack helpers instead of direct extcon reporting.
>
> This is a resend with some extra *-by tags collected and with the extcon
> folks added to the "To:" list, which I somehow missed with the original
> v4 posting, sorry.
>
> This is done by reworking the extcon driver into an arizona-jackdet
> library and then modifying the codec drivers to use that directly,
> replacing the old separate extcon child-devices and extcon-driver.
>
> This brings the arizona-codec jack-detect handling inline with how
> all other ASoC codec driver do this. This was developed and tested on
> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
>
> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
>
> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
> support for Intel Bay Trail boards with WM5102 codec" series and there
> are various interdependencies between the patches in this series.
>
> Lee Jones, the MFD maintainer has agreed to take this series upstream
> through the MFD tree and to provide an immutable branch for the ASoC
> and extcon subsystems to merge.
>
> Mark and extcon-maintainers may we have your ack for merging these
> through the MFD tree ?
About patch2~patch6, I agree to take these patches to MFD tree.
Acke-by: Chanwoo Choi <[email protected]>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Hi,
On 2/5/21 3:00 AM, Chanwoo Choi wrote:
> On 2/4/21 8:24 PM, Hans de Goede wrote:
>> Hi all,
>>
>> Here is v4 of my series to rework the arizona codec jack-detect support
>> to use the snd_soc_jack helpers instead of direct extcon reporting.
>>
>> This is a resend with some extra *-by tags collected and with the extcon
>> folks added to the "To:" list, which I somehow missed with the original
>> v4 posting, sorry.
>>
>> This is done by reworking the extcon driver into an arizona-jackdet
>> library and then modifying the codec drivers to use that directly,
>> replacing the old separate extcon child-devices and extcon-driver.
>>
>> This brings the arizona-codec jack-detect handling inline with how
>> all other ASoC codec driver do this. This was developed and tested on
>> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
>>
>> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
>>
>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
>> support for Intel Bay Trail boards with WM5102 codec" series and there
>> are various interdependencies between the patches in this series.
>>
>> Lee Jones, the MFD maintainer has agreed to take this series upstream
>> through the MFD tree and to provide an immutable branch for the ASoC
>> and extcon subsystems to merge.
>>
>> Mark and extcon-maintainers may we have your ack for merging these
>> through the MFD tree ?
>
>
> About patch2~patch6, I agree to take these patches to MFD tree.
> Acke-by: Chanwoo Choi <[email protected]>
Great, thank you.
Regards,
Hans
Hi Mark, Lee,
On 2/4/21 12:24 PM, Hans de Goede wrote:
> Hi all,
>
> Here is v4 of my series to rework the arizona codec jack-detect support
> to use the snd_soc_jack helpers instead of direct extcon reporting.
>
> This is a resend with some extra *-by tags collected and with the extcon
> folks added to the "To:" list, which I somehow missed with the original
> v4 posting, sorry.
>
> This is done by reworking the extcon driver into an arizona-jackdet
> library and then modifying the codec drivers to use that directly,
> replacing the old separate extcon child-devices and extcon-driver.
>
> This brings the arizona-codec jack-detect handling inline with how
> all other ASoC codec driver do this. This was developed and tested on
> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
>
> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
>
> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
> support for Intel Bay Trail boards with WM5102 codec" series and there
> are various interdependencies between the patches in this series.
>
> Lee Jones, the MFD maintainer has agreed to take this series upstream
> through the MFD tree and to provide an immutable branch for the ASoC
> and extcon subsystems to merge.
>
> Mark and extcon-maintainers may we have your ack for merging these
> through the MFD tree ?
Now that the pre-cursor (1) series to this has been merged, I guess it
is time to decide how to merge this series.
Chanwoo Choi has given his ack to merge the extcon bits through the MFD
tree and since Mark has expressed a preference for merging ASOC patches
directly I guess that it would be best to merge 1-6 through the MFD
tree and then Lee can send Mark a pull-req and Mark can apply the others? :
1/13 mfd: arizona: Drop arizona-extcon cells
2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
3/13 extcon: arizona: Fix various races on driver unbind
4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
2-6 are: Acked-by: Chanwoo Choi <[email protected]>
Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
but it does not touch any other files under sound/soc (including NOT touching
sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
conflicts.
Mark, would merging 1-6 through the MFD tree, and you applying the rest
(which are all ASoC patches) work for you ?
Regards,
Hans
1) "[PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec"
On Mon, 08 Feb 2021, Hans de Goede wrote:
> Hi Mark, Lee,
>
> On 2/4/21 12:24 PM, Hans de Goede wrote:
> > Hi all,
> >
> > Here is v4 of my series to rework the arizona codec jack-detect support
> > to use the snd_soc_jack helpers instead of direct extcon reporting.
> >
> > This is a resend with some extra *-by tags collected and with the extcon
> > folks added to the "To:" list, which I somehow missed with the original
> > v4 posting, sorry.
> >
> > This is done by reworking the extcon driver into an arizona-jackdet
> > library and then modifying the codec drivers to use that directly,
> > replacing the old separate extcon child-devices and extcon-driver.
> >
> > This brings the arizona-codec jack-detect handling inline with how
> > all other ASoC codec driver do this. This was developed and tested on
> > a Lenovo Yoga Tablet 1051L with a WM5102 codec.
> >
> > This was also tested by Charles Keepax, one of the Cirrus Codec folks.
> >
> > This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
> > support for Intel Bay Trail boards with WM5102 codec" series and there
> > are various interdependencies between the patches in this series.
> >
> > Lee Jones, the MFD maintainer has agreed to take this series upstream
> > through the MFD tree and to provide an immutable branch for the ASoC
> > and extcon subsystems to merge.
> >
> > Mark and extcon-maintainers may we have your ack for merging these
> > through the MFD tree ?
>
> Now that the pre-cursor (1) series to this has been merged, I guess it
> is time to decide how to merge this series.
>
> Chanwoo Choi has given his ack to merge the extcon bits through the MFD
> tree and since Mark has expressed a preference for merging ASOC patches
> directly I guess that it would be best to merge 1-6 through the MFD
> tree and then Lee can send Mark a pull-req and Mark can apply the others? :
>
> 1/13 mfd: arizona: Drop arizona-extcon cells
> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
> 3/13 extcon: arizona: Fix various races on driver unbind
> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
>
> 1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
> 2-6 are: Acked-by: Chanwoo Choi <[email protected]>
>
> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
> but it does not touch any other files under sound/soc (including NOT touching
> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
> conflicts.
>
> Mark, would merging 1-6 through the MFD tree, and you applying the rest
> (which are all ASoC patches) work for you ?
What a faff.
I still don't see why they can't all go in and a PR provided.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
On Tue, 09 Feb 2021, Hans de Goede wrote:
> Hi,
>
> On 2/9/21 3:14 PM, Lee Jones wrote:
> > On Mon, 08 Feb 2021, Hans de Goede wrote:
> >
> >> Hi Mark, Lee,
> >>
> >> On 2/4/21 12:24 PM, Hans de Goede wrote:
> >>> Hi all,
> >>>
> >>> Here is v4 of my series to rework the arizona codec jack-detect support
> >>> to use the snd_soc_jack helpers instead of direct extcon reporting.
> >>>
> >>> This is a resend with some extra *-by tags collected and with the extcon
> >>> folks added to the "To:" list, which I somehow missed with the original
> >>> v4 posting, sorry.
> >>>
> >>> This is done by reworking the extcon driver into an arizona-jackdet
> >>> library and then modifying the codec drivers to use that directly,
> >>> replacing the old separate extcon child-devices and extcon-driver.
> >>>
> >>> This brings the arizona-codec jack-detect handling inline with how
> >>> all other ASoC codec driver do this. This was developed and tested on
> >>> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
> >>>
> >>> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
> >>>
> >>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
> >>> support for Intel Bay Trail boards with WM5102 codec" series and there
> >>> are various interdependencies between the patches in this series.
> >>>
> >>> Lee Jones, the MFD maintainer has agreed to take this series upstream
> >>> through the MFD tree and to provide an immutable branch for the ASoC
> >>> and extcon subsystems to merge.
> >>>
> >>> Mark and extcon-maintainers may we have your ack for merging these
> >>> through the MFD tree ?
> >>
> >> Now that the pre-cursor (1) series to this has been merged, I guess it
> >> is time to decide how to merge this series.
> >>
> >> Chanwoo Choi has given his ack to merge the extcon bits through the MFD
> >> tree and since Mark has expressed a preference for merging ASOC patches
> >> directly I guess that it would be best to merge 1-6 through the MFD
> >> tree and then Lee can send Mark a pull-req and Mark can apply the others? :
> >>
> >> 1/13 mfd: arizona: Drop arizona-extcon cells
> >> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
> >> 3/13 extcon: arizona: Fix various races on driver unbind
> >> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
> >> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
> >> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
> >>
> >> 1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
> >> 2-6 are: Acked-by: Chanwoo Choi <[email protected]>
> >>
> >> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
> >> but it does not touch any other files under sound/soc (including NOT touching
> >> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
> >> conflicts.
> >>
> >> Mark, would merging 1-6 through the MFD tree, and you applying the rest
> >> (which are all ASoC patches) work for you ?
> >
> > What a faff.
> >
> > I still don't see why they can't all go in and a PR provided.
>
> Well patch 13/13 of this set relies on 5/5 from the previous set which is
> only in Mark's ASoC tree and not in the MFD tree, so splitting things over MFD + ASoC
> again makes the most sense here too.
Right, this is what can happen when patch-sets are split up.
> The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
> in MFD first, which seems less then ideal.
Well this set isn't likely to go in this cycle anyway, so actually the
problem should just go away. Best to let the first set get sucked
into v5.12, then send this one up subsequently for v5.13.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On 2/9/21 4:45 PM, Lee Jones wrote:
> On Tue, 09 Feb 2021, Hans de Goede wrote:
>
>> Hi,
>>
>> On 2/9/21 3:14 PM, Lee Jones wrote:
>>> On Mon, 08 Feb 2021, Hans de Goede wrote:
>>>
>>>> Hi Mark, Lee,
>>>>
>>>> On 2/4/21 12:24 PM, Hans de Goede wrote:
>>>>> Hi all,
>>>>>
>>>>> Here is v4 of my series to rework the arizona codec jack-detect support
>>>>> to use the snd_soc_jack helpers instead of direct extcon reporting.
>>>>>
>>>>> This is a resend with some extra *-by tags collected and with the extcon
>>>>> folks added to the "To:" list, which I somehow missed with the original
>>>>> v4 posting, sorry.
>>>>>
>>>>> This is done by reworking the extcon driver into an arizona-jackdet
>>>>> library and then modifying the codec drivers to use that directly,
>>>>> replacing the old separate extcon child-devices and extcon-driver.
>>>>>
>>>>> This brings the arizona-codec jack-detect handling inline with how
>>>>> all other ASoC codec driver do this. This was developed and tested on
>>>>> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
>>>>>
>>>>> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
>>>>>
>>>>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
>>>>> support for Intel Bay Trail boards with WM5102 codec" series and there
>>>>> are various interdependencies between the patches in this series.
>>>>>
>>>>> Lee Jones, the MFD maintainer has agreed to take this series upstream
>>>>> through the MFD tree and to provide an immutable branch for the ASoC
>>>>> and extcon subsystems to merge.
>>>>>
>>>>> Mark and extcon-maintainers may we have your ack for merging these
>>>>> through the MFD tree ?
>>>>
>>>> Now that the pre-cursor (1) series to this has been merged, I guess it
>>>> is time to decide how to merge this series.
>>>>
>>>> Chanwoo Choi has given his ack to merge the extcon bits through the MFD
>>>> tree and since Mark has expressed a preference for merging ASOC patches
>>>> directly I guess that it would be best to merge 1-6 through the MFD
>>>> tree and then Lee can send Mark a pull-req and Mark can apply the others? :
>>>>
>>>> 1/13 mfd: arizona: Drop arizona-extcon cells
>>>> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
>>>> 3/13 extcon: arizona: Fix various races on driver unbind
>>>> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
>>>> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
>>>> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
>>>>
>>>> 1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
>>>> 2-6 are: Acked-by: Chanwoo Choi <[email protected]>
>>>>
>>>> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
>>>> but it does not touch any other files under sound/soc (including NOT touching
>>>> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
>>>> conflicts.
>>>>
>>>> Mark, would merging 1-6 through the MFD tree, and you applying the rest
>>>> (which are all ASoC patches) work for you ?
>>>
>>> What a faff.
>>>
>>> I still don't see why they can't all go in and a PR provided.
>>
>> Well patch 13/13 of this set relies on 5/5 from the previous set which is
>> only in Mark's ASoC tree and not in the MFD tree, so splitting things over MFD + ASoC
>> again makes the most sense here too.
>
> Right, this is what can happen when patch-sets are split up.
>
>> The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
>> in MFD first, which seems less then ideal.
>
> Well this set isn't likely to go in this cycle anyway, so actually the
> problem should just go away.
That is true.
> Best to let the first set get sucked
> into v5.12, then send this one up subsequently for v5.13.
Ack. So should I resend this once 5.12-rc1 is out ?
Regards,
Hans
On Tue, 09 Feb 2021, Hans de Goede wrote:
> Hi,
>
> On 2/9/21 4:45 PM, Lee Jones wrote:
> > On Tue, 09 Feb 2021, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 2/9/21 3:14 PM, Lee Jones wrote:
> >>> On Mon, 08 Feb 2021, Hans de Goede wrote:
> >>>
> >>>> Hi Mark, Lee,
> >>>>
> >>>> On 2/4/21 12:24 PM, Hans de Goede wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Here is v4 of my series to rework the arizona codec jack-detect support
> >>>>> to use the snd_soc_jack helpers instead of direct extcon reporting.
> >>>>>
> >>>>> This is a resend with some extra *-by tags collected and with the extcon
> >>>>> folks added to the "To:" list, which I somehow missed with the original
> >>>>> v4 posting, sorry.
> >>>>>
> >>>>> This is done by reworking the extcon driver into an arizona-jackdet
> >>>>> library and then modifying the codec drivers to use that directly,
> >>>>> replacing the old separate extcon child-devices and extcon-driver.
> >>>>>
> >>>>> This brings the arizona-codec jack-detect handling inline with how
> >>>>> all other ASoC codec driver do this. This was developed and tested on
> >>>>> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
> >>>>>
> >>>>> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
> >>>>>
> >>>>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
> >>>>> support for Intel Bay Trail boards with WM5102 codec" series and there
> >>>>> are various interdependencies between the patches in this series.
> >>>>>
> >>>>> Lee Jones, the MFD maintainer has agreed to take this series upstream
> >>>>> through the MFD tree and to provide an immutable branch for the ASoC
> >>>>> and extcon subsystems to merge.
> >>>>>
> >>>>> Mark and extcon-maintainers may we have your ack for merging these
> >>>>> through the MFD tree ?
> >>>>
> >>>> Now that the pre-cursor (1) series to this has been merged, I guess it
> >>>> is time to decide how to merge this series.
> >>>>
> >>>> Chanwoo Choi has given his ack to merge the extcon bits through the MFD
> >>>> tree and since Mark has expressed a preference for merging ASOC patches
> >>>> directly I guess that it would be best to merge 1-6 through the MFD
> >>>> tree and then Lee can send Mark a pull-req and Mark can apply the others? :
> >>>>
> >>>> 1/13 mfd: arizona: Drop arizona-extcon cells
> >>>> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
> >>>> 3/13 extcon: arizona: Fix various races on driver unbind
> >>>> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
> >>>> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
> >>>> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
> >>>>
> >>>> 1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
> >>>> 2-6 are: Acked-by: Chanwoo Choi <[email protected]>
> >>>>
> >>>> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
> >>>> but it does not touch any other files under sound/soc (including NOT touching
> >>>> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
> >>>> conflicts.
> >>>>
> >>>> Mark, would merging 1-6 through the MFD tree, and you applying the rest
> >>>> (which are all ASoC patches) work for you ?
> >>>
> >>> What a faff.
> >>>
> >>> I still don't see why they can't all go in and a PR provided.
> >>
> >> Well patch 13/13 of this set relies on 5/5 from the previous set which is
> >> only in Mark's ASoC tree and not in the MFD tree, so splitting things over MFD + ASoC
> >> again makes the most sense here too.
> >
> > Right, this is what can happen when patch-sets are split up.
> >
> >> The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
> >> in MFD first, which seems less then ideal.
> >
> > Well this set isn't likely to go in this cycle anyway, so actually the
> > problem should just go away.
>
> That is true.
>
> > Best to let the first set get sucked
> > into v5.12, then send this one up subsequently for v5.13.
>
> Ack. So should I resend this once 5.12-rc1 is out ?
If you haven't heard from anything by then, [RESEND] by all means.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On 2/9/21 3:14 PM, Lee Jones wrote:
> On Mon, 08 Feb 2021, Hans de Goede wrote:
>
>> Hi Mark, Lee,
>>
>> On 2/4/21 12:24 PM, Hans de Goede wrote:
>>> Hi all,
>>>
>>> Here is v4 of my series to rework the arizona codec jack-detect support
>>> to use the snd_soc_jack helpers instead of direct extcon reporting.
>>>
>>> This is a resend with some extra *-by tags collected and with the extcon
>>> folks added to the "To:" list, which I somehow missed with the original
>>> v4 posting, sorry.
>>>
>>> This is done by reworking the extcon driver into an arizona-jackdet
>>> library and then modifying the codec drivers to use that directly,
>>> replacing the old separate extcon child-devices and extcon-driver.
>>>
>>> This brings the arizona-codec jack-detect handling inline with how
>>> all other ASoC codec driver do this. This was developed and tested on
>>> a Lenovo Yoga Tablet 1051L with a WM5102 codec.
>>>
>>> This was also tested by Charles Keepax, one of the Cirrus Codec folks.
>>>
>>> This depends on the previously posted "[PATCH v4 0/5] MFD/ASoC: Add
>>> support for Intel Bay Trail boards with WM5102 codec" series and there
>>> are various interdependencies between the patches in this series.
>>>
>>> Lee Jones, the MFD maintainer has agreed to take this series upstream
>>> through the MFD tree and to provide an immutable branch for the ASoC
>>> and extcon subsystems to merge.
>>>
>>> Mark and extcon-maintainers may we have your ack for merging these
>>> through the MFD tree ?
>>
>> Now that the pre-cursor (1) series to this has been merged, I guess it
>> is time to decide how to merge this series.
>>
>> Chanwoo Choi has given his ack to merge the extcon bits through the MFD
>> tree and since Mark has expressed a preference for merging ASOC patches
>> directly I guess that it would be best to merge 1-6 through the MFD
>> tree and then Lee can send Mark a pull-req and Mark can apply the others? :
>>
>> 1/13 mfd: arizona: Drop arizona-extcon cells
>> 2/13 extcon: arizona: Fix some issues when HPDET IRQ fires after the jack has been unplugged
>> 3/13 extcon: arizona: Fix various races on driver unbind
>> 4/13 extcon: arizona: Fix flags parameter to the gpiod_get("wlf,micd-pol") call
>> 5/13 extcon: arizona: Always use pm_runtime_get_sync() when we need the device to be awake
>> 6/14 ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c
>>
>> 1 is: Acked-for-MFD-by: Lee Jones <[email protected]>
>> 2-6 are: Acked-by: Chanwoo Choi <[email protected]>
>>
>> Note patch 6 renames drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c
>> but it does not touch any other files under sound/soc (including NOT touching
>> sound/soc/codecs/Makefile that is done in a later patch). So it cannot cause any
>> conflicts.
>>
>> Mark, would merging 1-6 through the MFD tree, and you applying the rest
>> (which are all ASoC patches) work for you ?
>
> What a faff.
>
> I still don't see why they can't all go in and a PR provided.
Well patch 13/13 of this set relies on 5/5 from the previous set which is
only in Mark's ASoC tree and not in the MFD tree, so splitting things over MFD + ASoC
again makes the most sense here too.
The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
in MFD first, which seems less then ideal.
Regards,
Hans
On Tue, Feb 09, 2021 at 03:45:11PM +0000, Lee Jones wrote:
> On Tue, 09 Feb 2021, Hans de Goede wrote:
> > The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
> > in MFD first, which seems less then ideal.
> Well this set isn't likely to go in this cycle anyway, so actually the
> problem should just go away. Best to let the first set get sucked
> into v5.12, then send this one up subsequently for v5.13.
Yeah, that's probably easiest at this point. the only other option that
looks viable would be to add the MFD and extcon parts to the branch you
already have, me to pull that in and then apply the ASoC bits in ASoC.
On Wed, 10 Feb 2021, Mark Brown wrote:
> On Tue, Feb 09, 2021 at 03:45:11PM +0000, Lee Jones wrote:
> > On Tue, 09 Feb 2021, Hans de Goede wrote:
>
> > > The alternative is Mark doing a PR from ASoC to MFD to get 5/5 from the previous set
> > > in MFD first, which seems less then ideal.
>
> > Well this set isn't likely to go in this cycle anyway, so actually the
> > problem should just go away. Best to let the first set get sucked
> > into v5.12, then send this one up subsequently for v5.13.
>
> Yeah, that's probably easiest at this point. the only other option that
> looks viable would be to add the MFD and extcon parts to the branch you
> already have, me to pull that in and then apply the ASoC bits in ASoC.
I'm not taking any more patches for this cycle anyway. Best wait.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog