google_rtc_audio_processing: Make control write reliable

[bzhg]

Userspace may write the config control repeatedly in quick succession.
Accept the new config in cmd callback to avoid -EBUSY error and ensure
the last successful control write before prepare/copy is applied.

This patch also fixes an edge case during init where the first non-empty
control write happens after prepare. This patch ensures the config is
applied during copy.

Tested:

1. Writes in quick succession
   for i in $(seq 1 100); do
   ./sof-ctl -n 92 -t 0 -b -r -s /root/test_blob0.txt &
   ./sof-ctl -n 92 -t 0 -b -r -s /root/test_blob1.txt &
   done

2. Large config requiring multiple ipcs
   for i in $(seq 1 1000); do
   ./sof-ctl -n 92 -t 0 -b -r -s /root/large_blob.txt
   ./sof-ctl -n 92 -t 0 -b -r -s /root/test_blob1.txt
   done

3. Reboot, write before and after arecord starts

4. Suspend/resume

Signed-off-by: Ben Zhang benzh@chromium.org

[lkoenig]

This look good to me.
I am still a bit itchy about the preemption but as it is possible at the moment, it should be fine.

[lkoenig]

I wonder if it would be possible in a follow-up PR to add locks around the config for the preemption case ?

[lgirdwood]

I wonder if it would be possible in a follow-up PR to add locks around the config for the preemption case ?

Yes, if this is an atomic config change. Some processing component can keep the old config whilst the new one is being copied and then switch over by change the config pointer.