This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.

v2:
- don't set intel_dp ptr for non-eDP encoders (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already call intel_display_power_get, which will get a power
domain, and every power domain should get a runtime PM reference,
which will wake up the machine.

v2: - Also touch intel_crt_detect() (Ville).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Fixup commit message as spotted by Ville.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only need to check for this in psr_enable, everything else is
already protect by the dev_priv->psr.enabled checks. Those need the
psr locking, but these functions are called infrequent enough that the
locking overhead is negligible.

Suggested by Chris Wilson.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm change.

- Use frontbuffer tracking bits stuff to separate disable and
  re-enable.

- Don't re-check everything in the psr work. We have now accurate
  tracking for everything, so no need to check for sprites or tiling
  really. Allows us to ditch tons of locks.

- That in turn allows us to properly cancel the work in the disable
  function - no more deadlocks.

- Add a check for HSW sprites and force a flush. Apparently the
  hardware doesn't forward the flushing when updating the sprite base
  address. We can do the same trick everywhere else we have such
  issues, e.g. on baytrail with ... everything.

- Don't re-enable psr with a delay in psr_exit. It really must be
  turned off forever if we detect a gtt write. At least with the
  current frontbuffer render tracking. Userspace can do a busy ioctl
  call or no-op pageflip to re-enable psr.

- Drop redundant checks for crtc and crtc->active - now that they're
  only called from enable this is guaranteed.

- Fix up the hsw port check. eDP can also happen on port D, but the
  issue is exactly that it doesn't work there. So an || check is
  wrong.

- We still schedule the psr work with a delay. The frontbuffer
  flushing interface mandates that we upload the next full frame, so
  need to wait a bit. Once we have single-shot frame uploads we can do
  better here.

v2: Don't enable psr initially, rely upon the fb flush of the initial
plane setup for that. Gives us more unified code flow and makes the
crtc enable sequence less a special case.

v3: s/psr_exit/psr_invalidate/ for consistency

v4: Fixup whitespace.

v5: Correctly bail out of psr_invalidate/flush when
dev_priv->psr.enabled is NULL. Spotted by Rodrigo.

v6:
- Only schedule work when there's work to do. Fixes WARNINGs reported
  by Rodrigo.
- Comments Chris requested to clarify the code.

v7: Fix conflict on rebase (Rodrigo)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v6)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's not really optional to have locking ...

The ugly part is how much locking the psr work needs since it has to
recheck everything. Which is way too much. But we need to ditch the
psr work in it's current form anyway and implement proper frontbuffer
tracking.

The other nasty bit that had to go was the delayed work cancle in
psr_exit. Which means a bunch of races just became a bit more likely,
but mea culpa.

v2: Fixup HAS_PSR checks, resulting in uninitialized mutex issues.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.

v2: Improve bisectability by moving one hunk to an earlier patch.

v3: added missing dev_priv declaration (Rodrigo)
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v2)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make sure we track the sw side (psr.active) correctly and WARN
everywhere it might get out of sync with the hw.

v2: Fixup WARN_ON logic inversion, reported by Rodrigo.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's disabled already except when we've raced.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Trying to fish that one out through looping is a bit a locking
nightmare. So just set it and use it in the work struct.

v2:
- Don't Oops in psr_work, spotted by Rodrigo.
- Fix compile warning.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Can't review this right now due to lack of DRRS code.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Due to runtime pm and system s/r we need to restore hw state every
time we enable a pipe again. Hence trying to avoid that is just
pointless book-keeping which Rodrigo then tried to work around by
manually adding psr_setup calls to our resume code.

Much simpler to just remove code instead.

v2: Properly bail out of psr exit if psr isn't enabled. Spotted by
Rodrigo.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds DP 1.2 MST support on Haswell systems.

Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.

Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders

Changes since v0.2:
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.

Changes since v0.3:
updates for mst apis
more state checker fixes
irq handling improvements
fbcon handling support
improved reference counting of link - fixes redocking.

