[Intel-gfx] [PATCH] drm/i915: read/write IOCTLs

[Chris Wilson]

On Fri, 01 Apr 2011 11:51:23 -0700, Eric Anholt <eric at anholt.net> wrote:
> On Fri, 01 Apr 2011 08:32:09 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > I'm just not happy about haphazard locking. Can we do simple and safe
> > locking and revisit it if a real use-case for brute-forcing the read/write
> > is found?
> 
> The concern we had was "I want to be sure that when the GPU is hung we
> can still reg_dump so people can write bug reports.  The mutex lock try
> should have a timeout, and we should go ahead and just try forcewaking
> and reading the reg anyway after a while."

If the GPU has hung (and more importantly in such a way as to block the
mutex - nowadays that is it an OOPS with the lock held), we can simply do
the reg read/write from the userspace without worry. But for bug reports,
I'd much rather we automatically capture any register that we might need than
rely on the frustrated user doing the right thing.

So I don't see having the haphazard locking in the kernel, for everyone to
criticise us for, justified.

> > It's not the performance I care about, but the atomicity. There seem to be
> > a growing abundance of messaging systems within the chip driven by
> > combinations of registers. I'd feel happier if we could send a message
> > without fouling or being fouled by the kernel.
> 
> Generally for those things, you end up needing to poll in the middle.
> Let's not build a more complicated interface than required for current
> use-cases in userland (reading many registers, or writing an arbitrary
> one), without solving a specific problem.

What I guess I was trying to express was that we need to be very clear
what the interface is for and the limitations about its use.

For the more complicated set of registers, we can and should expose knobs
in the debugfs to read and write them. For instance, to control the render
clock frequencies and thresholds.

But perhaps we do need to reconsider the performance aspect. intel_gpu_top
samples the ring HEAD and TAIL at around 10KHz and forcing gt-wake is
about 50 microseconds... I hope I'm mistaken, because even batched that is
doomed. Ben, do you mind checking that thought experiment with a little
hard fact?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre