- 07 Dec, 2018 5 commits
-
-
Eric Anholt authored
This is the write combiner for TMU writes. You're supposed to flush that at job end if you had dirtied any cachelines. Flushing it at job start then doesn't make any sense. Signed-off-by:
Eric Anholt <eric@anholt.net> Fixes: 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Reviewed-by:
Dave Emett <david.emett@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181203222438.25417-3-eric@anholt.net
-
Eric Anholt authored
Now that I've specified how the end-of-pipeline flushing should work, we're never going to use this function. Signed-off-by:
-
Eric Anholt authored
Right now, userspace doesn't do any L2T writes, but we should lay out our expectations for how it works. v2: Explicitly mention the VCD cache flushing requirements and that we'll flush the other caches before each of the CLs. Signed-off-by: -
Mika Kuoppala authored
Many errs of the form: drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function ‘__igt_reset_evict_vma’: ./include/linux/kern_levels.h:5:18: error: format ‘%x’ expects argument of type ‘unsigned int’, but argum Fixes: b312d8ca ("dma-buf: make fence sequence numbers 64 bit v2") Cc: Christian König <christian.koenig@amd.com> Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Christian König authored
For a lot of use cases we need 64bit sequence numbers. Currently drivers overload the dma_fence structure to store the additional bits. Stop doing that and make the sequence number in the dma_fence always 64bit. For compatibility with hardware which can do only 32bit sequences the comparisons in __dma_fence_is_later only takes the lower 32bits as significant when the upper 32bits are all zero. v2: change the logic in __dma_fence_is_later Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Link: https://patchwork.freedesktop.org/patch/266927/
-
- 06 Dec, 2018 2 commits
-
-
Gerd Hoffmann authored
So qxl kernel patches are sent to the spice-devel list for review. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20181121090129.23506-1-kraxel@redhat.com
-
Christian König authored
I missed one case during the recent revert of the replace_fence interface change. Fixes: 0b258ed1 drm: revert "expand replace_fence to support timeline point v2" Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/266134/
-
- 05 Dec, 2018 1 commit
-
-
Christian König authored
This reverts commit 9a09a423. The whole interface isn't thought through. Since this function can't fail we actually can't allocate an object to store the sync point. Sorry, I should have taken the lead on this from the very beginning and reviewed it more thoughtfully. Going to propose a new interface as a follow up change. Signed-off-by:
-
- 04 Dec, 2018 3 commits
-
-
YueHaibing authored
use kmemdup rather than duplicating its implementation Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/1543471233-159568-1-git-send-email-yuehaibing@huawei.com
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/vkms/vkms_plane.c: In function 'vkms_prepare_fb': drivers/gpu/drm/vkms/vkms_plane.c:144:26: warning: variable 'vkms_obj' set but not used [-Wunused-but-set-variable] It never used since introduction in commit 8ce1bb0b ("drm/vkms: map/unmap buffers in [prepare/cleanup]_fb hooks") Signed-off-by:
-
Jernej Skrabec authored
H6 is first Allwinner SoC which supports 10 bit colors, HDR and AFBC. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181104182705.18047-9-jernej.skrabec@siol.net
-
- 03 Dec, 2018 6 commits
-
-
Eric Anholt authored
The core scheduler tells us when the job is pushed to the scheduler's queue, and I had the job_run functions saying when they actually queue the job to the hardware. By adding tracepoints for the very top of the ioctls and the IRQs signaling job completion, "perf record -a -e v3d:.\* -e gpu_scheduler:.\* <job>; perf script" gets you a pretty decent timeline. Signed-off-by:
-
Eric Anholt authored
We shouldn't be returning v3d-render for our new queue. Signed-off-by:
-
Christian König authored
Extract of useful code from the timeline work. Let's use just a single stub fence instance instead of allocating a new one all the time. Signed-off-by:
-
Christian König authored
Extract of useful code from the timeline work. This provides a function to return a stub or dummy fence which is always signaled. Signed-off-by:
-
Alex Gonzalez authored
The change adds support for the AU Optronics G101EVN010 10.1" TFT LCD panel. Signed-off-by:
Alex Gonzalez <alex.gonzalez@digi.com> Reviewed-by:
Rob Herring <robh@kernel.org> [treding@nvidia.com: sort new entry alphabetically] Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/1540480173-12009-2-git-send-email-alex.gonzalez@digi.com
-
Neil Armstrong authored
On the Amlogic GXL & GXM SoCs, a bug occurs on the primary plane when alpha is used where the alpha is not aligned with the pixel content. The workaround Amlogic implemented is to reset the OSD1 plane hardware block each time the plane is (re)enabled, solving the issue. In the reset, we still need to save the content of 2 registers which depends on the status of the plane, in addition to reload the scaler conversion matrix at the same time. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Maxime Jourdan <mjourdan@baylibre.com> Reviewed-by:
-
- 30 Nov, 2018 12 commits
-
-
Eric Anholt authored
v3d_bo_get_pages() checks this to decide to map the imported buffer instead of the backing shmem file. The caller was about to set this value anyway, and there's no error path in between. Ideally we wouldn't even allocate the shmem file for our imports, but that's a more invasive fix. Signed-off-by:
-
Eric Anholt authored
They were unused, as Dave Emett noticed in TFU review. Signed-off-by:
-
Eric Anholt authored
The TFU can copy from raster, UIF, and SAND input images to UIF output images, with optional mipmap generation. This will certainly be useful for media EGL image input, but is also useful immediately for mipmap generation without bogging the V3D core down. For now we only run the queue 1 job deep, and don't have any hang recovery (though I don't think we should need it, with TFU). Queuing multiple jobs in the HW will require synchronizing the YUV coefficient regs updates since they don't get FIFOed with the job. v2: Change the ioctl to IOW instead of IOWR, always set COEF0, explain why TFU is AUTH, clarify the syncing docs, drop the unused TFU interrupt regs (you're expected to use the hub's), don't take &bo->base for NULL bos. v3: Fix a little whitespace alignment (noticed by checkpatch), rebase on drm_sched_job_cleanup() changes. Signed-off-by: -
Daniel Vetter authored
I've misplaced two functions by accident: - drm_atomic_helper_duplicate_state is really part of the resume/suspend/shutdown device-wide helpers. - drm_atomic_helper_legacy_gamma_set is part of the legacy ioctl compat helpers. Move them both back. Fixes: 9ef8a9dc ("drm: Extract drm_atomic_state_helper.[hc]") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Sean Paul <sean@poorly.run> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128100728.4674-1-daniel.vetter@ffwll.ch
-
Sean Paul authored
Kbuild was complaining about: >> drivers/gpu/drm/drm_atomic_helper.c:3169:27: warning: 'state' may be used uninitialized in this function [-Wmaybe-uninitialized] Now state can't actually be used uninitialized, but we'll assign a value anyways so it stops bellyaching. Kbuild config: link: https://lists.01.org/pipermail/kbuild-all/2018-November/055374.html tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next head: b7ea04d2 commit: b7ea04d2 [4/4] drm: Add DRM_MODESET_LOCK_BEGIN/END helpers config: x86_64-randconfig-x017-201847 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout b7ea04d2 # save the attached .config to linux build tree make ARCH=x86_64 Fixes: b7ea04d2 ("drm: Add DRM_MODESET_LOCK_BEGIN/END helpers") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Sean Paul <seanpaul@chromium.org> [seanpaul added extra details on airlied's suggestion] Link: https://patchwork.freedesktop.org/patch/msgid/20181129203652.223634-1-sean@poorly.run
-
Sean Paul authored
Need to pick up the following patch to fix htmldocs build 167bfe53 ("Documentation: drm: Remove dangling pointer from drm-mm.rst") Signed-off-by:
-
Boris Brezillon authored
Now that scaling is allowed on cursor planes, we can also allow YUV formats. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
-
Boris Brezillon authored
Now that async update has been reworked to allow scaled planes to be updated asynchronously when the scaling params do not change, we can remove the NO_SCALING constraint on cursor planes. Signed-off-by:
-
Boris Brezillon authored
vc4_plane_atomic_async_check() was only based on the state->{crtc,src}_{w,h} which was fine since scaling was not allowed on the cursor plane. We are about to change that to properly support underscan, and, in order to make the async check more reliable, we call vc4_plane_mode_set() from there and check that only the pos0, pos2 and ptr0 entries in the dlist have changed. In vc4_plane_atomic_async_update(), we no longer call vc4_plane_atomic_check() since vc4_plane_mode_set() has already been called in vc4_plane_atomic_async_check(), and we don't need to allocate a new LBM region (we reuse the one from the current state). Note that we now have to manually update each field of the current plane state since it's no longer updated in place (not sure we have to sync all of them, but it's harmless if we do). We also drop the vc4_plane_async_set_fb() call (ptr0 dlist entry has been properly updated in vc4_plane_mode_set()) Signed-off-by: -
Boris Brezillon authored
We are about to use vc4_plane_mode_set() in the async check path, but async check can decide that async update is not possible and force the driver to fallback to a sync update. All the checks that have been done on the plane state during async check stay valid, and checking it again is not necessary. Add a ->checked field to vc4_plane_state, and use it to track the status of the state (checked or not). Signed-off-by:
-
Boris Brezillon authored
We are about to use vc4_plane_mode_set() in the async check path, and async updates require that LBM size stay the same since they reuse the LBM from the previous state. So we definitely don't want to allocate a new LBM region that we know for sure will be free right away. Move the LBM allocation out of vc4_plane_mode_set() and call the new function (vc4_plane_update_lbm()) from vc4_plane_atomic_check(). Signed-off-by:
-
Boris Brezillon authored
LBM is not needed when vertical scaling is disabled. Return 0 in this case to avoid allocating LBM memory that will anyway be unused. While at it, drop the test on ->is_unity which is now redundant. Signed-off-by:
-
- 29 Nov, 2018 11 commits
-
-
Sean Paul authored
Fixes htmldocs build error: Error: Cannot open file ../drivers/gpu/drm/drm_global.c Fixes: 2bb42410 ("drm: Remove drm_global.{c,h} v2") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> Cc: Junwei Zhang <Jerry.Zhang@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129155522.33749-1-sean@poorly.run
-
Sean Paul authored
We should also get the drivers using the helpers. Seems like a good intermediate TODO item. Changes in v2: - Add line about replacing drm_modest_lock_all() (Daniel) Acked-by:
-
Sean Paul authored
This patch adds a couple of helpers to remove the boilerplate involved in grabbing all of the modeset locks. I've also converted the obvious cases in drm core to use the helpers. The only remaining instance of drm_modeset_lock_all_ctx() is in drm_framebuffer. It's complicated by the state clear that occurs on deadlock. ATM, there's no way to inject code in the deadlock path with the helpers, so it's unfit for conversion. Changes in v2: - Relocate ret argument to the end of the list (Daniel) - Incorporate Daniel's doc suggestions (Daniel) Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Reviewed-by:
-
Sean Paul authored
drm_atomic_state_put doesn't require any locking, and this makes things easier for switching to modeset_lock_all helpers in a future patch Changes in v2: - Moved state->acquire_ctx clear to a separate patch (Daniel) Reviewed-by:
-
Sean Paul authored
Instead of always re-initializing the variables we need to clean up on out, move the re-initialization into the branch that goes back to retry label. This is a lateral move right now, but will allow us to pull out the modeset locking into common code. I kept this change separate to make things easier to review. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
drm_atomic_helper_commit_duplicated_state() sets state->acquire_ctx to the context given in the argument and leaves it in state after it quits. The lifetime of state and context are not guaranteed to be the same, so we shouldn't leave that pointer hanging around. This patch resets the context to NULL to avoid any oopses. Changes in v2: - Added to the set Suggested-by:
-
Noralf Trønnes authored
The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. drm_fbdev_generic_setup() handles mode_config.num_connector being zero. In that case it retries fbdev setup on the next .output_poll_changed. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128212713.43500-4-noralf@tronnes.org
-
Maarten Lankhorst authored
Requested by Boris Brezillon for some vc4 fixes that are needed for future vc4 work. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Gerd Hoffmann authored
Signed-off-by:
Robert Foss <robert.foss@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20181128151021.29565-3-kraxel@redhat.com
-
Gerd Hoffmann authored
Since commit "9fdd90c0 drm/virtio: add virtio_gpu_alloc_fence()" fences are not allocated any more by virtio_gpu_fence_emit(). So there is no need to pass down a reference to the fence pointer, a plain pointer is enough now. Convert virtio_gpu_fence_emit() and callers. Signed-off-by:
-
Daniel Vetter authored
We need to handle allocation failures and bail out. While at it, tune the allocation failures down to debug level. syzbot injected an allocation failure and then hit this WARN_ON. Reported-by: syzbot+eb6e5365f23c02517dda@syzkaller.appspotmail.com Signed-off-by:
-
