Since the encoder is tied to its port, we need to make sure the power
domain for that port is on before reading out the encoder HW state.

Note that this also covers also all connector get_hw_state handlers,
since all those just call the corresponding encoder get_hw_state
handler, which checks - after this change - for all power domains
the connector needs.

v2:
- no change
v3:
- push down the power domain checks into the specific encoder
  get_hw_state handlers (Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The connector detect and get_mode handlers need to access the port
specific HW blocks to read the EDID etc. Get/put the port power domains
around these handlers.

v2:
- get port power domain for HDMI too (Ville)
- get port power domain for the DP,HDMI audio detect handlers (Jesse)
- Leave the intel_runtime_pm_get/put in the DP detect function in place.
  Instead of just removing them, these should be moved to the appropriate
  power_well enable/disable handlers. We can do this after Paulo's
  'Merge PC8 with runtime PM, v2' patchset.
v3:
- rebased on latest -nightly
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.

This reverts

commit 2514bc51
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs

I'm pretty sure I'll regret this patch, but otoh I expect we won't
make progress here without poking the devil occasionally.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
Cc: peter@colberg.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NItai BEN YAACOV <candeb@free.fr>
Tested-by: NDavid En <d.engraf@arcor.de>
Reported-and-Tested-by: NMarcus Bergner <marcusbergner@gmail.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch fixes the blank screen bug introduced in 3.14-rc1 on the
MacBook Air 6,2. The comments state that we need to force edp vdd so
lets put it back.

The regression was introduced by the following commit:

commit dff392db
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 6 17:32:41 2013 -0200

    drm/i915: don't touch the VDD when disabling the panel

v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm we set the parent of the dp i2c device to be the correspondig
connector device. During driver cleanup we first remove the connector
device through intel_modeset_cleanup()->drm_sysfs_connector_remove() and
only after that the i2c device through the encoder's destroy callback.
This order is not supported by the device core and we'll get a warning,
see the below bugzilla ticket. The proper order is to remove first any
child device and only then the parent device.

The first part of the fix changes the i2c device's parent to be the drm
device. Its logical owner is not the connector anyway, but the encoder.
Since the encoder doesn't have a device object, the next best choice is
the drm device. This is the same what we do in the case of the sdvo i2c
device and what the nouveau driver does.

The second part creates a symlink in the connector's sysfs directory
pointing to the i2c device. This is so, that we keep the current ABI,
which also makes sense in case someone wants to look up the i2c device
belonging to a specific connector.

Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038782.html
Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-February/039427.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since

commit d9255d57
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Thu Sep 26 20:05:59 2013 -0300

it became clear that we need to separate the unload sequence into two
parts:

1. remove all interfaces through which new operations on some object
   (crtc, encoder, connector) can be started and make sure all pending
   operations are completed
2. do the actual tear down of the internal representation of the above
   objects

The above commit achieved this separation for connectors by splitting
out the sysfs removal part from the connector's destroy callback and
doing this removal before calling drm_mode_config_cleanup() which does
the actual tear-down of all the drm objects.

Since we'll have to customize the interface removal part for different
types of connectors in the upcoming patches, add a new unregister
callback and move the interface removal part to it.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of modifying intel_panel in lvds_init_connector/dsi_init/
edp_init_connector, making changes to move intel_panel->downclock_mode
initialization to intel_panel_init()

v2: Jani's review comments incorporated
Removed downclock_mode local variable in dsi_init and
edp_init_connector
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NPradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The initial jiffies value can be non-0, so set the inital panel power
sequencer timestamps accordingly. This didn't cause a problem on 64 bit
machines but on 32 bit jiffies is initially -300*HZ, so if the panel
power is initally off in the call from edp_panel_vdd_on()->
wait_panel_power_cycle() we'd wait up to ~300 sec more than needed.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.

v2: Accepted all Daniel's suggestions:
    * grab modeset lock
    * loop over connector and check DPMS on
    * return errors
    * use _eDP1 suffix for easy future extension
    * don't cache crc_supported neither latest crc
    * return crc as a full array and read it at once with aux.
    * use 0 to turn TEST_SINK off.
    * split the drm_helpers definitions in another patch.

v3: Accepted 2 Damien's suggestion: remove h from printf hexa
    and return ENODEV when eDP not present instead of EAGAIN.

v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove
    _retry from aux read.

v5: removing last missing useless _retry (by Damien)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need a bit more flexibility here in the future, bits get shuffled
around.

v2: more descriptive commit message (Jani Nikula)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So it's easier to compare what we program with the documentation, not
having to jump at all.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also, move that computation outside of the for loop that tries 5 times,
this value doesn't change between tries.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A tiny clean-up to allow better code separation between platforms.

v2: Fix comment placement (put in in i9xx_get_aux_clock_divider()) and
    nuke the outdated PCH eDP comment (Jani Nikula)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support it. The
sink device must report that is supports Displayport 1.2 and the HBR2 bit rate in the
DPCD in order to use HBR2.
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because we already do the wait in software: see
ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.

For the "backlight on" delay, even BSpec says we need to program 0x1
to PP_ON_DELAYS 12:0.

For the "backlight off" delay, if we don't do the same thing, when we
call ironlake_wait_panel_off we'll end up waiting for the it again.

On my machine the off delay is 200ms, so we save this amount of time
whenever we disable the panel (e.g, suspend).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Function ironlake_wait_panel_off should just wait for the power off
delay, while function ironlake_wait_panel_power_cycle should wait for
the panel cycle (that's required after we turn the panel off, before
we enable it again).

The problem is that, currently, ironlake_wait_panel_off is waiting not
just for the panel to be off, but also for the power cycle delay and
the backlight off delay. This function relies on the PP_STATUS bits
3:0, which are not documented and not supposed to be used. A quick
analysis of the values we get while waiting quickly shows that power
off is reached while bits 3:0 are still 0x1, and the time it takes to
become 0x0 is the power cycle delay.

On my system with backlight off delay of 200ms, power down delay of
50ms and power cycle delay of 500ms, this is what I get:
 - Start waiting with value 0x80000008, timestamp 6.429364.
 - Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996)
 - Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913)
 - Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894)
 - Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648)

