diff options
author | Richard Fitzgerald <rf@opensource.cirrus.com> | 2023-04-11 16:25:28 +0100 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2023-04-12 17:34:36 +0100 |
commit | 59322d35179987e85b593e504fd334de8683c835 (patch) | |
tree | 1f5b4c06b109bcda54e14bc3538077be11b7468d /drivers/ssb/ssb_private.h | |
parent | 39a594dc0b4ac949edf221db33c7061c45e2c90b (diff) | |
download | linux-stable-59322d35179987e85b593e504fd334de8683c835.tar.gz linux-stable-59322d35179987e85b593e504fd334de8683c835.tar.bz2 linux-stable-59322d35179987e85b593e504fd334de8683c835.zip |
ASoC: cs35l56: Re-patch firmware after system suspend
Check during cs35l56_system_resume() whether the firmware patch must
be applied again.
The FIRMWARE_MISSING flag in the PROTECTION_STATUS register indicates
whether the firmware has been patched.
In non-secure mode the FIRMWARE_MISSING flag is cleared at the end of
dsp_work(). If it is set after system-resume we know that dsp_work()
must be run again.
In secure mode the pre-OS loader will have done the secure patching
and cleared the FIRMWARE_MISSING flag. So this flag does not tell us
whether firmware memory was lost. But the driver could only be
downloading non-secure tunings, which is always safe to do.
If the driver has control of RESET we will have asserted it during
suspend so the firmware patch will have been lost. The driver would only
have control of RESET in non-secure mode.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/168122674550.26.8545058503709956172@mailman-core.alsa-project.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/ssb/ssb_private.h')
0 files changed, 0 insertions, 0 deletions