With the base addresses shifting around, this is easier to handle.
Also move to the real reg offset on vlv.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Will be used more in the next patch.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access through
libpciaccess, the IOCTL can provide this service instead.

Currently the implementation whitelists only the render ring timestamp
register, because that is the only thing we need to expose at this time.

v2: make size implicit based on the register offset
Add a generation check
Reviewed-by: NEric Anholt <eric@anholt.net>
Cc: Jacek Lawrynowicz <jacek.lawrynowicz@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: fixup the ioctl numerb:]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Splitting them up between pch and gmch variants just makes it harder
to find things. Especially since the hotplug bits are actually valid
on earlier chips, too.

v2: Fixed the comment as pointed out by Paulo Zanoni.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I so totally suck.

This can cause a black screen if (for whatever reason) the bios
hasn't set this bit itself.

This regression has been introduced in

commit 7cf41601
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 5 10:07:09 2012 +0200

    drm/i915: clear up backlight #define confusion on gen4+
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Having had to dive into the bspec to understand what each stage of the
workaround meant, and how that the ring broadcasting IDLE corresponded
with the GT powering down the ring (i.e. rc6) add comments to aide
the next reader.

And since the register "is used to control all aspects of PSMI and power
saving functions" that makes it quite interesting to inspect with
regards to RC6 hangs, so add it to the error-state.

v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for
the ring to wake up.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There were some fields missed. Daniel pointed this out in review, and I
know I fixed it, but something happened somehow and some time.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

*sigh* the docs had it spelled wrong, corrected it, and then proceeded
to re-do the original error. The original code preserved this history,
and this patch attempts to keep in sync with the current docs.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is required for a stable FDI connection.

v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The tileoffset register only supports a limited offset in x/y of 4096,
so for giant screen configuration with a shared fb we wrap around.

Fix this by computing a linear offset in tiles (pages) and only use
the tileoffset register to offset within the tile.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To avoid recomputing the display framebuffer offset on gen2/3
pageflips. This is also prep work to do similar trickery on gen4+

Also:
- kill "Start", such upper-case remnants from the ddx must surely die.
- rename "Offset" to linear_offset, to make it clearer that on gen4+
  this is only used by the hw for linear buffers, for tiled buffers it
  uses the TILEOFF register.
- call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because
  the documentation really renamed the register).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only bits 30:28, bit 31 is PIPE_DDI_FUNC_ENABLE.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For Haswell, on some of the early hardware revisions, it is possible to
run into issues when RC6 state is enabled and when pipes change state.

v2: add comment saying that this is for early revisions only.

v3: beautify as suggested by Daniel Vetter.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Most of the RPS and RC6 enabling functionality is similar to what we had
on Gen6/Gen7, so we preserve most of the registers.

Note that Haswell only has RC6, so account for that as well. As suggested
by Daniel Vetter, to reduce the amount of changes in the patch, we still
write the RC6p/RC6pp thresholds, but those are ignored on Haswell.

Note: Some discussion about the nature of the new tuning constants
popped up in review - the answer is that we don't know why they've
changed, but the guide from VPG with the magic numbers simply has
different values now.

v2: Squash fix for ?: vs | operation precende bug into this patch.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message. Squashed fix.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is a different ACK register for force wake on Haswell, so account
for that.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As a w/a to prevent reads sporadically returning 0, we need to wait for
the GT thread to return to TC0 before proceeding to read the registers.

v2: adapt for Haswell changes (Eugeni).

v3: use wait_for_atomic_us for thread status polling.

v3: *really* use wait_for_atomic for polling.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50243Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Looks like a copy/paste error.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enable the on-chip messaging between the display engine and the GT.

v2: use bit definitions for DPFLIPSTAT reg
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ValleyView is similar to IbexPeak here, but with different register
offsets.

v2: use SDVOB instead ov VLV_HDMIB (Daniel)
    drop unnecessary eDP check in DP_C init (Daniel)

eDP support will be coming later from Shobit.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV supports two dp panels, there are two set of panel power sequence
registers which needed to be programmed based on the configured
pipe. This patch add supports for the same
Acked-by: NAcked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: NBeeresh G <beeresh.g@intel.com>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: NJesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop the lone hunk and only keep the register definitions - I
loathe incomplete bandaids. Also add a comment that this is for vlv.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add some VLV limit structures and update the PLL code.

v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits
v3: re-add dpio write function
v4: squash in Vijay's fixes for the PLL limits and clean up the m/n finder
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prevents a possible hang: WaDisableL3Bank2xClockGate.

v2: only apply to VLV, IVB doesn't need this anymore

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Another required workaround for a potential hang:
WaDisableTDLUnitClockGating.

v2: only apply this to VLV, IVB doesn't need it anymore (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The RCBP workaround still applies on these chips, and we need VDS as well.

v2: remove MB boot fetch that snuck in (Daniel)
    add workaround tags to comments for easier internal tracking (Daniel)
v3: only apply RCPB and VDS on SNB and VLV, IVB doesn't need them (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50251Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has showed up in several other patches. It's required for the next
context workaround.

