[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b170af451002260933i6a7a5e1el619f8e71c3ae0bc8@mail.gmail.com>
Date: Fri, 26 Feb 2010 18:33:57 +0100
From: Rafał Miłecki <zajec5@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
DRI <dri-devel@...ts.sourceforge.net>
Subject: Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep
(w. timeout) until wake_up
W dniu 26 lutego 2010 17:14 użytkownik Andrew Morton
<akpm@...ux-foundation.org> napisał:
> On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki <zajec5@...il.com> wrote:
>
>> +#define wait_interruptible_timeout(wq, timeout)
>> \
>> +({ \
>> + long ret = timeout; \
>> + \
>> + DEFINE_WAIT(wait); \
>> + prepare_to_wait(&wq, &wait, TASK_INTERRUPTIBLE); \
>> + if (!signal_pending(current)) \
>> + ret = schedule_timeout(ret); \
>> + finish_wait(&wq, &wait); \
>> + \
>> + ret; \
>> +})
>
> It's often a mistake to use signals in-kernel. Signals are more a
> userspace thing and it's better to use the lower-level kernel-specific
> messaging tools in-kernel. Bear in mind that userspace can
> independently and asynchronously send, accept and block signals.
Can you point me to something kernel-level please?
> Can KMS use wait_event_interruptible_timeout()?
No. Please check definition of this:
#define wait_event_interruptible_timeout(wq, condition, timeout) \
({ \
long __ret = timeout; \
if (!(condition)) \
__wait_event_interruptible_timeout(wq, condition, __ret); \
__ret; \
})
It uses condition there, but that's not a big issue. We just need to
pass 0 (false) there and it will work so far.
But then check __wait_event_interruptible_timeout definition, please.
It goes into sleep and after waking up it checks for value returned by
schedule_timeout. That's what breaks our (needed by radeon) sleeping.
If timeout didn't expire it does into sleep again!
What we need is continue reclocking after waking up. If this has
happend before timeout expired, that means we was woken up by VBLANK
interrupt handler. We love that situation and we do not want to go
sleep again.
On the other hand we need to have some timeout in case VBLANK
interrupt won't come.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists