- 26 Jul, 2022 1 commit
-
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-2-tzimmermann@suse.de
-
- 22 Jul, 2022 8 commits
-
-
Javier Martinez Canillas authored
If devm_drm_of_get_bridge() can't find the connected bridge, it returns an ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred. But this path also prints an error message, which pollutes the kernel log since is printed on every probe deferral, i.e: $ dmesg | grep "failed to create panel bridge" | wc -l 38 Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220722074755.660258-1-javierm@redhat.com
-
Liviu Dudau authored
Komeda driver relies on the generic DRM atomic helper functions to handle commits. It only implements an atomic_commit_tail hook for the mode_config_helper_funcs and even that one is pretty close to the generic implementation with the exception of additional dma_fence signalling. What the generic helper framework doesn't do is waiting for the actual hardware to signal that the commit parameters have been written into the appropriate registers. As we signal CRTC events only on the irq handlers, we need to flush the configuration and wait for the hardware to respond. Add the Komeda specific implementation for atomic_commit_hw_done() that flushes and waits for flip done before calling drm_atomic_helper_commit_hw_done(). The fix was prompted by a patch from Carsten Haitzler where he was trying to solve the same issue but in a different way that I think can lead to wrong event signaling to userspace. Reported-by:
Carsten Haitzler <carsten.haitzler@arm.com> Tested-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220722122139.288486-1-liviu.dudau@arm.com
-
Carsten Haitzler authored
If something has already set up the DPU before the komeda driver comes up, it will fail to init because it was just writing to the SRST bit in the GCU control register and ignoring others. This resulted in TBU bringup stalling and init failing. By writing completely we also set the mode back to 0 (inactive) too and thus TBU bringup works. Signed-off-by:
-
Carsten Haitzler authored
The komeda driver doesn't come up with a visible text (FB) mode VT by default as it was missing legacy FB support. It's useful to have a working text VT on a system for debug and general usability, so enable it. You can always toggle CONFIG_FRAMEBUFFER_CONSOLE. Signed-off-by:
-
Robin Murphy authored
Since we no longer need to conform to the structure of the various DRM IRQ callbacks, we can streamline the code by consolidating the piecemeal functions and passing around our private data structure directly. We're also a platform device so should never see IRQ_NOTCONNECTED either. Furthermore we can also get rid of all the unnecesary read-modify-write operations, since on install we know we cleared the whole interrupt mask before enabling the debug IRQs, and thus on uninstall we're always clearing everything as well. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
-
Robin Murphy authored
The Arm Juno board EDK2 port has provided an EFI GOP display via HDLCD0 for some time now, which works nicely as an early framebuffer. However, once the HDLCD driver probes and takes over the hardware, it should take over the logical framebuffer as well, otherwise the now-defunct GOP device hangs about and virtual console output inevitably disappears into the wrong place most of the time. We'll do this after binding the HDMI encoder, since that's the most likely thing to fail, and the EFI console is still better than nothing when that happens. However, the two HDLCD controllers on Juno are independent, and many users will still be using older firmware without any display support, so we'll only bother if we find that the HDLCD we're probing is already enabled. And if it is, then we'll also stop it, since otherwise the display can end up shifted if it's still scanning out while the rest of the registers are subsequently reconfigured. Signed-off-by:
-
pengfuyuan authored
Fix spelling typo in comments. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
pengfuyuan <pengfuyuan@kylinos.cn> Acked-by:
-
Thomas Zimmermann authored
Reverse the order of the final two arguments when calling aperture_remove_conflicting_devices(). An error report is available at [1]. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
- 21 Jul, 2022 3 commits
-
-
Chen-Yu Tsai authored
The datasheet says that VDD12 must be enabled and at full voltage before VDD33 is enabled. Reorder the bulk regulator supply names so that VDD12 is enabled before VDD33. Any enable ramp delays should be handled by setting proper constraints on the regulators. Fixes: bc1aee7f ("drm/bridge: Add I2C based driver for ps8640 bridge") Signed-off-by:
Chen-Yu Tsai <wenst@chromium.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220721092258.3397461-1-wenst@chromium.org
-
Liu Zixian authored
On failure, these functions return error pointer, not NULL. Signed-off-by:
Liu Zixian <liuzixian4@huawei.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220718015357.1722-1-liuzixian4@huawei.com
-
Wang Jingjin authored
Fix the error of implicit declaration of function 'drmm_of_get_bridge': drivers/gpu/drm/vc4/vc4_dpi.c:278:11: error: implicit declaration of function ‘drmm_of_get_bridge’; did you mean ‘devm_drm_of_get_bridge’? [-Werror=implicit-function-declaration] bridge = drmm_of_get_bridge(drm, dev->of_node, 0, 0); Fixes: 055af023 ("drm/vc4: dpi: Switch to drmm_of_get_bridge") Signed-off-by:
Wang Jingjin <wangjingjin1@huawei.com> Signed-off-by:
-
- 20 Jul, 2022 2 commits
-
-
Nícolas F. R. A. Prado authored
Add panel identification entry for the AUO B120XAN01.0 (product ID: 0x1062) panel. Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by:
-
Nícolas F. R. A. Prado authored
Add panel identification entry for the IVO R140NWF5 RH (product ID: 0x057d) panel. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
-
- 19 Jul, 2022 26 commits
-
-
Dmitry Baryshkov authored
Now as the driver does not depend on pdata->connector, add support for attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by:
Steev Klimaszewski <steev@kali.org> Reviewed-by:
-
Dmitry Baryshkov authored
Rather than reading the pdata->connector directly, fetch the connector using drm_atomic_state. This allows us to make pdata->connector optional (and thus supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR). Reviewed-by:
-
Christian König authored
We already discussed that the call to drm_sched_entity_select_rq() needs to move to drm_sched_job_arm() to be able to set a new scheduler list between _init() and _arm(). This was just not applied for some reason. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220714103902.7084-2-christian.koenig@amd.com
-
Geert Uytterhoeven authored
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence when converting from one format to another, multi-byte pixel values loaded from memory must be converted from little-endian to host-endian. Conversely, multi-byte pixel values written to memory must be converted from host-endian to little-endian. Currently only drm_fb_xrgb8888_to_rgb332_line() includes endianness handling. Fix gud_xrgb8888_to_color() on big-endian platforms by adding the missing endianness handling. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/b47589ed5d8ca44e0956684412e3f16f3227f887.1657300532.git.geert@linux-m68k.org
-
Geert Uytterhoeven authored
DRM formats are defined to be little-endian, unless the DRM_FORMAT_BIG_ENDIAN flag is set. Hence when converting from one format to another, multi-byte pixel values loaded from memory must be converted from little-endian to host-endian. Conversely, multi-byte pixel values written to memory must be converted from host-endian to little-endian. Currently only drm_fb_xrgb8888_to_rgb332_line() includes endianness handling. Fix this by adding endianness handling to all conversion functions that process multi-byte pixel values. Note that the conversion to RGB565 is special, as there are two versions: with and without byteswapping of the RGB565 pixel data. Signed-off-by:
-
Liang He authored
In tc_probe_bridge_endpoint(), we should call of_node_put() when breaking out of the for_each_endpoint_of_node() which will automatically increase and decrease the refcount. Fixes: 71f7d9c0 ("drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT") Signed-off-by:
Liang He <windhl@126.com> Reviewed-by:
-
Liang He authored
In anx7625_parse_dt(), 'pdata->mipi_host_node' will be assigned a new reference with of_graph_get_remote_node() which will increase the refcount of the object, correspondingly, we should call of_node_put() for the old reference stored in the 'pdata->mipi_host_node'. Fixes: 8bdfc5da ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Signed-off-by:
-
Christophe JAILLET authored
The remove() function calls bochs_hw_fini() but this function is not called in the error handling of the probe. This call releases the resources allocated by bochs_hw_init() used in bochs_load(). Update the probe and bochs_load() to call bochs_hw_fini() if an error occurs after a successful bochs_hw_init() call. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: http://patchwork.freedesktop.org/patch/msgid/0e676e4d56ab5b10fcf22860081414445611dfa7.1655565953.git.christophe.jaillet@wanadoo.frSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Danilo Krummrich authored
Allocate driver structures with drm managed resource allocators in order to cleanup/simplify the drm driver .release callback. Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220714130028.2127858-3-dakr@redhat.comSigned-off-by:
-
Danilo Krummrich authored
Use drm managed resource allocation (drmm_universal_plane_alloc()) in order to cleanup/simplify drm plane .destroy callback. Signed-off-by:
-
Dmitry Osipenko authored
Don't return -1 in error cases, return proper error code. The returned error codes propagate to error messages and to userspace and it's always good to have a meaningful error number for debugging purposes. Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-10-dmitry.osipenko@collabora.comSigned-off-by:
-
Dmitry Osipenko authored
Use common dev_is_pci() helper to replace the strcmp("pci") used by driver. Suggested-by: -
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 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 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:
-
