Main pull request for drm for 4.10 kernel - resync drm-misc with full
4.10 state (2 new drivers) so that we can start pulling in all the
refactorings for 4.11!
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

If atomic state is available, use this to read the current plane in
GetCrtc/GetPlane, rather than the legacy points.
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213181912.92904-1-daniels@collabora.com

We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: NKristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481657272-25975-1-git-send-email-hoegsberg@google.com

drm_put_dev is the old midlayer-broken device cleanup function, but
etnaviv has a proper unbind function which first unregisters and then
drops the final reference. No functional change since
drm_dev_unregister happens to be idempotent.

Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Russell King <linux+etnaviv@armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161208110739.24417-1-daniel.vetter@ffwll.ch

fsl is already fully demidlayered in the probe function, but for
convenience stuck with drm_put_dev. Call the unregister/unref parts
separately, to make sure this driver works correct.

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: CK Hu <ck.hu@mediatek.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161208110739.24417-3-daniel.vetter@ffwll.ch

- Put all the remaing bits of the old doc into suitable places in the
  new sphinx world.
- Also document the poll support, we forgot to do that.
- Delete dma-buf-sharing.txt.

v2: Don't forget to update MAINTAINERS.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209215055.3492-1-daniel.vetter@ffwll.ch

- Again move the information relevant for driver writers next to the
  callbacks.
- Put the overview and userspace interface documentation into a DOC:
  section within the code.
- Remove the text that mmap needs to be coherent - since the
  DMA_BUF_IOCTL_SYNC landed that's no longer the case. But keep the text
  that for pte zapping exporters need to adjust the address space.
- Add a FIXME that kmap and the new begin/end stuff used by the SYNC
  ioctl don't really mix correctly. That's something I just realized
  while doing this doc rework.
- Augment function and structure docs like usual.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
  [sumits: fix cosmetic issues]
Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-5-daniel.vetter@ffwll.ch

- Put the initial overview for dma-buf into dma-buf.rst.
- Put all the comments about detailed semantics into the right
  kernel-doc comment for functions or ops structure member.
- To allow that detail, switch the reworked kerneldoc to inline style
  for dma_buf_ops.
- Tie everything together into a much more streamlined overview
  comment, relying on the hyperlinks for all the details.
- Also sprinkle some links into the kerneldoc for dma_buf and
  dma_buf_attachment to tie it all together.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-4-daniel.vetter@ffwll.ch

This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.

Fixes: 30cd85dd ("dma-buf/sync_file: hold reference to fence when creating sync_file")
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209185309.1682-3-daniel.vetter@ffwll.ch

Backmerge the docs-next branch from Jon into drm-misc so that we can
apply the dma-buf documentation cleanup patches. Git found a conflict
where there was none because both drm-misc and docs had identical
patches to clean up file rename issues in the rst include directives.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.

And indeed it's entirely unused and can be nuked.

This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus points for implementing abstraction, and then storing the vfunc
in a global variable.

v2: Don't break the build soooo badly :(
Note that the cleanup function is a bit confused: ade_data was never
set as drvdata, and calling drm_crtc_cleanup directly is a bug - this
is called indirectly through drm_mode_config_cleanup, which calls into
crtc->destroy, which already has the call to drm_crtc_cleanup. Which
means we can just nuke it.

Note this is the 2nd attempt after the first one failed and had to be
reverted again in

commit 9cd2e854
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 17 13:59:40 2016 +0200

    Revert "drm/hisilicon: Don't set drm_device->platformdev"

Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209141944.22121-1-daniel.vetter@ffwll.ch

With the last round of changes all ioctls called by modern drivers now
have their own locking. Everything else is only allowed for legacy
drivers and hence the lack of locking doesn't matter.

One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag.
But that only works its magic on the context and bufs ioctls. And
drm_bufs.c is protected with dev->struct_mutex, and drm_context.c by
the same and dev->ctxlist_mutex. That should be all safe, and we can
finally mandata drm-bkl-less ioctls for everyone!
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161210215255.7765-3-daniel.vetter@ffwll.ch

