Inspired by a recent regression that seems to confuse pch transcoder
state, let's be a bit more paranoid.

References: https://bugs.freedesktop.org/show_bug.cgi?id=49712
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Pimped commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.

Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.

So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.

Note that DDI A can only drive eDP, so we do not handle it here for hdmi
initialization.

v2: simplify Haswell handling logic

v3: use generic function for handling digital outputs.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.

v2: calculate divisor values directly instead of relying on a table.

v3: merged a fix from Ben to properly check for invalid divider values.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.

v2: improve comment as per Chris Wilson suggestion

v3: incorporate latest changes in specs.

v4: move into wm update routine, also mention that the same routine can
program IPS watermarks. We do not have their enablement code yet, nor
handle the required clock settings at the moment, so this patch won't
program those values for now.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.

This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.

v2: simplify the commit as per Daniel Vetter suggestion.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.

Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On Haswell, only one pipe can work in FDI mode, so this patch prevents
messing with wrong registers when FDI is being used by non-first pipe. And
to prevent this, we also specify that the VGA can only be used on pipe 0
for now in the crtc_mask value.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prevent bogus asserts on DDI-related paths.

Longer explanation from Eugeni by mail:

"For the asserts there are 3 paths where we hit them:
- in assert_fdi_tx (we don't have the FDI_TX_CTL anymore, backup plan
  DDI_FUNC_CTL is used instead)
- in assert_fdi_tx_pll_enabled (we have the combination of iCLKIP and
  DDI_FUNC_CTL, plus PORT_CLK_SEL and PIPE_CLK_SEL now to make things
  work). We could use an assert here indeed - if we configure port to
  use one clock, and pipe to use another, everything hangs. Right now,
  we configure all of them in one place only; but yes, when DP code
  lands it will get more funky.
- and in ironlake_fdi_pll_enable. I reuse part of this function (to
  configure the TU sizes), but as in the 1st case, FDI_TX_CTL is gone
  so I just ignore it here."
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Pasted Eugeni's explanation into the commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Avoid bogus asserts and PCH PLL accesses on Lynx Point.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On Haswell, the recommended PCH-connected output is the one driven by DDI
E in FDI mode, used for VGA connection. All the others are handled by the
CPU.

Note that this does not accounts for Haswell/PPT combination yet, so if we
encounter such combination an error message is thrown to indicate that
things could go wrong.

v2: improve non-LPT detection warning per Daniel Vetter's suggestion.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should be already configured when FDI auto-negotiation is done.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be
simplified with a more simple check.

Also, as noticed by Jesse Barnes, it is worth mentioning that plane is an
enum and num_pipe is an int, so we could be more paranoid here about those
validation checks eventually.

CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.

v2: de-inline the function and address changes in bits names

v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.

v4: decrease paranoia a bit, as noticed by Chris Wilson
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we call gen6_enable_rps() (which writes into the per-ring
register mmio space) from intel_modeset_init_hw() which is called before
we initialise the rings. If we defer intel_modeset_init_hw() until
afterwards (in the intel_modeset_gem_init() phase) all is well.

v2: Rectify ordering of gem vs display HW init upon resume. (Daniel)

v3: Fix up locking. (Paulo)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Smash Paulo's locking fix onto Chris' patch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The principle of intel_mark_busy() is that we want to spot the
transition of when the display engine is being used in order to bump
powersaving modes and increase display clocks. As such it is only
important when the display is changing, i.e. when rendering to the
scanout or other sprite/plane, and these are characterised by being
pinned.

v2: Mark the whole device as busy on execbuffer and pageflips as well
and rebase against dinq for the minor bug fix to be immediately
applicable.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: fix compile fail.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake
and newer, so now we use PIPEFRAME.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Ditch the check for disable pipe from the new ilk wait for
vblank function to keep it consisten with existing behaviour.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Gen3+ is 13 bits (12:0), and on gen2 only 12 (11:0). For both the high
bits are marked reserved, read-only so continue to mask them. Bit 31
is not reserved and has a meaning.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with

commit f9bef081
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Apr 15 19:53:19 2012 +0200

    drm/i915: don't clobber the special upscaling lvds timings

and

commit ca9bfa7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 14:49:20 2012 +0100

    drm/i915: fixup interlaced vertical timings confusion, part 1

we now only set the crtc timing fields in the encoder->mode_fixup
(lvds only) and in crtc->mode_fixup (for everyone else). And since

commit 75c13993
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jan 28 23:48:46 2012 +0100

    drm/i915: fixup overlay checks for interlaced modes

the only places we actually need the crtc timings is in the mode_set
function.

I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e.  after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).

So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Every time we use the device after a period of idleness, check that the
power management setup is still sane. This is to workaround a bug
whereby it seems that we begin suppressing power management interrupts,
preventing SandyBridge+ from going into turbo mode.

This patch does have a side-effect. It removes the mark-busy for just
moving the cursor - we don't want to increase the render clock just for
the sprite, though we may want to bump the display frequency. I'd argue
that we do not, and certainly don't want to take the struct_mutex here
due to the large latencies that introduces.

References: https://bugs.freedesktop.org/show_bug.cgi?id=44006Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When initialising the PLL registers we may have to clear existing state
from the BIOS - that is the PLL may already be enabled. So we need to
disable it, wait for the clocks to settle and then rewrite it.

