It is possible for userspace to create a big object large enough for a
256x256, and then switch over to using it as a 64x64 cursor. This
requires the cursor update routines to check for a change in width on
every update, rather than just when the cursor is originally enabled.

This also fixes an issue with 845g/865g which cannot change the base
address of the cursor whilst it is active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[Antti:rebased, adjusted macro names and moved some lines, no functional
changes]
Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Tested-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Cc: stable@vger.kernel.org
Testcase: igt/kms_cursor_crc/cursor-size-change
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

If both KMS is disabled (by i915.modeset=0 or nomodeset parameters) and
UMS is disabled (by CONFIG_DRM_I915_UMS=n, the default), the user might
not be aware his setup is not supported. Inform the users (and, by
extension, the poor i915 developers having to read their dmesgs in bug
reports) why their graphics experience might be lacking.

A similar message was added on the UMS path in
commit e147accb
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Oct 10 15:25:37 2013 +0300

    drm/i915: tell the user KMS is required for gen6+

but it won't be reached if CONFIG_DRM_I915_UMS=n since
commit b30324ad
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Nov 13 22:11:25 2013 +0100

    drm/i915: Deprecated UMS support

v2: Use DRM_DEBUG_DRIVER.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.

A few of the checks here were also updated based on suggestions by
Ville Syrjälä.

v3:
 - s/primary_helper/plane_helper/ --- this checking logic may be useful
   for other types of planes as well.
 - Fix visibility check (need to dereference visibility pointer)
v2:
 - Pass src/dest/clip rects and min/max scaling down to helper to avoid
   duplication of effort between helper and drivers (suggested by
   Ville).
 - Allow caller to specify whether the primary plane should be
   updatable while the crtc is disabled.

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
[danvet: Include header properly and fixup declaration mismatch to
make this compile.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.

Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane helper).

Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Some platforms may not have it, and enumerating it is both confusing and
time consuming due to the hotplug and DDC probing.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Gen2 doesn't have the ring idle/stop bits in the SCPD/MI_MODE register,
so don't go spewing warnings about the state of those bits.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

If the user tries to mmap through the GTT an object that is marked as
snooped, we report an error rather than allow the GPU to hang the
machine. The choice of EINVAL, however, was unfortunate as we turn that
into a WARN rather than a quiet SIGBUS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Move the MI_ARB_STATE MI_ARB_C3_LP_WRITE_ENABLE setup to
gen3_init_clock_gating() from i915_gem_load() when KMS is enabled. Leave
it in i915_gem_load() for the UMS case, but add an explcit check, just
to make it easier to spot it when we eventually rip out UMS support.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

85x also has a similar AGPBUSY# bit as gen3. Enable it to make
sure vblank interrupts don't get dealyed during C3 state.

There's also another bit which controls whether AGPBUSY# is asserted
based on pending cacheable cycles and interrupts, or just based on
pending commands in the ring and interrupts. Select the cacheable
cycles mode since that seems to be the new way of doing things in
85x, and it does give slightly better C3 residency numbers with
glxgears running.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

My Gen3 Bspec lists the AGPBUSY# bit in INSTPM as an enable bit rather
than a disable bit. Our code has the opposite idea. Make the code match
the spec.

Might fix some gen3 C3 related interrupt delivery problems. Untested
due to lack of hardware.

v2: call it AGPBUSY_INT_EN to make it clearer it has to do with interrupts
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

I don't see why we wouldn't want interrupts to wake up the CPU from C3
always, so just set the AGPBUSY# bit in gen3_init_clock_gating().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

When doing this, all PLLs should be disabled.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We need to do this anytime we power gate the DPIO common well.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

There may be a dependency here.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This needs to be done before we power back on the CMN_BC well so the PHY
can calibrate properly.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We do this at runtime and later on now.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This is a bit like the CMN reset de-assert we do in DPIO_CTL, except
that it resets the whole common lane section of the PHY.  This is
required on machines where the BIOS doesn't do this for us on boot or
resume to properly re-calibrate and get the PHY ready to transmit data.

Without this patch, such machines won't resume correctly much of the time,
with the symptom being a 'port ready' timeout and/or a link training
failure.

Note that simply asserting reset at suspend and de-asserting at resume
is not sufficient, nor is simply de-asserting at boot.  Both of these
cases have been tested and have still been found to have failures on
some configurations.

v2: extract simpler set_power_well function for use in reset_dpio (Imre)
    move to reset_dpio (Daniel & Ville)
v3: don't reset if DPIO reset is already de-asserted (Imre)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

