One more drm-misc pull for 4.2. The important one is the fix from Laurent
for Daniel Stone's mode_blob work.

* tag 'topic/drm-misc-2015-06-22' of git://anongit.freedesktop.org/drm-intel:
  drm/atomic: Don't set crtc_state->enable manually
  drm: prime: Document gem_prime_mmap
  drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()
  drm/atomic: Extract needs_modeset function
  drm/cma: Fix 64-bit size_t build warnings
  Documentation/drm: Update rotation property

The enable field needs to be kept in sync with the mode_blob field. Call
drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false
in order to dereference the mode blob correctly.

v2:
- Check the return value of drm_atomic_set_mode_prop_for_crtc()
- Drop the num_connectors local variable
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

gem_prime_map is not currently described in the DRM manual, lets document
it.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

As the clflush operates on cache lines, and we can flush any byte
address, in order to flush all bytes given in the range we issue an
extra clflush on the last byte to ensure the last cacheline is flushed.
We can can the iteration to be over the actual cache lines to avoid this
double clflush on the last byte.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

We use the same check already in the atomic core, so might as well
make this official. And it's also reused in e.g. i915.

Motivated by Maarten's idea to extract a connector_changed state out
of mode_changed.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-By: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Merge tag 'drm-intel-next-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel into drm-next

i915 fixes for stuff in next

* tag 'drm-intel-next-fixes-2015-06-18' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Don't set enabled value of all CRTCs when restoring the mode
  drm/i915: Don't update staged config during force restore modesets
  drm/i915: Don't check modeset state in the hw state force restore path
  drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.
  drm/i915: Extend the parser to check register writes against a mask/value pair.
  drm/i915: Fix command parser to validate multiple register access with the same command.
  drm/i915: Don't skip request retirement if the active list is empty

fixes and virtio-vga support.

* 'virtio-gpu-drm-next' of git://git.kraxel.org/linux:
  virtio-gpu: add locking for vbuf pool
  drm/virtgpu: initialise fbdev after getting initial display info
  Add virtio-vga bits.

drm/panel: Changes for v4.2-rc1

This contains fixes for the long-standing build issues that some of the
bridge drivers were exposing. Other than that it's mostly cleanup and a
couple of new simple panels that are supported.

* tag 'drm/panel/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux:
  drm/panel: simple: Add bus format for HannStar HSD100PXN1
  drm/panel: simple: Add display timing for HannStar HSD100PXN1
  drm/panel: ld9040: Remove useless padding
  drm/panel: Constify OF match tables
  drm/bridge: Remove stale ptn3460.h include
  drm/bridge: ps8622: Include linux/gpio/consumer.h
  drm/bridge: ptn3460: Include linux/gpio/consumer.h
  drm/bridge: dw-hdmi: Return number of EDID modes
  drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel
  drm/bridge: ptn3460: Pass flags to devm_gpiod_get()
  drm/bridge: ps8622: Pass flags to devm_gpiod_get()
  drm/bridge: ptn3460: Fix I2C ID table to match the reported modalias
  drm/bridge: dw-hdmi: Staticize dw_hdmi_bridge_funcs

drm/tegra: Changes for v4.2-rc1

This contains a couple of mostly fixes for issues that have crept up in
recent versions of linux-next. One issue is that DP AUX transactions of
more than 4 bytes will access the wrong FIFO registers and hence become
corrupt. Another fix is required to restore functionality of Tegra20 if
using the GART. The current code expects the IOMMU aperture to be the
complete 4 GiB address space, whereas the GART on Tegra20 only provides
a 128 MiB aperture. One more issue with IOMMU support is that on 64-bit
ARM, swiotlb is the default IOMMU implementation backing the DMA API. A
side-effect of that is that when dma_map_sg() is called to flush caches
(yes, this is a bit of a hack, but ARM does not provide a better API),
swiotlb will immediately run out of memory because its bounce buffer is
too small to make a framebuffer.

Finally I've included a mostly cosmetic fix that stores register values
in u32 rather than unsigned long to avoid sign-extension issues on 64-
bit ARM. This is only a precaution since it hasn't caused any issues
(yet).

* tag 'drm/tegra/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: dpaux: Registers are 32-bit
  drm/tegra: gem: Flush pages after allocation
  drm/tegra: gem: Take into account IOMMU aperture
  drm/tegra: dpaux: Fix transfers larger than 4 bytes

rcar-du fixes

* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev:
  drm: rcar-du: Use the drm atomic state duplication helpers for planes
  drm: rcar-du: Clean up planes in the error paths of .atomic_commit()
  drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0
  drm: rcar-du: Clarify error message when encoder initialization fails
  drm: rcar-du: Fix crash with groups that have less than 9 planes
  drm: rcar-du: Disable all planes when stopping the CRTC
  drm: rcar-du: Print the error value when DRM/KMS init fails

Merge tag 'drm-amdkfd-next-fixes-2015-06-16' of git://people.freedesktop.org/~gabbayo/linux into drm-next

- Dan fixed some range checks in the address watch ioctl impl.
- Remove obsolete member from radeon_device structure

