- 19 Jul, 2022 29 commits
-
-
Dmitry Osipenko authored
DRM API requires the DRM's driver to be backed with the device that can be used for generic DMA operations. The VirtIO-GPU device can't perform DMA operations if it uses PCI transport because PCI device driver creates a virtual VirtIO-GPU device that isn't associated with the PCI. Use PCI's GPU device for the DRM's device instead of the VirtIO-GPU device and drop DMA-related hacks from the VirtIO-GPU driver. Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-8-dmitry.osipenko@collabora.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dmitry Osipenko authored
Change the order of SHMEM initialization and reservation locking to make code cleaner and to prepare for transitioning of the common GEM SHMEM code to use the GEM's reservation lock instead of the shmem.page_lock. There is no need to lock reservation during allocation of the SHMEM pages because the lock is needed only to avoid racing with the async host-side allocation. Hence we can safely move the SHMEM initialization out of the reservation lock. Signed-off-by:
-
Dmitry Osipenko authored
Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core wants to clean up and not the current plane's state. Normally the older atomic state is cleaned up, but the newer state could also be cleaned up in case of aborted commits. Cc: stable@vger.kernel.org Signed-off-by:
-
Dmitry Osipenko authored
Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens. Cc: stable@vger.kernel.org Fixes: c8d4c18b ("dma-buf/drivers: make reserving a shared slot mandatory v4") Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
-
Dmitry Osipenko authored
Unlock reservations in the error code path of virtio_gpu_object_create() to silence debug warning splat produced by ww_mutex_destroy(&obj->lock) when GEM is released with the held lock. Cc: stable@vger.kernel.org Fixes: 30172efb ("drm/virtio: blob prep: refactor getting pages and attaching backing") Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
Transferred 2D BO always must be a shmem BO. Add check for that to prevent NULL dereference if userspace passes a VRAM BO. Cc: stable@vger.kernel.org Reviewed-by:
-
Dmitry Osipenko authored
Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages. Fixes: c2496873 ("drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init") Reviewed-by:
-
Thomas Zimmermann authored
Remove the call to do_remove_conflicting_framebuffers() from the framebuffer registration. Aperture helpers take care of removing conflicting devices. With all ownership information stored in the aperture datastrcutures, remove remove_conflicting_framebuffers() entirely. This change also rectifies DRM generic-framebuffer registration, which tried to unregister conflicting framebuffers, even though it's entirely build on top of DRM. v2: * remove internal aperture-overlap helpers, which are now unused Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-12-tzimmermann@suse.de
-
Thomas Zimmermann authored
When registering a generic framebuffer, automatically acquire ownership of the framebuffer's I/O range. The device will now be handled by the aperture helpers. Fbdev-based conflict handling is no longer required. v2: * use fb_ prefix instead of fbm_ (Javier) Signed-off-by:
-
Thomas Zimmermann authored
On the primary graphics adapter, a driver might conflict with a VGA driver that controls the VGA framebuffer I/O range. Remove the VGA driver from the aperture helpers. Until now, this case has been hendled by fbdev, but it should work even with fbdev disabled. Signed-off-by:
-
Thomas Zimmermann authored
Provide VGA_FB_ constants for the VGA framebuffer I/O range and convert fbdev code. In the case of vga16fb, this is a rename of the existing constants VGA_FB_PHYS and VGA_FB_PHYS_LEN. v2: * clarify relationship with old constants in vga16fb (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Call sysfb_disable() before removing conflicting devices in aperture helpers. Fixes sysfb state if fbdev has been disabled. Signed-off-by:
-
Thomas Zimmermann authored
Remove firmware devices on the PCI bus, by calling aperture_remove_conflicting_pci_devices() in the probe function of each related fbdev driver. iSo far, most of these drivers did not remove conflicting VESA or EFI devices, or outride failed for resource conflicts (i.e., matroxfb.) This must have been broken for quite some time. Signed-off-by:
-
Thomas Zimmermann authored
Convert fbdev drivers from fbdev's remove_conflicting_framebuffers() to the framework-independent aperture_remove_conflicting_devices(). Calling this function will also remove conflicting DRM drivers. Signed-off-by:
-
Thomas Zimmermann authored
Remove remove_conflicting_pci_framebuffers() and implement similar functionality in aperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Move vgag16fb's option parsing into the driver's probe function and generate the rest of the module's init/exit functions from macros. Keep the options code, although there are no options defined. v2: * no options are supported, remove the code (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Move the device-creation from vga16fb to sysfb code. The driver's videomode checks are independent from device creation, so move them into vga16fb's probe function. This will allow to create the module init/exit code automatically. The vga16fb driver requires a screen_info for type VIDEO_TYPE_VGAC or VIDEO_TYPE_EGAC. Such code is nowhere present in the kernel, except for some MIPS systems. It's not clear if the vga16fb driver actually works in practice. v2: * keep driver name to "vga16fb" (Javier) * give rational for moving mode checks (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
-
Marek Vasut authored
The ST7701 initialization sequence is well parametrized, split the GIP programming sequence, which is fully custom completely undocumented TFT matrix specific magic register programming sequence into separate callback so other TFT matrix definitions can add their own GIP sequence. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Guido Günther <agx@sigxcpu.org> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220710194437.289042-9-marex@denx.de
-
Marek Vasut authored
Instead of hard-coding TFT matrix voltage and timing settings, which can even lead to permanent TFT matrix damage, parametrize them in TFT matrix descriptor. Signed-off-by:
-
Marek Vasut authored
The horizontal pixel count is a property of the TFT matrix. Currently the driver hard-codes content of this register to specific value which is only compatible with one TFT matrix, likely the TS8550B one. Calculate the horizontal pixel count from the mode instead. Signed-off-by:
-
Marek Vasut authored
Define DSI_CMD2_BK0_PORCTRL_VBP_MASK and DSI_CMD2_BK0_PORCTRL_VFP_MASK and move the vertical back and front porch calculation from macros into the st7701_init_sequence() function, so it is clear what this does. No functional change. Signed-off-by:
-
Marek Vasut authored
The vertical line count is a property of the TFT matrix. Currently the driver hard-codes content of this register to specific value which is only compatible with one TFT matrix, likely the TS8550B one. Calculate the vertical line count from the mode instead. Signed-off-by:
-
Marek Vasut authored
The gamma correction values are specific to the TFT which is attached to the ST7701 TFT matrix driver, move the gamma correction values from what incorrectly looks like common init sequence into TFT matrix specific settings. While doing so, add macros which defined fields within the gamma register file and a macro which mimics FIELD_PREP except works with constant expressions. Signed-off-by:
-
Marek Vasut authored
The ST7701 and ST7701S all have two voltage supplies, one for internal logic and one for the TFT matrix driver. The supplies are not property of the TFT matrix driver, so move them to common ST7701 code. Signed-off-by:
-
Marek Vasut authored
The ST7701(S) is capable of DSI burst mode, which is more energy efficient than the non-burst modes. Make use of it. The ST7701(S) is capable of DSI non-continuous clock, since it sources the TFT matrix driver clock from internal clock source. The DSI non-continuous clock further reduce power utilization. The ST7701(S) uses DSI LPM for command transmissions, make sure this is configured correctly in the DSI mode flags. Signed-off-by:
-
Marek Vasut authored
The ST7701 and ST7701S are TFT matrix drivers with integrated multi protocol decoder capable of DSI/DPI/SPI input and 480x360...864 line TFT matrix output. Currently the only supported input is DSI. The protocol decoder is separate from the TFT matrix driver and is always capable of handling all of DSI non-burst mode with sync pulses or sync events as well as DSI burst mode. Move the DSI mode configuration from TFT matrix driver properties to common ST7701 code, because this is common to all TFT matrices. Signed-off-by:
-
shaomin Deng authored
there is a repeated word "in", so remove it. Signed-off-by:
shaomin Deng <dengshaomin@cdjrlc.com> Signed-off-by:
-
shaomin Deng authored
remove the rebundant word "the" from comments. Signed-off-by:
-
- 18 Jul, 2022 8 commits
-
-
Christian König authored
Make it clear that DMA_RESV_USAGE_BOOKKEEP can be used for explicit synced user space submissions as well and document the rules around adding the same fence with different usages. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220712131201.131475-1-christian.koenig@amd.com
-
shaomin Deng authored
there is a repeated word "or" in comments, so remove it. Signed-off-by:
-
allen chen authored
Speed up video clock calculation and remove redundant video debug message. Signed-off-by:
Pin-Yen Lin <treapking@chromium.org> Signed-off-by:
Allen Chen <allen.chen@ite.com.tw> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
allen chen authored
Use i2c bus to read/write when it6505 power off will occur i2c error. Add this check will prevent i2c error when it6505 power off. Signed-off-by:
-
allen chen authored
Change power sequence to meet it6505 data sheet requirement when boot on. Signed-off-by:
-
Pin-Yen Lin authored
Send DPCD DP_SET_POWER_D0 command to the monitor in .atomic_enable callback. Without this command, some monitors won't show up again after changing the resolution. Fixes: 46ca7da7 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream") Signed-off-by:
-
Javier Martinez Canillas authored
Data writes for the ssd130x 4-wire SPI protocol need special handling, due the Data/Command control (D/C) pin having to be toggled prior to the write. The regmap API only allowed drivers to provide .reg_{read,write} callbacks to do per register read/write, but didn't provide a way for drivers to do the same for bulk read/writes. For this reason, a custom regmap bus was used by the driver just to define a bulk write callback that implements the D/C pin toggling. But the regmap API has been extended to support defining bulk read/write handlers, so the custom regmap bus is not needed anymore and could just be dropped. Signed-off-by:Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220618174338.2253021-1-javierm@redhat.com
-
Laurent Pinchart authored
Add FourCCs for two missing permutations of the packed YUV 4:4:4 color components, namely AVUY and XVUY. These formats are needed by the NXP i.MX8 ISI. While the ISI is supported by a V4L2 device (corresponding formats have been submitted to V4L2), it is handled in userspace by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220616185210.22018-1-laurent.pinchart@ideasonboard.com
-
- 16 Jul, 2022 3 commits
-
-
Sam Ravnborg authored
- Fix comments using wrong style - Drop repeated word This fixes all checkpatch complains and makes the file a little bit easier to read - as the eye is not distracted by the style violations. Suggested-by:
-
Sam Ravnborg authored
The macros for texture 1 setting all used continuation on a new line, resulting in a highly ureadable definition. Merge the lines so they are each on a single line. As a nice side-effect this fixes a number of checkpatch warnings: "WARNING: please, no spaces at the start of a line". Suggested-by:
-
Sam Ravnborg authored
The license for the via_3d_reg header is MIT - so use the shorter SPDX tag to identify the license. Suggested-by:
-
