Question about device recovery when under/over run error case

Question about device recovery when under/over run error case

[Kuninori Morimoto]

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 ?

Re: Question about device recovery when under/over run error case

[Takashi Sakamoto]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Question about device recovery when under/over run error case

[Kuninori Morimoto]

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.

Re: Question about device recovery when under/over run error case

[Takashi Iwai]

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

Re: Question about device recovery when under/over run error case

[Kuninori Morimoto]

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.

Re: Question about device recovery when under/over run error case

[Takashi Sakamoto]

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.html


Regards

Takashi Sakamoto

Re: Question about device recovery when under/over run error case

[Kuninori Morimoto]

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.html

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 ?

Re: Question about device recovery when under/over run error case

[Takashi Sakamoto]

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.html
>
> 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

Re: Question about device recovery when under/over run error case

[Kuninori Morimoto]

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.html
> >
> > 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

Re: Question about device recovery when under/over run error case

[Takashi Sakamoto]

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/sh/rcar/core.c#n501

It's my concern since I did read your codes.


Regards

Takashi Sakamoto

Re: Question about device recovery when under/over run error case

[Kuninori Morimoto]

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/sh/rcar/core.c#n501

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" ?

Re: Question about device recovery when under/over run error case

[Takashi Sakamoto]

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/sh/rcar/core.c#n501
>
> 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