As you can see, ironlake_wait_panel_off is sleeping 760ms instead of
the expected 50ms: the first 200ms matches the backlight off delay
(which we should already have waited for!), then the 50ms for the real
panel off delay, then the 500ms for the panel power cycle.

This patch makes is look just at bits 31 and 29:28, which will ignore
the panel power cycle.

And just to be clear: this saves 500ms on my system every time we
disable the panel. But we can still save 200ms more (the backlight off
delay) on the next patches.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuougseek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I like how the macros are nicely column-aligned, so we can properly
compare what each macro waits for, but a column full of zeroes doesn't
really help anything: it just makes the lines bigger, and they're
already way past 80 columns. I imagine this column was used in the
past, but IMHO now we can get rid of it.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They now also work on vlv, which has the regs somewhere else. And
daring a glance into the looking glass it seems like this
functionality will continue to work the same for the next few hardware
platforms.

So it's better to just remove that misleading prefix and have a bit
shorter code for better readability.

The only exceptions are the panel/backlight functions shared with
intel_ddi.c, those get an intel_ prefix.

While at it make the vdd_on/off functions static.

And one straggler was missing the edp_ in the name, so make everything
neatly OCD.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch does is that we record the
timestamp of when action A happened, then, just before action B, we
look at how much time has passed and only sleep the remaining amount
needed.

With this change, I am able to save about 5-20ms (out of the total
200ms) of the backlight_off delay and completely skip the 1ms
backlight_on delay. The 600ms vdd_off delay doesn't happen during
normal usage anymore due to a previous patch.

v2: - Rename ironlake_wait_jiffies_delay to intel_wait_until_after and
      move it to intel_display.c
    - Fix the msleep call: diff is in jiffies
v3: - Use "tmp_jiffies" so we don't need to worry about the value of
      "jiffies" advancing while we're doing the math.
v4: - Rename function again.
    - Move function to i915_drv.h.
    - Store last_power_cycle at edp_panel_off too.
    - Use msecs_to_jiffies_timeout, then replace the msleep with an
      open-coded version that avoids the extra +1 jiffy.
    - Try to add units to every variable name so we don't confuse
      jiffies with milliseconds.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our driver has two different ways of waiting for panel power
sequencing delays. One of these ways is through
ironlake_wait_panel_status, which implicitly uses the values written
to our registers. The other way is through the functions that call
intel_wait_until_after, and on this case we do direct msleep() calls
on the intel_dp->xxx_delay variables.

Function intel_dp_init_panel_power_sequencer is responsible for
initializing the _delay variables and deciding which values we need to
write to the registers, but it does not write these values to the
registers. Only at intel_dp_init_panel_power_sequencer_registers we
actually do this write.

