[PATCH] ASoC: SOF: Intel: hda: unsolicited RIRB response

[Takashi Iwai]

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