On Thu, 22 Mar 2018 08:19:51 +0100, Hui Wang wrote:
On 2018年03月21日 21:09, Hui Wang wrote:
On 2018年03月21日 17:48, Takashi Iwai wrote:
On Wed, 21 Mar 2018 10:39:35 +0100, Ughreja, Rakesh A wrote:
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel-bounces@alsa- project.org] On Behalf Of Takashi Iwai Sent: Wednesday, March 21, 2018 2:45 PM To: alsa-devel@alsa-project.org Cc: Hui Wang hui.wang@canonical.com Subject: [alsa-devel] [PATCH] ALSA: hda - Force polling mode on CFL for fixing codec communication
We've observed too long probe time with Coffee Lake machines, and the likely cause is some communication problem between the HD-audio controller and the codec chips. While the controller expects an IRQ wakeup for each codec response, it seems sometimes missing, and it takes one second for the controller driver to time out and read the response in the polling mode.
I think I faced similar problem while doing the HDA ASoC work.
I don't have any way to reproduce and test this. Can we increase the delay after the link is powered ON. The present delay is 100usec, can we make it 521 uSec ? Possibly the codec is not ready after the link is powered on and so it's not responding.
I'm afraid that this wouldn't help since the issue appears repeatedly at later points.
But still it's worth to try. Hui, could you investigate?
OK, I will test it tomorrow.
Regards, Hui.
I disabled the polling_mode and changed udelay(100) to udelay(521)/mdelay(521), the problem still can be reproduced.
Looks like only enabling polling_mode can fix this problem. extending delay after intel_ml_lctl_set_power(chip, 1); does not help fix this problem.
Thanks, that's what I expected. Will include the tentative fix with polling mode in the next pull request.
Takashi