drm/i915: prepare for multiple power wells

In the future we'll need to support multiple power wells, so prepare for
that here. Create a new power domains struct which contains all
power domain/well specific fields. Since we'll have one lock protecting
all power wells, move power_well->lock to the new struct too.

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com>
drm/i915: use power get/put instead of set for power on after init

Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.

This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
"power well on during init" logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.

For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.

This also fixes

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

    drm/i915: enable only the needed power domains during modeset

where removing intel_set_power_well() resulted in not releasing the
reference on the power well that was taken during init and thus leaving
the power well on all the time. Regression reported by Paulo.

v2:
- move the init_power_on flag to the power_domains struct (Daniel)

v3:
- add note about this being a regression fix too (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: remove device field from struct power_well

The only real need for this field was in
i915_{request,release}_power_well, but there we can get at it by a
container_of magic. Also since in the future we'll have multiple power
wells each with its own power_well struct it makes sense to remove the
field from there where it'd be just redundancy.

Suggested-by: Paulo Zanoni <paulo.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: rename i915_init_power_well to i915_init_power_domains

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.

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: 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: 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: add vlv power wells

Based on an early draft from Jesse.

Add support for powering on/off the dynamic power wells on VLV by
registering its dynamic power wells with the power domain framework.

I tested this so far only with VGA output and I have to double check the
HW state save/restore part as well as the need to force some clocks on
during power toggling. For all this Jesse has already some code posted
to intel-gfx, so that should be used as a basis.

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 a
later 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 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 output power domains

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.

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>