[alsa-devel] Question about device recovery when under/over run error case
Hi Mark
Our sound device needs recovery if under/over run error happen. Basically, this "recovery" means "restart hardware". But, in such case, who should recovers sound device, Kernel or Userland ?
Current our sound driver recovers it by kernel automatically. (But I need do work more for it)
We considered that userland should know it, or, run it by himself (?) If userland should do it, which function should be called to announce error to userland from kernel ?
Hi,
I'm not Mark but might answer it.
On 2016年01月18日 13:45, Kuninori Morimoto wrote:
Our sound device needs recovery if under/over run error happen. Basically, this "recovery" means "restart hardware". But, in such case, who should recovers sound device, Kernel or Userland ?
Current our sound driver recovers it by kernel automatically. (But I need do work more for it)
I think you should not recover it in kernel space, because 'hw_ptr' in mapped page includes values unexpected by userspace application. (The value may suddenly jump up to unexpected value after recovered.)
What driver in kernel land is to notify XRUN to the applications in your case. If recovering processing includes event waiting, it should not be executed in interrupt context.
We considered that userland should know it, or, run it by himself (?) If userland should do it, which function should be called to announce error to userland from kernel ?
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
Regards
Takashi Sakamoto
Hi Sakamoto-san
Thank you for your feedback
Our sound device needs recovery if under/over run error happen. Basically, this "recovery" means "restart hardware". But, in such case, who should recovers sound device, Kernel or Userland ?
Current our sound driver recovers it by kernel automatically. (But I need do work more for it)
I think you should not recover it in kernel space, because 'hw_ptr' in mapped page includes values unexpected by userspace application. (The value may suddenly jump up to unexpected value after recovered.)
What driver in kernel land is to notify XRUN to the applications in your case. If recovering processing includes event waiting, it should not be executed in interrupt context.
We considered that userland should know it, or, run it by himself (?) If userland should do it, which function should be called to announce error to userland from kernel ?
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose. I will try to investigate it.
On Mon, 18 Jan 2016 07:04:03 +0100, Kuninori Morimoto wrote:
Hi Sakamoto-san
Thank you for your feedback
Our sound device needs recovery if under/over run error happen. Basically, this "recovery" means "restart hardware". But, in such case, who should recovers sound device, Kernel or Userland ?
Current our sound driver recovers it by kernel automatically. (But I need do work more for it)
I think you should not recover it in kernel space, because 'hw_ptr' in mapped page includes values unexpected by userspace application. (The value may suddenly jump up to unexpected value after recovered.)
What driver in kernel land is to notify XRUN to the applications in your case. If recovering processing includes event waiting, it should not be executed in interrupt context.
We considered that userland should know it, or, run it by himself (?) If userland should do it, which function should be called to announce error to userland from kernel ?
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose.
Right. But beware of locking by this function. Unlike snd_pcm_stop() this function takes the stream lock by itself.
Takashi
Hi Iwai-san
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose.
Right. But beware of locking by this function. Unlike snd_pcm_stop() this function takes the stream lock by itself.
Thanks ! I see. I will investigate it.
Hi,
On Jan 19 2016 09:04, Kuninori Morimoto wrote:
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose.
Right. But beware of locking by this function. Unlike snd_pcm_stop() this function takes the stream lock by itself.
Thanks ! I see. I will investigate it.
The 'lock' is what I mentioned in former message to you:
[alsa-devel] Can I stop sound from driver as system error ? http://mailman.alsa-project.org/pipermail/alsa-devel/2015-December/102010.ht...
Regards
Takashi Sakamoto
Hi Sakamoto-san
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose.
Right. But beware of locking by this function. Unlike snd_pcm_stop() this function takes the stream lock by itself.
Thanks ! I see. I will investigate it.
The 'lock' is what I mentioned in former message to you:
[alsa-devel] Can I stop sound from driver as system error ? http://mailman.alsa-project.org/pipermail/alsa-devel/2015-December/102010.ht...
Yes, I had asked same question to ML, I'm sorry about that. And, can I confirm about your concern ? I guess you are worrying about dead-lock by stop xrun, but is that correct ?
Hi,
On Jan 19 2016 12:08, Kuninori Morimoto wrote:
Userspace can get to know the XRUN state by calling some APIs. Then, it can recover PCM substream by executing SNDRV_PCM_IOCTL_PREPARE ioctl.
I think we can use snd_pcm_stop_xrun() for this purpose.
Right. But beware of locking by this function. Unlike snd_pcm_stop() this function takes the stream lock by itself.
Thanks ! I see. I will investigate it.
The 'lock' is what I mentioned in former message to you:
[alsa-devel] Can I stop sound from driver as system error ? http://mailman.alsa-project.org/pipermail/alsa-devel/2015-December/102010.ht...
Yes, I had asked same question to ML, I'm sorry about that. And, can I confirm about your concern ? I guess you are worrying about dead-lock by stop xrun, but is that correct ?
Recent SoC tends to accumurate much IPs with variety functionalities.
If your SoC, R-Car, has such IPs and snd-soc-rcar utilize it, I can assume that snd-soc-rcar require to wait for some events after operating to the IPs. Or snd-soc-rcar require to manage race conditions between many PCM substreams.
In this case, current structure of snd-soc-rcar may cause problems (at least, in the end of last year), because it pushes many operations into 'struct snd_pcm_ops.trigger'. This callback is executed in both of process context and interrupt context and drivers should not wait for events or should not manage race conditions.
This is my concern about it.
Regards
Takashi Sakamoto
Hi Sakamoto-san
The 'lock' is what I mentioned in former message to you:
[alsa-devel] Can I stop sound from driver as system error ? http://mailman.alsa-project.org/pipermail/alsa-devel/2015-December/102010.ht...
Yes, I had asked same question to ML, I'm sorry about that. And, can I confirm about your concern ? I guess you are worrying about dead-lock by stop xrun, but is that correct ?
Recent SoC tends to accumurate much IPs with variety functionalities.
If your SoC, R-Car, has such IPs and snd-soc-rcar utilize it, I can assume that snd-soc-rcar require to wait for some events after operating to the IPs. Or snd-soc-rcar require to manage race conditions between many PCM substreams.
In this case, current structure of snd-soc-rcar may cause problems (at least, in the end of last year), because it pushes many operations into 'struct snd_pcm_ops.trigger'. This callback is executed in both of process context and interrupt context and drivers should not wait for events or should not manage race conditions.
Thank you for explaining detail of your concern. I believe snd-soc-rcar is OK at this point, but of course not sure in the future. I will keep considering your advice, and fix any problems step-by-step. Thanks again
On Jan 19 2016 13:42, Kuninori Morimoto wrote:
I believe snd-soc-rcar is OK at this point,
Could I request you to explain about usage of this lock primitive in SoC with a few cores (i.e. 2) when dts allows the driver to handle several PCM substreams and userspace applications try to use the PCM substreams almost the same time? http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/s...
It's my concern since I did read your codes.
Regards
Takashi Sakamoto
Hi Sakamoto-san
Could I request you to explain about usage of this lock primitive in SoC with a few cores (i.e. 2) when dts allows the driver to handle several PCM substreams and userspace applications try to use the PCM substreams almost the same time? http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/s...
Your concern is that my driver is using "trigger", and it will be called from several context. Indeed, one side might be locked if few substreams are used in same time, because it is using shared lock. But, I think I need to use it since it is using shared register. And, I'm confusing that what is the problem in this case ? Do you mean I shoudn't use "trigger" ?
Hi,
On Jan 20 2016 10:17, Kuninori Morimoto wrote:
Could I request you to explain about usage of this lock primitive in SoC with a few cores (i.e. 2) when dts allows the driver to handle several PCM substreams and userspace applications try to use the PCM substreams almost the same time? http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/s...
Your concern is that my driver is using "trigger", and it will be called from several context. Indeed, one side might be locked if few substreams are used in same time, because it is using shared lock.
Background: current Linux kernel don't execute kernel preemption in interrupt contexts. For further information, please follow to CONFIG_PREEMPT_RT patchset project. https://rt.wiki.kernel.org/
When using spin_lock_irqsave() in any context, processor core local is under: * kernel preemption disable * software IRQ disable * hardware IRQ disable
When the process context is in the critical section of the code, the other process contexts can spin over each core with the state.
In a processor with a few cores, which cores can handle _any_ hardware interrupts? It may be quite a short time in your case but...
Althogh I don't know exactly how your SoC controls hardware interrupts, I'm concern about this situation based on my understanding of typical embedded platform. If I misunderstand anything, please inform it to me to update my knowledgement.
But, I think I need to use it since it is using shared register. And, I'm confusing that what is the problem in this case ? Do you mean I shoudn't use "trigger" ?
I don't exactly know about for which purpose the SoC is used and what constitution the SoC actually have. Here, I suggest a possible scenarioin of your future:
The snd-rcar-soc gets more 'struct rsnd_mod' to use IPs in the SoC and some operations are executed the .trigger(). The .trigger() takes a bit long. During the time, the local CPU cannot handle any hardware interrupts. In this situation, the other process context enters the critical section by userspace applications. These contexts spin over cores, and all of cores cannot handle hardware interrupts. As a result, no hardware interrupts cannot be handled. This causes a response latency of the system in a certain situation which is hard to be identified.
Well, I think it better to do it in 'struct snd_pcm_ops.prepare()' callback, because it runs in process contexts and any lock primitives with interrupts-enabled state are available (i.e. mutex). It's better for cheap embedded platforms.
Takashi Sakamoto
participants (3)
-
Kuninori Morimoto -
Takashi Iwai -
Takashi Sakamoto