wait_event and interrupts

wait_event and interrupts

[Rune Torgersen]

Hi
I have a driver that roughly does something like:

int driver_read(int cs, int addr, void *buf, int len)
{
    hw_done =3D 0;
    /* init_hw */

    if (!hw_done)
    {
        ret =3D wait_event_interruptible_timeout(inq, hw_done, TIMEOUT);
        if (ret =3D=3D 0)
        {
            if (hw_done)
                goto hw_finished;
		=09
            return -EIO;
        }
    }
hw_finished:
    return len;
}

static irqreturn_t myinterrupt(int irq, void * dev_id, struct pt_regs *
regs)
{
    hw_done =3D 1;
    schedule_work(&tqueue);

    return IRQ_HANDLED;
}

static void do_softint(void *private_)
{
    wake_up_interruptible(&inq);

}

I have a problem however with this, because in about 10% of my cases,
the interrupt triggers very fast, and ends up being served between the
check for hw_done and the wait_event call. This cause the wait to
timeout instead of getting waked up.

Is there a better way of doing this?
I do not want to do a busy wait, because the hardware can take up to
several 100's of ms to return, but most often returns within 20us.

Re: wait_event and interrupts

[Jeff Angielski]

On Tue, 2005-09-20 at 12:56 -0500, Rune Torgersen wrote:

> Is there a better way of doing this?

If you *must* share the variable between interrupt and non-interrupt
context, you must mutex it in an interrupt safe way.  The use of
spin_lock_irqsave() comes to mind for you read function.

But you are going to have other problems with this approach anyways
since you "appear" to be assuming a one-to-one relationship between your
interrupt handler and the read function.  Is that really true?

Jeff Angielski
The PTR Group

Re: wait_event and interrupts

[Kalle Pokki]

Rune Torgersen wrote:

>Hi
>I have a driver that roughly does something like:
>
>int driver_read(int cs, int addr, void *buf, int len)
>{
>    hw_done = 0;
>    /* init_hw */
>
>    if (!hw_done)
>    {
>        ret = wait_event_interruptible_timeout(inq, hw_done, TIMEOUT);
>        if (ret == 0)
>        {
>            if (hw_done)
>                goto hw_finished;
>			
>            return -EIO;
>        }
>    }
>hw_finished:
>    return len;
>}
>
>static irqreturn_t myinterrupt(int irq, void * dev_id, struct pt_regs *
>regs)
>{
>    hw_done = 1;
>    schedule_work(&tqueue);
>
>    return IRQ_HANDLED;
>}
>
>static void do_softint(void *private_)
>{
>    wake_up_interruptible(&inq);
>
>}
>
>I have a problem however with this, because in about 10% of my cases,
>the interrupt triggers very fast, and ends up being served between the
>check for hw_done and the wait_event call. This cause the wait to
>timeout instead of getting waked up.
>
>Is there a better way of doing this?
>I do not want to do a busy wait, because the hardware can take up to
>several 100's of ms to return, but most often returns within 20us.
>  
>
You seem to create an unnecessary race condition by checking the hw_done 
variable in the read function. You can avoid this by changing it to

int driver_read(int cs, int addr, void *buf, int len)
{
    hw_done = 0;
    /* init_hw */

    if (wait_event_interruptible_timeout(inq, hw_done, TIMEOUT))
	return -ERESTARTSYS;

    hw_done = 0;

    /* copy the data to user space here */

    return len;
}

The wait_event_interruptible_timeout() function checks the variable for 
you. You still must make sure the read function does the right thing if 
it is called simultaneously by more than one application.

RE: wait_event and interrupts

[Rune Torgersen]

> -----Original Message-----
> From: Jeff Angielski [mailto:jeff@theptrgroup.com]=20
> Sent: Tuesday, September 20, 2005 13:40
> On Tue, 2005-09-20 at 12:56 -0500, Rune Torgersen wrote:
>=20
> > Is there a better way of doing this?
>=20
> If you *must* share the variable between interrupt and non-interrupt
> context, you must mutex it in an interrupt safe way.  The use of
> spin_lock_irqsave() comes to mind for you read function.

The shared variable is an int, which should be atomic to access anyways.
Someone else told me to try to set the shared variable to volatile.

> But you are going to have other problems with this approach anyways
> since you "appear" to be assuming a one-to-one relationship=20
> between your
> interrupt handler and the read function.  Is that really true?
Yes. The read function starts the hardware, and the hardware responds
with an interrupt when it's done.