... instead of relying on the register save/restore madness to do this.

To extract a bit of code call drm_mode_config_reset both on resume
and boot-up and move the hw state frobbing from the crt_init to the
->reset callback. The crt connector is the only one with a ->reset
callback, hence we can easily do this.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since this only calls crtc helper functions, of which a shocking
amount are NULL.

Now the curious thing is how the new modeset code worked with this
function call still present:

Thanks to the hw state readout and the suspend fixes to properly
quiescent the register state, nothing is actually enabled at resume
(if the bios doesn't set up anything). Which means resume_force_mode
doesn't actually do anything and hence nothing blows up at resume
time.

The other reason things do work is that the fbcon layer has it's own
resume notifier callback, which restores the mode. And thanks to the
force vt switch at suspend/resume, that then forces X to restore it's
own mode.

Hence everything still worked (as long as the bios doesn't enable
anything). And we can just kill the call to resume_force_mode.

The upside of both this patch and the preceeding patch to quiescent
the modeset state is that our resume path is much simpler:
- We now longer restore bogus register values (which most often would
  enable the backlight a bit and a few ports), causing flickering.
- We now longer call resume_force_mode to restore a mode that the
  fbcon layer would overwrite right away anyway.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this to avoid confusing the hw state readout code with the cpt
pch plls at resume time: We'd read the new pipe state (which is
disabled), but still believe that we have a life pll connected to that
pipe (from before the suspend). Hence properly disable pipes to clear
out all the residual state.

This has the neat side-effect that we don't enable ports prematurely
by restoring bogus state from the saved register values.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... instead of resetting a few things and hoping that this will work
out.

To properly disable the output pipelines at the initial modeset after
resume or boot up we need to have an accurate picture of which outputs
are enabled and connected to which crtcs. Otherwise we risk disabling
things at the wrong time, which can lead to hangs (or at least royally
confused panels), both requiring a walk to the reset button to fix.

Hence read out the hw state with the freshly introduce get_hw_state
functions and then sanitize it afterwards.

For a full modeset readout (which would allow us to avoid the initial
modeset at boot up) a few things are still missing:
- Reading out the mode from the pipe, especially the dotclock
  computation is quite some fun.
- Reading out the parameters for the stolen memory framebuffer and
  wrapping it up.
- Reading out the pch pll connections - luckily the disable code
  simply bails out if the crtc doesn't have a pch pll attached (even
  for configurations that would need one).

