[Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit
Chris Wilson
chris at chris-wilson.co.uk
Wed Jan 16 16:09:24 UTC 2019
Quoting Lionel Landwerlin (2019-01-16 16:02:51)
> On 16/01/2019 15:58, Lionel Landwerlin wrote:
> > On 16/01/2019 15:52, Chris Wilson wrote:
> >> Quoting Lionel Landwerlin (2019-01-16 15:36:20)
> >>> @@ -1877,6 +1883,21 @@ struct drm_i915_private {
> >>> wait_queue_head_t poll_wq;
> >>> bool pollin;
> >>> + /**
> >>> + * Atomic counter incremented by the interrupt
> >>> + * handling code for each OA half full
> >>> interrupt
> >>> + * received.
> >>> + */
> >>> + atomic64_t half_full_count;
> >>> +
> >>> + /**
> >>> + * Copy of the atomic half_full_count that
> >>> was last
> >>> + * processed in the i915-perf driver. If
> >>> both counters
> >>> + * differ, there is data available to read
> >>> in the OA
> >>> + * buffer.
> >>> + */
> >>> + u64 half_full_count_last;
> >> Eh? But why a relatively expensive atomic64. You only need one bit, and
> >> reading the tail pointer from WB memory should just be cheap. You should
> >> be able to sample the perf ringbuffer pointers very cheaply... What am I
> >> missing?
> >> -Chris
> >>
> > Fair comment.
> >
> > The thing is with this series there are 2 mechanism that notify the
> > poll_wq.
> >
> > One is the hrtimer that kicks in at regular interval and polls the
> > register with the workaround.
> >
> > The other is the interrupt which doesn't read the registers and
> > workaround.
>
>
> What I meant is that I need a way to know which one did the wake up so I
> can call oa_check_buffer() in the interrupt case, that's wait the
> atomic64 is there for.
I thought oa_check_buffer() was just "is there any data for me?"
-Chris
More information about the Intel-gfx
mailing list