drm/i915: pack the intel_display_power_domain enum

A following patch will change the enum values, so that they can be
used in bitmasks. Prepare for that now, by removing the gap in the
enum value space.

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

It is just cleaner this way and makes it easier to add support for
other HW generations with a always-on power wells powering a different
set of domains.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: change power_well->lock to be mutex

There is no hard need for this to be a spin lock, as we don't take these
locks in irq context from anywhere. An upcoming patch will add calls to
punit read/write functions from within regions protected by this lock
and those functions need a mutex in turn. As a solution for that convert
the spin lock to be a mutex.

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

We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: enable only the needed power domains during modeset

So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder) we didn't do anything, for all other domains we just
enabled the single dynamic power well.

Future HW generations will change this, as they add multiple dynamic
power wells. Support for these will be added later, this patch prepares
for those by making sure we only enable the required domains.

Note that after this change on HSW we'll enable all power domains even
if it was the domain for the panel fitter on pipe A or the eDP
transcoder. This isn't a problem since the power domain framework
already checks if the domain is on an always-on power well and doesn't
do anything in this case.

Signed-off-by: Imre Deak <imre.deak@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.

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>
drm/i915: vlv: fix VGA hotplug after modeset

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