drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb

Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.

For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.

Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.

To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).

Unfortunately this requires us to move the bifurcate helpers around a
bit.

Also update the commit message, I've misanalyzed the bug rather badly.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: rename i915_init_power_well to init_power_domains_init

Similarly rename the other related functions in the power domain
interface.

Higher level driver code calling these functions knows only about power
domains, not the underlying power wells which may be different on
different platforms. Also these functions really init/cleanup/resume
power domains and only through that all related power wells, so rename
them accordingly.

Note that I left i915_{request,release}_power_well as is, since that
really changes the state only of a single power well (and is HSW
specific). It should also get a better name once we make it more
generic by controlling things through a new audio power domain.

v4:
- use intel prefix instead of i915 everywhere (Paulo)
- use a $prefix_$block_$action format (Daniel)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: handle faked missed interrupts as simulated hangs, too

Otherwise QA will report this as a real hang when running igt
ZZ_missed_irq.

v2: Actually test the right stuff and really shut up the DRM_ERROR
output ...

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70747
Tested-by: lu hua <huax.lu@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Capture batchbuffer state upon GPU hang

The bbstate contains useful bits of debugging information such as
whether the batch is being read from GTT or PPGTT, or whether it is
allowed to execute privileged instructions.

v2: Only record BB_STATE for gen4+

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: use enum pipe consistently in i915_irq.c

Request by Ville in his review of the CRC stuff. This converts
everything but ilk_display_irq_handler since that needs a bit more
than a simple search&replace to look nice.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: refactor ilk display interrupt handling

- Use a for_each_loop and add the corresponding #defines.
- Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for
  consistency with everything else.
- Also use macros (and add the missing one for plane flips) for the
  ivb display interrupt handler.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Drop the useless parens that Ville spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Merge remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly

Conflicts:
	drivers/gpu/drm/i915/i915_dma.c
	drivers/gpu/drm/i915/i915_drv.c
	drivers/gpu/drm/i915/intel_crt.c
	drivers/gpu/drm/i915/intel_ddi.c
	drivers/gpu/drm/i915/intel_display.c
	drivers/gpu/drm/i915/intel_dp.c
	drivers/gpu/drm/i915/intel_drv.h
Merge remote-tracking branch 'drm-upstream/drm-next' into drm-intel-nightly
drm/i915: add back checking for i915_disable_power_well

In

commit 6efdf354ddb186c6604d1692075421e8d2c740e9
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Oct 16 17:25:52 2013 +0300

the check for i915_disable_power_well flag was removed by overlook,
so add it back now.

Reported-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: support for multiple power wells

HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.

The idea is to keep the existing power domain API used by the rest of
the driver and create a mapping between these power domains and the
underlying power wells. This mapping can differ from one HW to another
but high level driver code doesn't need to know about this. Through the
existing get/put API it would just ask for a given power domain and the
power domain framework would make sure the relevant power wells get
enabled in the right order.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: add an always_on_domains field

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: factor out reset_vblank_counter

We need to do the same for other GENs adding power domain support in the
upcoming patches.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: restrict HSW specific powerdomains HW init to HSW

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: check powerwell in get_pipe_config

We should only try to read out the pipe's HW state if it's powered.
Otherwise we should just conclude that it's off.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: add intel_encoder_get_hw_state

We need to make sure that we only try to read out the HW state if the
required power domains are on. Otherwise we should just conclude that
the given encoder is off, which case is already handled by the callers
of this function. The check for the power domain will be added in the
next patch here just prepare for that by having a dedicated function
instead of directly calling the encoder's get_hw_state hook.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: check output power domains before accessing related HW regs

Parts that poke output specific HW blocks like the encoder HW state
readout or connector hotplug detect code need to be able to check
whether power domains they require are on or enable/disable these. For
this purpose add a set of power domains that refer to HW blocks with
output functionality and check/enable/disable these where needed.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: get port power domains for connector detect

At least the VLV hotplug / DDC HW block needs the VLV dynamic power well
to be on, so make sure this is the case when we access these blocks.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: fix HAS_POWER_WELL->IS_HASWELL

When adding more GENs to the HAS_POWER_WELL macro this part of the code
will be relevant only for HSW.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: support for multiple power wells

HW generations so far had only one always-on power well and optionally
one dynamic power well. Upcoming HW gens may have multiple dynamic power
wells, so add some infrastructure to support them.

The idea is to keep the existing power domain API used by the rest of
the driver and create a mapping between these power domains and the
underlying power wells. This mapping can differ from one HW to another
but high level driver code doesn't need to know about this. Through the
existing get/put API it would just ask for a given power domain and the
power domain framework would make sure the relevant power wells get
enabled in the right order.

Signed-off-by: Imre Deak <imre.deak@intel.com>