| Message ID | 20220105113026.18955-1-ckeepax@opensource.cirrus.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add low power hibernation support to cs35l41 | expand |
On Wed, 05 Jan 2022 12:30:18 +0100, Charles Keepax wrote: > > This patch series adds support for the low power hibernation feature > on cs35l41. This allows the DSP memory to be retained whilst the > device enters a very low power state. > > Patches 1-6 can happily be applied straight away and are mostly bug > fixes to set things up for the series specifically around getting the > cache handling corrected in the driver. > > Patches 7,8 specifically will cause some very minor conflicts with > Lucas's currently outstanding work on the HDA version of cs35l41. > Whilst things will still build, this patch adds a test key function > his code will now have to call. If his patches are getting merged > first I will respin this series to update his code, he is currently on > holiday until the 12th of Jan, so if we want to wait for another spin > of those patches I can work with him to update them at that time. Or > alternatively we could just merge them all and I will do a quick fixup > patch at the end, since there is no build breakage. FWIW, the ASoC part of Lucas's patch set has been already merged in Mark's asoc tree. (HD-audio part isn't merged yet though). Takashi
On Wed, Jan 05, 2022 at 01:03:45PM +0100, Takashi Iwai wrote: > On Wed, 05 Jan 2022 12:30:18 +0100, > Charles Keepax wrote: > > Patches 7,8 specifically will cause some very minor conflicts with > > Lucas's currently outstanding work on the HDA version of cs35l41. > > Whilst things will still build, this patch adds a test key function > > his code will now have to call. If his patches are getting merged > > first I will respin this series to update his code, he is currently on > > holiday until the 12th of Jan, so if we want to wait for another spin > > of those patches I can work with him to update them at that time. Or > > alternatively we could just merge them all and I will do a quick fixup > > patch at the end, since there is no build breakage. > > FWIW, the ASoC part of Lucas's patch set has been already merged in > Mark's asoc tree. (HD-audio part isn't merged yet though). > Yeah its the HDA part that would require a small change after those last two patches to call the additional function. The series is already based on top of the merged ASoC changes. Thanks, Charles
On Wed, 05 Jan 2022 14:05:12 +0100, Charles Keepax wrote: > > On Wed, Jan 05, 2022 at 01:03:45PM +0100, Takashi Iwai wrote: > > On Wed, 05 Jan 2022 12:30:18 +0100, > > Charles Keepax wrote: > > > Patches 7,8 specifically will cause some very minor conflicts with > > > Lucas's currently outstanding work on the HDA version of cs35l41. > > > Whilst things will still build, this patch adds a test key function > > > his code will now have to call. If his patches are getting merged > > > first I will respin this series to update his code, he is currently on > > > holiday until the 12th of Jan, so if we want to wait for another spin > > > of those patches I can work with him to update them at that time. Or > > > alternatively we could just merge them all and I will do a quick fixup > > > patch at the end, since there is no build breakage. > > > > FWIW, the ASoC part of Lucas's patch set has been already merged in > > Mark's asoc tree. (HD-audio part isn't merged yet though). > > > > Yeah its the HDA part that would require a small change after > those last two patches to call the additional function. The > series is already based on top of the merged ASoC changes. Ah, OK, that's what you commented in Lukas's v6 patchset, right? We can fix it up later after the merge, too. Right now I'm waiting for the PR from Mark, then will merge v6 patches (modulo the ACPI one). thanks, Takashi
On Wed, Jan 05, 2022 at 03:07:35PM +0100, Takashi Iwai wrote: > On Wed, 05 Jan 2022 14:05:12 +0100, > Charles Keepax wrote: > > > > On Wed, Jan 05, 2022 at 01:03:45PM +0100, Takashi Iwai wrote: > > > On Wed, 05 Jan 2022 12:30:18 +0100, > > > Charles Keepax wrote: > > > > Patches 7,8 specifically will cause some very minor conflicts with > > > > Lucas's currently outstanding work on the HDA version of cs35l41. > > > > Whilst things will still build, this patch adds a test key function > > > > his code will now have to call. If his patches are getting merged > > > > first I will respin this series to update his code, he is currently on > > > > holiday until the 12th of Jan, so if we want to wait for another spin > > > > of those patches I can work with him to update them at that time. Or > > > > alternatively we could just merge them all and I will do a quick fixup > > > > patch at the end, since there is no build breakage. > > > > > > FWIW, the ASoC part of Lucas's patch set has been already merged in > > > Mark's asoc tree. (HD-audio part isn't merged yet though). > > > > > > > Yeah its the HDA part that would require a small change after > > those last two patches to call the additional function. The > > series is already based on top of the merged ASoC changes. > > Ah, OK, that's what you commented in Lukas's v6 patchset, right? > We can fix it up later after the merge, too. > > Right now I'm waiting for the PR from Mark, then will merge v6 patches > (modulo the ACPI one). Yeah I suspect me just doing a small fix up patch at the end might be the simplest solution. Thanks, Charles
On Wed, Jan 05, 2022 at 11:30:18AM +0000, Charles Keepax wrote: > Patches 7,8 specifically will cause some very minor conflicts with > Lucas's currently outstanding work on the HDA version of cs35l41. > Whilst things will still build, this patch adds a test key function No they won't, an x86 allmodconfig gives this: ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-i2c.ko] undefined! ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-spi.ko] undefined! ERROR: modpost: "cs35l41_test_key_lock" [sound/soc/codecs/snd-soc-cs35l41.ko] undefined! ERROR: modpost: "cs35l41_test_key_unlock" [sound/soc/codecs/snd-soc-cs35l41.ko] undefined!
On Wed, Jan 05, 2022 at 02:30:29PM +0000, Mark Brown wrote: > On Wed, Jan 05, 2022 at 11:30:18AM +0000, Charles Keepax wrote: > > > Patches 7,8 specifically will cause some very minor conflicts with > > Lucas's currently outstanding work on the HDA version of cs35l41. > > Whilst things will still build, this patch adds a test key function > > No they won't, an x86 allmodconfig gives this: > > ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-i2c.ko] undefined! > ERROR: modpost: "cs35l41_pm_ops" [sound/soc/codecs/snd-soc-cs35l41-spi.ko] undefined! > ERROR: modpost: "cs35l41_test_key_lock" [sound/soc/codecs/snd-soc-cs35l41.ko] undefined! > ERROR: modpost: "cs35l41_test_key_unlock" [sound/soc/codecs/snd-soc-cs35l41.ko] undefined! Hmm... apologies, let me look into that one. Thanks, Charles
On Wed, 5 Jan 2022 11:30:18 +0000, Charles Keepax wrote: > This patch series adds support for the low power hibernation feature > on cs35l41. This allows the DSP memory to be retained whilst the > device enters a very low power state. > > Patches 1-6 can happily be applied straight away and are mostly bug > fixes to set things up for the series specifically around getting the > cache handling corrected in the driver. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/8] ASoC: cs35l41: Add cs35l51/53 IDs commit: dcf821319474edde7e85b95608a4539703a2b67d [2/8] ASoC: cs35l41: Remove incorrect comment commit: 4e7c3cd87db8d9350062a25a8476f90fd1cbc4c9 [3/8] ASoC: cs35l41: Correct DSP power down commit: 56852cf4b2179fb90068a49538501f31c2de18ea [4/8] ASoC: cs35l41: Correct handling of some registers in the cache commit: 5f2f539901b0d9bda722637521a11b7f7cf753f1 [5/8] firmware: cs_dsp: Clear core reset for cache commit: 7aa1cc1091e0a424e9e7711ca381ebe98b6865bc [6/8] ASoC: wm_adsp: Add support for "toggle" preloaders commit: ba235634b138cd9d012dbe983e7920481211e132 [7/8] ASoC: cs35l41: Update handling of test key registers (no commit info) [8/8] ASoC: cs35l41: Add support for hibernate memory retention mode (no commit info) 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