W dniu 26 lutego 2010 17:14 użytkownik Andrew Morton
<a...@linux-foundation.org> napisał:
> On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki <zaj...@gmail.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ł

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to