I tested this one on its own and saw no differences in basic tests
(performance or otherwise). This patch is relatively likely to cause
regressions, hence why it's split out.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.

FWIW, I eventually want to play with some of the arbitration stuff, and
I'd hate to forget about this.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

The GPUs can have different default context layouts, and the sizes could
vary based on platform or BIOS. In order to back the context object with
a properly sized BO, we must read this register in order to find out a
sufficient size.

Thankfully (sarcarm!), the register moves and changes meanings
throughout generations.

CTX and CXT differences are intentional as that is how it is in the
documentation (prior to GEN6 it was CXT).
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

- Regroup definitions for BLC_PWM_CTL so that they're all together and
  and ordered according to the bitfields.

- Add all missing definitions for BLC_PWM_CTL2.

- Use the BLM_ (for backlight modulation) prefix consistently.

- Note that combination mode (i.e. also taking the legacy backlight
  control value from pci config space into account) is gen4 only.

- Move the new registers for PCH-split machines up, they're an almost
  match for the gen4 defitions.  Prefix the special PCH-only bits with
  BLM_PCH_. Also add the pipe C select bit for ivb.

- Rip out the second pair of PCH polarity definitions - they're only
  valid on early (pre-production) ilk silicon.

- Adapt the existing code to use the new definitions. This has the
  nice benefit of killing a magic (1 << 30) left behind be Jesse
  Barnes.

No functional changes in this patch.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already correctly ignore bit0 on gen < 4, now we also know why ;-)
I've decided that losing that single bit of precision isn't worth the
trouble to sprinkle IS_PINEVIEW checks all over the backlight control
code - that code is way too fragile imo.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cougar/Panther Point redefine the bits in SDEIIR pretty completely.
This function is just debugging, but if we're debugging we probably want
to be told accurate things instead of lies.

I'm told Lynx Point changes this yet more, but I have no idea how...

Note from Eugeni's review:

"For the record and for future enabling efforts, for LPT, bits 28-31
and 1-14 are gone since CPT/PPT (e.g., those must be zero). And there
is the bit 15 as a new addition, but we are not using it yet and
probably won't be using in foreseeable future."
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Or at least plug another gapping hole. Apparrently hw desingers only
moved the bit field, but did not bother ot re-enumerate the planes
when adding support for a 3rd pipe.

Discovered by i-g-t/flip_test.

This may or may not fix the reference bugzilla, because that one
smells like we have still larger fish to fry.

v2: Fixup the impossible case to catch programming errors, noticed by
Chris Wilson.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50069Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@vger.kernel.org
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If any l3 rows have been previously remapped, we must remap them after
GPU reset/resume too.

v2: Just return (no warn) on remapping init if not IVB (Jesse)
Move the check of schizo userspace to i915_gem_l3_remap (Jesse)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On IVB hardware we are given an interrupt whenever a L3 parity error
occurs in the L3 cache. The L3 cache is used by internal GPU clients
only.  This is a very rare occurrence (in fact to test this I need to
use specially instrumented silicon).

When a row in the L3 cache detects a parity error the HW generates an
interrupt. The interrupt is masked in GTIMR until we get a chance to
read some registers and alert userspace via a uevent. With this
information userspace can use a sysfs interface (follow-up patch) to
remap those rows.

Way above my level of understanding, but if a given row fails, it is
statistically more likely to fail again than a row which has not failed.
Therefore it is desirable for an operating system to maintain a lifelong
list of failing rows and always remap any bad rows on driver load.
Hardware limits the number of rows that are remappable per bank/subbank,
and should more than that many rows detect parity errors, software
should maintain a list of the most frequent errors, and remap those
rows.

V2: Drop WARN_ON(IS_GEN6) (Jesse)
DRM_DEBUG row/bank/subbank on errror (Jesse)
Comment updates (Jesse)
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

From this point on, the 'set_infoframe' functions always set the DIP
registers to a known state, so anything done will always be undone at
the modeset.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Note that gen3 is the only platform where we've got the bit
definitions right, hence the workaround of disabling sdvo hotplug
support on i945g/gm is not due to misdiagnosis of broken hotplug irq
handling ...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
wondered about while reviewing.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The status bits corresponding to the interrupt enable bits are the
"live" hotplug status bits, and reflect the current status of the port
(high for a detected connection, low for a disconnect). The actual bits
corresponding to the interrupt source are elsewhere. The actual event is
then determined by a combination of the interrupt flag and the current
live status (if the interrupt is active, but the current status is not,
then we have detected a disconnect.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Both the control and data registers are completely different now.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Haswell has different DIP control registers and offsets which we need to
use for infoframes, which this patch adds.

Note that this does not adds full DIP frames support, but only the basic
functionality necessary for HDMI to work in early enablement.

v2: replace infoframe handling with a debug message, proper support will
be added via a patch from Paulo Zanoni later.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NPaulo Zanoni <przanoni@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just like Gen 4, IBX has a "Port Select" field on the DIP register,
but the ports are different.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Better safe than sorry. Currently we never change the frequency and
use the same for every infoframe type, so the only way to reproduce a
bug would be with the BIOS doing something.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>