Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.

This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
  Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!

Cc: Laura Abbott <labbott@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Pratik Patel <pratikp@codeaurora.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Vincent Donnefort <Vincent.Donnefort@arm.com>
Cc: Sudipto Paul <Sudipto.Paul@arm.com>
Cc: Andrew F. Davis <afd@ti.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Hillf Danton <hdanton@sina.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Acked-by: NLaura Abbott <labbott@redhat.com>
Tested-by: NAyan Kumar Halder <ayan.halder@arm.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-3-john.stultz@linaro.org

This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.

Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.

This code is an evoluiton of the Android ION implementation,
and a big thanks is due to its authors/maintainers over time
for their effort:
  Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
  Laura Abbott, and many other contributors!

Cc: Laura Abbott <labbott@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Pratik Patel <pratikp@codeaurora.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Vincent Donnefort <Vincent.Donnefort@arm.com>
Cc: Sudipto Paul <Sudipto.Paul@arm.com>
Cc: Andrew F. Davis <afd@ti.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Alistair Strachan <astrachan@google.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Hillf Danton <hdanton@sina.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Acked-by: NLaura Abbott <labbott@redhat.com>
Tested-by: NAyan Kumar Halder <ayan.halder@arm.com>
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-2-john.stultz@linaro.org

Those are not supposed to be used by drivers.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/333290/

The ttm_mem_io_* functions were intended to be internal to TTM and
shouldn't have been used in a driver. They were exported in commit
afe6804c just for QXL.

Instead call the qxl_ttm_io_mem_reserve() function directly and
completely drop the free call since that is a dummy on QXL.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/333289/

This way the TTM is destroyed with the correct dma_resv object
locked and we can even pipeline imported BO evictions.

v2: Limit this to only cases when the parent object uses a separate
    reservation object as well. This fixes another OOM problem.
v3: fix init and try_lock on the wrong object
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/337499/

As the name says global memory and bo accounting is global. So it doesn't
make to much sense having pointers to global structures all around the code.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NThomas Hellström <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/332879/

This allows blocking for BOs to become available
in the memory management.

Amdgpu is doing this for quite a while now during CS. Now
apply the new behavior to all drivers using TTM.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NThomas Hellstrom <thellstrom@vmware.com>
Link: https://patchwork.freedesktop.org/patch/332878/

This feature is only used by vmwgfx and superfluous for everybody else.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Co-developed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Tested-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/333650/

-Issue found using checkpatch.pl
-Insert comments for memory barrier usage
Signed-off-by: NBhanusree <bhanusreemahesh@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1571984858-4644-1-git-send-email-bhanusreemahesh@gmail.com

-Insert a blank line after the declarations.
-Issue found using checkpatch.pl
Signed-off-by: NBhanusree <bhanusreemahesh@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1571984833-4596-1-git-send-email-bhanusreemahesh@gmail.com

Fix misspellings of "connector" and "connection"
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024151737.29287-1-geert+renesas@glider.be

GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_plane_helper_funcs. Switch over vboxvideo.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024081404.6978-5-tzimmermann@suse.de

This patch implements prepare_fb() and cleanup_fb() in hibmc with the
GEM VRAM helpers. In the current code, pinning the BO is performed by
hibmc_plane_atomic_update(), where the operation does not belong.

This patch also fixes a bug where the pinned BO was never unpinned.
Pinning multiple BOs would have exhaused the available VRAM and further
pin operations would have failed, leaving the display in a corrupt
state.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024081404.6978-4-tzimmermann@suse.de

GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_simple_display_pipe_funcs. Switch over bochs.

v2:
	* use helpers for struct drm_simple_display_pipe_funcs
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024081404.6978-3-tzimmermann@suse.de

The new helpers pin and unpin a framebuffer's GEM VRAM objects during
plane updates. This should be sufficient for most drivers' implementation
of prepare_fb() and cleanup_fb().

v2:
	* provide helpers for struct drm_simple_display_pipe_funcs
	* rename plane-helper funcs
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024081404.6978-2-tzimmermann@suse.de

-Add comment for memory barrier
-Issue found using checkpatch.pl
Signed-off-by: NBhanusree <bhanusreemahesh@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1571891313-14341-1-git-send-email-bhanusreemahesh@gmail.com

Remove unnecessary casts to pointer types passed to kfree.
Issue detected by coccinelle:
@@
type t1;
expression *e;
@@

-kfree((t1 *)e);
+kfree(e);
Signed-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191023111107.9972-1-wambui.karugax@gmail.com

Passing the wrong type feels icky, everywhere else we use the pipe as
the first parameter. Spotted while discussing patches with Thomas
Zimmermann.

v2: Make xen compile correctly

Acked-By: Thomas Zimmermann <tzimmermann@suse.de> (v1)
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: virtualization@lists.linux-foundation.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191023101256.20509-1-daniel.vetter@ffwll.ch

The attachment list is now protected by the dma_resv object.

Stop holding the dma_buf->lock while calling ->attach/->detach,
this allows for concurrent attach/detach operations.

v2: cleanup commit message and locking in _debug_show()
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336790

This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.

It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.

For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.

Issues and solutions we considered:

- We can't change all existing drivers, and existing improters have
  strong opinions about which locks they're holding while calling
  dma_buf_attachment_map/unmap. Exporters also have strong opinions about
  which locks they can acquire in their ->map/unmap callbacks, levaing no
  room for change. The solution to avoid this was to move the
  actual map/unmap out from this call, into the attach/detach callbacks,
  and cache the mapping. This works because drivers don't call
  attach/detach from deep within their code callchains (like deep in
  memory management code called from cs/execbuf ioctl), but directly from
  the fd2handle implementation.