Changes since v0.4:
handle gpu reset hpd reinit without oopsing
check link status on HPD irqs
fix suspend/resume

Changes since v0.5:
use proper functions to get max link/lane counts
fix another checker backtrace - due to connectors disappearing.
set output type in more places fro, unknown->displayport
don't talk to devices if no HPD asserted
check mst on short irqs only
check link status properly
rebase onto prepping irq changes.
drop unsued force_act

Changes since v0.6:
cleanup unused struct entry.

[airlied: fix some sparse warnings].
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not enough brown paper bags, you'll have to share one.
(oops below).

The initial match condition code was racy (locking is coming I hear).

then along came:
cd234b0b
drm/i915: Do not dereference NULL crtc or fb until after checking

Chris made an attempt to fix it, Ben "reviewed" it.
Daniel merged it.

Then
drm/i915: Make use of intel_fb_obj() (v2)
2ff8fde1

made it worse by removing the obj check later.

All in all, my laptop can't barely turn off the display
without hitting this.

Posted to #intel-gfx out of niceness, but I've merged
this already into drm-next.

Here's an oops.
[   11.528185] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0
[   11.528233] IP: [<ffffffffa0161fde>] intel_edp_psr_match_conditions+0x1e/0x2e0 [i915]
[   11.528294] PGD 35bc0067 PUD c997c067 PMD 0
[   11.528321] Oops: 0000 [#1] SMP
[   11.528916] CPU: 3 PID: 244 Comm: kworker/3:2 Not tainted 3.16.0-rc4+ #17
[   11.528949] Hardware name: LENOVO 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
[   11.529004] Workqueue: events intel_edp_psr_work [i915]
[   11.529031] task: ffff8803079fdaa0 ti: ffff8803079c4000 task.ti: ffff8803079c4000
[   11.529067] RIP: 0010:[<ffffffffa0161fde>]  [<ffffffffa0161fde>] intel_edp_psr_match_conditions+0x1e/0x2e0 [i915]
[   11.529129] RSP: 0018:ffff8803079c7d40  EFLAGS: 00010246
[   11.529155] RAX: 0000000000000000 RBX: ffff88030c11c000 RCX: c000000000000000
[   11.529189] RDX: 0000000000000001 RSI: 1df0000000000000 RDI: ffff88030c1190d8
[   11.529222] RBP: ffff8803079c7d60 R08: ffffffff82691140 R09: 0000000000000000
[   11.529256] R10: ffff8803079fdaa0 R11: 3e00000000000000 R12: ffff88030c11c728
[   11.529290] R13: ffff88030c1190d8 R14: ffff88031e2d8e00 R15: 00000000000000c0
[   11.529324] FS:  0000000000000000(0000) GS:ffff88031e2c0000(0000) knlGS:0000000000000000
[   11.529361] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   11.529389] CR2: 00000000000000d0 CR3: 00000000c8d9d000 CR4: 00000000001407e0
[   11.529423] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   11.529457] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   11.529489] Stack:
[   11.529500]  ffff88030c119000 ffff88030c11c728 ffff88030c1190d8 ffff88031e2d8e00
[   11.529541]  ffff8803079c7d88 ffffffffa01679b2 ffff880035b29a80 ffff880307909f00
[   11.529583]  ffff88031e2d4740 ffff8803079c7df8 ffffffff810a78ab ffffffff810a7849
[   11.529624] Call Trace:
[   11.529654]  [<ffffffffa01679b2>] intel_edp_psr_work+0x52/0x90 [i915]
[   11.529689]  [<ffffffff810a78ab>] process_one_work+0x1db/0x540
[   11.529719]  [<ffffffff810a7849>] ? process_one_work+0x179/0x540
[   11.529750]  [<ffffffff810a81ed>] worker_thread+0x11d/0x520
[   11.529779]  [<ffffffff810a80d0>] ? create_and_start_worker+0x60/0x60
[   11.529810]  [<ffffffff810aeb04>] kthread+0xe4/0x100
[   11.529836]  [<ffffffff810aea20>] ? kthread_create_on_node+0x200/0x200
[   11.529870]  [<ffffffff81705ebc>] ret_from_fork+0x7c/0xb0
[   11.529896]  [<ffffffff810aea20>] ? kthread_create_on_node+0x200/0x200
[   11.529926] Code: ba 31 13 f0 c9 85 f6 75 84 eb d0 66 90 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 53 48 8b 87 68 ff ff ff 48 8b 9f 28 ff ff ff <48> 8b 80 d0 00 00 00 4c 8b 63 28 48 8b 40 48 48 85 c0 0f 84 1a
[   11.530110] RIP  [<ffffffffa0161fde>] intel_edp_psr_match_conditions+0x1e/0x2e0 [i915]
[   11.530163]  RSP <ffff8803079c7d40>
[   11.530180] CR2: 00000000000000d0
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 38aecea0.

