ASoC: Intel: catpt: Firmware loading and context restore
authorCezary Rojewski <cezary.rojewski@intel.com>
Tue, 29 Sep 2020 14:12:38 +0000 (16:12 +0200)
committerMark Brown <broonie@kernel.org>
Fri, 2 Oct 2020 14:32:31 +0000 (15:32 +0100)
commita9aa6fb3eb6c7e0e7e117b3f2dfafef8c45b9ea6
tree708c1f1a85bf0dc454a015914db7b52f31489777
parentba202a7bc3da05ca4548c7247f9be769b4e8c9fa
ASoC: Intel: catpt: Firmware loading and context restore

For Lynxpoint and Wildcat Point solution, is it host's responsibility to
allocate SRAM regions and ensure those already taken are not overwritten
with other data until released. Blocks are transferred to SRAM - either
IRAM or DRAM - via DW DMA controller. Once basefw is booted, ownership
of DMA transfer is lost in favour of DSP.

Hosts reponsibilities don't end on initial block allocation and binary
transfer. During Dx transitions host must store FW runtime context from
DRAM before putting AudioDSP subsystem into lower power state. Said
context gets flashed after D0 entry to bring DSP right where it was just
before suspending.

Load and restore procedures are finalized with SRAM power gating and
adequate clock level selection. This power gates unused EBBs and clock
speed effectively reducing power consumption.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200929141247.8058-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
sound/soc/intel/catpt/core.h
sound/soc/intel/catpt/loader.c