On Wed, 06 Jul 2022 12:40:36 +0200, Vitaly Rodionov wrote: > > > Hi Takashi, > > On 04/07/2022 13:50, Takashi Iwai wrote: > > On Thu, 30 Jun 2022 02:23:21 +0200, > Vitaly Rodionov wrote: > > The CS35L41 Amplifier contains a DSP, capable of running firmware. > The firmware can run algorithms such as Speaker Protection, to ensure > that playback at high gains do not harm the speakers. > Adding support for CS35L41 firmware into the CS35L41 HDA driver also > allows us to support several extra features, such as hiberation > and interrupts. > > The chain adds support in stages: > - General fixes to improve generalization and code re-use inside > the CS35L41 HDA driver. > - Add support for interrupts into the driver, which is required > for complete support of the firmware. > - Refactor ASoC CS35L41 code which deals with firmware to allow > for code re-use inside the CS35L41 HDA driver. > - Add support for loading firmware and tuning files from file system, > and creating alsa controls to control it. > - Support firmware load paths for different hardware systems. > - Support suspend/resume in the driver when using firmware. The firmware > supports hibernation, which allows the CS35L41 to drop into a low > power mode during suspend. > - Support the ability to unload firmware, swap and reload the firmware. > This is to allow different firmware to run during calibration. > > The intended use-case is to load the firmware once on boot, and the driver > autmatically tries to load the firmware after it binds to the HDA driver. > This behaviour can be switched off using a kconfig, if desired. > > changes since v7: > - Use private_data rather than private_value to save control info > - Clean up alsa control memory allocation/deallocation > - Remove unnecessary whitespace > - Get subsystem id from codec, rather than saving it separately > > changes since v6: > - Fix warning by kernel test robot <lkp@xxxxxxxxx> > > changes since v5: > - Fix warning by kernel test robot <lkp@xxxxxxxxx> > > changes since v4: > - Fully remove tlv remnants from control add apis > - Remove unnecessary debug > - Rename variable to be more generic > - Remove redundent length check from read/write control apis > > - Use SNDRV_CTL_ELEM_IFACE_CARD for firmware load controls > - Make kcontrol add/remove synchronous > - Load firmware asynchronous when loading via control > - Used cached controls when reloading firmware; only delete > controls when removing the driver itself > > - Improve kcontrol remove > - Fix control write + notify > - Cleanup of unnecessary code > - Fix race condition when loading firmware before playback > - Ensure errors are properly propogated > - Fix include for Module parameters > > Stefan Binding (13): > ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls > ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly > ALSA: hda: cs35l41: Save codec object inside component struct > ALSA: hda: cs35l41: Save Subsystem ID inside CS35L41 Driver > ALSA: hda: cs35l41: Support reading subsystem id from ACPI > ALSA: hda: cs35l41: Support multiple load paths for firmware > ALSA: hda: cs35l41: Support Speaker ID for laptops > ALSA: hda: cs35l41: Support Hibernation during Suspend > ALSA: hda: cs35l41: Read Speaker Calibration data from UEFI variables > ALSA: hda: hda_cs_dsp_ctl: Add fw id strings > ALSA: hda: cs35l41: Add defaulted values into dsp bypass config > sequence > ALSA: hda: cs35l41: Support Firmware switching and reloading > ALSA: hda: cs35l41: Add module parameter to control firmware load > > Vitaly Rodionov (1): > ALSA: hda: cs35l41: Add initial DSP support and firmware loading > > Thanks, this version looks better than previous ones, and I'm fine to > apply as is, to make things going forward. But this seems requiring > the prerequisite in ASoC codec side. > > Mark, could you send a PR to merge into my tree so that I can apply > those series? > > And, one still uncertain thing is about the handling of system > suspend/resume, especially about the firmware loading work. e.g. what > happens if a f/w work is in run and the system goes to suspend at the > very same time? Or does the S3/S4 work in general at all? > > Sorry for the delay, but your comments raised our attention and we wanted to > run extensive testing again to make sure there is no hidden issue. No issues > were found during tests. When we start FW download work we call "resume", so > the resume counter should be incremented and suspend will not happen till we > finish the download process. Now all patches have been merged to for-next branch. thanks, Takashi
