[PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support

[Lee Jones]

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 <lee.jones at linaro.org>
> >> 2-6 are: Acked-by: Chanwoo Choi <cw00.choi at samsung.com>
> >>
> >> 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