- 27 Jun, 2023 5 commits
-
-
Thomas Zimmermann authored
Rename struct bd6107_platform_data.fbdev to 'dev', as it stores a pointer to the Linux platform device; not the fbdev device. Makes the code easier to understand. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Cc: Lee Jones <lee@kernel.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Struct bd6107_platform_data refers to a platform device within the Linux device hierarchy. The test in bd6107_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Fixes: 67b43e59 ("backlight: Add ROHM BD6107 backlight driver") Signed-off-by:
-
Adrián Larumbe authored
The hdmi_datamap enum is no longer in use. Also reindent enable_audio's call params. Signed-off-by:
Adrián Larumbe <adrian.larumbe@collabora.com> Acked-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Adrián Larumbe authored
The current output bus format selection logic is enforcing YUV420 even when the drm mode allows for other bus formats as well. Fix it by adding check for 420-only drm modes. Signed-off-by:
-
Adrián Larumbe authored
Right now clocking value selection code is prioritising RGB, YUV444 modes over YUV420 for HDMI2 sinks. However, because of the bus format selection procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always be picked during the drm bridge chain check stage. Later on dw_hdmi_setup will configure a colour space based on the bus format that doesn't match the pixel value we had calculated as described above. Fix it by bringing back dw-hdmi bus format check when picking the right pixel clock. Signed-off-by:
-
- 26 Jun, 2023 3 commits
-
-
Thomas Zimmermann authored
Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). Both are only used internally within the PRIME code. v2: * reword docs as functions are now unexported (Simon) Signed-off-by:
Simon Ser <contact@emersion.fr> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230620080252.16368-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Clear all assignments of struct drm_driver's fd/handle callbacks to drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These functions are called by default. Add a TODO item to convert vmwgfx to the defaults as well. v2: * remove TODO item (Zack) * also update amdgpu's amdgpu_partition_driver Signed-off-by:
-
Thomas Zimmermann authored
Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by default if no PRIME import/export helpers have been set. Both functions are the default for almost all drivers. DRM drivers implement struct drm_driver.gem_prime_import_sg_table to import dma-buf objects from other drivers. Having the function drm_gem_prime_fd_to_handle() functions set by default allows each driver to import dma-buf objects to itself, even without support for other drivers. For drm_gem_prime_handle_to_fd() it is similar: using it by default allows each driver to export to itself, even without support for other drivers. This functionality enables userspace to share per-driver buffers across process boundaries via PRIME (e.g., wlroots requires this functionality). The patch generalizes a pattern that has previously been implemented by GEM VRAM helpers [1] to work with any driver. For example, gma500 can now run the wlroots-based sway compositor. v2: * clean up docs and TODO comments (Simon, Zack) * clean up style in drm_getcap() Signed-off-by:
-
- 25 Jun, 2023 1 commit
-
-
Liu Ying authored
When disabling overlay plane in mxsfb_plane_overlay_atomic_update(), overlay plane's framebuffer pointer is NULL. So, dereferencing it would cause a kernel Oops(NULL pointer dereferencing). Fix the issue by disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead. Fixes: cb285a53 ("drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr()") Cc: stable@vger.kernel.org # 5.19+ Signed-off-by:
Liu Ying <victor.liu@nxp.com> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
- 24 Jun, 2023 3 commits
-
-
Maíra Canal authored
All convertions from the ARGB16161616 format follow the same structure. Instead of repeting the same structure for each supported format, create a function to encapsulate the common logic and isolate the pixel conversion functions in a callback function. Suggested-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230515135204.115393-4-mcanal@igalia.com
-
Maíra Canal authored
The VKMS already has a function to convert ARGB16161616 to ARGB8888, so it is possible to use this function to provide the writeback support for the ARGB8888 format. Therefore, add the ARGB8888 format to the writeback format list. Signed-off-by:
-
Maíra Canal authored
The spinlock composer_lock protects the variables crc_pending, wb_pending, frame_start and frame_end, which are variables that are used by the composer worker. There is no need to protect the wb_frame_info information with a spinlock. Therefore, reduce the critical section of the lock by removing the assignments to the wb_frame_info from the critical section. Signed-off-by:
-
- 23 Jun, 2023 13 commits
-
-
Douglas Anderson authored
In order to read the EDID from an eDP panel, you not only need to power on the bridge chip itself but also the panel. In the ps8640 driver, this was made to work by having the bridge chip manually power the panel on by calling pre_enable() on everything connectorward on the bridge chain. This worked OK, but... ...when trying to do the same thing on ti-sn65dsi86, feedback was that this wasn't a great idea. As a result, we designed the "DP AUX" bus. With the design we ended up with the panel driver itself was in charge of reading the EDID. The panel driver could power itself on and the bridge chip was able to power itself on because it implemented the DP AUX bus. Despite the fact that we came up with a new scheme, implemented in on ti-sn65dsi86, and even implemented it on parade-ps8640, we still kept the old code around. This was because the new scheme required a DT change. Previously the panel was a simple "platform_device" and in DT at the top level. With the new design the panel needs to be listed in DT under the DP controller node. The old code allowed us to properly fetch EDIDs with ps8640 with the old DTs. Unfortunately, the old code stopped working as of commit 102e80d1 ("drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs"). There are cases at bootup where connector->state->state is NULL and the kernel crashed at: * drm_atomic_bridge_chain_pre_enable * drm_atomic_get_old_bridge_state * drm_atomic_get_old_private_obj_state The crash went away at commit 4fb912e5 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") which added a NULL check. However, even though we were no longer crashing the end result was that we weren't actually powering the panel on when we thought we were. Things could end up working (despite warning splats) if userspace was persistent and tried to get the mode again, but it wasn't great. A bit of digging was done to see if there was an easy fix but there was nothing obvious. Instead, the only device using ps8640 the "old" way had its DT updated so that the panel was no longer a simple "platform_deice". See commit c2d94f72 ("arm64: dts: mediatek: mt8173-elm: Move display to ps8640 auxiliary bus") and commit 113b5cc06f44 ("arm64: dts: mediatek: mt8173-elm: remove panel model number in DT"). Let's delete the old broken code so nobody gets tempted to copy it or figure out how it works (since it doesn't). NOTE: from a device tree "purist" point of view, we're supposed to keep old device trees working and this patch is technically "against policy". Reasons I'm still proposing it anyway: 1. Officially, old mt8173-elm device trees worked via the "little white lie" approach. The DT would list an arbitrary/representative panel that would be used for power sequencing. The mode information in the panel driver would then be ignored / overridden by the EDID reading code in ps8640. I don't feel too terrible breaking DTs that contained the wrong "compatible" string to begin with. NOTE that any old device trees that _didn't_ lie about their compatible will still work because the mode information will come from the hardcoded panels in panel-edp. 2. The only users of the old code were Chromebooks and Chromebooks don't bake their DTs into the BIOS (they are bundled with the kernel). Thus we don't need to worry about breaking someone using an old DT with a new kernel. 3. The old code was broken anyway. If someone wants to fix the old code instead of deleting it then they have my blessing, but without a proper fix the old code isn't useful. Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230616165517.v2.1.I7b8f60b3fbfda068f9bf452d584dc934494bfbfa@changeid
-
Simon Ser authored
User-space may query an existing object not included in a lease. Make it easier to debug such situations by logging a debug message. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230623143514.38707-1-contact@emersion.fr
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
Signed-off-by:
-
Simon Ser authored
This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
-
Simon Ser authored
Rename drm_sysfs_connector_status_event() to drm_sysfs_connector_property_event(). Indeed, "status" is a bit vague: it can easily be confused with the connected/disconnected status of the connector. This function has nothing to do with connected/disconnected: it merely sends a notification that a connector's property has changed (e.g. HDCP, privacy screen, etc). Signed-off-by:
-
Simon Ser authored
Only the stuff inside the brackets should be indented. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428100115.9802-1-contact@emersion.fr
-
Tom Rix authored
smatch reports drivers/gpu/drm/mgag200/mgag200_drv.c:23:5: warning: symbol 'mgag200_modeset' was not declared. Should it be static? This variable is only used in its defining file, so it should be static Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
-
- 22 Jun, 2023 8 commits
-
-
Ondrej Jirman authored
Before this patch, booting to Linux VT and doing a simple: echo 2 > /sys/class/graphics/fb0/blank echo 0 > /sys/class/graphics/fb0/blank would result in failures to re-enable the panel. Mode set callback is called only once during boot in this scenario, while calls to enable/disable callbacks are balanced afterwards. The driver doesn't work unless userspace calls modeset before enabling the CRTC/connector. This patch moves enabling of the DSI host from mode_set into pre_enable callback, and removes some old hacks where this bridge driver is directly calling into other bridge driver's callbacks. pre_enable_prev_first flag is set on the panel's bridge so that panel drivers will get their prepare function called between DSI host's pre_enable and enable callbacks, so that they get a chance to perform panel setup while DSI host is already enabled in command mode. Otherwise panel's prepare would be called before DSI host is enabled, and any DSI communication used in prepare callback would fail. With all these changes, the enable/disable sequence is now well balanced, and host's and panel's callbacks are called in proper order documented in the drm_panel API documentation without needing the old hacks. (Mainly that panel->prepare is called when DSI host is ready to allow the panel driver to send DSI commands and vice versa during disable.) Tested on Pinephone Pro. Trace of the callbacks follows. Before: [ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable [ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare [ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable [ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 echo 2 > /sys/class/graphics/fb0/blank [ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable [ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110 [ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare [ 431.169357] pclk_mipi_dsi0 already disabled echo 0 > /sys/class/graphics/fb0/blank [ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare [ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable [ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 ----------------------------------------------------------------------- After: [ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable [ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare [ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable (But depends on functionality intorduced in Linux 6.3, so this patch will not build on older kernels when applied to older stable branches.) Fixes: 46fc5154 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge") Signed-off-by:Ondrej Jirman <megi@xff.cz> Reviewed-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Andi Shyti <andi.shyti@kernel.org> Signed-off-by:
-
Marek Vasut authored
Add support for handling the HS/VS sync signals polarity in the bridge driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity sync signals and the image is shifted to the left, up, and wobbly. Signed-off-by:
-
Marek Vasut authored
The register content and behavior is very similar to TC358764 VP_CTRL. All the bits except for unknown bit 6 also seem to match, even though the datasheet is just not available. Add a comment and reuse the bit definitions. Signed-off-by:
-
Marek Vasut authored
This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by:
-
Marek Vasut authored
Switch the bridge driver over to atomic ops. No functional change. Signed-off-by:
-
Marek Vasut authored
Move the register programming part, which actually enables the bridge and makes it push data out of its DPI side, into the enable callback. The DSI host like DSIM may not be able to transmit commands in pre_enable, moving the register programming into enable assures it can transmit commands. Signed-off-by:
-
Marek Vasut authored
None of these four bits are bitfields, use BIT() macro and treat them as bits. No functional change. Signed-off-by:
-
- 21 Jun, 2023 7 commits
-
-
Dmitry Osipenko authored
Replace all drm-shmem locks with a GEM reservation lock. This makes locks consistent with dma-buf locking convention where importers are responsible for holding reservation lock for all operations performed over dma-bufs, preventing deadlock between dma-buf importers and exporters. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-7-dmitry.osipenko@collabora.com
-
Dmitry Osipenko authored
Change locking policy of mmap() callback, making exporters responsible for handling dma-buf reservation locking. Previous locking policy stated that dma-buf is locked for both importers and exporters by the dma-buf core, which caused a deadlock problem for DRM drivers in a case of self-imported dma-bufs which required to take the lock from the DRM exporter side. Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares DRM drivers for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares udmabuf for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem solved by moving the lock down to exporters. This patch prepares dma-buf heaps for the locking policy update. Reviewed-by:
-
Dmitry Osipenko authored
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares videobuf2 for the locking policy update. Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Jocelyn Falempe authored
I've contributed to these two drivers, fixing bugs and performance issues. Signed-off-by:
-