This patch here turned up tons of smelly stuff around resume: We
restore tons of register in seemingly random way (well, not quite, but
we're not too careful either), which leaves the hw in a rather
ill-defined state: E.g. the port registers are sometimes
unconditionally restore (lvds, crt), leaving us with an active
encoder/connector but no active pipe connected to it. Luckily the hw
state sanitizer detects this madness and fixes things up a bit.

v2: When checking whether an encoder with active connectors has a crtc
wire up to it, check for both the crtc _and_ it's active state.

v3:
- Extract intel_sanitize_encoder.
- Manually disable active encoders without an active pipe.

v4: Correclty fix up the pipe<->plane mapping on machines where we
switch pipes/planes. Noticed by Chris Wilson, who also provided the
fixup.

v5: Spelling fix in a comment, noticed by Paulo Zanoni
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

ERR_INT on HSW will display unclaimed MMIO accesses. This can be either
the result of a driver bug writing to an invalid addresses, or the
result of RC6.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NAntti Koskipaa <antti.koskipaa@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also properly indent the HB IDs.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
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>

All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.

Call that directly in the only callsite.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Simply failing to reset the gpu because someone else might still hold
the mutex isn't a great idea - I see reliable silent reset failures.
And gpu reset simply needs to be reliable and Just Work.

"But ... the deadlocks!"

We already kick all processes waiting for the gpu before launching the
reset work item. New waiters need to check the wedging state anyway
and then bail out. If we have places that can deadlock, we simply need
to fix them.

"But ... testing!"

We have the gpu hangman, and if the current gpu load gem_exec_nop
isn't good enough to hit a specific case, we can add a new one.

"But ...  don't we return -EAGAIN for non-interruptible calls to
wait_seqno now?"

Yep, but this problem already exists in the current code. A follow up
patch will remedy this by returning -EIO for non-interruptible sleeps
if the gpu died and the low-level wait bails out with -EAGAIN.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This function is used to set the PCH_DREF_CONTROL register, which does
not exist on LPT anymore.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Previously we had has_pch_split to tell us whether we had a PCH or not
and we also had dev_priv->pch_type to tell us which kind of PCH it
was, but it could only be used if we were 100% sure we did have a PCH.
Now that PCH_NONE was added to dev_priv->pch_type we don't need
has_pch_split anymore: we can just check for pch_type != PCH_NONE.

The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can
only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks
at dev_priv->info->has_pch_split, which is available earlier.

Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type
instead of dev_priv->info->has_pch_split, we need to make sure that
intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made.
So we moved the intel_detect_pch call to an earlier stage.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This commit moves force wake support routines into intel_pm modules, and
exports the gen6_gt_check_fifodbg routine (used in I915_READ).
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>

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>

Tidy up the routines for interacting with the GT (in particular the
forcewake dance) which are scattered throughout the code in a single
structure.

v2: use wait_for_atomic for polling.

v3: *really* use wait_for_atomic for polling.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
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>

This is the quick&dirty way Dave Airlie suggested to workaround the
midlayer drm agp brain-damange. Note that i915_probe is only called
when the driver has ksm enabled, so no need to check for that.

We also need to move the intel_agp_enabled check at the right place.
Note that the only thing this does is enforce the correct module load
order (by using a symbol from intel-agp.ko) to ensure that the fake
agp driver is ready before the drm core tries to set up the agp stuff.

v2: Add a comment to explain why gen3 needs all this legacy fake agp
stuff - we've shipped an XvMC library with a kms-enabled ddx that
requires it (but only on gen3).

v3: Make it clear that this is only a gen3 issue in the comment.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the code in place, we can bind the driver, should make bisect possible.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since the offsets have all moved around.

v2: switch IS_DISPLAYREG and IS_VALLEYVIEW checks around since the latter is
    cheaper (Daniel)
    bail out early in IS_DISPLAYREG if the reg is in the new range (Daniel)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup if cascading fail that broke HAS_FORCEWAKE machines.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It seems to blow up my ilk in all kinds of strange ways. And now that
we're no longer resetting the entire modeset state, it shouldn't be
necessary any longer.

This essentially reverts

commit f817586c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 10 15:50:11 2012 +0200

    drm/i915: re-init modeset hw state after gpu reset

safe for the introduction of modeset_init_hw, that one is nice to
prevent code duplication between driver load and resume.

v2: Add a comment to the code to warn future travellers of the dragon
dungeon ahead, suggested by Chris Wilson.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've added a bit of logic such that running the hangman test on chips
without any hw reset support at all doesn't wedge the gpu because the
reset failed. This relied on checking for non-null stop_rings.
Unfortunately I've botched a rebase somewhere and stop_rings is still
cleared at the old place before the reset code.

Fix this up so that running the i-g-t tests on gen2/3 doesn't result
in a wedged gpu.

v2: Actually remove the lines instead of adding them twice ... my git
license should be revoked immediately.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's the only way we know how to make the GPU actually forget about the
default context.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

Very basic code for context setup/destruction in the driver.

Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores.  With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5).  Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.

In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state.  The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.

All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.

There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.

As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.

v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

Empirical evidence suggests that we need to: On at least one ivb
machine when running the hangman i-g-t test, the rings don't properly
initialize properly - the RING_START registers seems to be stuck at
all zeros.

Holding forcewake around this register init sequences makes chip reset
reliable again. Note that this is not the first such issue:

commit f01db988
Author: Sean Paul <seanpaul@chromium.org>
Date:   Fri Mar 16 12:43:22 2012 -0400

    drm/i915: Add wait_for in init_ring_common

added delay loops to make RING_START and RING_CTL initialization
reliable on the blt ring at boot-up. So I guess it won't hurt if we do
this unconditionally for all force_wake needing gpus.

To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new
intel_info bit for that.

v2: Fixup missing commas in static struct and properly handling the
error case in init_ring_common, both noticed by Jani Nikula.

