igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accommodate this
allow userspace to set a flag on the context that any hang emanating
from that context will not be recorded. We still do the error capture
(otherwise how do we find the guilty context and know its intent?) as
part of the reason for random GPU hang injection is to exercise the race
conditions between the error capture and normal execution.

v2: Split out the request->ringbuf error capture changes.
v3: Move the flag defines next to the intel_context->flags definition
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDave Gordon <david.s.gordon@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467616119-4093-9-git-send-email-chris@chris-wilson.co.uk

Pooled EU is a bxt only feature and kernel changes are already merged. This
feature is not yet exposed to userspace as the support was not yet
available. Beignet team expressed interest and added patches to use this.

Since we now have a user and patches to use them, expose them from the
kernel side as well.

v2: fix compile error

[1] https://lists.freedesktop.org/archives/beignet/2016-June/007698.html
[2] https://lists.freedesktop.org/archives/beignet/2016-June/007699.html

Cc: Winiarski, Michal <michal.winiarski@intel.com>
Cc: Zou, Nanhai <nanhai.zou@intel.com>
Cc: Yang, Rong R <rong.r.yang@intel.com>
Cc: Tim Gore <tim.gore@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467369782-25992-1-git-send-email-arun.siluvery@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Brian Paul <brianp@vmware.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NSinclair Yeh <syeh@vmware.com>

Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Similar to the rest of the DRM UAPI - these are to be imported
unmodified into libdrm. In current form that's impossible.
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com> (over irc)

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@intel.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>

Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

One cannot rename the struct at this point, so might as well remove the
comment.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Right now exynos is exposing DPI as a TMDS encoder and VGA connector,
which seems rather misleading.  This isn't just an internal detail,
since xrandr actually exposes "VGA" as the output name.  Define some
new enums so that vc4's DPI can have a more informative name.

I considered other names for the connector as well.  For VC4, the
Adafruit DPI kippah takes the 28 GPIO pins and routes them to a
standard-ish 40-pin FPC connector, but "40-pin FPC" doesn't uniquely
identify an ordering of pins (apparently some other orderings exist),
doesn't explain things as well for the user (who, if anything, knows
their product is a DPI kippah/panel combo), and actually doesn't have
to exist (one could connect the 28 GPIOs directly to something else).
Simply "DPI" seems like a good compromise name to distinguish from the
HDMI, DSI, and TV connectors .
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This ports the below libdrm commit to the kernel

commit 0f4452bb51306024fbf4cbf77d8baab20cefba67
Author: Daniel Kurtz <djkurtz@chromium.org>
Date:   Mon Aug 26 23:39:16 2013 +0800

    libdrm: Make some drm headers compatible with gcc -std=c89 -pedantic

    The following minor changes were needed to these headers:
     * Convert // comments to /* */
     * No , after final member of enum

    With these changes, these header files can be included by a program that
    is built with gcc options:
      -std=c89 -Werror -pedantic
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459348943-12803-2-git-send-email-daniel.vetter@ffwll.ch

make headers_install can't handle fancy conditions, so let's simplify
things for it a bit.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459348943-12803-1-git-send-email-daniel.vetter@ffwll.ch

These type defines are officially part of the uapi, but ended up in
the wrong headers somehow when we split them all.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459347584-30566-3-git-send-email-daniel.vetter@ffwll.ch

We can't use <drm/*.h> because that upsets the serach paths in libdrm.
Also, drop the circular inclusion in drm_mode.h.

v2: Actually change the right headers.

v3: Drop the #include removal per Emil's request.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459353292-9063-1-git-send-email-daniel.vetter@ffwll.ch

virtual is a protected keyword in C++ and can't be used at all. Ugh.

This aligns the kernel versions of the drm headers with the ones in
libdrm.

v2: Also annote with __user, as request by Emil&Ilia.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459350753-18320-1-git-send-email-daniel.vetter@ffwll.ch

The commit d931589c ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
ioctl") removed it same with the ioctl that this patch adds. The reason
that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.

Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
    More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
    Add legacy gamma_set atomic helper
    Describe CTM/LUT acronyms in the kernel doc

v6: Fix missing blob unref in drm_atomic_helper_crtc_reset
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NKumar, Kiran S <kiran.s.kumar@intel.com>
Signed-off-by: NKausal Malladi <kausalmalladi@gmail.com>
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Acked-by: NRob Bradford <robert.bradford@intel.com>
[danvet: CrOS maintainers are also happy with the userspacde side:
https://codereview.chromium.org/1182063002/ ]
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com

We need this for GL_TIMESTAMP queries.

Note: currently only supported on a4xx.. a3xx doesn't have this
always-on counter.  I think we could emulate it with the one CP
counter that is available, but for now it is of limited usefulness
on a3xx (since we can't seem to do time-elapsed queries in any sane
way with the existing firmware on a3xx, and if you are trying to do
profiling on a tiler you want time-elapsed).  We can add that later
if it becomes useful.
Signed-off-by: NRob Clark <robdclark@gmail.com>

User API structs should not use types which size/alignment/padding depends
on architecture. The patch fixes it for all structures except
drm_exynos_g2d_userptr, as g2d related stuff seems to be more complicated
and will be reviewed/adjusted later.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

We need this in userspace for interpreting some of the perf ctrs.

Note possibly not quite sufficient if we had some frequency mgmt
approach other than race-to-idle.  Not really sure what the best
thing to do if we did.  Although displaying results as a percentage
of max frequence seems sensible(ish) if we did.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.

It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.

v3 (Tiago): removed unused flags variable from drm_prime_handle_to_fd_ioctl.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: NTiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1450820214-12509-2-git-send-email-tiago.vignatti@intel.com

This got broken in:

   commit de1add36
   Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
   Date:   Fri Jan 15 15:12:50 2016 +0000

       drm/i915: Decouple execbuf uAPI from internal implementation

BSD ring flags need to be shifted before they can be considered
indices into the ring array.

Reported by Zhipeng Gong.

v2: Simplify the code. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1453902069-31353-1-git-send-email-tvrtko.ursulin@linux.intel.com
Testcase: igt/gem_exec_basic # bdw-gt3

Export further minor feature bitmasks and the varyings count from
the GPU specifications registers to userspace.
Acked-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>