This is useful for userspace utilities which wish to use the previous
interface, specifically for micromanaging the increase/decrease steps by
setting min == max.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Provide a standardized sysfs interface for setting min, and max
frequencies.  The code which reads the limits were lifted from the
debugfs files. As a brief explanation, the limits are similar to the CPU
p-states. We have 3 states:

RP0 - ie. max frequency
RP1 - ie. "preferred min" frequency
RPn - seriously lowest frequency

Initially Daniel asked me to clamp the writes to supported values, but
in conforming to the way the cpufreq drivers seem to work, instead
return -EINVAL (noticed by Jesse in discussion).
The values can be used by userspace wishing to control the limits of the
GPU (see the CC list for people who care).

v4: Make exceeding the soft limits return -EINVAL as well (Daniel)

v3: bug fix (Ben) -  was passing the MHz value to gen6_set_rps instead of
the step value. To fix, deal only with step values by doing the divide
at the top.

v2: add the dropped mutex_unlock in error cases (Chris)
EINVAL on both too min, or too max (Daniel)

v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).

The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 30 13:26:48 2012 +0200

    drm/i915: add a tracepoint for gpu frequency changes

Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The original patch was actually incorrect in stubbing out the sysfs for
l3 parity.
commit 5ab3633d
Author: Hunt Xu <mhuntxu@gmail.com>
Date:   Sun Jul 1 03:45:07 2012 +0000

    drm/i915: make rc6 in sysfs functions conditional

Unfortunately Hunt didn't respond to my review comments, and Daniel
sucked in the patch again ignoring. Worst of all, I'm too lazy to write
the patch for what I originally wanted, which was to keep rc6 sysfs even
without CONFIG_PM. This simpler patch does enough to enable us to add
more sysfs entries though.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 0136db58 merges rc6 information
into the power group. However, when compiled with CONFIG_PM not set,
modprobing i915 would taint since power_group_name is defined as NULL.

This patch makes these rc6 in sysfs functions conditional upon the
definition of the CONFIG_PM macro to avoid the above-mentioned problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181
Cc: stable@vger.kernel.org
Tested-by: NKris Karas <bugs-a12@moonlit-rail.com>
Signed-off-by: NHunt Xu <mhuntxu@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Originally I had a macro specifically for DPF support, and Daniel, with
good reason asked me to change it to this. It's not the way I would have
gone (and indeed I didn't), but for now there is no distinction as all
platforms with L3 also have DPF.

Note: The good reasons are that dpf is a l3$ feature (at least on
currrent hw), hence I don't expect one to go without the other.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: added note]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Positively checking for the required feature/gen is simpler than build
a cascade of negative "we need to bail" checks. And the later won't
scale if we add more stuff that doesn't fit in nicely.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Dumb binary interfaces which allow root-only updates of the cache
remapping registers. As mentioned in a previous patch, software using
this interface needs to know about HW limits, and other programming
considerations as the kernel interface does no checking for these things
on the root-only interface.

v1: Drop extra posting reads (Chris)
Return negative values in the sysfs interfaces on errors (Chris)

v2: Return -EINVAL for offset % 4 (Jesse)
Move schizo userspace check out (Jesse)
Cleaner sysfs item initializers (Daniel)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Chris' fix for my 32b breakage was incorrect. do_div returns a
remainder. Go back to a divide macro which is more 32b friendly.

Tested on x86-64.

This has only been compile tested on 32b systems.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48756
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Sincere-apologies: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
[danvet: fixup 32bit compile-fail.]
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Merge rc6 information into the power group for our device. Until now the
i915 driver has not had any sysfs entries (aside from the connector
stuff enabled by drm core). Since it seems like we're likely to have
more in the future I created a new file for sysfs stubs, as well as the
rc6 sysfs functions which don't really belong elsewhere (perhaps
i915_suspend, but most of the stuff is in intel_display,c).

displays rc6 modes enabled (as a hex mask):
cat /sys/class/drm/card0/power/rc6_enable

displays #ms GPU has been in rc6 since boot:
cat /sys/class/drm/card0/power/rc6_residency_ms

displays #ms GPU has been in deep rc6 since boot:
cat /sys/class/drm/card0/power/rc6p_residency_ms

displays #ms GPU has been in deepest rc6 since boot:
cat /sys/class/drm/card0/power/rc6pp_residency_ms

Important note: I've seen on SNB that even when RC6 is *not* enabled the
rc6 register seems to have a random value in it. I can only guess at the
reason reason for this. Those writing tools that utilize this value need
to be careful and probably want to scrutinize the value very carefully.

v2: use common rc6 residency units to milliseconds for the other RC6 types

v3: don't create sysfs files for GEN <= 5
add a rc6_enable to show a mask of enabled rc6 types
use unmerge instead of remove for sysfs group
squash intel_enable_rc6() extraction into this patch

v4: rename sysfs files (Chris)

CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>f
CC: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: squash in the 64bit division fix by Chris Wilson.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>