lkml.org 
[lkml]   [1999]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDriver sync code; got it right?
I've been looking at this code (from a sound card driver) and the kernel
code for a while, but I'd like to be sure I understood it correctly:
(Some irrelevant driver specific stuff removed)

static int drain_dac1(struct es1370_state *s)
{
struct wait_queue wait = { current, NULL };
unsigned long flags;
current->state = TASK_INTERRUPTIBLE;
add_wait_queue(s->dma_dac1.wait, &wait);
for (;;) {
if (signal_pending(current))
break;
if (we_are_done_waiting)
break;
schedule_timeout( calculate_dma_timeout() );
}
remove_wait_queue(s->dma_dac1.wait, &wait);
current->state = TASK_RUNNING;
if (signal_pending(current))
return -ERESTARTSYS;
return 0;
}
This code is used by a sound card driver to wait for the playback buffer
to be played before returning. (Used by SNDCTL_DSP_SYNC, fileop
_release() etc...)

From what I've manage to understand from the kernel source,
TASK_INTERRUPTIBLE and the add_wait_queue() will cause this task to
sleep on the schedule_timeout() until someone (the irq handler in this
case) wakes it up, or schedule_timeout() times out. The signal_pending()
stuff is for that good ol' signal-while-in-kernel thing.

Did I miss something here?

The reason why I want the details here is that I'd like to make it as
simple as possible to convert this kind of code to the Linux/RTL driver
API, if possible by simply using functions with similar names and
identical arguments. The same code should work with RTL as well as
Linux, as far as possible.

Don't want my API to cause unpleasant surprizes when converting
drivers...


//David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans