drm/i915: turn the eDP VDD on for any i2c transactions

If the eDP output is disabled, then we try to use /dev/i2c-X file to
do i2c transations, we get a WARN from intel_dp_check_edp() saying
we're trying to do AUX communication with the panel off. So this
commit reorganizes the code so we enable the VDD at
intel_dp_i2c_aux_ch() instead of just the callers inside i915.ko.

This fixes the i2c subtest from the pc8 test of intel-gpu-tools on
machines that have eDP panels.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: reduce eDP VDD message verbose

Now we only print messages when we actually enable VDD and when we
actually disable VDD.

The changes in the last commit triggered a big number of messages
while the driver was being initialized, and I thought we were toggling
things on/off too many times, but that was not really true: we were
just being too verbose.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/vlv: Fix typo in the DPIO register define.

Incorrect definition DPIO_TX3_SWING_CTL4.

From Ville's review: "Based on the specs, the typo meant that HDMI B
ended up using "incorrect" de-emphasis for the TMDS data lanes."

Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add comment from Ville's review about the impact.]
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/sysfs: Do not drop device reference twice

device_unregister() already drops its reference to the struct device, so
explicitly calling put_device() before device_unregister() can cause the
device to have been freed before it can be unregistered.

Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/i915: add audio power domain

This way the code is simpler and can also be used for other platforms
where the audio power domain->power well mapping is different.

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 always-on power wells instead of special casing them

Instead of using a separate function to check whether a power domain is
is always on, add an always-on power well covering all these power
domains and do the usual get/put on these unconditionally. Since we
don't assign a .set handler for these the get/put won't have any effect
besides the adjusted refcount.

This makes the code more readable and provides debug info also on the
use of always-on power wells (once the relevant debugfs entry is added.)

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

Some upcoming platforms with power wells don't have this register, so
check for Haswell instead.

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga

This may need work if other platforms do the same thing, but in the
meantime we should avoid looking at HSW specific bits in this generic
function.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
drm/i915: restrict HSW specific powerdomains HW init to HSW

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: add a default always-on power well

So far we distinguished platforms without a dynamic power well with
the HAS_POWER_WELL macro and for such platforms we didn't call any power
domain functions. Instead of doing this check we can add an always-on
power well for these platforms and call the power domain functions
unconditionally. For always-on power wells we only increase/decrease
their refcounts, otherwise they are nop.

This makes high level driver code more readable and as a bonus provides
some idea of the current power domains state for all platforms (once
the relevant debugfs entry is added).

Signed-off-by: Imre Deak <imre.deak@intel.com>
drm/i915: add a debugfs entry for power domain info

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

We need to do the same for other platforms in upcoming patches.

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: 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 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>