From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Arun Murthy <arunrmurthy.83@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v8 3/9] drm/i915: Make sprite updates atomic
Date: Mon, 19 May 2014 13:46:57 +0300 [thread overview]
Message-ID: <20140519104657.GY27580@intel.com> (raw)
In-Reply-To: <CAAnUQp1Qm67GoMUYU7y4TxmxZAaTXtkehi-E+ddSwvvg_8oXBw@mail.gmail.com>
On Mon, May 19, 2014 at 02:49:59PM +0530, Arun Murthy wrote:
> Add a mechanism by which we can evade the leading edge of vblank. This
> guarantees that no two sprite register writes will straddle on either
> side of the vblank start, and that means all the writes will be latched
> together in one atomic operation.
>
> Here only one sprite update followed by the primary enable/disable can be
> achieved atomically. But I feel update of all planes are to be considered,
> i.e
> update of planes per pipe basis to achieve atomicity.
>
>
> We do the vblank evade by checking the scanline counter, and if it's too
> close to the start of vblank (too close has been hardcoded to 100usec
> for now), we will wait for the vblank start to pass. In order to
> eliminate random delayes from the rest of the system, we operate with
> interrupts disabled, except when waiting for the vblank obviously.
>
> This can be achieved easily by checking the previous vblank time in
> drm_get_last_vblanktimestamp(), using this the next vblank time cab be
> predicted. Using these with the hardcoded value 100usec, a check can be
> made to continue or to wait for a vblank. For waiting for a vblank instead
> of adding new function just use the available intel_wait_for_vblank().
>
> last_vblank = drm_get_last_vblanktimestamp();
> curr_time = do_getttimeofday();
> if ((last_vblank + VBLANK_TIME_INTERVAL) - curr_time.tv_usec > 100)
> /* acquire lock and proceed*/
> else
> /* wait for one vblank, acquire lock and proceed */
Sure, if your aim is to make it less robust.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-05-19 10:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 9:19 [PATCH v8 3/9] drm/i915: Make sprite updates atomic Arun Murthy
2014-05-19 10:46 ` Ville Syrjälä [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-04-29 10:35 [PATCH v4 0/9] drm/i915: Atomic sprites v4 ville.syrjala
2014-04-29 10:35 ` [PATCH v8 3/9] drm/i915: Make sprite updates atomic ville.syrjala
[not found] ` <CAHofq8MHrbki1XtXeMZGSDSABnu4LUkZDfbYWCvU5Nng0AjM5g@mail.gmail.com>
2014-05-19 10:49 ` Murthy, Arun R
2014-05-19 10:57 ` G, Pallavi
2014-05-22 13:03 ` Daniel Vetter
2014-05-22 13:24 ` Ville Syrjälä
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=20140519104657.GY27580@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=arunrmurthy.83@gmail.com \
--cc=intel-gfx@lists.freedesktop.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