[Intel-gfx] [PATCH 2/4] drm/i915: Always clear semaphore mboxes on seqno wrap

[Chris Wilson]

On Tue, 18 Dec 2012 16:19:52 +0200, Mika Kuoppala <mika.kuoppala at linux.intel.com> wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > On Mon, 17 Dec 2012 18:44:27 +0200, Mika Kuoppala <mika.kuoppala at linux.intel.com> wrote:
> >> We need to clear the hw semaphore values explicitly.
> >> Even if sync_seqnos are zero, there might still be
> >> invalid values in the hw semaphores when we wrap.
> >
> > This changelog does not make it clear why you want this patch. This is
> > for enabling a future feature, right?
> >
> > Anyway, after initial misgivings because I thought you were trying to
> > fix a bug rather than add a feature, and provided that you improve the
> > changelog,
> 
> The intent is to always clear the mboxes and also set the hws page when
> seqno is set. Both when wrapping and setting seqno from debugfs. 
> The hws part is needed to fix a bug where initial seqno in hws page is
> zero (after boot) and driver seqno is past the 2^31 boundary.
> I guess i could have split the mboxes and hws page setting apart
> saving the optimization but the gain would be little.
> 
> I think this is also issue on suspend/resume if we have passed 2^31 on
> suspend and we come back with driver setting initial seqno to 1.
> 
> In both cases i915_seqno_passed(ring->get_seqno(), driver_seqno) will
> return errorneous value.
> 
> > Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> > -Chris
> 
> Does r-b still stand after the explanation above?

Not really, that's an explanation for the series (setting initial seqno
values was incomplete, we needed to adjust the hw side as well as our
bookkeeping). But it doesn't explain why you want to change
i915_gem_seqno_handle_wrap() in this patch, which as far as I can tell
is because you want to reuse it later for a more general purpose.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre