| Message ID | 20210120214957.140232-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec | expand |
Hi all, On 1/20/21 10:49 PM, Hans de Goede wrote: > Hi All, > > Here is v4 of my series to add support for Intel Bay Trail based devices > which use a WM5102 codec for audio output/input. > > This was developed and tested on a Lenovo Yoga Tablet 1051L. > > The MFD and ASoC parts do not have any build-time dependencies > on each other. But the follow-up jack-detect series does have > patches depending on each-other and on this series. So IMHO it > would be best if this entire series would be merged through the > MFD tree to make merging the follow-up series easier. > > Mark, if that is ok with you (and you are happy with the ASoC > changes) can you please Ack this ? I believe that this series and the follow-up: "[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support" series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now. I guess it is too late for 5.12, but it would be nice to at least formulate a plan for getting this merged after 5.12-rc1 is out. Given the interdependencies I still believe that it is best to merge all the patches through the mfd tree and then have Lee provide an immutable branch for the other subsystems to merge. Mark and extcon-maintainers (for the follow-up series) may we have your ack for merging these through the MFD tree ? Regards, Hans
On Thu, 04 Feb 2021, Hans de Goede wrote: > Hi all, > > On 1/20/21 10:49 PM, Hans de Goede wrote: > > Hi All, > > > > Here is v4 of my series to add support for Intel Bay Trail based devices > > which use a WM5102 codec for audio output/input. > > > > This was developed and tested on a Lenovo Yoga Tablet 1051L. > > > > The MFD and ASoC parts do not have any build-time dependencies > > on each other. But the follow-up jack-detect series does have > > patches depending on each-other and on this series. So IMHO it > > would be best if this entire series would be merged through the > > MFD tree to make merging the follow-up series easier. > > > > Mark, if that is ok with you (and you are happy with the ASoC > > changes) can you please Ack this ? > > I believe that this series and the follow-up: > > "[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support" > > series are both ready for merging. All patches have Reviewed-by and/or > Acked-by tags now. I don't think they do. You're missing ASoC and Extcon Acks. Not sure why *this* set fell through the cracks though. However, it's now on my to-review list. If I can work fast enough, maybe this series can get into 5.12, but the follow-up still needs reviews. It might be best to collect the *-bys you do have and [RESEND]. > I guess it is too late for 5.12, but it would be nice to at least formulate > a plan for getting this merged after 5.12-rc1 is out. Given the > interdependencies I still believe that it is best to merge all the patches > through the mfd tree and then have Lee provide an immutable branch for the > other subsystems to merge. Yes, that's fine. > Mark and extcon-maintainers (for the follow-up series) may we have your ack > for merging these through the MFD tree ? Ah, you noticed that too!
Hi, On 2/4/21 11:57 AM, Lee Jones wrote: > On Thu, 04 Feb 2021, Hans de Goede wrote: > >> Hi all, >> >> On 1/20/21 10:49 PM, Hans de Goede wrote: >>> Hi All, >>> >>> Here is v4 of my series to add support for Intel Bay Trail based devices >>> which use a WM5102 codec for audio output/input. >>> >>> This was developed and tested on a Lenovo Yoga Tablet 1051L. >>> >>> The MFD and ASoC parts do not have any build-time dependencies >>> on each other. But the follow-up jack-detect series does have >>> patches depending on each-other and on this series. So IMHO it >>> would be best if this entire series would be merged through the >>> MFD tree to make merging the follow-up series easier. >>> >>> Mark, if that is ok with you (and you are happy with the ASoC >>> changes) can you please Ack this ? >> >> I believe that this series and the follow-up: >> >> "[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support" >> >> series are both ready for merging. All patches have Reviewed-by and/or >> Acked-by tags now. > > I don't think they do. You're missing ASoC and Extcon Acks. Right, what I meant is that the patches have been reviewed by other stake-holders, including the follow-up series being tested by the cirrus codec folks (thank you Charles). But yes the actual subsys maintainers have not acked these yet; and I'm aware that you will need those for merging this through the MFD tree. Note that this series only requires Mark ack, the follow-up also touches extcon code, this one is purely MFD + ASoC patches. > Not sure why *this* set fell through the cracks though. However, it's > now on my to-review list. > > If I can work fast enough, maybe this series can get into 5.12, but > the follow-up still needs reviews. > > It might be best to collect the *-bys you do have and [RESEND]. Ok, will do. >> I guess it is too late for 5.12, but it would be nice to at least formulate >> a plan for getting this merged after 5.12-rc1 is out. Given the >> interdependencies I still believe that it is best to merge all the patches >> through the mfd tree and then have Lee provide an immutable branch for the >> other subsystems to merge. > > Yes, that's fine. > >> Mark and extcon-maintainers (for the follow-up series) may we have your ack >> for merging these through the MFD tree ? > > Ah, you noticed that too! Ack :) Regards, Hans
On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote: > On 2/4/21 11:57 AM, Lee Jones wrote: > > On Thu, 04 Feb 2021, Hans de Goede wrote: > >> series are both ready for merging. All patches have Reviewed-by and/or > >> Acked-by tags now. > > I don't think they do. You're missing ASoC and Extcon Acks. > Right, what I meant is that the patches have been reviewed by other > stake-holders, including the follow-up series being tested by the cirrus > codec folks (thank you Charles). > But yes the actual subsys maintainers have not acked these yet; > and I'm aware that you will need those for merging this through > the MFD tree. The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
Hi, On 2/4/21 1:43 PM, Mark Brown wrote: > On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote: >> On 2/4/21 11:57 AM, Lee Jones wrote: >>> On Thu, 04 Feb 2021, Hans de Goede wrote: > >>>> series are both ready for merging. All patches have Reviewed-by and/or >>>> Acked-by tags now. > >>> I don't think they do. You're missing ASoC and Extcon Acks. > >> Right, what I meant is that the patches have been reviewed by other >> stake-holders, including the follow-up series being tested by the cirrus >> codec folks (thank you Charles). > >> But yes the actual subsys maintainers have not acked these yet; >> and I'm aware that you will need those for merging this through >> the MFD tree. > > The usual pattern here is that the MFD patches get merged and then I > pull a shared branch in for any dependencies - at this point the series > is now on the backlog of serieses where I'm waiting for the MFD to sort > itself out before I really look at it again. I understand. But this series is somewhat special, if you also take the follow-up series into account: "[PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support" That again has some MFD bits, and some extcon patches and ASoC patches which depend on the extcon bits and this series. So it is really hard to merge all the bits through there separate trees and just merging it all through one tree and then pulling in the end-result as a shared branch would IMHO be easier. In the follow-up series one of the patches is moving the jackdet code from the extcon dir to sound/asoc/codecs. So that is a single commit touching 2 trees ... Regards, Hans
On Thu, 04 Feb 2021, Mark Brown wrote: > On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote: > > On 2/4/21 11:57 AM, Lee Jones wrote: > > > On Thu, 04 Feb 2021, Hans de Goede wrote: > > > >> series are both ready for merging. All patches have Reviewed-by and/or > > >> Acked-by tags now. > > > > I don't think they do. You're missing ASoC and Extcon Acks. > > > Right, what I meant is that the patches have been reviewed by other > > stake-holders, including the follow-up series being tested by the cirrus > > codec folks (thank you Charles). > > > But yes the actual subsys maintainers have not acked these yet; > > and I'm aware that you will need those for merging this through > > the MFD tree. > > The usual pattern here is that the MFD patches get merged and then I > pull a shared branch in for any dependencies - at this point the series > is now on the backlog of serieses where I'm waiting for the MFD to sort > itself out before I really look at it again. I tend to push patches awaiting Acks to the back of the queue. Stalemate.
On Thu, Feb 04, 2021 at 02:18:54PM +0100, Hans de Goede wrote: > On 2/4/21 1:43 PM, Mark Brown wrote: > > The usual pattern here is that the MFD patches get merged and then I > > pull a shared branch in for any dependencies - at this point the series > > is now on the backlog of serieses where I'm waiting for the MFD to sort > > itself out before I really look at it again. > I understand. But this series is somewhat special, if you also take > the follow-up series into account: > "[PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support" > That again has some MFD bits, and some extcon patches and ASoC patches > which depend on the extcon bits and this series. That series is drifting along in the same way AFAICT, and it's also got the extcon dependency so it'll need to leave it a bit longer for extcon review (unless some happens sooner). > So it is really hard to merge all the bits through there separate trees > and just merging it all through one tree and then pulling in the end-result > as a shared branch would IMHO be easier. Most of this for me is just about not wanting to have to repeatedly look at the same series as it goes through small changes due to changes in the dependencies.
On Thu, Feb 04, 2021 at 01:46:06PM +0000, Lee Jones wrote: > On Thu, 04 Feb 2021, Mark Brown wrote: > > The usual pattern here is that the MFD patches get merged and then I > > pull a shared branch in for any dependencies - at this point the series > > is now on the backlog of serieses where I'm waiting for the MFD to sort > > itself out before I really look at it again. > I tend to push patches awaiting Acks to the back of the queue. > Stalemate. I'm only going to ack things if I expect to see them applied via another tree, that's generally what an ack means from a maintainer. Especially with ASoC where we keep on having subsystem wide changes quite often I'm not likely to do that for things like new drivers unless it's very clear what the timelines are. It would be enormously helpful to get the bits of the core MFDs that create dependencies committed while the rest of the series is still in process, as well as allowing things to be applied it also helps with knowing if the dependencies are stable.
On Thu, 04 Feb 2021, Mark Brown wrote: > On Thu, Feb 04, 2021 at 01:46:06PM +0000, Lee Jones wrote: > > On Thu, 04 Feb 2021, Mark Brown wrote: > > > > The usual pattern here is that the MFD patches get merged and then I > > > pull a shared branch in for any dependencies - at this point the series > > > is now on the backlog of serieses where I'm waiting for the MFD to sort > > > itself out before I really look at it again. > > > I tend to push patches awaiting Acks to the back of the queue. > > > Stalemate. > > I'm only going to ack things if I expect to see them applied via another > tree, that's generally what an ack means from a maintainer. Especially > with ASoC where we keep on having subsystem wide changes quite often I'm > not likely to do that for things like new drivers unless it's very clear > what the timelines are. > > It would be enormously helpful to get the bits of the core MFDs that > create dependencies committed while the rest of the series is still in > process, as well as allowing things to be applied it also helps with > knowing if the dependencies are stable. The default point-of-view is; if a patch was submitted as part of a set, it's likely that it makes the most sense to merge it as a set. Very often sets will have inter-dependencies (usually headers) which would otherwise require the base patches to be applied (perhaps the MFD core and the headers) in one release, followed by the accompanying child device changes during a subsequent release. This doesn't scale well and puts the contributor in an unfair position. This is how we usually work together. Why is ASoC so different?
On Thu, Feb 04, 2021 at 03:21:24PM +0000, Lee Jones wrote: > The default point-of-view is; if a patch was submitted as part of a > set, it's likely that it makes the most sense to merge it as a set. Blocking the whole series is itself not ideal since it means the whole large series keeps on getting resent for minor changes in individual patches where it's only a small number of leaf patches that have issues, with a lot of these serieses the reason they're bundled together is that there's some constants being added in one of the early patches that gets used everywhere else, not that there's a really a particularly strong relationship. > Very often sets will have inter-dependencies (usually headers) which > would otherwise require the base patches to be applied (perhaps the > MFD core and the headers) in one release, followed by the accompanying > child device changes during a subsequent release. This doesn't scale > well and puts the contributor in an unfair position. You had been sharing pull requests for the common bits in the past which had resolved the dependency issues? > This is how we usually work together. Why is ASoC so different? Like I say we've got active work that ends up doing subsystem wide interface changes on a fairly frequent basis which then creates issues if a new user pops up that's still trying to use the old API. Often it's fine but coordinating near the time is safer than just acking with a potentially long lead time on things actually going through.
On Wed, 20 Jan 2021 22:49:52 +0100, Hans de Goede wrote: > Here is v4 of my series to add support for Intel Bay Trail based devices > which use a WM5102 codec for audio output/input. > > This was developed and tested on a Lenovo Yoga Tablet 1051L. > > The MFD and ASoC parts do not have any build-time dependencies > on each other. But the follow-up jack-detect series does have > patches depending on each-other and on this series. So IMHO it > would be best if this entire series would be merged through the > MFD tree to make merging the follow-up series easier. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [4/5] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() commit: 8ade6d8b02b1ead741bd4f6c42921035caab6560 [5/5] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 commit: 9a87fc1e061900e81ab13d823e85012a78849244 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Hi Mark, On 2/8/21 7:38 PM, Mark Brown wrote: > On Wed, 20 Jan 2021 22:49:52 +0100, Hans de Goede wrote: >> Here is v4 of my series to add support for Intel Bay Trail based devices >> which use a WM5102 codec for audio output/input. >> >> This was developed and tested on a Lenovo Yoga Tablet 1051L. >> >> The MFD and ASoC parts do not have any build-time dependencies >> on each other. But the follow-up jack-detect series does have >> patches depending on each-other and on this series. So IMHO it >> would be best if this entire series would be merged through the >> MFD tree to make merging the follow-up series easier. >> >> [...] > > Applied to > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [4/5] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() > commit: 8ade6d8b02b1ead741bd4f6c42921035caab6560 > [5/5] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 > commit: 9a87fc1e061900e81ab13d823e85012a78849244 Thank you. Regards, Hans
Hi All, Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input. This was developed and tested on a Lenovo Yoga Tablet 1051L. The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier. Mark, if that is ok with you (and you are happy with the ASoC changes) can you please Ack this ? Changes in v4: - Add a comment to the irq-flags override explaining that theoretically DSDTs using IRQF_TRIGGER_FALLING could be correct on boards where the IRQ controller does not support active low level interrupts Changes in v3: - Fix compilation error when CONFIG_ACPI is not set Changes in v2: - Split my WM5102 work into 2 series, one series adding basic support for Bay Trail boards with a WM5102 codec and a second series with the jack-detect work - Various other minor code tweaks Hans de Goede (4): mfd: arizona: Add MODULE_SOFTDEP("pre: arizona_ldo1") mfd: arizona: Replace arizona_of_get_type() with device_get_match_data() mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() Pierre-Louis Bossart (1): ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 drivers/mfd/arizona-core.c | 11 - drivers/mfd/arizona-i2c.c | 11 +- drivers/mfd/arizona-spi.c | 138 +++++- drivers/mfd/arizona.h | 9 - sound/soc/intel/boards/Kconfig | 12 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcr_wm5102.c | 465 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 16 + sound/soc/intel/common/soc-intel-quirks.h | 25 + 9 files changed, 661 insertions(+), 28 deletions(-) create mode 100644 sound/soc/intel/boards/bytcr_wm5102.c Regards, Hans