Re: [PATCH] Video : Amba: Use in_interrupt() in clcdfb_sleep().

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Sun, Mar 11, 2012 at 10:27:12PM +0530, santosh prasad nayak wrote:
> Russel,
> 
> Is this what you want ?
> 
>  static inline void clcdfb_sleep(unsigned int ms)
>  {
> -       if (in_atomic()) {
>                 mdelay(ms);
> -       } else {
> -               msleep(ms);
> -       }
>  }

"want" is a strong word - I would not say "want" because I don't want the
system busy-spinning for 20ms at a time during normal blank and unblank
events preventing any other thread in the system from running.

Looking at do_unblank_screen() in drivers/tty/vt/vt.c:

/*
 * Called by timer as well as from vt_console_driver
 */
void do_unblank_screen(int leaving_gfx)
{
        struct vc_data *vc;

        /* This should now always be called from a "sane" (read: can schedule)
         * context for the sake of the low level drivers, except in the special
         * case of oops_in_progress
         */
        if (!oops_in_progress)
                might_sleep();

There may be another option of changing in_atomic() to be oops_in_progress()
if that comment is to be believed.  However, that comment conflicts with
the comment immediately above the function.  That said, the code is more
authorative than the comment above it because if that comment were true,
we'd see might_sleep() warnings.

So, I suspect:

 static inline void clcdfb_sleep(unsigned int ms)
 {
-       if (in_atomic()) {
+       if (oops_in_progress) {
                mdelay(ms);
        } else {
                msleep(ms);

is about the best that can be hoped for.

However, I think framebuffer people need to comment about what contexts
a framebuffer driver's fb_blank method would be called from (including
when oops-dumping.)