From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55559C433DF for ; Thu, 11 Jun 2020 20:14:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 39E5C206C3 for ; Thu, 11 Jun 2020 20:14:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726386AbgFKUOn (ORCPT ); Thu, 11 Jun 2020 16:14:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:37980 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbgFKUOn (ORCPT ); Thu, 11 Jun 2020 16:14:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EA442ABCE; Thu, 11 Jun 2020 20:14:43 +0000 (UTC) Date: Thu, 11 Jun 2020 22:14:39 +0200 Message-ID: From: Takashi Iwai To: Ranjani Sridharan Cc: "Lu, Brent" , "alsa-devel@alsa-project.org" , Pierre-Louis Bossart DRIVERS , "authored:2/16=12%,added_lines:21/248=8%,removed_lines:5/84=6%,),Liam " "Girdwood DRIVERS )" , "commit_signer:6/16=38%,authored:6/16=38%,added_lines:123/248=50% ,removed_lines:36/84=43%,Kai " "Vehmanen DRIVERS )" , "Daniel Baluta DRIVERS )" , Mark Brown , Jaroslav Kysela , Takashi Iwai , "Rojewski, Cezary" , Zhu Yingjiang , Keyon Jie , Bard Liao , "sound-open-firmware@alsa-project.orgDRIVERS" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ASoC: SOF: Intel: hda: unsolicited RIRB response In-Reply-To: References: <1591883073-17190-1-git-send-email-brent.lu@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 11 Jun 2020 20:12:53 +0200, Ranjani Sridharan wrote: > > On Thu, 2020-06-11 at 19:59 +0200, Takashi Iwai wrote: > > On Thu, 11 Jun 2020 19:09:08 +0200, > > Lu, Brent wrote: > > > > > > > Hi Brent, > > > > > > > > Thanks for the patch. Is this fix for a specific issue you're > > > > seeing? > > > > If so, could you please give us some details about it? > > > > > > > > Thanks, > > > > Ranjani > > > > > > Hi Ranjani, > > > > > > It's reported to happen on GLK Chromebook 'Fleex' that sometimes it > > > cannot output the audio stream to external display. The kernel is > > > Chrome v4.14 branch. Following is the reproduce step provided by > > > ODM but I could reproduce it simply running aplay or > > > cras_test_client > > > so I think it's not about the cable plug/unplug handling. > > > > > > What steps will reproduce the problem? > > > 1. Play YouTube video on Chromebook and connect it to external > > > monitor with Type C to DP dongle > > > 2. Press monitor power button to turn off the monitor > > > 3. Press monitor power button again to turn on the monitor > > > 4. Continue to play YouTube video and check audio playback > > > 5. No sound comes out from built-in speaker of external > > > monitor when turn on external monitor > > > > > > I added debug messages to print the RIRBWP register and realize > > > that > > > response could come between the read of RIRBWP in the > > > snd_hdac_bus_update_rirb() function and the interrupt clear in the > > > hda_dsp_stream_interrupt() function. The response is not handled > > > but > > > the interrupt is already cleared. It will cause timeout unless more > > > responses coming to RIRB. > > > > Now I noticed that the legacy driver already addressed it recently > > via > > commit 6d011d5057ff > > ALSA: hda: Clear RIRB status before reading WP > > > > We should have checked SOF at the same time, too... > > Thanks, Takashi. But the legacy driver but doesnt remove the loop. The > loop added in the SOF driver was based on the legacy driver and > specifically to handle missed stream interrupts. Is there any harm in > keeping the loop? A loop there might be safer to keep, indeed. That's basically for a difference kind of race, and it can still happen theoretically. Though, SOF is with the threaded interrupt, and it's interesting how the behavior differs. I can imagine that, if a thread irq is running while a new IRQ is re-triggered, the hard irq handler won't queue it again. But I might be wrong here, need some checks. Takashi