If we disable first the port (by disabling DPI) and only then the
display pipe the pipe-off flag will never be set, possibly leading to a
hanged pipe state at the next modeset-enable.

Note that according to the VLV2 display cluster HAS, we should disable
the port before the pipe. This doesn't seem to match reality based on
the above and it's also asymmetric with the enabling sequence, where we
first enable the port and then the pipe.

v2:
- send the panel shutdown command before stopping the pipe, since this
  is the recommended sequence (Shobhit)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

It seems by default the VBT has MIPI configuration block as well. The
Generic driver will assume always MIPI if MIPI configuration block is found.
This is causing probelm when actually there is eDP. Fix this by looking
into general definition block which will have device configurations. From here
we can figure out what is the LFP type and initialize MIPI only if MIPI
is found.

v2: Addressed review comments by Damien
    - Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA
    - renamed is_mipi to has_mipi and moved definition as suggested
    - Check has_mipi inside parse_mipi and intel_dsi_init insted of outside

v3: Make has_mipi as a bitfield as suggested
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: fold in conditions to pack everything neatly below 80 chars.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

For disabling L3 clock gating we need to set bit 25 of MMIO
register 940c. Earlier this was being done by just writing 1
into bit 25 and resetting all other bits.
This patch modifies the routine to read-modify-write of the
register, so that the values of other bits are not destroyed.

v2: Modifying the comments and the patch commit message (Chris)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Apply checkpatch fixup.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
power sequence which is unique to each panel. The generic driver uses the
panel configuration and sequence parsed from VBT block #52 and #53

v2: Address review comments by Jani
    - Move all of the things in driver c file from header
    - Make all functions static
    - Make use of video/mipi_display.c instead of redefining
    - Null checks during sequence execution

v3: Address review comments by Damien
    - Rename the panel driver file as intel_dsi_panel_vbt.c
    - Fix style changes as suggested
    - Correct comments for lp->hs and hs->lp count calculations
    - General updating comments to have more clarity
    - using max() instead of ternary operator
    - Fix names (ui_num, ui_den) while using UI in calculations
    - compute max of lp_to_hs switch and hs_to_lp switch while computing
      hs_lp_switch_count
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Fallout from an intermediate patch revision that I deemed worth saving.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Currently we do a full re-init of all interrupts after a gpu hang.
Which is pretty bad since we don't restore the interrupts we've
enabled at runtime correctly. Even with that addressed it's rather
horribly race.

But on g4x and later we only reset the gt and not the entire gpu.
Which means we only need to reset the GT interrupt bits. Which has the
nice benefit that vblank waits, pipe CRC interrupts and everything
else display related just keeps on working.

The downside is that gt interrupt handling (i.e. ring->get/put_irq) is
still racy. But as long as the gpu hang reliably wakes all waters and
we have a short time where the refcount drops to 0 we'll recover. So
not that bad really.

v2: Ville noticed that GTIMR and PMIMR don't get cleared, only the
subordinate per-ring registers. So let's rip out all the interrupt dancing.
The FIXME comment is still required though since the ring irq handling
happens at the per-ring interrupt mask registers, too.

Testcase: igt/kms_flip/vblank-vs-hang
Testcase: igt/kms_pipe_crc_basic/hang-*
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

No point in having this indirection.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Ville figured out that it needs a full display reset since apparently
a lot more goes down than just the GT. Until that's address it's
better to just diable gpu reset.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

So apparently this is tricky.

We need to consider:
- We start out with all the hw enabling bits disabled, both the
  individual fifo underrun interrupts and the shared display error
  interrupts masked. Otherwise if the bios config is broken we'll blow
  up with a NULL deref in our interrupt handler since the crtc
  structures aren't set up yet at driver load time.
- On gmch we need to mask fifo underruns on the sw side, so always
  need to set that in sanitize_crtc for those platforms.
- On other platforms we try to set the sw tracking so that it reflects
  the real state. But since a few platforms have shared bits we must
  _not_ disable fifo underrun reporting. Otherwise we'll never enable
  the shared error interrupt.

This is the state before out patch, but unfortunately this is not good
enough. But after a suspend resume operation this is broken:
1. We don't enable the hw interrupts since the same code runs on
resume as on driver load.
2. The fifo underrun state adjustments we do in sanitize_crtc doesn't
fire on resume since (except for hilarious firmware) all pipes are off
at that point. But they also don't hurt since the subsequent crtc
enabling due to force_restore will enable fifo underruns.

Which means when we enable fifo underrun reporting we notice that the
per-crtc state is already correct and short-circuit everthing out. And
the interrupt doesn't get enabled.