It only updates per-file feature flags. And all the ioctl which change
behaviour depending upon these flags (they're all kms features) do
_not_ hold the BKL. Therefor this is pure cargo-cult and can be
removed.

Note that there's a risk that the ioctl will behave inconsistently
when userspace is racing with itself, but that's ok. The only thing
it's not allowed to do is oops the kernel, and from an audit all
places are safe.

v2: Clarify that the inconsistency is only when userspace races
(Chris).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161210215255.7765-2-daniel.vetter@ffwll.ch

No one looks at the major/minor versions except the unique/busid
stuff. If we protect that with the master_mutex (since it also affects
the unique of each master, oh well) we can mark these two IOCTL with
DRM_UNLOCKED.

While doing this I realized that the comment for the magic_map is
outdated, I've forgotten to update it in:

commit d2b34ee6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jun 17 09:33:21 2016 +0200

    drm: Protect authmagic with master_mutex

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
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/20161210215255.7765-1-daniel.vetter@ffwll.ch

Not setting the fb modifiers flag is something different from setting
the fb modifiers to 0 (which means explicitly linear). We kinda failed
to document that properly. Spotted by Kristian.

Cc: hoegsberg@google.com
Reviewed-by: NKristian H. Kristensen <hoegsberg@google.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478694996-4200-1-git-send-email-daniel.vetter@ffwll.ch

- Regression fix from atomic conversion (rotation on the original G80).
- Concurrency fix when clearing compression tags.
- Fixes DP link training issues on GP102/4/6.
- Fixes backlight handling in the presence of Apple GMUX.
- Improvements to GPU error recovery in a number of scenarios.
- GP106 support.

* 'linux-4.10' of git://github.com/skeggsb/linux:
  drm/nouveau/kms/nv50: fix atomic regression on original G80
  drm/nouveau/bl: Do not register interface if Apple GMUX detected
  drm/nouveau/bl: Assign different names to interfaces
  drm/nouveau/bios/dp: fix handling of LevelEntryTableIndex on DP table 4.2
  drm/nouveau/ltc: protect clearing of comptags with mutex
  drm/nouveau/gr/gf100-: handle GPC/TPC/MPC trap
  drm/nouveau/core: recognise GP106 chipset
  drm/nouveau/ttm: wait for bo fence to signal before unmapping vmas
  drm/nouveau/gr/gf100-: FECS intr handling is not relevant on proprietary ucode
  drm/nouveau/gr/gf100-: properly ack all FECS error interrupts
  drm/nouveau/fifo/gf100-: recover from host mmu faults

drm/tegra: Changes for v4.10-rc1

This has a couple of fixes for IOMMU support and some fixes for error
handling.

* tag 'drm/tegra/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux:
  drm/tegra: Set sgt pointer in BO pin
  drm/tegra: Support kernel mappings with IOMMU
  gpu: host1x: Add locking to syncpt
  gpu: host1x: Store device address to all bufs
  drm/tegra: gem: Remove some dead code
  drm/tegra: sor: No need to free devm_ allocated memory
  drm/tegra: Fix error handling
  drm/tegra: dpaux: Fix error handling

drm/panel: Changes for v4.10-rc1

This adds support for a couple more panels to the simple-panel driver.
There is also a fix for a long-standing bug, but it's not critical since
no code will currently trigger it.

* tag 'drm/panel/for-4.10-rc1' of git://anongit.freedesktop.org/tegra/linux:
  drm/panel: simple: Add support for AUO G185HAN01
  drm/panel: simple: Add support for AUO G133HAN01
  drm/panel: simple: Add more properties to Innolux G121I1-L01
  drm/panel: simple: Add bits-per-component for Sharp LQ123P1JX31
  drm/panel: simple: Check against num_timings when setting preferred for timing
  drm/panel: Add support for Chunghwa CLAA070WP03XG panel
  drm/panel: simple: Add NVD9128 as a simple panel
  drm/panel: simple: Add support for AUO T215HVN01
  drm/panel: simple: Add support for Sharp LQ150X1LG11 panels
  dt-bindings: display: Add Sharp LQ150X1LG11 panel binding

Merge tag 'drm-misc-next-fixes-2016-12-10' of git://anongit.freedesktop.org/git/drm-misc into drm-next

single fix for backwards compat.

* tag 'drm-misc-next-fixes-2016-12-10' of git://anongit.freedesktop.org/git/drm-misc:
  drm: Add fake controlD* symlinks for backwards compat

This pull request brings in VEC (TV-out) support for vc4, along with a
pageflipping race fix.

* tag 'drm-vc4-next-2016-12-09' of https://github.com/anholt/linux:
  drm/vc4: Don't use drm_put_dev
  drm/vc4: Document VEC DT binding
  drm/vc4: Add support for the VEC (Video Encoder) IP
  drm: Add TV connector states to drm_connector_state
  drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum
  drm/vc4: Fix ->clock_select setting for the VEC encoder
  drm/vc4: Fix race between page flip completion event and clean-up

Reported-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
    it, as pointed out by Lukas Wunner

v3: Add a missing end-of-line character to the printed message
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Reviewed-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539

v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
  suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

v4:
* Do not create similarly named interfaces when reaching the maximum
  amount of unique names, but fail instead, as pointed out by Lukas Wunner
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.

That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.

This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org [v4.8+]

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This has been on the TODO list for a while now, recovering from things
such as attempting to execute a push buffer or touch a semaphore in an
unmapped memory area.

The only thing required on the HW side here is that the offending
channel is removed from the runlist, and *not* a full reset of PFIFO.

This used to be a bit messier to handle before the rework to make use
of engine topology info, but is apparently now trivial.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Looping twice when we can do it once is silly. Also use a consistent
style. Note that there's a good race with the connector list walking,
since that is no longer protected by mode_config.mutex. But that's for
a later patch to fix.

v2: Actually try to not blow up, somehow I lost the hunk that checks
we don't copy too much. Noticed by Chris.

v3:
- squash all drm_mode_getresources cleanups into one
- use consistent style for walking objects (Chris)

v4:
- Use u64_to_user_ptr (Chris)
- Don't forget to copy the last connector (Chris)

v5: Chris was right ...

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161211192019.29603-1-daniel.vetter@ffwll.ch

Joonas complained that writing ww_mutex_lock(&resv->lock, ctx) was too
intrusive compared to reservation_object_lock(resv, ctx);
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161115154642.31850-1-chris@chris-wilson.co.uk

Just prep work to polish and consolidate all the dma-buf related
documenation.

Unfortunately I didn't discover a way to both integrate this new file
into the overall toc while keeping it at the current place. Work
around that by moving it into the overall driver-api/index.rst.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

We thought that no userspace is using them, but oops libdrm is using
them to figure out whether a driver supports modesetting. Check out
drmCheckModesettingSupported but maybe don't because it's horrible and
totally runs counter to where we want to go with libdrm device
handling. The function looks in the device hierarchy for whether
controlD* exist using the following format string:

/sys/bus/pci/devices/%04x:%02x:%02x.%d/drm/controlD%d

The "/drm" subdirectory is the glue directory from the sysfs class
stuff, and the only way to get at it seems to through
kdev->kobj.parent (when kdev is represents e.g. the card0 chardev
instance in sysfs). Git grep says we're not the only ones touching
that, so I hope it's ok we dig into such internals - I couldn't find a
proper interface for getting at the glue directory.

Quick git grep shows that at least -amdgpu, -ati are using this.
-modesetting do not, and on -intel it's only about the 4th fallback
path for device lookup, which is why this didn't blow up earlier.

Oh well, we need to keep it working, and the simplest way is to add a
symlink at the right place in sysfs from controlD* to card*.

v2:
- Fix error path handling by adding if (!minor) return checks (David)
- Fix the controlD* numbers to match what's been there (David)
- Add a comment what exactly userspace minimally needs.
- Correct the analysis for -intel (Chris).

Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes")
Cc: Dave Airlie <airlied@gmail.com>
Reported-and-tested-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NEmil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161209135656.14881-1-daniel.vetter@ffwll.ch

vc4 already has a proper load sequence, but the unload one needed some
fixups: First unregister, and last drop the final ref.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Document the DT binding for the VEC (Video EnCoder) IP.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NRob Herring <robh@kernel.org>

The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Some generic TV connector properties are exposed in drm_mode_config, but
they are currently handled independently in each DRM encoder driver.

Extend the drm_connector_state to store TV related states, and modify the
drm_atomic_connector_{set,get}_property() helpers to fill the connector
state accordingly.

Each driver is then responsible for checking and applying the new config
in its ->atomic_mode_{check,set}() operations.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better
represented with enums.

Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>