Cc: stable@vger.kernel.org
Reported-and-tested-by: NYang Guang <guang.a.yang@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

v4: fix the error reporting bugs pointed out by ickle.

v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.

Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.

Note that this slightly changes the semantics in the hangcheck code:
We now always cycle through all enabled rings instead of
short-circuiting the logic.

v2: Pull in a couple of suggestions from Ben and Daniel for
intel_ring_initialized() and not removing the warning (just moving them
to a new home, closer to the error).
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Added note to commit message about the small behaviour
change, suggested by Ben Widawsky.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
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>

Inspired by the recent ppgtt regression report, where switching of
dmar only for the gpu seems to fix things completely, I've looked
again at the semaphores+vt-d situation.

Contrary to my earlier testing a few months back my system is now
stable with dmar disabled for the igd, and not only when disabling
dmar completely.

So I'm rather hopeful that all our recent fixes for snb have changed
things for code and it's time to try enabling semaphores again. We've
also had issues with enabling semaphores which are not vt-d related,
but I guess these are all fixed by the autoreport-disabling and lazy
request fix. And there's only one way to find out whether there are
still other issues ...

When I've tried to apply this patch I've noticed that semaphores on
gen6 have already silently been enabled in

commit 2911a35b
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Apr 5 14:47:36 2012 -0700

    drm/i915: use semaphores for the display plane

Fix this up by only checking whether dmar is enabled on the gfx (not
on the entire system).
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While trying to fix up gen4 gpu reset in

commit f49f0586
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Sat Sep 11 01:19:14 2010 -0700

    drm/i915: Actually set the reset bit in i965_reset

a little confusion about when wait_for times out has been introduced -
wait for loops _until_ the condition is true.

This fixes gpu reset on my gm45, testing with my hangman code shows
that it's now fairly reliable - it only died after well over 100 reset
cycles.

Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On gen4+ we don't reset the display unit, so resetting the complete
modeset state should not be necessary.

We can't do reset on gen3 anyway, which leaves us with gen2 reset:
According to Chris Wilson, that doesn't work so great, so he suggested
we just ignore that. If the need ever arrises, we can re-add it later
on.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... we actually use it.

Unfortunately we can't reset both at the same time without also
resetting the display unit, so do render and media separately.

Also replace magic constants with proper #defines.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only half of them even cared, and it's always the same one.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- reset the stop_rings infrastructure while resetting the hw to
  avoid angering the hangcheck right away (and potentially declaring
  the gpu permanently wedged).

- ignore reset failures when hanging due to the hangman - we don't
  have reset code for all generations.

v2: Ensure that we only ignore reset failures when the hw reset is not
implemented and not when it failed.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Slightly cleans up the code and could be useful for e.g. Ben
Widawsky's hw context patches.

v2: New colours!

Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- need_display is always true, scrap it.
- don't reacquire the mutex to do nothing after having restored the
  gem state.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang detection
- error capture
- actual gpu reset
- reset of all the gem bookkeeping
- reinitialition of the entire gpu

This patch adds a debugfs to selectively stopping rings by ceasing to
update the hw tail pointer, which will result in the gpu no longer
updating it's head pointer and eventually to the hangcheck firing.
This way we can exercise the gpu hang code under controlled conditions
without a dying gpu taking down the entire systems.

Patch motivated by me forgetting to properly reinitialize ppgtt after
a gpu reset.

Usage:

echo $((1 << $ringnum)) > i915_ring_stop # stops one ring

echo 0xffffffff > i915_ring_stop # stops all, future-proof version

then run whatever testload is desired. i915_ring_stop automatically
resets after a gpu hang is detected to avoid hanging the gpu to fast
and declaring it wedged.

v2: Incorporate feedback from Chris Wilson.

v3: Add the missing cleanup.

v4: Fix up inconsistent size of ring_stop_read vs _write, noticed by
Eugeni Dodonov.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... and put them to so good use.

Note that there's functional change in vlv clock gating code, we now
no longer spuriously read back the current value of the bit. According
to Bspec the high bits should always read zero, so ORing this in
should have no effect.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
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>