Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

init: Boot DSP before SLPI again #598

Merged
merged 1 commit into from May 22, 2019

Conversation

ix5
Copy link
Contributor

@ix5 ix5 commented Apr 21, 2019

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 ix5 force-pushed the devstart-adsp-cdsp branch 2 times, most recently from 7f0d242 to d7286e3 Compare Apr 27, 2019
@ix5
Copy link
Contributor Author

@ix5 ix5 commented Apr 27, 2019

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
Copy link
Contributor Author

@ix5 ix5 commented Apr 27, 2019

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

@ix5
Copy link
Contributor Author

@ix5 ix5 commented Apr 27, 2019

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

@ix5
Copy link
Contributor Author

@ix5 ix5 commented May 11, 2019

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
Copy link
Contributor Author

@ix5 ix5 commented May 16, 2019

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

@ix5 ix5 changed the title [WIP] init: Boot DSP before SLPI again init: Boot DSP before SLPI again May 16, 2019
@ix5
Copy link
Contributor Author

@ix5 ix5 commented May 21, 2019

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

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.
@jerpelea jerpelea merged commit f011ade into sonyxperiadev:master May 22, 2019
@ix5 ix5 deleted the devstart-adsp-cdsp branch May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants