Re: [PATCH igt 2/3] igt/perf_pmu: Stop peeking at intel_mmio registers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Tvrtko Ursulin (2017-11-24 08:55:13)
> 
> On 23/11/2017 08:22, Chris Wilson wrote:
> > @@ -522,51 +524,52 @@ event_wait(int gem_fd, const struct intel_execution_engine2 *e)
> >        * listen to the recorded time spent in engine wait state as reported
> >        * by the PMU.
> >        */
> > -     reg = intel_register_read(DERRMR);
> > -
> > -     kmstest_set_vt_graphics_mode();
> > -     igt_display_init(&data.display, gem_fd);
> > -
> > -     bb_handle = gem_create(gem_fd, 4096);
> > +     obj.handle = gem_create(gem_fd, 4096);
> >   
> >       b = batch;
> >       *b++ = MI_LOAD_REGISTER_IMM;
> > +     *b++ = FORCEWAKE_MT;
> > +     *b++ = 2 << 16 | 2;
> > +     *b++ = MI_LOAD_REGISTER_IMM;
> >       *b++ = DERRMR;
> > -     *b++ = reg & ~((1 << 3) | (1 << 11) | (1 << 21));
> > -     *b++ = MI_WAIT_FOR_EVENT | MI_WAIT_FOR_PIPE_A_VBLANK;
> > +     *b++ = ~0u;
> > +     *b++ = MI_WAIT_FOR_EVENT;
> >       *b++ = MI_LOAD_REGISTER_IMM;
> >       *b++ = DERRMR;
> > -     *b++ = reg;
> > +     *b++ = ~0u;
> > +     *b++ = MI_LOAD_REGISTER_IMM;
> > +     *b++ = FORCEWAKE_MT;
> > +     *b++ = 2 << 16;
> >       *b++ = MI_BATCH_BUFFER_END;
> >   
> It looks fine apart from the assumption that DERRMR always have to 
> remain at default ~0. Worst I can imagine is that in the future we have 
> to make this test force disconnect all displays, should some of the 
> reserved bits be used for something which we will be turning on by default.

I think more of the HW designers than that they will require routing
Display Engine messages to the Render Ring at all times! What are we
going to do with the messages we are not using in our batches? ;)

I believe the point of disabling it by default was that it was causing a
coupling between different powerwells across the other side of the chip,
and so we had to explicitly enable messages we wanted in the batch. I
don't imagine that they will stuff a different meaning into it, rather
they will just scrap it and start again (like every other gen).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux