[PATCH] cs46xx update SMP fixes

[PATCH] cs46xx update SMP fixes

[Benny Sjostrand]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

Hi!

In my prev. patch I've missed a up(...) call with no good consequences, 
however only affects
when looking in /proc.

Finally, just use this one instead.

/Benny

PS. see my previous mail for details.

[-- Attachment #2: cs46xx_patch --]
[-- Type: application/x-java-vm, Size: 32537 bytes --]

Re: [PATCH] cs46xx update SMP fixes

[Takashi Iwai]

Hi,

At Thu, 22 Aug 2002 11:59:41 +0200,
Benny Sjostrand wrote:
> 
> Hi!
> 
> In my prev. patch I've missed a up(...) call with no good consequences, 
> however only affects
> when looking in /proc.
> 
> Finally, just use this one instead.
> 
> /Benny
> 
> PS. see my previous mail for details.

could you rewrite mutex with spinlock if not too long held?

you cannot use mutex on trigger since this could be called from
interrupt handlers, too (in order to stop the stream when xrun is
detected).


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: [PATCH] cs46xx update SMP fixes

[Benny Sjostrand]

>
>
>could you rewrite mutex with spinlock if not too long held?
>
>you cannot use mutex on trigger since this could be called from
>interrupt handlers, too (in order to stop the stream when xrun is
>detected).
>
I believe that the critical sections are too long and will lose to much 
performance
on a SMP machines that's why i've choose the mutex instead of spin_locks.
However, that the trigger functions could be called from interrupt 
context is new to me,
thanks to pointing it out.
Mutexes are used in _trigger function in current CVS too, not directly 
in trigger function,
but in _link and _unlink function called by _trigger, and SMP is broken, 
so in  some
way we need to fix it.

I'll try to come with another solution, if you have any suggestion how 
to solve it, then great.

/Benny





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: [PATCH] cs46xx update SMP fixes

[Takashi Iwai]

At Thu, 22 Aug 2002 15:33:05 +0200,
Benny Sjostrand wrote:
> 
> >
> >
> >could you rewrite mutex with spinlock if not too long held?
> >
> >you cannot use mutex on trigger since this could be called from
> >interrupt handlers, too (in order to stop the stream when xrun is
> >detected).
> >
> I believe that the critical sections are too long and will lose to much 
> performance
> on a SMP machines that's why i've choose the mutex instead of spin_locks.
> However, that the trigger functions could be called from interrupt 
> context is new to me,
> thanks to pointing it out.
> Mutexes are used in _trigger function in current CVS too, not directly 
> in trigger function,
> but in _link and _unlink function called by _trigger, and SMP is broken, 
> so in  some
> way we need to fix it.
> 
> I'll try to come with another solution, if you have any suggestion how 
> to solve it, then great.

how about to do pcm_link/unlink in open/close or prepare callback?
they are definitely not called from interrupts.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: [PATCH] cs46xx update SMP fixes

[Benny Sjostrand]

>
>
>how about to do pcm_link/unlink in open/close or prepare callback?
>they are definitely not called from interrupts.
>
The idea of calling  pcm_unlink in trigger (PLAYBACK_STOP) function is 
to stop the DMA tranfers,
and so on stop the  DSP from requesting interrupts, and still have the 
channel prepared
to be quickly started again on trigger (PLAYBACK_START/RESUME).

Another idea  that I have in mind is to use in_interrupt() && 
schedule_task() functions, then if _trigger
function is called from interrupt context, mute/unmute pcm channel,  use 
schedule_task() to
indirectly invoke pcm_link/unlink. Otherwise if not in interrupt context 
call pcm_link/unlnk
directly using mutexes.
What do you think ?

/Benny




-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: [PATCH] cs46xx update SMP fixes

[Takashi Iwai]

At Thu, 22 Aug 2002 16:13:07 +0200,
Benny Sjostrand wrote:
> 
> >
> >
> >how about to do pcm_link/unlink in open/close or prepare callback?
> >they are definitely not called from interrupts.
> >
> The idea of calling  pcm_unlink in trigger (PLAYBACK_STOP) function is 
> to stop the DMA tranfers,
> and so on stop the  DSP from requesting interrupts, and still have the 
> channel prepared
> to be quickly started again on trigger (PLAYBACK_START/RESUME).
 
how about to make the list of free scbs so that the free scb can be
found without loop?  also, doulbe linked lists would be more feasible
for such frequent insert/deletion.


> Another idea  that I have in mind is to use in_interrupt() && 
> schedule_task() functions, then if _trigger
> function is called from interrupt context, mute/unmute pcm channel,  use 
> schedule_task() to
> indirectly invoke pcm_link/unlink. Otherwise if not in interrupt context 
> call pcm_link/unlnk
> directly using mutexes.
> What do you think ?

but this may introduce the inconsistent status until the scheduled
task is really called.

i think the best way is to shorten the code path of trigger callback.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: [PATCH] cs46xx update SMP fixes

[Takashi Iwai]

At Thu, 22 Aug 2002 20:21:21 +0200,
Benny Sjostrand wrote:
> 
> 
> 
> >how about to make the list of free scbs so that the free scb can be
> >found without loop?  also, doulbe linked lists would be more feasible
> >for such frequent insert/deletion.
> >
> I dont known if I understand you, the SCB tree is already like a big 
> complex double linked
> list. However they are stored in a array.

yes, i figured out it later, too.  sorry for confusion.


> >
> >but this may introduce the inconsistent status until the scheduled
> >task is really called.
> >
> >i think the best way is to shorten the code path of trigger callback.
> >
> I agree that it may not be the best solution, I believe it can work but 
> will end up
> in a dirty hack.

basically trigger callback should be as short as possible, because
it's called just at the time you want to "start" the playback.
semaphore or schedule in trigger may cause unexpected long delay
(except for the problem that it can be called by interrupt handlers).


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390