Home
last modified time | relevance | path

Searched hist:"59322 d35" (Results 1 – 3 of 3) sorted by relevance

/openbmc/linux/sound/soc/codecs/
H A Dcs35l56-sdw.c59322d35 Tue Apr 11 10:25:28 CDT 2023 Richard Fitzgerald <rf@opensource.cirrus.com> 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>
H A Dcs35l56.c59322d35 Tue Apr 11 10:25:28 CDT 2023 Richard Fitzgerald <rf@opensource.cirrus.com> 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>
/openbmc/linux/include/sound/
H A Dcs35l56.h59322d35 Tue Apr 11 10:25:28 CDT 2023 Richard Fitzgerald <rf@opensource.cirrus.com> 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>