[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Daniel Vetter]

On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> ville.syrjala at linux.intel.com> wrote:
> 
> > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > On 26 Oct 2016 9:54 a.m., "Chris Wilson" <chris at chris-wilson.co.uk>
> > wrote:
> > > >
> > > > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > > > >    On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > > > >    <[1]matthew.william.auld at gmail.com> wrote:
> > > > >
> > > > >      On 25 October 2016 at 00:19, Robert Bragg <[2]
> > robert at sixbynine.org>
> > > > >      wrote:
> > > > >
> > > > >
> > > > >
> > > > >      > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > >      b/drivers/gpu/drm/i915/i915_drv.h
> > > > >      > index 3448d05..ea24814 100644
> > > > >      > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > >      > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > >      > @@ -1764,6 +1764,11 @@ struct intel_wm_config {
> > > > >
> > > > >      >
> > > > >      >  struct drm_i915_private {
> > > > >      > @@ -2149,16 +2164,46 @@ struct drm_i915_private {
> > > > >      >
> > > > >      >         struct {
> > > > >      >                 bool initialized;
> > > > >      > +
> > > > >      >                 struct mutex lock;
> > > > >      >                 struct list_head streams;
> > > > >      >
> > > > >      > +               spinlock_t hook_lock;
> > > > >      > +
> > > > >      >                 struct {
> > > > >      > -                       u32 metrics_set;
> > > > >      > +                       struct i915_perf_stream
> > > *exclusive_stream;
> >
> > OT:
> > What kind of MUA are you using that mangles quoted mails like this? I've
> > not seen it on intel-gfx before. mesa-dev seems rife with it, but as I
> > rarely read that in any great detail I've managed to ignore it there.
> > Anyways, it makes it espesially hard to navigate long mails since mutt's
> > 'S' (skip quoted text) no longer works correctly.
> >
> 
> Not sure I want to say, and get booted out the door :-)
> 
> I've heard that gmail has an annoying habit of forcibly wrapping plain text
> emails like this, and a lot of people have complained that there's no way
> to disable that 'feature' :-/
> 
> I used to use Mutt, but I don't think I could really bare to go back to it
> any more. Last time I was using it I found myself spending too much time
> patching it to try and make it work how I'd like, but can't say I got much
> enjoyment from that process.
> 
> I've tried most MUA options available, and can't say any of them make me
> very happy - I think these days it's just not something developers are very
> interesting in working on.
> 
> I'm a sell out and just use Gmail... sorry. I can't really see myself
> changing, though I do wish Google weren't so pedantic about forcing
> wrapping without any option to change that behaviour. I suspect you
> wouldn't be happy with me sending html emails, which has been Google's
> default response to this complaint afik.
> 
> Maybe it's gmail users causing trouble on the Mesa list too.
> 
> - Robert
> 
> P.S please don't think lesser of me due to my misguided MUA choices.

I use a mix of mutt+gmail web interface, since each has their upsides.
Haven't yet seen badly misquoted stuff, I think it mostly seems to work
for me. And there's lots of kernel folks who use gmail too afaik.
-Daniel

> 
> 
> 
> >
> > > > >      > +
> > > > >      > +                       u32 specific_ctx_id;
> > > > >      Can we just get rid of this, now that the vma remains pinned we
> > can
> > > > >      simply get the ggtt address at the time of configuring the
> > > OA_CONTROL
> > > > >      register ?
> > > > >
> > > > >    I considered that, but would ideally prefer to keep it considering
> > > the
> > > > >    gen8+ patches to come. For gen8+ (with execlists) the context ID
> > > isn't a
> > > > >    gtt offset.
> > > >
> > > > In terms of symmetry, keeping the vma you pinned and unpinning the same
> > > > later makes its ownership much clearer. (And I do want the owner of
> > each
> > > > pin to be clear, for when we start enabling debug to catch the VMA
> > > > leaks.)
> > >
> > > Keeping our own pointer to the pinned vma could be a clarification.
> > >
> > > Considering Matt's comments too, I'm thinking I'll put the pinning and
> > > specific_ctx_id initialization together with setting stream->ctx, keeping
> > > the state together under the stream. It's going to potentially mean
> > > redundantly pinning the ctx for the sake of the ID in the future for
> > > streams that don't really need it, but I think it's probably not worth
> > > worrying about that.
> > >
> > > - Robert
> > >
> > > > -Chris
> > > >
> > > > --
> > > > Chris Wilson, Intel Open Source Technology Centre
> >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> >

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch