[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <78c75ba0-a061-e7b0-dafb-c611d79f433f@sakamocchi.jp>
Date: Mon, 4 Sep 2017 21:45:32 +0900
From: Takashi Sakamoto <o-takashi@...amocchi.jp>
To: Takashi Iwai <tiwai@...e.de>
Cc: alsa-devel@...a-project.org, keescook@...omium.org,
peterz@...radead.org, linux-kernel@...r.kernel.org,
mingo@...hat.com, john.stultz@...aro.org, tglx@...utronix.de,
hch@....org, anna-maria@...utronix.de
Subject: Re: [PATCH 23/25] ALSA/dummy: Replace tasklet with softirq hrtimer
Hi,
On Sep 2 2017 10:19, Takashi Sakamoto wrote:
> Well, in sound subsystem, there're a few drivers which uses hrtimer:
> - snd-pcsp
> - snd-sh-dac-audio
> - snd-soc-imx-pcm-fiq
>
> As a quick glance, 'snd-sh-dac-audio' includes the same bug, too.
> Additionally, 'snd-soc-imx-pcm-fiq' maintains hrtimer with loose manner
> in a point of state of PCM substream and it shall gain the same bug if
> improved. Later, I posted some patches for them.
After reading code thoroughly, I conclude that no need to fix these two
drivers. They're programmed with own protections. The former
(snd-sh-dac-audio) has 'struct snd_sh_dac.empty' and the latter
(snd-soc-imx-pcm-fiq) has 'struct imx_pcm_runtime_data.playing' and
'.capturing', to avoid cancellation of hrtimer on hrtimer callback.
These ways are not necessarily efficient but actually have no trouble.
I leave them as is.
Regards
Takashi Sakamoto
Powered by blists - more mailing lists