init: Boot DSP before SLPI again

[ix5]

init: Boot DSP before SLPI again

Before 8792c97, adsp and cdsp were booted before slpi:

init.qcom.devstart.sh
echo 1 > /sys/kernel/boot_adsp/boot
echo 1 > /sys/kernel/boot_cdsp/boot
echo 1 > /sys/kernel/boot_slpi/boot

8792c97 changed that behaviour to first booting SLPI via init.qcom.devstart.sh, setting vendor.qcom.devup=1 and only then booting ADSP/CSDP via init.qcom.(adsp|cdsp)start.sh.

That and later commits caused race conditions that meant audio was gone on tone devices every other boot.

This commit restores the old behaviour of first booting ADSP/CDSP and then SLPI.

[ix5]

Updated PR with the following changes:

rootdir/vendor/bin/init.qcom.adspstart.sh and cdspstart.sh:
Add 2s sleep delay after booting before setting vendor.qcom.adspup (or cdspup)

rootdir/vendor/etc/init/adsprpcd.rc:
Changed class late_start to class main for vendor.adsprpcd
Start the service immediately, don't just enable it:

 on property:vendor.qcom.devup=1
+    start vendor.adsprpcd
     enable vendor.adsprpcd

rootdir/vendor/etc/init/sensors.rc:
Start vendor.sensors on property:vendor.qcom.devup=1 and not on adspup. This means sensors will only be started after SLPI is up.

[ix5]

Tested successfully on kagura, but needs testing on other platforms.

[ix5]

Updated again to remove the start vendor.adsprpcd line, no need since class_start main is triggered before devup is set.

[ix5]

With further results rolling in it appears that this PR isn't needed after all.
Still leaving open for visibility since we should start the services in the correct order.

[ix5]

Updated to remove the 2s sleep delay. Tested for weeks on kagura with no regressions.

[ix5]

Tested exhaustively, also on tama. Fixes urgent adsp race on tone.
MERGEME