- The caching has some troubles on some soc drivers, which set other modes
  than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we
  can't re-create the mapping at _map time due to the above locking fun.
  We very carefuly step around that by only caching at attach time if the
  dynamic mode between importer/expoert mismatches.

- There's been quite some discussion on dma-buf mappings which need active
  cache management, which would all break down when caching, plus we don't
  have explicit flush operations on the attachment side. The solution to
  this was to shrug and keep the current discrepancy between what the
  dma-buf docs claim and what implementations do, with the hope that the
  begin/end_cpu_access hooks are good enough and that all necessary
  flushing to keep device mappings consistent will be done there.

v2: cleanup set_name merge, improve kerneldoc
v3: update commit message, kerneldoc and cleanup _debug_show()
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/336788/

During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. After
all other drivers have been converted not to use these helpers anymore,
move these helpers into the last remaining user: Tegra DRM.

If at some point these helpers are deemed more widely useful, they can
be moved out into the DRM DP helpers again.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-14-thierry.reding@gmail.com

During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-13-thierry.reding@gmail.com

During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-12-thierry.reding@gmail.com

The DP specification uses the term "default framing" instead of "non-
enhanced framing".
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-11-thierry.reding@gmail.com

During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.

v3: make link rate unsigned int to avoid overflow
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-10-thierry.reding@gmail.com

During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.

v4: use bulk DPCD writes if possible (Daniel Vetter)
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022145211.2258525-1-thierry.reding@gmail.com

If the transmitter supports pre-emphasis post cursor2 the sink will
request adjustments in a similar way to how it requests adjustments to
the voltage swing and pre-emphasis settings.

Add a helper to extract these adjustments on a per-lane basis from the
DPCD link status.
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-8-thierry.reding@gmail.com

Use microsecond sleeps for the clock recovery and channel equalization
delays during link training. The duration of these delays can be from
100 us up to 16 ms. It is rude to busy-loop for that amount of time.

While at it, also convert to standard coding style by putting the
opening braces in a function definition on a new line. Also switch to
using an unsigned int for the AUX read interval to match the data type
of the parameters to usleep_range().

v2: use correct multiplier for training delays (Philipp Zabel)
v3: clarify data type change in commit message
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-7-thierry.reding@gmail.com

Add a helper to check if the sink supports the eDP alternate scrambler
reset value of 0xfffe.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-6-thierry.reding@gmail.com

Add a helper to check whether the sink supports ANSI 8B/10B channel
coding capability as specified in ANSI X3.230-1994, clause 11.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-5-thierry.reding@gmail.com

Add a helper that checks for the fast training capability given the DPCD
receiver capabilities blob.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-4-thierry.reding@gmail.com

It's idiomatic to check the return value of a function call immediately
after the function call, without any blank lines in between, to make it
more obvious that the two lines belong together.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-3-thierry.reding@gmail.com

Keeping the list sorted alphabetically makes it much easier to determine
where to add new includes.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-2-thierry.reding@gmail.com

Parroting Daniel's backmerge justification from
2e79e22e:

Thierry needs fd70c775 ("drm/bridge: tc358767: fix max_tu_symbol
value") to be able to merge his dp_link patch series.
Signed-off-by: NSean Paul <seanpaul@chromium.org>

This reverts commit 23b48225.

This patch does not have an acceptable open source userspace
implementation, and as such it does not meet the requirements for adding
new UAPI.

Discussion is in the Link.

Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html
Fixes: 23b48225 ("drm/omap: add OMAP_BO flags to affect buffer allocation")
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022204733.235801-1-sean@poorly.run

Thierry needs fd70c775 ("drm/bridge: tc358767: fix max_tu_symbol
value") to be able to merge his dp_link patch series.

Some adjacent changes conflicts, plus some clashes in i915 due to
cherry-picking and git trying to be helpful and leaving both versions
in.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Should help new people pick suitable tasks.

Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Sean Paul <sean@poorly.run>
Reviewed-by: NSean Paul <sean@poorly.run>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022152530.22038-2-daniel.vetter@ffwll.ch

Done with

commit aef9f33b
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Oct 23 17:43:10 2018 +0300

    drm/i915: Ensure proper HDA suspend/resume ordering with a device link

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NSean Paul <sean@poorly.run>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022152530.22038-1-daniel.vetter@ffwll.ch

This is not something we'll fix, because failing to clean up stuff (or
doing it in the wrong order) is a driver bug. The offending FIXME goes
all the way back to the original modeset merge.

We've added a WARN_ON in

commit 2b677e8c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Dec 10 21:16:05 2012 +0100

    drm: reference framebuffers which are on the idr

including a comment blaming drivers on this. Right thing to do is most
likely drm_atomic_helper_shutdown plus making sure that
drm_mode_config_cleanup is not called too early (i.e. not in driver
unload, but only in the final drm_device release callback).

Cc: Mihail Atanassov <Mihail.Atanassov@arm.com>
Reported-by: NMihail Atanassov <Mihail.Atanassov@arm.com>
Reviewed-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191022163717.1064-1-daniel.vetter@ffwll.ch

Use the new drm_hdmi_avi_infoframe_bars() helper instead
of hand rolling it.

Cc: Eric Anholt <eric@anholt.net>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008164814.5894-2-ville.syrjala@linux.intel.comReviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>