* tag 'drm-amdkfd-next-fixes-2015-06-16' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: fix some range checks in address watch ioctl
  drm/radeon: remove obsolete kfd_bo from radeon_device

The code in intel_crtc_restore_mode() sets the enabled value of all the
CRTCs when restoring the mode after a suspend/resume cycle. When more
than one CRTC is enabled, that causes drm_atomic_helper_check_modeset()
to fail if there is more than one pipe enabled, since all but one CRTC
has valid connector data. Instead, set only the enabled value for the
CRTC passed as an argument.

v2: Don't leak atomic state. (Matt)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90468
References: https://bugs.freedesktop.org/show_bug.cgi?id=90396Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

The force restore path relies on the staged config to preserve the
configuration used before a suspend/resume cycle. The update done to it
in intel_modeset_fixup_state() would cause that information to be lost
after the first modeset, making it impossible to restore the modes for
pipes B and C.

References: https://bugs.freedesktop.org/show_bug.cgi?id=90468Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Since the force restore logic will restore the CRTCs state one at a
time, it is possible that the state will be inconsistent until the whole
operation finishes. A call to intel_modeset_check_state() is done once
it's over, so don't check the state multiple times in between. This
regression was introduced in:

commit 7f27126e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Nov 5 14:26:06 2014 -0800

    drm/i915: factor out compute_config from __intel_set_mode v3

v2: Rename check parameter to force_restore. (Matt)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

buf_size_in_bytes must be large enough to hold ->num_watch_points and
watch_mode so I have added a sizeof(int) * 2 to the minimum size.

Also we have to subtract sizeof(*args) from the max args_idx limit so
that it matches the allocation.  Also I changed a > to >= for the last
compare.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>

Ensure that the duplicate and destroy plane state operations will always
be in sync with the DRM core implementation of the plane state by using
the __drm_atomic_helper_plane_duplicate_state() and
__drm_atomic_helper_plane_destroy_state() functions designed especially
for this purpose.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

When the .atomic_commit() handler fails, clean up planes previoulsy
prepared by drm_atomic_helper_prepare_planes() with a call to
drm_atomic_helper_cleanup_planes().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

The function returns 1 on success, and either 0 or a negative error code
on failure. As the 0 and negative values don't need to be differentiated
by the caller, convert it to the usual scheme of returning 0 on success
and a negative error code on failure.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

A failure to initialize an encoder currently prints an error message in
the kernel log without mentioning which encoder failed to initialize. To
help debugging initialization issues print the encoder DT node name.

This requires moving the error message to the rcar_du_encoders_init_one
function and refactoring it slightly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Commit 917de180 ("drm: rcar-du: Implement universal plane support")
made the number of planes per group dynamic, but didn't update all loops
over the planes array, resulting in out-of-bound accesses on DU
instances that have an odd number of CRTCs (such as the R8A7790). Fix
it.

Fixes: 917de180 ("drm: rcar-du: Implement universal plane support")
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The DSnPR plane configuration registers are updated on vblank, and no
vblank will occur once the CRTC is stopped. We thus can't only disable
planes right before starting the CRTC as it would start scanning out
immediately from old frame buffers until the next vblank.

Fix the problem by disabling all planes when stopping the CRTC and wait
for the change to take effect. This increases the CRTC stop delay,
especially when multiple CRTCs are stopped in one operation as we now
wait for one vblank per CRTC. Whether this can be improved needs to be
researched.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

This helps debugging probe failures.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

This should avoid issues with the fbdev path trying to render
before we've gotten the display info.
Signed-off-by: Dave Airlie <airlied@redhat.com>

[ kraxel: wait for display-info reply ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>

Merge tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next

omapdrm atomic modesetting support

Atomic modesetting support for omapdrm.

" we've had issues with omapdrm for years,
which we've not been able to fix properly (like warnings/crashes when unloading
modules, page-flips tearing, race issues with fbs). All those problems seem to
be gone after this rewrite of omapdrm for atomic modesetting, and the resulting
code is much cleaner and more maintainable."

* tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (43 commits)
  drm: omapdrm: new vblank and event handling
  drm: omapdrm: merge omap_crtc_flush and omap_crtc_atomic_flush
  drm: omapdrm: add lock for fb pinning
  drm: omapdrm: if omap_plane_atomic_update fails, disable plane
  drm: omapdrm: inline omap_plane_setup into update/disable
  drm: omapdrm: omap_plane_setup() cannot fail, use WARN
  drm: omapdrm: Don't setup planes manually from CRTC .enable()/.disable()
  drm: omapdrm: Don't flush CRTC when enabling or disabling it
  drm: omapdrm: Move encoder setup to encoder operations
  drm: omapdrm: Simplify DSS power management
  drm: omapdrm: Remove nested PM get/sync when configuring encoders
  drm: omapdrm: Support unlinking page flip events prematurely
  drm: omapdrm: omap_crtc_flush() isn't called with modeset locked
  drm: omapdrm: Don't get/put dispc in omap_crtc_flush()
  drm: omapdrm: Make the omap_crtc_flush function static
  drm: omapdrm: Remove omap_plane enabled field
  drm: omapdrm: Remove omap_crtc enabled field
  drm: omapdrm: Move crtc info out of the crtc structure
  drm: omapdrm: Move plane info and win out of the plane structure
  drm: omapdrm: Switch crtc and plane set_property to atomic helpers
  ...

Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be
set because of security-sensitive bits we don't want userspace to mess
with.  On HSW hardware the whitelisted bits control whether atomic
read-modify-write operations are performed on L3 or on GTI, and when
set to L3 (which can be 10x-30x better performing than on GTI,
depending on the application) require great care to avoid a system
hang, so we currently program them to be handled on GTI by default.