Then problem is that when we call intel_dp_i2c_init, we will get some
I2C calls, which will trigger a VDD enable, which will make use of the
panel power sequencing registers and the _delay variables, so we need
to have both ready by this time. Today, when this happens, the _delay
variables are zero (because they were not computed) and the panel
power sequence registers contain whatever values were written by the
BIOS (which are usually correct).

What this patch does is to make sure that function
intel_dp_init_panel_power_sequencer is called earlier, so by the time
we call intel_dp_i2c_init, the _delay variables will already be
initialized. The actual registers won't contain their final values,
but at least they will contain the values set by the BIOS.

The good side is that we were reading the values, but were not using
them for anything (because we were just skipping the msleep(0) calls),
so this "fix" shouldn't fix any real existing bugs. I was only able to
identify the problem because I added some debug code to check how much
time time we were saving with my previous patch.

Regression introduced by:
    commit ed92f0b2
    Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Date:   Wed Jun 12 17:27:24 2013 -0300
        drm/i915: extract intel_edp_init_connector

v2: - Rewrite commit message.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add new definitions for hotplug live status bits for VLV2 since they're
in reverse order from the gen4x ones.

Changelog:
- Restored gen4 bit definitions
- Added new definitions for VLV2
- Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct
  bit defintions
- Replaced a lost trailing brace for the added switch()
Signed-off-by: NTodd Previte <tprevite@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951
[danvet: Switch to _VLV postfix instead of prefix and regroupg
comments again so that the g4x warning is right next to those defines.
Also add a _G4X suffix for those special ones. Also cc stable.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.

As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.

v2:
- fix explanation of change impact (Chris)
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.

Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).

Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.

See also the next patch fixing the other half of this issue.

Solution suggested by Ville.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current values seem to be defined in a format that's specific to the
i915, gma500 and radeon drivers. To make this more generally useful, use
the values as defined in the specification.

While at it, prefix the constants with DP_ for improved namespacing.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for panel_power_cycle_delay, not
panel_power_down_delay, because the power down delay was already
respected when we disabled the panel.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo.
Also drop the runtime_pm_put call which now has to go due to different
patch ordering. Also from Paul.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get some messages saying we're touching registers while the HW
is suspended.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are needed when we cat the debugfs and sysfs files.

V2: - Rebase
V3: - Rebase
V4: - Rebase
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When inspecting reports that boot/suspend/resume times are unusual it
would be useful to clearly identify the time we must spend waiting for
the hardware to complete its task. In this case we have a notification
before we start waiting for the panel to change state, but none
afterwards - which would be useful.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sweeping some dead code away.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reduce the eDP detection to just checking if it's port A, or if
the VBT tells us that the port is eDP for the other ports.
Suggested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.

So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051Tested-by: NRobert Hooker <robert.hooker@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now we have this everywhere. Next up would be to wire up the DP
hotplug pin to speed up panel power sequencing for eDP panels ...

I've decided to leave the has_aux_irq logic in the code, it should
come handy for hw bringup.

For testing/fail-safety the dp aux code already has a timeout when
waiting for interrupts to signal completion and screams rather loud if
they don't arrive in time. Given that we need a real piece of hw to
talk to anyway this is probably as good as it gets.

v2: Don't check the dp aux channel bits on i965 machines, they have a
different meaning there. Yay for reusing bits at will! Spotted by
Jani.

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We used to put the local sink and any downstream sinks to power down
mode at disable or dpms off using the DPCD SET_POWER register, until
this was broken by

commit e8cb4558
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 1 13:05:48 2012 +0200

    drm/i915/dp: convert to encoder disable/enable

Fix it.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index.  This should better to gather for upcoming platform.

v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO register define.

v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
DPIO_PHY, and remove unrelated change. (Ville)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Broadwell PSR support is a superset of Haswell. With this simple
register base calculation, everything that worked on HSW for eDP PSR
should work on BDW.

Note that Broadwell provides additional PSR support. This is not
addressed at this time.

v2: Make the HAS_PSR include BDW

v3: Use the correct offset (I had incorrectly used one from my faulty
brain) (Art!)

v4: It helps if you git add

v5: Be explicit about not setting min link entry time for BDW. This
should be no functional change over v4 (Jani)
Reviewed-by: NArt Runyan <arthur.j.runyan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They're not the same as the Haswell ones.
Reviewed-by: NArt Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>