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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