Beignet can immediately start taking advantage of this change to
enable L3 atomics.  Mesa should eventually switch to L3 atomics too,
but a number of non-trivial changes are still required so it will
continue using GTI atomics for now.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

In some cases it might be unnecessary or dangerous to give userspace
the right to write arbitrary values to some register, even though it
might be desirable to give it control of some of its bits.  This patch
extends the register whitelist entries to contain a mask/value pair in
addition to the register offset.  For registers with non-zero mask,
any LRM writes and LRI writes where the bits of the immediate given by
the mask don't match the specified value will be rejected.

This will be used in my next patch to grant userspace partial write
access to some sensitive registers.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Until now the software command checker assumed that commands could
read or write at most a single register per packet.  This is not
necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length
list of offset/value pairs and writes them in sequence.  The previous
code would only check whether the first entry was valid, effectively
allowing userspace to write unrestricted registers of the MMIO space
by sending a multi-register write with a legal first register, with
potential security implications on Gen6 and 7 hardware.

Fix it by extending the drm_i915_cmd_descriptor table to represent
multi-register access and making validate_cmd() iterate for all
register offsets present in the command packet.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Apparently we can have requests even if though the active list is empty,
so do the request retirement regardless of whether there's anything
on the active list.

The way it happened here is that during suspend intel_ring_idle()
notices the olr hanging around and then proceeds to get rid of it by
adding a request. However since there was nothing on the active lists
i915_gem_retire_requests() didn't clean those up, and so the idle work
never runs, and we leave the GPU "busy" during suspend resulting in a
WARN later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Fix warnings related to size_t when building for 64-bit architectures:

drivers/gpu/drm/drm_gem_cma_helper.c: In function ‘drm_gem_cma_create’:
drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat=]
    size);
    ^
drivers/gpu/drm/drm_gem_cma_helper.c: In function ‘drm_gem_cma_describe’:
drivers/gpu/drm/drm_gem_cma_helper.c:393:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 8 has type ‘size_t’ [-Wformat=]
    off, &cma_obj->paddr, cma_obj->vaddr, obj->size);
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Moving rotation property to "Drm" and removing from i915 and omap.
Also, adding description to the property

Cc: DRI Development <dri-devel@lists.freedesktop.org>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Rework the crtc event/flip_wait system as follows:

- If we enable a crtc (full modeset), we set omap_crtc->pending and
  register vblank irq.

- If we need to set GO bit (page flip), we do the same but also set the
  GO bit.

- On vblank we unregister the irq, clear the 'pending' flag, send vblank
  event to userspace if crtc->state->event != NULL, and wake up
  'pending_wait' wq.

- In omap_atomic_complete() we wait for the 'pending' flag to get reset
  for all enabled crtcs  using 'pending_wait' wq.

The above ensures that we send the events to userspace in vblank, and
that after the wait in omap_atomic_complete() everything for the
affected crtcs has been completed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

omap_crtc_atomic_flush() is the only user of omap_crtc_flush(), so just
move the code from omap_crtc_flush() to omap_crtc_atomic_flush().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Before atomic modesetting omap_framebuffer_pin() and
omap_framebuffer_unpin() were always called with modesetting locks
taken. With atomic modesetting support this is no longer the case, and
we need locking to protect the pin_count and the paddr, as multiple
threads may pin the same fb concurrently.

This patch adds a mutex to struct omap_framebuffer, and uses it in
omap_framebuffer_pin() and omap_framebuffer_unpin().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

omap_plane_atomic_update() calls dispc_ovl_setup(), which can fail (but
shouldn't). To make the code a bit more robust, make sure the plane gets
disabled if dispc_ovl_setup() fails, as otherwise we might get illegal
HW configuration leading to error interrupts.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

At the moment we have omap_plane_setup() function which handles both
enabling (and configuring) and disabling the plane. With atomic
modesetting we have separate hooks for plane enable/config and disable.

This patch moves the code from omap_plane_setup() to
omap_plane_atomic_update() and omap_plane_atomic_disable().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

With atomic modesetting, omap_plane_setup()'s return value is ignored as
the functions using it cannot fail. dispc_ovl_setup(), called by
omap_plane_setup(), can fail (but shouldn't).

Instead of returning an error from omap_plane_setup() which gets
ignored, return void and use WARN if dispc_ovl_setup() fails.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Planes setup is handled by the DRM core through the atomic helpers,
there's no need to duplicate the code in the CRTC .enable() and
.disable() operations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>