kernel/linux.git/drivers/gpu/drm/mxsfb, branch v6.13.6

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43+00:00

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

drm/mxsfb: Run DRM default client setup

2024-09-26T06:28:08+00:00

Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. The mxsfb driver specifies a preferred color mode of 32. As this is the default if no format has been given, leave it out entirely. v5: - select DRM_CLIENT_SELECTION v3: - fix driver name "msxfb" to "mxsfb" Signed-off-by: Thomas Zimmermann Cc: Marek Vasut Cc: Stefan Agner Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Acked-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-31-tzimmermann@suse.de

drm/mxsfb/lcdif: Run DRM default client setup

2024-09-26T06:28:08+00:00

Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. The lcdif driver specifies a preferred color mode of 32. As this is the default if no format has been given, leave it out entirely. v5: - select DRM_CLIENT_SELECTION Signed-off-by: Thomas Zimmermann Cc: Marek Vasut Cc: Stefan Agner Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Acked-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-30-tzimmermann@suse.de

drm: lcdif: Use adjusted_mode .clock instead of .crtc_clock

2024-07-16T18:15:31+00:00

In case an upstream bridge modified the required clock frequency in its .atomic_check callback by setting adjusted_mode.clock , make sure that clock frequency is generated by the LCDIFv3 block. This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767 with (e)DP output, where the TC358767 expects precise timing on its input side, the precise timing must be generated by the LCDIF. Signed-off-by: Marek Vasut Reviewed-by: Alexander Stein Link: https://patchwork.freedesktop.org/patch/msgid/20240531202813.277109-1-marex@denx.de

drm/lcdif: Do not disable clocks on already suspended hardware

2024-03-20T03:32:55+00:00

In case the LCDIF is enabled in DT but unused, the clocks used by the LCDIF are not enabled. Those clocks may even have a use count of 0 in case there are no other users of those clocks. This can happen e.g. in case the LCDIF drives HDMI bridge which has no panel plugged into the HDMI connector. Do not attempt to disable clocks in the suspend callback and re-enable clocks in the resume callback unless the LCDIF is enabled and was in use before the system entered suspend, otherwise the driver might end up trying to disable clocks which are already disabled with use count 0, and would trigger a warning from clock core about this condition. Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions internally perform the clocks disable and enable operations and act as runtime PM hooks too. Reviewed-by: Liu Ying Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20240226082644.32603-1-marex@denx.de

drm: lcdif: Switch to drmm_mode_config_init

2024-02-26T07:33:45+00:00

Switch from deprecated unmanaged drm_mode_config_init() to managed drmm_mode_config_init(). No functional change. Signed-off-by: Marek Vasut Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20231127212638.77688-1-marex@denx.de

drm/mxsfb: Switch to drmm_mode_config_init

2024-02-26T07:33:25+00:00

drm: Use device_get_match_data()

2023-11-27T19:56:32+00:00

Use preferred device_get_match_data() instead of of_match_device() to get the driver match data in a single step. With this, adjust the includes to explicitly include the correct headers. That also serves as preparation to remove implicit includes within the DT headers (of_device.h in particular). Reviewed-by: Tomi Valkeinen Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20231020125214.2930329-1-robh@kernel.org Signed-off-by: Rob Herring

drm: Explicitly include correct DT includes

2023-07-21T07:12:43+00:00

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Acked-by: Sam Ravnborg Reviewed-by: Steven Price Acked-by: Liviu Dudau Reviewed-by: Kieran Bingham Acked-by: Robert Foss Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20230714174545.4056287-1-robh@kernel.org

drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()

2023-06-25T12:51:35+00:00

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: cb285a5348e7 ("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 Reviewed-by: Marek Vasut Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20230612092359.784115-1-victor.liu@nxp.com