diff options
author | Cezary Rojewski <cezary.rojewski@intel.com> | 2020-09-29 16:12:38 +0200 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2020-10-02 15:32:31 +0100 |
commit | a9aa6fb3eb6c7e0e7e117b3f2dfafef8c45b9ea6 (patch) | |
tree | 708c1f1a85bf0dc454a015914db7b52f31489777 /sound/arm | |
parent | ba202a7bc3da05ca4548c7247f9be769b4e8c9fa (diff) |
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>
Diffstat (limited to 'sound/arm')
0 files changed, 0 insertions, 0 deletions