ASoC: SOF: update gain ipc msg definition to align with fw #4071
Conversation
RanderWang
requested review from
lgirdwood,
plbossart,
ranj063,
kv2019i,
dbaluta,
bardliao,
ujfalusi,
ajitkupandey,
kuanhsuncheng and
yaochunhung
as code owners
|
The discussion is in #4026 . The gain ipc msg was first supported based on closed source TGL branch in 2020. At that time it was 32 bits. It was updated to 64bits later but kernel side is not updated |
@RanderWang will this break TGL with the tester? |
I validated on TGL with Closed source FW. Please check the original definition, a u32 sized memory is padded by compiler to align 8. Why FW is crashed ? because we don't zeroed "struct sof_ipc4_gain_data" in volume update, so the padded u32 is full of garbage, so FW get a 64bit data with high part of unexpected data. Now we change the padded u32 to explicitly defined high part and zero it. struct sof_ipc4_gain_data {
uint32_t channels;
uint32_t init_val;
uint32_t curve_type;
uint32_t reserved;
uint32_t curve_duration;
// compiler will allocate more u32 memory to aligned(8)
} __aligned(8); |
RanderWang
force-pushed
the
fix_ipc4_gain_bug
branch
from
f7eeed6
to
6be8697
Compare
Recent firmware changes modified the curve duration from 32 to 64 bits, which breaks volume ramps. A simple solution would be to change the definition, but unfortunately the ASoC topology framework only supports up to 32 bit tokens. This patch suggests breaking the 64 bit value in low and high parts, with only the low-part extracted from topology and high-part only zeroes. Since the curve duration is represented in hundred of nanoseconds, we can still represent a 400s ramp, which is just fine. The defacto ABI change has no effect on existing users since the IPC4 firmware has not been released just yet. Link: thesofproject#4026 Signed-off-by: Rander Wang <[email protected]>
RanderWang
force-pushed
the
fix_ipc4_gain_bug
branch
from
6be8697
to
d814472
Compare
Fw uses latest 64 bits curve_duration in gain ipc msg definition so update kernel driver side. Curve_duration is in number of hundreds nanoseconds, and only 32 bits int can support up to 400s volume ramp, which is enough for ramp feature, so we don't need to support 64 bits read by topology. Now divide 64 bits curve_duration to two parts: low part set by topology and high part zeroed in driver.
fix #4026 (IPC4 volume windows ramp was broken with latest sof-dev kernel and sof firmware)