- 08 Jul, 2021 8 commits
-
-
Noralf Trønnes authored
Add VID/PID for the Raspberry Pi Pico implementation. Source: https://github.com/notro/gud-pico Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Peter Stuge <peter@stuge.se> Link: https://patchwork.freedesktop.org/patch/msgid/20210703141321.35494-1-noralf@tronnes.org
-
Noralf Trønnes authored
There'a limit to how big a kmalloc buffer can be, and as memory gets fragmented it becomes more difficult to get big buffers. The downside of smaller buffers is that the driver has to split the transfer up which hampers performance. Compression might also take a hit because of the splitting. Solve this by allocating the transfer buffer using vmalloc and create a SG table to be passed on to the USB subsystem. vmalloc_32() is used to avoid DMA bounce buffers on USB controllers that can only access 32-bit addresses. This also solves the problem that split transfers can give host side tearing since flushing is decoupled from rendering. usb_sg_wait() doesn't have timeout handling builtin, so it is wrapped in a timer like 4 out of 6 users in the kernel have done. v2: - Use DIV_ROUND_UP (Linus) - Add timeout note to the commit log (Linus) - Expand note about upper buffer limit (Linus) - Change var name s/timer/ctx/ in gud_usb_bulk_timeout() Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Noralf Trønnes authored
Free transfer and compression buffers on device removal instead of at DRM device removal time. This ensures that the usual 2x8MB buffers are released when the device is unplugged and not kept around should userspace keep the DRM device fd open. At least Ubuntu 20.04 doesn't release the DRM device on unplug. The damage_lock mutex is not destroyed because it is used outside the drm_dev_enter/exit block in gud_pipe_update(). AFAICT it's possible for an open fbdev descriptor to trigger a commit after the USB device is gone. v2: Don't destroy damage_lock Reviewed-by:
-
Thomas Zimmermann authored
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210706075425.9257-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Vmwgfx already uses Linux IRQ functions. All that's left to replace is the reference to struct drm_device.irq. Use irq value of struct pci_dev instead. Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706072253.6844-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
The header file is not required. Don't include it. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706072712.7558-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706074545.8763-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
The function qxl_gem_prime_mmap() returns an error. The two callers of gem_prime_mmap are drm_fbdev_fb_mmap() and drm_gem_dmabuf_mmap(), which both already handle NULL-callbacks with an error code. So clear gem_prime_mmap in qxl and remove qxl_gem_prime_mmap(). Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210624090500.8320-1-tzimmermann@suse.de
-
- 06 Jul, 2021 4 commits
-
-
Beatriz Martins de Carvalho authored
Replace macro in vkms_release() Signed-off-by:
Beatriz Martins de Carvalho <martinsdecarvalhobeatriz@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210706154510.224695-1-martinsdecarvalhobeatriz@gmail.com
-
Tim Gover authored
Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back to pixelvalve causing it to not clear the FIFO. Adjust the ordering and timing of operations to ensure the clear signal makes it through to pixelvalve. Signed-off-by:
Tim Gover <tim.gover@raspberrypi.com> Signed-off-by:
-
Nicolas Saenz Julienne authored
We don't want to print an error message each time devm_snd_soc_register_card() returns -EPROBE_DEFER, the function will most likely succeed some time in the future, once the missing resources are available. So use dev_err_probe(), which will redirect the messages to the debug log level in such case. Signed-off-by:
Nicolas Saenz Julienne <nsaenzju@redhat.com> Signed-off-by:
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The respective vgem functions are being removed. The file_operations structure vgem_driver_fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS(). Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210624095238.8804-1-tzimmermann@suse.de
-
- 05 Jul, 2021 7 commits
-
-
Thomas Zimmermann authored
Declare constant LUT for bpp programming as static const. Removes mutable data from device structure. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210702075642.27834-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
The type and flags values are stored in the PCI ID list. Extract them in the probe function. Makes the device initialization more readable. Signed-off-by:
-
Thomas Zimmermann authored
Inline mgag200_device_init() into mgag200_device_create(), which is the only caller. Also remove a duplicate error message for mgag200_modeset_init(). The function will print an error if/where it failed. v2: * include a note about the removed error message in changelog (Sam) Signed-off-by:
-
Thomas Zimmermann authored
The flags argument is only relevant for UMS drivers. Pass 0. Signed-off-by:
-
Thomas Zimmermann authored
All GEM-VRAM-based drivers use auto-cleanup via drmm_vram_helper_init(). Unexport the manual APIs and make them internal implementation. Signed-off-by:
-
Thomas Zimmermann authored
Convert to managed GEM VRAM initialization and switch bochs to full autocleanup. Signed-off-by:
-
Thomas Zimmermann authored
The bochs driver is only ~600 lines of code. Putting it into tiny/ cleans up the DRM directory slightly. Some style problems were fixed and unneeded include statements were removed. No functional changes. v2: * make bochs_mode_funcs static (Daniel, kernel test robot) * rebase onto aperture API changes Signed-off-by:
-
- 04 Jul, 2021 1 commit
-
-
Linus Walleij authored
The macro mipi_dbi_command() does not report errors unless you wrap it in another macro to do the error reporting. Report a rate-limited error so we know what is going on. After this any code wishing to send command arrays can rely on mipi_dbi_command() providing an appropriate error message if something goes wrong. Suggested-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 01 Jul, 2021 18 commits
-
-
Melissa Wen authored
Update: - debugging issues on igt testcases - plane composition features: add primary plane improvements - suggestions of good tasks to start working on vkms Drop: - syzkaller bug report: what triggered the warning was replaced by shmem functions at https://patchwork.freedesktop.org/patch/394614/ - overlay plane: this feature was added by https://patchwork.freedesktop.org/patch/430941/Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210626092655.ghmmt2yux5klrne7@smtp.gmail.com
-
Thomas Zimmermann authored
Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by: Chen-Yu Tsai <wens@csie.org> # sun4i Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson Link: https://patchwork.freedesktop.org/patch/msgid/20210629135833.22679-1-tzimmermann@suse.de
-
Boris Brezillon authored
Experience has shown that 1ms is sometimes not enough, even when the GPU is running at its maximum frequency, not to mention that an MMU operation might take longer if the GPU is running at a lower frequency, which is likely to be the case if devfreq is active. Let's pick a significantly bigger timeout value (1ms -> 100ms) to be on the safe side. v5: * New patch Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-17-boris.brezillon@collabora.com
-
Steven Price authored
The hardware has a set of '_NEXT' registers that can hold a second job while the first is executing. Make use of these registers to enqueue a second job per slot. v5: * Fix a comment in panfrost_job_init() v3: * Fix the done/err job dequeuing logic to get a valid active state * Only enable the second slot on GPUs supporting jobchain disambiguation * Split interrupt handling in sub-functions Signed-off-by:
-
Boris Brezillon authored
If the process who submitted these jobs decided to close the FD before the jobs are done it probably means it doesn't care about the result. v5: * Add a panfrost_exception_is_fault() helper and the DRM_PANFROST_EXCEPTION_MAX_NON_FAULT value v4: * Don't disable/restore irqs when taking the job_lock (not needed since this lock is never taken from an interrupt context) v3: * Set fence error to ECANCELED when a TERMINATED exception is received Signed-off-by:
-
Boris Brezillon authored
If we can recover from a fault without a reset there's no reason to issue one. v3: * Drop the mention of Valhall requiring a reset on JOB_BUS_FAULT * Set the fence error to -EINVAL instead of having per-exception error codes Signed-off-by:
-
Boris Brezillon authored
Things are unlikely to resolve until we reset the GPU. Let's not wait for other faults/timeout to happen to trigger this reset. Signed-off-by:
-
Boris Brezillon authored
If we don't do that, we have to wait for the job timeout to expire before the fault jobs gets killed. v3: * Make sure the AS is re-enabled when new jobs are submitted to the context Signed-off-by:
-
Boris Brezillon authored
This is not yet needed because we let active jobs be killed during by the reset and we don't really bother making sure they can be restarted. But once we start adding soft-stop support, controlling when we deal with the remaining interrrupts and making sure those are handled before the reset is issued gets tricky if we keep job interrupts active. Let's prepare for that and mask+flush job IRQs before issuing a reset. v4: * Add a comment explaining why we WARN_ON(!job) in the irq handler * Keep taking the job_lock when evicting stalled jobs v3: * New patch Signed-off-by:
-
Boris Brezillon authored
Now that we can pass our own workqueue to drm_sched_init(), we can use an ordered workqueue on for both the scheduler timeout tdr and our own reset work (which we use when the reset is not caused by a fault/timeout on a specific job, like when we have AS_ACTIVE bit stuck). This guarantees that the timeout handlers and reset handler can't run concurrently which drastically simplifies the locking. v5: * Don't call cancel_delayed_timeout() in the reset path (those works are canceled in drm_sched_stop()) v4: * Actually pass the reset workqueue to drm_sched_init() * Don't call cancel_work_sync() in panfrost_reset(). It will deadlock since it might be called from the reset work, which is executing and cancel_work_sync() will wait for the handler to return. Checking the reset pending status should avoid spurious resets v3: * New patch Suggested-by:
-
Boris Brezillon authored
This should avoid switching to interrupt context when the GPU is under heavy use. v3: * Don't take the job_lock in panfrost_job_handle_irq() Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Boris Brezillon authored
Expose a helper to trigger a GPU reset so we can easily trigger reset operations outside the job timeout handler. Signed-off-by:
-
Boris Brezillon authored
Do the exception -> string translation using a table. This way we get rid of those magic numbers and can easily add new fields if we need to attach extra information to exception types. v4: * Don't expose exception type to userspace * Merge the enum definition and the enum -> string table declaration in the same patch v3: * Drop the error field Signed-off-by:
-
Boris Brezillon authored
Currently unused. We'll add it back if we need per-GPU definitions. Signed-off-by:
-
Boris Brezillon authored
Exception types will be defined as an enum. v4: * Fix typo in the commit message Signed-off-by:
-
Boris Brezillon authored
If the fence creation fail, we can return the error pointer directly. The core will update the fence error accordingly. Signed-off-by:
-
Boris Brezillon authored
Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU reset. This leads to extra complexity when we need to synchronize timeout works with the reset work. One solution to address that is to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. Thanks to the serialization provided by the ordered workqueue we are guaranteed that timeout handlers are executed sequentially, and can thus easily reset the GPU from the timeout handler without extra synchronization. v5: * Add a new paragraph to the timedout_job() method v3: * New patch v4: * Actually use the timeout_wq to queue the timeout work Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
-
Boris Brezillon authored
The documentation is a bit vague and doesn't really describe what the ->timedout_job() is expected to do. Let's add a few more details. v5: * New patch Suggested-by:
-
- 30 Jun, 2021 1 commit
-
-
Mikel Rychliski authored
radeon_ttm_bo_destroy() is attempting to access the resource object to update memory counters. However, the resource object is already freed when ttm calls this function via the destroy callback. This causes an oops when a bo is freed: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:radeon_ttm_bo_destroy+0x2c/0x100 [radeon] Call Trace: radeon_bo_unref+0x1a/0x30 [radeon] radeon_gem_object_free+0x33/0x50 [radeon] drm_gem_object_release_handle+0x69/0x70 [drm] drm_gem_handle_delete+0x62/0xa0 [drm] ? drm_mode_destroy_dumb+0x40/0x40 [drm] drm_ioctl_kernel+0xb2/0xf0 [drm] drm_ioctl+0x30a/0x3c0 [drm] ? drm_mode_destroy_dumb+0x40/0x40 [drm] radeon_drm_ioctl+0x49/0x80 [radeon] __x64_sys_ioctl+0x8e/0xd0 Avoid the issue by updating the counters in the delete_mem_notify callback instead. Also, fix memory statistic updating in radeon_bo_move() to identify the source type correctly. The source type needs to be saved before the move, because the moved from object may be altered by the move. Fixes: bfa3357e ("drm/ttm: allocate resource object instead of embedding it v2") Signed-off-by:
Mikel Rychliski <mikel@mikelr.com> Reviewed-by:
-
- 29 Jun, 2021 1 commit
-
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in zte. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
-
