drm/komeda: Optionally dump DRM state on interrupts
It's potentially useful information when diagnosing error/warn IRQs, so
dump it to dmesg with a drm_info_printer. Hide this extra debug dumping
behind another komeda_dev->err_verbosity bit.
Note that there's not much sense in dumping it for INFO events,
since the VSYNC event will swamp the log.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:34 +0000 (17:58 +0100)]
drm/mcde: dsi: Enable clocks in pre_enable() instead of mode_set()
The DSI initialization sequence incorrectly assumes that the mode_set()
function of the DRM bridge is always called when (re-)enabling the display.
This is not necessarily the case.
Keeping the device idle in the framebuffer console for a while results
in the display being turned off using the disable() function. However,
as soon as any key is pressed only (pre_)enable() are called.
mode_set() is skipped because the mode has not been changed.
In this case, the DSI HS/LP clocks are never turned back on,
preventing the display from working.
Fix this by moving a part of the initialization sequence from
mode_set() to pre_enable(). Keep most of the video mode setup in
mode_set() since most of the registers are only dependent on the mode
that is set for the panel - there is no need to write them again each
time we re-enable the display.
Although both show up as connected, the first one does not have
any size and no available modes. This confuses userspace tools
(e.g. kmscube) who look for available modes for the first connector.
The reason for the duplicated connector is that mcde_dsi.c and the
DRM panel bridge helper both set up a DSI connector, with more or less
the same code. The connector set up by the DRM panel bridge is the
one that is correctly set up in the example above.
Therefore we can just remove the connector setup from mcde_dsi.c
and let the DRM core handle all the hard work.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:32 +0000 (17:58 +0100)]
drm/mcde: dsi: Delay start of video stream generator
The initialization order for DSI video mode is important - if we
enable the video stream generator (VSG) before the MCDE DSI formatter
starts sending pixel data, it will immediately run into an error and
disable itself again.
Avoid this problem by delaying the activation of the VSG
until the MCDE DSI formatter is properly set up and running
(i.e. when mcde_dsi_bridge_enable() is called).
Stephan Gerhold [Wed, 6 Nov 2019 16:58:30 +0000 (17:58 +0100)]
drm/mcde: Fix frame sync setup for video mode panels
The MCDE driver differentiates only between "te_sync"
(for hardware TE0 sync) and software sync
(i.e. manually triggered updates) at the moment.
However, none of these options work correctly for video mode panels.
Therefore, we need to make some changes to make them work correctly:
- Select hardware sync coming from the (DSI) formatter.
- Keep the FIFO permanently enabled (otherwise MCDE will stop
feeding data to the panel).
- Skip manual software sync (this is not necessary in video mode).
Automatically detect if the connected panel is using video mode
and enable the necessary changes in that case.
Stephan Gerhold [Wed, 6 Nov 2019 16:58:29 +0000 (17:58 +0100)]
drm/mcde: Provide vblank handling unconditionally
At the moment, vblank handling is only enabled together with
TE synchronization. However, the vblank IRQ is also working with
on displays without TE synchronization (e.g. DSI video mode panels).
It seems like the vblank IRQ is actually generated by the
MCDE hardware for the channel.
Therefore, the vblank handling should be working correctly in
all the cases and we can enable it unconditionally.
Wambui Karuga [Thu, 7 Nov 2019 09:29:45 +0000 (12:29 +0300)]
drm/rockchip: use DRM_DEV_ERROR for log output
Replace the use of the dev_err macro with the DRM_DEV_ERROR
DRM helper macro. rockchip driver uses almost exclusively DRM_* logging
(aside from 2 dev_* instances, one of which is converted in this patch),
so this makes things more consistent.
Udl's GEM code and the generic SHMEM are almost identical. Replace
the former with SHMEM. The dmabuf support in udl is being replaced
with generic GEM PRIME functions.
The main difference is in the caching flags for mmap pages. By
default, SHMEM always sets (uncached) write combining. In udl's
memory management code, only imported buffers use write combining.
Memory pages of locally created buffer objects are mmap'ed with
caching enabled. To keep the optimization, udl provides its own
mmap function for GEM objects where it fixes up the mapping flags.
v3:
- restore udl vmap that enables caching
v2:
- remove obsolete code in a separate patch
Christian König [Fri, 27 Sep 2019 12:34:25 +0000 (14:34 +0200)]
drm/radeon: finally fix the racy VMA setup
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
No functional change, but only compile tested.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/339354/
Christian König [Fri, 27 Sep 2019 12:34:24 +0000 (14:34 +0200)]
drm/ttm: also export ttm_bo_vm_fault v2
That is needed by at least a cleanup in radeon.
v2: also export ttm_bo_vm_access
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/339353/
This commit sets the remaining atomic-modesetting helpers and the flag
DRIVER_ATOMIC. Legacy cursor functions are removed in favor of the cursor
plane. For power management, atomic helpers replace the indvidual
operations that the driver currently runs.
As the CRTC code has already been prepared for a split between mode
setting and plane handling, most of the CRTC's atomic modesetting is
build upon primitives of the non-atomic implementation.
Like the original mode-setting code, the primary plane supports XRGB888,
RGB565 and C8. The plane itself only pins BOs and sets the base address
and scanline offset. The mode-setting code will be located in the CRTC's
atomic helpers.
v2:
* don't set plane call-back functions to NULL explicitly
* define plane format array in global scope
The implementation of ast_set_vbios_mode() converts a DRM display mode
and framebuffer into an adjusted mode and stores information for the
video BIOS to several scratch regsiters.
Here we split the function into individual functions that do the
conversion, set the VBIOS mode information and format information.
This makes it compatible with support for primary planes and atomic
modesetting.
drm/ast: Split ast_set_ext_reg() into color and threshold function
In ast_set_ext_reg() sets several framebuffer options and CRT threshold
parameters. The former is mostly state of the primary plane; the latter
is constant. Hence, split the function in two and make it work with
atomic modesetting.
drm/ast: Don't clear base address and offset with default values
The content of the base-address and offset registers are state of
the primary plane. Clearing it to default values will interfere with
plane functions for atomic mode setting.
drm/ast: Check video-mode requirements against VRAM size
Each video mode's primary plane requires a minimum amount of video
memory. For double buffering, this is at most half the available
VRAM. Check this constraint.
drm/ast: Remove last traces of struct ast_gem_object
The ast driver has switched to struct drm_vram_gem_object a while ago.
This patch removes a function and forward declaration that were forgotten
before.
Icenowy Zheng [Tue, 29 Oct 2019 12:16:57 +0000 (13:16 +0100)]
drm/bridge: Add Analogix anx6345 support
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Icenowy Zheng [Tue, 29 Oct 2019 12:16:57 +0000 (13:16 +0100)]
drm/bridge: split some definitions of ANX78xx to dedicated headers
Some definitions currently in analogix-anx78xx.h are not restricted to
the ANX78xx series, but also applicable to other DisplayPort
transmitters by Analogix.
Split out them to dedicated headers, and make analogix-anx78xx.h include
them.
drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/
drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/
Few for_each macro set variables that are never used later which led
to generate unused-but-set-variable warnings.
Add (void)(foo) inside the macros to remove these warnings
Legacy (non-atomic) page flip support is added to the driver by using the
mode_set_base CRTC function, that allows configuring a new framebuffer for
display. Since the function requires the primary plane's fb to be set
already, this is done prior to calling the function in the page flip helper
and reverted if the flip fails.
The vblank interrupt handler is also refactored to support passing an event.
The PIPE_TE_STATUS bit is also considered to indicate vblank on medfield
only, as explained in psb_enable_vblank.
It was tested by running weston on both poulsbo and cedartrail.
drm/gma500: Add missing call to allow enabling vblank on psb/cdv
This adds a missing call to drm_crtc_vblank_on to the common DPMS helper
(used by poulsbo and cedartrail), which is called in the CRTC enable path.
With that call, it becomes possible to enable vblank when needed.
It is already balanced by a drm_crtc_vblank_off call in the helper.
Other platforms (oaktrail and medfield) use a dedicated DPMS helper that
does not have the proper vblank on/off hooks. They are not added in this
commit due to lack of hardware to test it with.
Daniel Vetter [Mon, 4 Nov 2019 17:38:01 +0000 (18:38 +0100)]
drm/ttm: remove ttm_bo_wait_unreserved
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)
v3: Rebase over fault handler helperification.
Reviewed-by: Christian König <christian.koenig@amd.com> (v2) Reviewed-by: Thomas Hellström <thellstrom@vmware.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-3-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 4 Nov 2019 17:38:00 +0000 (18:38 +0100)]
drm/nouveau: slowpath for pushbuf ioctl
We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.
Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.
Aside from "it compiles" entirely untested unfortunately.
Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-2-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 4 Nov 2019 17:37:59 +0000 (18:37 +0100)]
dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring <robh@kernel.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Eric Anholt <eric@anholt.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
Leandro Ribeiro [Wed, 30 Oct 2019 01:12:11 +0000 (22:12 -0300)]
drm/doc: Update IGT documentation
The IGT documentation in this page is telling us to build it using
make. According to commit 67993c1 ("automake: Point builders at
meson") from the IGT project, this is deprecated and IGT should be
built with meson. Instead of having a documentation for IGT in this
page, point to their GitLab README, which should always be up to
date.
Daniel Vetter [Wed, 23 Oct 2019 14:49:53 +0000 (16:49 +0200)]
drm/todo: Add entry to remove load/unload hooks
They're midlayer, broken, and because of the old gunk, we can't fix
them. For examples see the various checks in drm_mode_object.c against
dev->registered, which cannot be enforced if the driver still uses the
load hook.
Unfortunately our biggest driver still uses load/unload, so this would
be really great to get fixed.
Daniel Vetter [Wed, 23 Oct 2019 14:49:52 +0000 (16:49 +0200)]
drm/property: Enforce more lifetime rules
Properties can't be attached after registering, userspace would get
confused (no one bothers to reprobe really).
- Add kerneldoc
- Enforce this with some checks. This needs a somewhat ugly check
since connectors can be added later on, but we still need to attach
all properties before they go public.
Note that we already enforce that properties themselves are created
before the entire device is registered.
Unfortunately this doesn't work for drivers which have a ->load
callback, see
Christian König [Mon, 4 Nov 2019 11:59:01 +0000 (12:59 +0100)]
drm/ttm: ttm_tt_init_fields() can be static
Fixes: 75a57669cbc8 ("drm/ttm: add ttm_sg_tt_init") Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.kernel.org/patch/10263323/
Thomas Hellstrom [Wed, 25 Sep 2019 13:11:23 +0000 (15:11 +0200)]
drm/ttm: Convert vm callbacks to helpers
The default TTM fault handler may not be completely sufficient
(vmwgfx needs to do some bookkeeping, control the write protectionand also
needs to restrict the number of prefaults).
Also make it possible replicate ttm_bo_vm_reserve() functionality for,
for example, mkwrite handlers.
So turn the TTM vm code into helpers: ttm_bo_vm_fault_reserved(),
ttm_bo_vm_open(), ttm_bo_vm_close() and ttm_bo_vm_reserve(). Also provide
a default TTM fault handler for other drivers to use.
Thomas Hellstrom [Wed, 25 Sep 2019 13:11:22 +0000 (15:11 +0200)]
drm/ttm: Remove explicit typecasts of vm_private_data
The explicit typcasts are meaningless, so remove them.
Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/332899/ Signed-off-by: Christian König <christian.koenig@amd.com>
This patchset doesn't meet the UAPI requirements set out in [1] for the DRM
subsystem. Once the userspace component is reviewed and ready for merge
we can try again.
This patchset doesn't meet the UAPI requirements set out in [1] for the DRM
subsystem. Once the userspace component is reviewed and ready for merge
we can try again.
This patchset doesn't meet the UAPI requirements set out in [1] for the DRM
subsystem. Once the userspace component is reviewed and ready for merge
we can try again.
This patchset doesn't meet the UAPI requirements set out in [1] for the DRM
subsystem. Once the userspace component is reviewed and ready for merge
we can try again.
This patchset doesn't meet the UAPI requirements set out in [1] for the DRM
subsystem. Once the userspace component is reviewed and ready for merge
we can try again.
Rob Herring [Thu, 24 Oct 2019 19:18:59 +0000 (14:18 -0500)]
drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
introduced a GEM object mmap() hook which is expected to subtract the
fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
a fake offset.
To fix this, let's always call mmap() object callback with an offset of 0,
and leave it up to drm_gem_mmap_obj() to remove the fake offset.
TTM still needs the fake offset, so we have to add it back until that's
fixed.
Fixes: c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191024191859.31700-1-robh@kernel.org
Instead of tracking per-slot utilisation track a single value for the
entire GPU. Ultimately it doesn't matter if the GPU is busy with only
vertex or a combination of vertex and fragment processing - if it's busy
then it's busy and devfreq should be scaling appropriately.
This also makes way for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.
Hans de Goede [Mon, 28 Oct 2019 13:31:59 +0000 (14:31 +0100)]
drm/vboxvideo: Use drm_gem_fb_create_with_dirty instead of drm_gem_fb_create
Commit 7d79aa8628fe ("drm/vboxvideo: Replace struct vram_framebuffer
with generic implemenation") removed the diy framebuffer code from
the vboxvideo driver, resulting in a nice cleanup.
But since the vboxvideo driver needs the generic dirty tracking code,
it's drm_mode_config_funcs.fb_create should be set to
drm_gem_fb_create_with_dirty not drm_gem_fb_create.
This commit fixes this, fixing the framebuffer not always updating.
Christian König [Thu, 7 Jun 2018 08:28:47 +0000 (10:28 +0200)]
drm/amdgpu: add independent DMA-buf import v9
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
stop using _(map|unmap)_locked
v7: drop invalidations when the BO is already in system domain
v8: rebase on new DMA-buf patch and drop move notification
v9: cleanup comments
Christian König [Wed, 30 May 2018 12:42:24 +0000 (14:42 +0200)]
drm/amdgpu: add independent DMA-buf export v8
Add an DMA-buf export implementation independent of the DRM helpers.
This not only avoids the caching of DMA-buf mappings, but also
allows us to use the new dynamic locking approach.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports
v7: rebased on new DMA-buf locking patch
v8: drop extra include
drm/todo: Clarify situation around fbdev and defio
The TODO item is misleading and makes it seem as if fbdev emulation
cannot be used with SHMEM. Rephrase the text to describe the current
situation more correctly.
drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs
There are no users of drm_fb_helper_defio_init(), so we can remove
it. The documentation around defio support is a bit misleading and
should mention compatibility issues with SHMEM helpers. Clarify this.
Steven Price [Fri, 25 Oct 2019 10:51:56 +0000 (11:51 +0100)]
drm: Don't free jobs in wait_event_interruptible()
drm_sched_cleanup_jobs() attempts to free finished jobs, however because
it is called as the condition of wait_event_interruptible() it must not
sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep.
Instead let's rename drm_sched_cleanup_jobs() to
drm_sched_get_cleanup_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com> Fixes: 5918045c4ed4 ("drm/scheduler: rework job destruction") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/337652/
John Stultz [Mon, 21 Oct 2019 19:03:09 +0000 (19:03 +0000)]
dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds the default CMA heap. We will enable
selectively adding other CMA memory regions to the dmabuf heaps
interface with a later patch (which requires a dt binding)
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: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Laura Abbott <labbott@redhat.com> Tested-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-5-john.stultz@linaro.org
John Stultz [Mon, 21 Oct 2019 19:03:08 +0000 (19:03 +0000)]
dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
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: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Laura Abbott <labbott@redhat.com> Tested-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-4-john.stultz@linaro.org
John Stultz [Mon, 21 Oct 2019 19:03:07 +0000 (19:03 +0000)]
dma-buf: heaps: Add heap helpers
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: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Laura Abbott <labbott@redhat.com> Tested-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-3-john.stultz@linaro.org
Andrew F. Davis [Mon, 21 Oct 2019 19:03:06 +0000 (19:03 +0000)]
dma-buf: Add dma-buf heaps framework
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: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Laura Abbott <labbott@redhat.com> Tested-by: Ayan Kumar Halder <ayan.halder@arm.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191021190310.85221-2-john.stultz@linaro.org
Christian König [Fri, 27 Sep 2019 13:06:22 +0000 (15:06 +0200)]
drm/qxl: stop using TTM to call driver internal functions
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 afe6804c045fbd69a1b75c681107b5d6df9190de 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.
Christian König [Tue, 16 Apr 2019 18:19:07 +0000 (20:19 +0200)]
drm/ttm: use the parent resv for ghost objects v3
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: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/337499/
Christian König [Tue, 1 Oct 2019 08:02:58 +0000 (10:02 +0200)]
drm/ttm, drm/vmwgfx: move cpu_writers handling into vmwgfx
This feature is only used by vmwgfx and superfluous for everybody else.
Signed-off-by: Christian König <christian.koenig@amd.com> Co-developed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Tested-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/333650/
drm/hisilicon/hibmc: Use GEM VRAM's prepare_fb() and cleanup_fb() helpers
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.
drm/vram-helpers: Add helpers for prepare_fb() and cleanup_fb()
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
Christian König [Tue, 3 Jul 2018 14:42:26 +0000 (16:42 +0200)]
dma-buf: change DMA-buf locking convention v3
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:37 +0000 (16:34 +0200)]
drm/tegra: Move drm_dp_link helpers to Tegra DRM
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:36 +0000 (16:34 +0200)]
drm/rockchip: Avoid drm_dp_link helpers
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.
Thierry Reding [Mon, 21 Oct 2019 14:34:35 +0000 (16:34 +0200)]
drm/msm: edp: Avoid drm_dp_link helpers
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.