On Fri, Mar 25, 2011 at 07:07:48PM -0700, Ben Widawsky wrote:
>
> Chris, do you already have something like this queued up?
>
> I don't have a SNB with which to test this patch right now. I'd like to
> know if anyone has any major issues with this, because I intend to use
> this to enable userspa
On Gen6, forcewake must be used to ensure certain HW bits are powered to
process commands (such as register writes). Forcewake should be
persistent according to the spec, so it is unnecessary to set it more
than once.
Further this "refcount" allows a userspace interaction with this part of
the HW
Chris, do you already have something like this queued up?
I don't have a SNB with which to test this patch right now. I'd like to
know if anyone has any major issues with this, because I intend to use
this to enable userspace to properly read and write registers on SNB.
Also if you see any glari
On Thu, 24 Mar 2011 19:55:59 +
Chris Wilson wrote:
> During modesetting, we need to wait for the hardware to report
> readiness by polling the registers. Normally, we call msleep() between
> reads, because some state changes may take a whole vblank or more
> to complete. However during a pani
The kernel has always been lax in enforcing size restrictions upon the
buffers it is handed to by userspace, and userspace has always tried to
overallocate its buffers.
However, userspace made a mistake and failed to follow the undocumented
requirement that gen2 hardware requires its allocations t
The kernel has always been lax in enforcing size restrictions upon the
buffers it is handed to by userspace, and userspace has always tried to
overallocate its buffers.
However, userspace made a mistake and failed to follow the undocumented
requirement that gen2 hardware requires its allocations t
On Thu, 24 Mar 2011 17:38:32 -0700, Keith Packard wrote:
> On Thu, 24 Mar 2011 19:55:59 +, Chris Wilson
> wrote:
>
> > - if (W && !in_dbg_master()) msleep(W); \
> > + if (W && !(in_dbg_master() || in_atomic())) msleep(W); \
>
> If the MSLEEP macro wer
