intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* forcewake junk, RFC, RFT(test)
@ 2011-04-08 17:47 Ben Widawsky
  2011-04-08 17:47 ` [PATCH 1/4] drm/i915: proper use of forcewake Ben Widawsky
                   ` (5 more replies)
  0 siblings, 6 replies; 18+ messages in thread
From: Ben Widawsky @ 2011-04-08 17:47 UTC (permalink / raw)
  To: intel-gfx


I am requesting 3 things:
1. code review/request for comments
2. testing on SNB
3. performance regression on < SNB

review
------
The first two patches have nothing to do with the user's ability to
interact with registers. Those patches are about enforcing correctness
within our driver for newer generation products. In other words, if
patch 3 doesn't make sense, don't automatically drop 1, and 2.

review patch 1/2
----------------
The first change is straight forward. It attempts to fold the forcewake stuff
into our standard register read and write functions. Some overhead is added as
a result, but I'd guess it is nothing compared to the UC read about to happen,
and so will not be noticeable.

The existing method for doing the forcewake_get and put requires some
synchronization. For the most part it is protected by struct_mutex and life is
good. Adding a WARN to the get()/put() function is there more as documentation
to future developers, and reminders to the current ones.

To provide an interface to allow user space to use forcewake, I've decided to
change the mechanism that get()/put() operate by introducing a reference count.
The reference count itself must be protected by struct mutex (since we need
synchronization between the initial condition and the destructor). Imagine for
instance: Thread A does a get() and is in the middle of waking the GT (ref has
already been incremented), thread B comes in, thinks the GT is awake,
and incorrectly goes about its business. This does allow users of the
interface to only have to hold struct_mutex while doing the get() and
not for every read and write.

review patch 3
--------------
User space interface is mostly what you'd expect, except the in the case
of trying to get lockless access. This code is a bit meh, but to
remind everyone, it is root only debug code.

testing
-------
The assertion that forcewake is currently properly protected for the
most part, may not be true. People interested should run these patches
on SNB systems with their favorite graphics applications and report the
warnings that occur, they will be in the kernel log, ie. dmesg.

performance
-----------
Looking mostly for regressions on older systems. There is a slight
overhead added to all register reads and writes, which I think shouldn't
be noticeable, but who knows.

Thanks, and let the flames begin!
Ben

^ permalink raw reply	[flat|nested] 18+ messages in thread
* force wake reference counting (another try)
@ 2011-04-12  1:01 Ben Widawsky
  2011-04-12  1:01 ` [PATCH 2/4] drm/i915: refcounts for forcewake Ben Widawsky
  0 siblings, 1 reply; 18+ messages in thread
From: Ben Widawsky @ 2011-04-12  1:01 UTC (permalink / raw)
  To: intel-gfx


Contrary to the discussion on IRC, I have decided not to add
config.mutex as part of the warning criteria. Upon further thought, it
just seemed incorrect to me. This patch series implies that all register
reads which may require a forcewake must now hold struct_mutex, ie. make
struct_mutex more global. The alternative is to invent a new lock for
forcewake which must be acquired prior to said register reads.

I know, that sucks. It has implications on non-SNB platforms, and that
is exactly what I was hoping to avoid. The current code is dangerous. If
two threads need register reads requiring forcewake but aren't
protected by the same mutex, it will lead to unpredictable register
reads (I can't think of a case where it will actually work correctly).

So once again, I expect this patch to potentially generate a lot of
warnings, but I consider all of those warnings to be serious bugs for
SNB.

If anyone has clever ideas on how to handle this outside of what I've
already mentioned, please let me know.

I expect ongoing patches to fix these issues as they come up.

Ben

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2011-04-12  1:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-08 17:47 forcewake junk, RFC, RFT(test) Ben Widawsky
2011-04-08 17:47 ` [PATCH 1/4] drm/i915: proper use of forcewake Ben Widawsky
2011-04-08 17:47 ` [PATCH 2/4] drm/i915: refcounts for forcewake Ben Widawsky
2011-04-08 17:47 ` [PATCH 3/4] drm/i915: userspace interface to the forcewake refcount Ben Widawsky
2011-04-08 17:47 ` [PATCH 4/4] drm/i915: optional fewer warning patch Ben Widawsky
2011-04-09 20:26 ` forcewake junk, part2 Ben Widawsky
2011-04-09 20:26   ` (no subject) Ben Widawsky
     [not found]     ` <1302380787-2957-3-git-send-email-ben@bwidawsk.net>
2011-04-09 20:26       ` [PATCH 1/4] drm/i915: proper use of forcewake Ben Widawsky
2011-04-09 20:26         ` [PATCH 2/4] drm/i915: refcounts for forcewake Ben Widawsky
2011-04-09 20:26           ` [PATCH 3/4] drm/i915: userspace interface to the forcewake refcount Ben Widawsky
2011-04-09 20:31 ` forcewake patches (ignore previous, please) Ben Widawsky
2011-04-09 20:31   ` [PATCH 1/4] drm/i915: proper use of forcewake Ben Widawsky
2011-04-09 20:31     ` [PATCH 2/4] drm/i915: refcounts for forcewake Ben Widawsky
2011-04-09 20:31       ` [PATCH 3/4] drm/i915: userspace interface to the forcewake refcount Ben Widawsky
2011-04-09 20:31         ` [PATCH 4/4] drm/i915: optional fewer warning patch Ben Widawsky
2011-04-09 22:31           ` Chris Wilson
2011-04-09 23:32             ` Ben Widawsky
2011-04-12  1:01 force wake reference counting (another try) Ben Widawsky
2011-04-12  1:01 ` [PATCH 2/4] drm/i915: refcounts for forcewake Ben Widawsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).