MFC r254817:

drm: Import drm_dp_helper.c from Linux 3.8-rc3

While here, update drm_dp_helper.h to better match Linux one.
MFC r254818:

drm: Move definition of EREMOTEIO to drmP.h

It will be used by both i915 and radeon drivers.

Add ERESTARTSYS definition at the same time.
MFC r254819:

drm: Don't delete already deleted iicbus child from drm_iic_dp_aux

The iic_dp_aux_detach callback is therefore useless: it's replaced by
bus_generic_detach. This fixes a "General protection fault" panic during
second (incorrect) deletion of the child.

Tested by:	kwm@
Reviewed by:	ray@
MFC r254820:

drm: Use driver-provided "use_msi" callback to determine if MSI is blacklisted

For now, keep the static array for i915. But eventually, it should be
moved to a callback in the driver itself.
MFC r254821:

drm: Fix cleanup if device initialization fails

This plugs some memory leaks.
MFC r254833:

drm: Import Linux commit cd004b3f4cd4169815c82bf9e424fda06978898a

Author: Shirish S <s.shirish@samsung.com>
Date:   Thu Aug 30 07:04:06 2012 +0000

    drm: edid: add support for E-DDC

    The current logic for probing ddc is limited to
    2 blocks (256 bytes), this patch adds support
    for the 4 block (512) data.

    To do this, a single 8-bit segment index is
    passed to the display via the I2C address 30h.
    Data from the selected segment is then immediately
    read via the regular DDC2 address using a repeated
    I2C 'START' signal.

    Signed-off-by: Shirish S <s.shirish@samsung.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
MFC r254835:

drm: Fix typo in KASSERT message: s/Dandling/Dangling/
MFC r254836, r254837:

drm: Support gem_open_object() and gem_close_object() callbacks

... in struct drm_driver_info.
MFC r254838:

drm: In drm_gem_name_create(), verify argument before acquiring lock

Submitted by:	J.R. Oldroyd <jr@opal.com>
MFC r254840:

drm: Use DRM_IF_MAJOR & DRM_IF_MINOR from drm_core.h
MFC r254841:

drm: Import list_for_each_entry_safe_from() macro
MFC r254848, r258930:

drm: Import drm_pcie_get_speed_cap_mask() in drm_pci.c

This comes with several PCI_VENDOR_ID_* defines which should go in a
more central place.
MFC r254853:

drm: Import drm_fixed.h from Linux 3.8
MFC r254852:

drm: Update drm_pciids.h based on Linux 3.8

This header can be easily updated using the new "gen-drm_pciids" script,
available in tools/tools/drm. The script uses the Linux' drm_pciids.h
header for new IDs, the FreeBSD's one because we add the name of the
device to each IDs, and the PCI IDs database (misc/pciids port) to fill
this name automatically for new IDS.

To call the script:
  tools/tools/drm/gen-drm_pciids					\
    /path/to/linux/drm_pciids.h						\
    /path/to/freebsd/drm_pciids.h					\
    /path/to/pciids/pci.ids
MFC r258262:

drm: Support DRM_CAP_TIMESTAMP_MONOTONIC capability

This fixes DPMS with KDE and radeonkms. Without this, the display would
freeze when the monitor is put into sleep state, and only resumes after
several dozens of minutes once the monitor is powered on again.

Tested by:	Mathias Picker <Mathias.Picker@virtual-earth.de>
MFC r258549:

drm: Dereference pointers given to qsort_r()'s cmp callback

drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.

Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.

This bug triggered an infinite loop in KDE/xserver:

    1. KDE has a kded module called "randrmonitor" which queries xserver
       for current monitors at startup and then listens to RandR
       notifications from xserver.

    2. xserver handles the query from "randrmonitor" by polling the
       video device using the "drm_mode_getconnector()" ioctl. This
       ioctl returns a list of connectors and, for those with a
       connected monitor, the available modes. Each modes list is sorted
       by the kernel before returning. When xserver gets the connectors
       list, it sorts the modes lists again.

       In the case of this bug, when two modes are equal (in xserver's
       compare function PoV), their order is kept stable (ie. the
       kernel order is kept for those two modes). And because the list
       was shuffled by the kernel, the order of two equal modes was
       frequently changed in the final modes list in xserver.

    3. xserver compares the returned connectors list with the list
       obtained earlier. In particular, it compares the sorted
       modes lists for each connector. If a property of a connector
       changes (eg. modes), xserver sends a "RRNotify_OutputChange"
       notification.

       Because of the change of order between equal modes, xserver sent
       a notification after each polling of the connectors.

    4. "randrmonitor" receives a notification, triggered by its query. The
       notification doesn't contain the new connectors list, therefore, it
       asks for the new list using the same function: go back to step #2.
MFC r259717:

drm: Lower priority of "EDID checksum is invalid" message

The priority goes from "error" to "debug".

Connectors are polled every 10 seconds. Reading EDID is part of this
polling. However, when an invalid EDID is returned, this error message
is logged. When using Newcons for instance, having a kernel message
every 10 seconds is getting annoying.

Now that it's a debug message, it'll be logged only if hw.dri.debug is
enabled. This fix console spamming for some users.

Tested by:	Larry Rosenman <ler@lerctr.org>
MFC: 260796

Fix various places where we don't properly release a lock.

PR:		185043
Submitted by:	Michael Bentkofsky
[automated] Merge in upstream-github/stable/9