linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering
Date: Tue, 30 Mar 2010 20:36:21 +0000	[thread overview]
Message-ID: <20100330133621.e897cdb5.akpm@linux-foundation.org> (raw)
In-Reply-To: <A24693684029E5489D1D202277BE89445316FAB1@dlee02.ent.ti.com>

On Mon, 29 Mar 2010 08:16:51 -0500
"Ambrose, Martin" <martin@ti.com> wrote:

> +/*
> + * Function to wait for vertical sync which for this LCD peripheral
> + * translates into waiting for the current raster frame to complete.
> + */
> +static int fb_wait_for_vsync(struct fb_info *info)
> +{
> +       struct da8xx_fb_par *par = info->par;
> +       wait_queue_t wq;
> +       int ret;
> +
> +       init_waitqueue_entry(&wq, current);

DECLARE_WAITQUEUE() would be more conventional.

> +       /*
> +        * Set flag to 0 and wait for isr to set to 1. It would seem there is a
> +        * race condition here where the ISR could have occured just before or
> +        * just after this set. But since we are just coarsely waiting for
> +        * a frame to complete then that's OK. i.e. if the frame completed
> +        * just before this code executed then we have to wait another full
> +        * frame time but there is no way to avoid such a situation. On the
> +        * other hand if the frame completed just after then we don't need
> +        * to wait long at all. Either way we are guaranteed to return to the
> +        * user immediately after a frame completion which is all that is
> +        * required.
> +        */
> +       par->vsync_flag = 0;
> +       ret = wait_event_interruptible_timeout(par->vsync_wait,
> +                                              par->vsync_flag != 0,
> +                                              par->vsync_timeout);

If the calling process has signal_pending() (say, someone hit ^C) then
wait_event_interruptible_timeout() will fall straight through with
-ERESTARTSYS.  Will this cause the driver to malfunction at all?


> +       if (ret < 0)
> +               return ret;
> +       if (ret = 0)
> +               return -ETIMEDOUT;
> +
> +       return 0;
> +}

  reply	other threads:[~2010-03-30 20:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 13:16 [PATCH v2] DA8XX/OMAP-L1XX: FB: Implement double buffering Ambrose, Martin
2010-03-30 20:36 ` Andrew Morton [this message]
2010-04-01  0:32 ` Andrew Morton
2010-04-01  1:43 ` Ambrose, Martin
2010-04-01  6:47 ` Jon Povey
2010-04-04 16:49 ` Ambrose, Martin
2010-04-04 16:51 ` Ambrose, Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100330133621.e897cdb5.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).