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

[Lee Jones <lee.jones@linaro.org>]

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