[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80068116-eb04-fd75-f656-804ab9f5d414@redhat.com>
Date: Tue, 9 Feb 2021 17:34:46 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: MyungJoo Ham <myungjoo.ham@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Cezary Rojewski <cezary.rojewski@...el.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Jie Yang <yang.jie@...ux.intel.com>,
Mark Brown <broonie@...nel.org>, patches@...nsource.cirrus.com,
linux-kernel@...r.kernel.org,
Andy Shevchenko <andy.shevchenko@...il.com>,
Charles Keepax <ckeepax@...nsource.cirrus.com>,
alsa-devel@...a-project.org
Subject: Re: [PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec
jack-detect support
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@...aro.org>
>>>> 2-6 are: Acked-by: Chanwoo Choi <cw00.choi@...sung.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 ?
Regards,
Hans
Powered by blists - more mailing lists