A similar problem would happen if the bios doesn't light up anything
when the driver loads. Which is exactly what happens when we reload
the driver since our unload functions disables all outputs.

Now we can't just rip out the short-circuit logic and unconditionally
update the fifo underrun reporting interrupt masking: We have some
checks for shared error interrupts to catch issues that happened when
the shared error interrupt was disabled.

The right fix is to push down this logic so that we can always update
the hardware state, but only check for missed fifo underruns on a real
enabled->disabled transition and ignore them when we're already
disabled.

On platforms with shared error interrupt the pipe CRC interrupts are
grouped together with the fifo underrun reporting this fixes pipe CRC
support after suspend and driver reloads.

Testcase: igt/kms_pipe_crc_basic/suspend-*
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

On platforms with shared interrupt enable bits (which are shared even
with the pipe CRC logic) there's some tricky corner cases. Add
information to make debugging those easier.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same
locking.  Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

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: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave 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: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Just flushing out my pile of random drm patches for the merge window,
nothing big. And it all hung around in drm-intel trees for a while (only
just rebased now).

* tag 'topic/core-stuff-2014-06-02' of git://anongit.freedesktop.org/drm-intel:
  imx-drm: imx-tve: remove unused variable
  drm: Missed clflushopt in drm_clflush_virt_range
  drm/plane: Fix a couple of checkpatch warnings
  drm/plane: Fix sparse warnings
  drm/exynos: Fix double locks at PM resume
  drm/ast: Fix double lock at PM resume
  drm/dp-helper: Deprecate old i2c-over-dp_aux heleprs

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

Summary:
- Resolve probe order and deferred probe issue with component framework
  support.
- Resolve hdmi dt broken issue.
  . HDMI DT support, which was broken since CCF (common clock framework)
    support, and considring legacy dt binding.
- Consolidate HDMI part.
  . APB based phy support for Exynos5420 and later, and fixups related
    to power on/off sequence.
- Consolidate IPP part.
  . Mostly bug fixups and code cleanups.
- Trivial fixups and code cleanups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (64 commits)
  drm/exynos: consider deferred probe case
  drm/exynos: remove unnecessary exynos_hdmi.h file
  drm/exynos/fimd: allow multiplatform configuration
  drm/exynos: add hdmiphy power on/off sequence
  drm/exynos: ipp: remove description of non-existing field
  drm/exynos: ipp: update comment for struct drm_ipp_buf_info
  drm/exynos: ipp: rearrange c_node->event_lock using routine
  drm/exynos: ipp: rearrange c_node->mem_lock using routines
  drm/exynos: ipp: add ipp_remove_id()
  drm/exynos: ipp: add cmd_lock for cmd_list
  drm/exynos: ipp: rename cmd_lock to lock
  drm/exynos: ipp: remove duplicated setting
  drm/exynos: ipp: remove usless list_empty() functions
  drm/exynos: Use PTR_ERR_OR_ZERO in exynos_dp_core.c
  drm/exynos: remove hardware overlays disable from fimd probe
  drm/exynos: Fix checkpatch warning in exynos_dp_reg.c
  drm/exynos: add fimd dependency to fimd related encoders
  drm/exynos: remove redundant mutex_unlock
  drm/exynos/fimc: simplify and rename fimc_dst_get_buf_seq
  drm/exynos/fimc: replace mutex by spinlock
  ...

Pretty small pull this time around for msm.  Adds some useful debugfs
I'd been carrying around on a branch for a while, plus few fixes.  And
Kconfig update for the great ARCH_MSM -> ARCH_QCOM split.

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: use correct gfp flag for vram allocation
  drm/msm/mdp5: fix error return value
  drm/msm: remove redundant private plane cleanup
  drm/msm: add perf logging debugfs
  drm/msm: add rd logging debugfs
  drm/msm: update for ARCH_MSM -> ARCH_QCOM
  drm/msm/hdmi: use gpio and HPD polling
  drm/msm/mdp5: fix crash in error/unload paths

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

v2: Don't break the build for vmwgfx, spotted by Matt.

v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
since it involves select). Reported by Chris.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave 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: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>

I find myself making this change locally whenever debugging FB reference
counting.  Which seems a bit silly.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Like range, but values are signed.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

If we continue to use bitmask for type, we will quickly run out of room
to add new types.  Split this up so existing part of bitmask range
continues to function as before, but reserve a chunk of the remaining
space for an integer type-id.  Wrap this all up in some type-check
helpers to keep the backwards-compat uglyness contained.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Add a few more useful helpers to find mode objects.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>