Hi Pierre,
On 8/1/2024 1:33 AM, Pierre-Louis Bossart wrote:
On 8/1/24 03:17, Wesley Cheng wrote:
For USB offloading situations, the AFE port start command will result in a QMI handshake between the Q6DSP and the main processor. Depending on if the USB bus is suspended, this routine would require more time to complete, as resuming the USB bus has some overhead associated with it. Increase the timeout to 3s to allow for sufficient time for the USB QMI stream enable handshake to complete.
Reviewed-by: Srinivas Kandagatla srinivas.kandagatla@linaro.org Signed-off-by: Wesley Cheng quic_wcheng@quicinc.com
sound/soc/qcom/qdsp6/q6afe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe.c b/sound/soc/qcom/qdsp6/q6afe.c index 948007955934..452d7e8b9b30 100644 --- a/sound/soc/qcom/qdsp6/q6afe.c +++ b/sound/soc/qcom/qdsp6/q6afe.c @@ -366,7 +366,7 @@ #define AFE_API_VERSION_SLOT_MAPPING_CONFIG 1 #define AFE_API_VERSION_CODEC_DMA_CONFIG 1
-#define TIMEOUT_MS 1000 +#define TIMEOUT_MS 3000
Surprising that 1s is not enough to resume a bus, and conversely is 3s enough then if the overhead is so significant? It looks like either too much or too little...
To clarify, if USB bus suspend isn't enabled, then this isn't an issue. I just picked 3s since this is a worst case timeout value. I don't think it will take longer than that to start an audio session, otherwise there is another inherent problem. When I initially tested this, it may have been on a platform/chipset that wasn't running with optimized CPU settings, and might have been running slower overall.
Thanks
Wesley Cheng
#define AFE_CMD_RESP_AVAIL 0 #define AFE_CMD_RESP_NONE 1 #define AFE_CLK_TOKEN 1024