This breaks Haswell Thinkpad + Lenovo dock in SST mode with a HDMI monitor attached.

Before this we can 1920x1200 mode, after this we only ever get 1024x768, and
a lot of deferring.

This didn't revert clean, but this should be fine.

bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1117008
Cc: stable@vger.kernel.org # v3.15
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way only the dynamic WRPLL selection for hdmi ddi mode is
done in intel_ddi_pll_select.

v2: Don't clobber the precomputed values when selecting clocks fro
hdmi encoders.
v3 (from Paulo): Rebase on top of the s/IS_HASWELL/HAS_DDI/ patch.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <przanoni@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Don't let it fall in the HAS_PCH_SPLIT() case.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should hopefully simplify the display code slightly and also
solves at least one mistake in intel_pipe_set_base() where
to_intel_framebuffer(fb)->obj is referenced during local variable
initialization, before 'if (!fb)' gets checked.

Potential uses of this macro were identified via the following
Coccinelle patch:

        @@
        expression E;
        @@
        * to_intel_framebuffer(E)->obj

        @@
        expression E;
        identifier I;
        @@
          I = to_intel_framebuffer(E);
          ...
        * I->obj

v2: Rewrite some NULL tests in terms of the obj rather than the fb.
    Also add a WARN() if trying to pageflip with a disabled primary
    plane.  [Suggested by Chris Wilson]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.

Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg

Ver3: moved SYS_RESTART check earlier, new name for pp_div.

Ver4: Minor issue changes

Ver5: Move registration of reboot notifier to edp_connector_init,
      Added warning comment to handler about lack of PM notification.
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new checks in place, we can see we're doing things backwards,
so fix them up per the spec.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.

However with DP 1.2 MST we need to handle the short irqs on their
own outside the modesetting locking the long hpd's involve. This
patch adds the framework to distinguish between short/long to the
current code base, to lay the basis for future DP 1.2 MST work.

This should mean we get better bisectability in case of regression
due to the new irq handling.

