soc: qcom: mark pd-mapper as broken
PATCH 1/1 soc: qcom: mark pd-mapper as broken
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request: 0x10 (-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125
ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110
Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
---
It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service).
Johan
#regzbot introduced: 1ebcde047c54
drivers/soc/qcom/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/soc/qcom/Kconfig +1 -0
@@ -78,6 +78,7 @@ config QCOM_PD_MAPPER select QCOM_PDR_MSG select AUXILIARY_BUS depends on NET && QRTR && (ARCH_QCOM || COMPILE_TEST) + depends on BROKEN default QCOM_RPROC_COMMON help The Protection Domain Mapper maps registered services to the domains
Signature · 1 line
2.45.2
Quoted 26 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Quoted 8 lines
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>
Please don't break what is working. pd_mapper is working on all previous platforms. I suggest reverting commit bd6db1f1486e ("soc:
qcom: pd_mapper: Add X1E80100") instead.
Quoted 31 lines
---
It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service).
Johan
#regzbot introduced:
1ebcde047c54drivers/soc/qcom/Kconfig | 1 + 1 file changed, 1 insertion(+)drivers/soc/qcom/Kconfig +1
-1@@ -78,6 +78,7 @@ config QCOM_PD_MAPPER select QCOM_PDR_MSG select AUXILIARY_BUS depends on NET && QRTR && (ARCH_QCOM || COMPILE_TEST) + depends on BROKEN default QCOM_RPROC_COMMON help The Protection Domain Mapper maps registered services to the domains --2.45.2
Signature · 2 lines
With best wishes Dmitry
Quoted 31 lines · Dmitry Baryshkov
Quoted 30 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Quoted 8 lines
Quoted 4 lines
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>Please don't break what is working.
pd_mapperis working on all previous platforms. I suggest reverting commitbd6db1f1486e("soc:
qcom:pd_mapper: Add X1E80100") instead.
As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
Let's disable it until the underlying bugs have been addressed.
Johan
Quoted 38 lines · Johan Hovold
Quoted 36 lines · Dmitry Baryshkov
Quoted 34 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>
Quoted 7 lines
Quoted 3 lines
Please don't break what is working.
pd_mapperis working on all previous platforms. I suggest reverting commitbd6db1f1486e("soc:
qcom:pd_mapper: Add X1E80100") instead.As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
I have the understanding that the issues are related to the ADSP switching the firmware on the fly, which is only used on X1E8.
Quoted 4 lines
Let's disable it until the underlying bugs have been addressed.
Johan
Signature · 2 lines
With best wishes Dmitry
Quoted 7 lines · Dmitry Baryshkov
Quoted 6 lines · Johan Hovold
Quoted 3 lines · Dmitry Baryshkov
Please don't break what is working.
pd_mapperis working on all previous platforms. I suggest reverting commitbd6db1f1486e("soc:
qcom:pd_mapper: Add X1E80100") instead.
Quoted 6 lines
Quoted 3 lines
As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
I have the understanding that the issues are related to the ADSP switching the firmware on the fly, which is only used on X1E8.
Is this speculation on your part or something that has recently been confirmed to be the case? AFAIK, there is nothing SoC specific about the ECANCELED issue, and we also still do not know what is causing the audio regression.
The thing is, we have a working and well-tested solution in the user-space service so there is no rush to switch to the in-kernel one (and risk distros removing the user-space service) before this has been fixed.
Johan
Quoted 20 lines · Johan Hovold
Quoted 7 lines · Dmitry Baryshkov
Quoted 6 lines · Johan Hovold
Quoted 3 lines · Dmitry Baryshkov
Please don't break what is working.
pd_mapperis working on all previous platforms. I suggest reverting commitbd6db1f1486e("soc:
qcom:pd_mapper: Add X1E80100") instead.Quoted 6 lines
Quoted 3 lines
As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
I have the understanding that the issues are related to the ADSP switching the firmware on the fly, which is only used on X1E8.
Is this speculation on your part or something that has recently been confirmed to be the case? AFAIK, there is nothing SoC specific about the ECANCELED issue, and we also still do not know what is causing the audio regression.
Quoted 4 lines
The thing is, we have a working and well-tested solution in the user-space service so there is no rush to switch to the in-kernel one (and risk distros removing the user-space service) before this has been fixed.
The in-kernel pd-mapper works fine on SM8550 and SM8650, please just revert the X1E8 patch as suggested by Dmitry.
Neil
Quoted 3 lines
Johan
Quoted 8 lines · On Thu, Oct 10, 2024 at 01:46:48PM +0200, [email protected] wrote:
Quoted 5 lines
Quoted 5 lines · Johan Hovold
Quoted 4 lines
As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
The in-kernel pd-mapper works fine on SM8550 and SM8650, please just revert the X1E8 patch as suggested by Dmitry.
Again, you may just be lucky, we have x1e users that also don't hit these issues due to how things are timed during boot in their setups.
If there's some actual evidence that suggests that this is limited to x1e, then that would of course be a different matter, but I'm not aware of anything like that currently.
Johan
Quoted 10 lines · Johan Hovold
Quoted 8 lines · On Thu, Oct 10, 2024 at 01:46:48PM +0200, [email protected] wrote:
Quoted 5 lines
Quoted 5 lines · Johan Hovold
Quoted 4 lines
As I tried to explain in the commit message, there is currently nothing indicating that these issues are specific to x1e80100 (even if you may not hit them in your setup depending on things like probe order).
The in-kernel pd-mapper works fine on SM8550 and SM8650, please just revert the X1E8 patch as suggested by Dmitry.
Quoted 6 lines
Again, you may just be lucky, we have x1e users that also don't hit these issues due to how things are timed during boot in their setups.
If there's some actual evidence that suggests that this is limited to x1e, then that would of course be a different matter, but I'm not aware of anything like that currently.
Is there an evidence that it is broken on other platforms? I have been daily driving the pd-mapper in my testing kernels for a long period of time.
Signature · 2 lines
With best wishes Dmitry
Quoted 5 lines · Dmitry Baryshkov
Quoted 3 lines · Johan Hovold
Again, you may just be lucky, we have x1e users that also don't hit these issues due to how things are timed during boot in their setups.
Quoted 7 lines
Quoted 3 lines
If there's some actual evidence that suggests that this is limited to x1e, then that would of course be a different matter, but I'm not aware of anything like that currently.
Is there an evidence that it is broken on other platforms? I have been daily driving the pd-mapper in my testing kernels for a long period of time.
Yes, Chris's analysis of the ECANCELED issue suggests that this is not SoC specific.
Johan
Quoted 11 lines · Johan Hovold
Quoted 9 lines · Dmitry Baryshkov
Quoted 6 lines · Johan Hovold
Again, you may just be lucky, we have x1e users that also don't hit these issues due to how things are timed during boot in their setups.
If there's some actual evidence that suggests that this is limited to x1e, then that would of course be a different matter, but I'm not aware of anything like that currently.
Quoted 6 lines
Quoted 3 lines
Is there an evidence that it is broken on other platforms? I have been daily driving the pd-mapper in my testing kernels for a long period of time.
Yes, Chris's analysis of the ECANCELED issue suggests that this is not SoC specific.
"When the firmware implements the glink channel this way...", etc. Yes, it doesn't sound like being SoC-specific, but we don't know which SoC use this implementation.
Quoted 2 lines
Johan
Signature · 2 lines
With best wishes Dmitry
Quoted 8 lines · Dmitry Baryshkov
Quoted 2 lines · Johan Hovold
Yes, Chris's analysis of the ECANCELED issue suggests that this is not SoC specific.
"When the firmware implements the glink channel this way...", etc. Yes, it doesn't sound like being SoC-specific, but we don't know which SoC use this implementation.
So let's err on the safe side until we have more information and avoid having distros drop the user-space daemon until these known bugs exposed by the in-kernel pd-mapper have been fixed.
Johan
Quoted 6 lines · Johan Hovold
Quoted 5 lines · Dmitry Baryshkov
Quoted 2 lines · Johan Hovold
Yes, Chris's analysis of the ECANCELED issue suggests that this is not SoC specific.
Quoted 7 lines
Quoted 3 lines
"When the firmware implements the glink channel this way...", etc. Yes, it doesn't sound like being SoC-specific, but we don't know which SoC use this implementation.
So let's err on the safe side until we have more information and avoid having distros drop the user-space daemon until these known bugs exposed by the in-kernel pd-mapper have been fixed.
Then default n + revert X1E sounds like a better approach?
Quoted 2 lines
Johan
Signature · 2 lines
With best wishes Dmitry
Quoted 33 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>
Quoted 7 lines
---
It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service).
This is just a random thought, but I wonder if we could insert a delay somewhere as temporary workaround to make the in-kernel pd-mapper more reliable. I just tried replicating the userspace pd-mapper timing on X1E80100 CRD by:
1. Disabling auto-loading of qcom_pd_mapper (modprobe.blacklist=qcom_pd_mapper)
2. Adding a systemd service that does nothing except running "modprobe qcom_pd_mapper" at the same point in time where the userspace pd-mapper would usually be started.
This seems to work quite well for me, I haven't seen any of the mentioned errors anymore in a couple of boot tests. Clearly, there is no actual bug in the in-kernel pd-mapper, only worse timing.
Thanks,
Stephan
Quoted 47 lines · Stephan Gerhold
Quoted 33 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>Quoted 7 lines
---
It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service).
This is just a random thought, but I wonder if we could insert a delay somewhere as temporary workaround to make the in-kernel pd-mapper more reliable. I just tried replicating the userspace pd-mapper timing on X1E80100 CRD by:
Quoted 5 lines
1. Disabling auto-loading of
qcom_pd_mapper(modprobe.blacklist=qcom_pd_mapper)
2. Adding a systemd service that does nothing except running "modprobeqcom_pd_mapper" at the same point in time where the userspace pd-mapper would usually be started.
Thank you so much for this idea. I'm currently using this workaround on my sdm845 device (where the in-kernel pd-mapper is breaking the out-of-tree call audio functionality).
Is there any work going on on making the timing of the in-kernel pd-mapper more reliable?
Cheers,
Frank
Quoted 6 lines
This seems to work quite well for me, I haven't seen any of the mentioned errors anymore in a couple of boot tests. Clearly, there is no actual bug in the in-kernel pd-mapper, only worse timing.
Thanks,
Stephan
Quoted 54 lines · Frank Oltmanns
Quoted 47 lines · Stephan Gerhold
Quoted 33 lines · Johan Hovold
When using the in-kernel pd-mapper on x1e80100, client drivers often fail to communicate with the firmware during boot, which specifically breaks battery and USB-C altmode notifications. This has been observed to happen on almost every second boot (41%) but likely depends on probe order:
pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to send altmode request:
0x10(-125) pmic_glink_altmode.pmic_glink_altmode pmic_glink.altmode.0: failed to request altmode notifications: -125ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125
qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications
In the same setup audio also fails to probe albeit much more rarely:
PDR: avs/audio get domain list txn wait failed: -110
PDR: service lookup for avs/audio failed: -110Chris Lew has provided an analysis and is working on a fix for the ECANCELED (125) errors, but it is not yet clear whether this will also address the audio regression.
Even if this was first observed on x1e80100 there is currently no reason to believe that these issues are specific to that platform.
Disable the in-kernel pd-mapper for now, and make sure to backport this to stable to prevent users and distros from migrating away from the user-space service.
Fixes 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")Cc [email protected] # 6.11Signed-off-by Johan Hovold <[email protected]>Quoted 7 lines
---
It's now been over two months since I reported this regression, and even if we seem to be making some progress on at least some of these issues I think we need disable the pd-mapper temporarily until the fixes are in place (e.g. to prevent distros from dropping the user-space service).
This is just a random thought, but I wonder if we could insert a delay somewhere as temporary workaround to make the in-kernel pd-mapper more reliable. I just tried replicating the userspace pd-mapper timing on X1E80100 CRD by:
Quoted 5 lines
1. Disabling auto-loading of
qcom_pd_mapper(modprobe.blacklist=qcom_pd_mapper)
2. Adding a systemd service that does nothing except running "modprobeqcom_pd_mapper" at the same point in time where the userspace pd-mapper would usually be started.
Quoted 3 lines
Thank you so much for this idea. I'm currently using this workaround on my sdm845 device (where the in-kernel pd-mapper is breaking the out-of-tree call audio functionality).
Thanks for letting us know that the audio issue affects sdm845 as well (I don't seem to hit it on sc8280xp and the X13s).
Quoted 2 lines
Is there any work going on on making the timing of the in-kernel pd-mapper more reliable?
The ECANCELLED regression has now been fixed, but the audio issue remains to be addressed (I think Bjorn has done some preliminary investigation).
There is also a NULL-deref in an MHI path that is triggered by the in-kernel pd-mapper for which Chris has posted a workaround here:
https://lore.kernel.org/r/[email protected]
Johan
Quoted 8 lines · Johan Hovold
Quoted 3 lines · Frank Oltmanns
Thank you so much for this idea. I'm currently using this workaround on my sdm845 device (where the in-kernel pd-mapper is breaking the out-of-tree call audio functionality).
Thanks for letting us know that the audio issue affects sdm845 as well (I don't seem to hit it on sc8280xp and the X13s).
And today I also hit this on the sc8280xp CRD reference design, so as expected, there is nothing SoC specific about the audio service regression either:
[ 11.235564] PDR: avs/audio get domain list txn wait failed: -110 [ 11.241976] PDR: service lookup for avs/audio failed: -110
even if it may be masked by random changes in timing.
These means it affects also machines like the X13s which already have audio enabled.
Quoted 6 lines
Quoted 2 lines
Is there any work going on on making the timing of the in-kernel pd-mapper more reliable?
The ECANCELLED regression has now been fixed, but the audio issue remains to be addressed (I think Bjorn has done some preliminary investigation).
Hopefully Bjorn or Chris have some plan on how to address the audio regression.
Johan
Quoted 14 lines · Johan Hovold
Quoted 8 lines · Johan Hovold
Quoted 3 lines · Frank Oltmanns
Thank you so much for this idea. I'm currently using this workaround on my sdm845 device (where the in-kernel pd-mapper is breaking the out-of-tree call audio functionality).
Thanks for letting us know that the audio issue affects sdm845 as well (I don't seem to hit it on sc8280xp and the X13s).
And today I also hit this on the sc8280xp CRD reference design, so as expected, there is nothing SoC specific about the audio service regression either:
Quoted 7 lines
[ 11.235564] PDR: avs/audio get domain list txn wait failed: -110 [ 11.241976] PDR: service lookup for avs/audio failed: -110even if it may be masked by random changes in timing.
These means it affects also machines like the X13s which already have audio enabled.
I've blocklisted the in-kernel pd-mapper module for now and have switched back to the userspace pd-mapper.
I don't know if it's helpful or not, but I don't get these error logs when using to the in-kernel pd-mapper. It's just that the phone's mic only works on approximately every third boot (unless I defer loading the module).
Quoted 10 lines
Quoted 7 lines
Quoted 3 lines
Is there any work going on on making the timing of the in-kernel pd-mapper more reliable?
The ECANCELLED regression has now been fixed, but the audio issue remains to be addressed (I think Bjorn has done some preliminary investigation).
Hopefully Bjorn or Chris have some plan on how to address the audio regression.
If you come up with a patch, I'd be glad to test it on my xiaomi-beryllium device.
Thanks again,
Frank
Quoted 2 lines
Johan
Quoted 14 lines · Frank Oltmanns
Quoted 11 lines · Johan Hovold
And today I also hit this on the sc8280xp CRD reference design, so as expected, there is nothing SoC specific about the audio service regression either:
[ 11.235564] PDR: avs/audio get domain list txn wait failed: -110 [ 11.241976] PDR: service lookup for avs/audio failed: -110even if it may be masked by random changes in timing.
These means it affects also machines like the X13s which already have audio enabled.
Quoted 7 lines
I've blocklisted the in-kernel pd-mapper module for now and have switched back to the userspace pd-mapper.
I don't know if it's helpful or not, but I don't get these error logs when using to the in-kernel pd-mapper. It's just that the phone's mic only works on approximately every third boot (unless I defer loading the module).
Ok, then it sounds like you're hitting a separate bug that is also triggered by the changed timings with the in-kernel pd-mapper.
Are there any hints in the logs about what goes wrong in your setup? And the speakers are still working, it's just affecting the mic?
Johan
Quoted 18 lines · Johan Hovold
Quoted 17 lines · Frank Oltmanns
Quoted 11 lines · Johan Hovold
And today I also hit this on the sc8280xp CRD reference design, so as expected, there is nothing SoC specific about the audio service regression either:
[ 11.235564] PDR: avs/audio get domain list txn wait failed: -110 [ 11.241976] PDR: service lookup for avs/audio failed: -110even if it may be masked by random changes in timing.
These means it affects also machines like the X13s which already have audio enabled.
I've blocklisted the in-kernel pd-mapper module for now and have switched back to the userspace pd-mapper.
Quoted 7 lines
Quoted 4 lines
I don't know if it's helpful or not, but I don't get these error logs when using to the in-kernel pd-mapper. It's just that the phone's mic only works on approximately every third boot (unless I defer loading the module).
Ok, then it sounds like you're hitting a separate bug that is also triggered by the changed timings with the in-kernel pd-mapper.
I worked on finding out what's causing the issue on sdm845 and I've submitted a patch here: [1]
Quoted 1 line
Are there any hints in the logs about what goes wrong in your setup?
Unfortunately not, see [1].
Quoted 2 lines
And
the speakers are still working, it's just affecting the mic?
Yes, it's only affecting the mic in my setup on xiaomi-beryllium, but there seem to be issues with the speaker on oneplus-enchilada that can be fixed with the same approach.
Best regards,
Frank
[1]: https://lore.kernel.org/all/[email protected]/
Quoted 2 lines
Johan