The issue came to light when Ben tested

commit 88ca4bb7974277793e602d88739d4e8f56b89e64
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Apr 20 17:11:53 2012 +0100

    drm/i915: manage PCH PLLs separately from pipes

and found that booting into a VGA monitor was no longer working. Closer
inspection suggests that it was a pre-existing bug now being hit by the
rearranged code. Perhaps Ben was not even the first person to stumble
upon this bug, https://bugs.freedesktop.org/show_bug.cgi?id=37029.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-and-Tested-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unfortunately it looks like further vlv patches are still stalled due
to fried hw, and too many people are a bit annoyed about the unused
function warning.

So let's just rip it out, we can easily put it back in again.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a pretty racy way to close these races, and we have
much better means to cope with these races meanwhile: For
non-broken userspace we correctly wait for any outstanding
rendering, for broken userspace the hangcheck will save the
day.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The LP refers to 'low priority' as opposed to the high priority
ring on gen2/3. So lets constrain its use to the code of that era.

Unfortunately we can't yet completely remove the associated
macros from common headers and shove them into i915_dma.c to
the other dri1 legacy support code, a few cleanups are still
missing for that.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also ditch the cargo-culted dev_priv checks - either we have a
giant hole in our setup code or this is useless. Plainly bogus
to check for it in either case.

v2: Chris Wilson noticed that I've missed one bogus dev_priv check.

v3: The check in the overlay code is redundant (Chris)
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enabling the plane before we have assigned valid address means that it
will access random PTE (often with conflicting memory types) and cause
GPU lockups. However, enabling the plane too early appears to workaround
a number of bugs in our modesetting code.

Cc: Franz Melchior <melchior.franz@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=39947
References: https://bugs.freedesktop.org/show_bug.cgi?id=41091
References: https://bugs.freedesktop.org/show_bug.cgi?id=49041Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
treat them as part of the pipe.

So split the code out and manage PCH PLLs separately, allocating them
when needed or trying to re-use existing PCH PLL setups when the timings
match.

v2: add num_pch_pll field to dev_priv (Daniel)
    don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse)
    put register offsets in pll struct (Chris)

v3: Decouple enable/disable of PLLs from get/put.
v4: Track temporary PLL disabling during modeset
v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni)
v6: Avoid mishandling allocation failure by embedding the small array of
    PLLs into the device struct

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+)
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only execute intel_decrease_pllclock for pre-PCH hardware, typically
gen4 mobiles. However, in the variable declaration we did read from the
non-PCH DPLL register, quite naughty and detected by SandyBridge.
Reported-and-tested-by: NAndrey Rahmatullin <wrar@wrar.name>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the change to start adjusting the sync polarity of the LVDS mode
was introduced in

commit aa9b500d
Author: Bryan Freed <bfreed@google.com>
Date:   Wed Jan 12 13:43:19 2011 -0800

    drm/i915: Honour LVDS sync polarity from EDID

we made the change in state verbose so that we could quickly spot any
regressions that made have also been introduced with it. As there do not
appear to have been any, remove the extra logging.

v2: Remove the no longer used variables.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds intel_pm routine for generic power-related infrastructure
initialization.

v2: now that all the platform-specific stuff is initialized in one place, we
can also add back the static definitions to platform-specific functions which
we abstract now.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This moves the clock gating-related functions into intel_pm module.

Also, please note that we do change the function type from static to
non-static in this patch for the move, to prevent breaking bisecting with
non-working intermediate commit. Those are returned back to static form in
the following patch which setups a generic PM initialization function,
which was split into a different one to simplify review.

v2: rebase on top of latest drm-intel-next-queued to incorporate all the
changes that went there meanwhile.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This moves the Ironlake energy monitoring functionality into intel_pm
module.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This moves DRPS, RPS and RC6-related functionality into intel_pm module.

It also removes the linux/cpufreq.h include from intel_display, as its
only user was the GPU turbo-related functionality in Gen6+ code path.

v2: rebase on top of latest drm-intel-next-queued adding the bits that
shifted around since the last patch.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move watermarks and helper functions (such as cxsr and fifo buffers) into
intel_pm module.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This commit moves Frame Buffer Compression-related operations and support
functions into the new intel_pm module.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We never succeeded in getting pipelined fencing to work (unresolved
spurious GPU hangs), so begin the process of dismantling and removal
the broken code.

Step 1 is the removal of the pipeline parameter to get_fence().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During modeset we have to disable the pipe to reconfigure its timings
and maybe its size. Userspace may have queued up command buffers that
depend upon the pipe running in a certain configuration and so the
commands may become confused across the modeset. At the moment, we use a
less than satisfactory kick-scanline-waits should the GPU hang during
the modeset. It should be more reliable to wait for the pending
operations to complete first, even though we still have a window for
userspace to submit a broken command buffer during the modeset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we need to manipulate our device structure and allocate queue a task,
it is no longer a simple atomic operation and cannot be performed along
the atomic modeset paths. Instead make sure that we disable FBC (which
must be therefore kept as a set of simple register writes) when
performing the atomic modeset and leave the heavy-weight
intel_update_fbc() for the normal modeset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>