v2: add GM45 support (untested, due to lack of hw)
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
[danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling
race fixes and a trivial one in intel_drv.h with the psr code.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It doesn't make sense to never again schedule the work, since by the
time we might want to re-enable psr the world might have changed and
we can do it again.

The only exception is when we shut down the pipe, but that's an
entirely different thing and needs to be handled in psr_disable.

Note that later patch will again split psr_exit into psr_invalidate
and psr_flush. But the split is different and this simplification
helps with the transition.

v2: Improve the commit message a bit.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have _enable/_disable interfaces now for the modeset sequence and
intel_edp_psr_exit for workarounds.

The callsites in intel_display.c are all redundant with the modeset
sequence enable/disable calls in intel_ddi.c. The one in
intel_sprite.c is real and needs to be switched to psr_exit.

If this breaks anything then we need to augment the enable/disable
functions accordingly.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's not needed and further more will get in the way of a sane
locking scheme - psr_exit _can't_ take modeset locks due to lock
inversion, and at least once dp mst hits the connector list
is no longer static.

But since we track all state in dev_priv->psr there is no need
at all.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduce generic functions to register and unregister connectors. This
provides a common place to add and remove associated user space
interfaces.
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Any comment containing "current Intel hardware supports" quickly
becomes obsolete, so remove it and let people discover the information
by looking at the function implementation.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Two BSpec updates changed the recommended values for BDW eDP and DP
DDI buffer translations. Now the signal levels also match the HSW signal
levels, which simplify things a little bit.

It seems some DP sinks don't work properly without voltage level 0 and
pre-emphasis level 3, so this patch may fix some bugs on
panels/monitors that happen on BDW but not on HSW.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The perfect solution for psr_exit is the hardware tracking the changes and
doing the psr exit by itself. This scenario works for HSW and BDW with some
environments like Gnome and Wayland.

However there are many other scenarios that this isn't true. Mainly one right
now is KDE users on HSW and BDW with PSR on. User would miss many screen
updates. For instances any key typed could be seen only when mouse cursor is
moved. So this patch introduces the ability of trigger PSR exit on kernel side
on some common cases that.

Most of the cases are coverred by psr_exit at set_domain. The remaining cases
are coverred by triggering it at set_domain, busy_ioctl, sw_finish and
mark_busy.

The downside here might be reducing the residency time on the cases this
already work very wall like Gnome environment. But so far let's get focused
on fixinge issues sio PSR couild be used for everybody and we could even
get it enabled by default. Later we can add some alternatives to choose the
level of PSR efficiency over boot flag of even over crtc property.

v2: remove exit from connector_dpms. Daniel pointed this is the wrong way and
also this isn't needed for BDW and HSW anyway.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Broadwell has a PSR per transcoder, where DDIA supports
link disable and link standby modes while other
transcoders only support link standby.
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When link is in stand by and PSR exit is triggered by a primary or sprite
plane flip this mode allows only one single updated frame to be send to
display than get back to PSR immediately.
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also do not cache aux info. That info could be related to another panel.
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Being more conservative by enabling PSR only on psr_enable function.
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's be more conservative and protect platforms that don't
support PSR from unecessary interactions.
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Try to force the PHY clock buffer enables to make the clock routing
work.

v2: Fix the pipe B case to actually enable CH0 clock buffers
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These should make it possible to feed port C from pipe A or port B from
pipe B. Didn't quite seem to work though.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

"Because our driver assumes only one panel is PSR capable, and we
already have other PSR information on dev_priv instead of intel_dp. If
we ever support multiple PSR panels, we'll have to move struct
i915_psr to intel_dp anyway." (by Paulo)

v2: Avoid more than one setup. Removing initialization
    and trusting allocation. (By Paulo Zanoni).
v3: rebase.
v4: Adding comment.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For atomic, it will be quite necessary to not need to care so much
about locking order.  And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.

Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.

Atomic will use this to keep track of which locks have been acquired
in a transaction.

v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This should avoid races between connector probing and HPD
irqs in the future, currently mode_config.mutex blocks this
possibility.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
  properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
  modeset-relevant connector state (e.g. properties which control the
  panel fitter).

The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.

Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.

The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.

For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.

Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.

I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
  sprinkle mode_config.connection_mutex over this file a bit, but
  since it already lacks mode_config.mutex this patch wont make the
  situation any worse. This is material for a follow-up patch.

- omap has a omap_framebuffer_flush function which walks the
  connector->encoder->crtc links and is called from many contexts.
  Some look like they don't acquire mode_config.mutex, so this is
  already racy. Again fixing this is material for a separate patch.

- The radeon hot_plug function to retrain DP links looks at
  connector->dpms. Currently this happens without any locking, so is
  already racy. I think radeon_hotplug_work_func should gain
  mutex_lock/unlock calls for the mode_config.connection_mutex.

- Same applies to i915's intel_dp_hot_plug. But again, this is already
  racy.

- i915 load_detect code needs to acquire this lock. Which means the
  w/w dance due to Rob's work will be nicely contained to _just_ this
  function.

I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.

v1: original (only compile tested)

v2: missing mutex_init(), etc (from Rob Clark)

v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
  get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.

Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>