kernel/linux.git/drivers/gpu/drm/solomon, branch v6.6.132

drm/solomon: Fix page start when updating rectangle in page addressing mode

2026-03-25T10:05:39+00:00

[ Upstream commit 36d9579fed6c9429aa172f77bd28c58696ce8e2b ] In page addressing mode, the pixel values of a dirty rectangle must be sent to the display controller one page at a time. The range of pages corresponding to a given rectangle is being incorrectly calculated as if the Y value of the top left coordinate of the rectangle was 0. This can result in rectangle updates being displayed on wrong parts of the screen. Fix the above issue by consolidating the start page calculation in a single place at the beginning of the update_rect function, and using the calculated value for all addressing modes. Fixes: b0daaa5cfaa5 ("drm/ssd130x: Support page addressing mode") Signed-off-by: Francesco Lavra Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260210180932.736502-1-flavra@baylibre.com Signed-off-by: Javier Martinez Canillas Signed-off-by: Sasha Levin

drm/ssd130x: Replace .page_height field in device info with a constant

2026-03-25T10:05:39+00:00

[ Upstream commit ec5dceb8180f0cb110dc7029d55d6a83d0583015 ] This deemed useful to avoid hardcoding a page height and allow to support other Solomon controller families, but dividing the screen in pages seems to be something that is specific to the SSD130x chip family. For example, SSD132x chip family divides the screen in segments (columns) and common outputs (rows), so the concept of screen pages does not exist for the SSD132x family. Let's drop this field from the device info struct and just use a constant SSD130X_PAGE_HEIGHT macro to define the page height. While being there, replace hardcoded 8 values in places where it is used as the page height. Signed-off-by: Javier Martinez Canillas Reviewed-by: Geert Uytterhoeven Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-2-javierm@redhat.com Stable-dep-of: 36d9579fed6c ("drm/solomon: Fix page start when updating rectangle in page addressing mode") Signed-off-by: Sasha Levin

drm/ssd130x: Store the HW buffer in the driver-private CRTC state

2026-03-25T10:05:38+00:00

[ Upstream commit d51f9fbd98b6d88aef4f6431bbb575378a6c7a24 ] The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") moved the allocation of the intermediate and HW buffers from the encoder's .atomic_enable callback, to the plane's .atomic_check callback. This was suggested by Maxime Ripard, because drivers aren't allowed to fail after the drm_atomic_helper_swap_state() function has been called. And the encoder's .atomic_enable happens after the new atomic state has been swapped, so allocations (that can fail) shouldn't be done there. But the HW buffer isn't really tied to the plane's state. It has a fixed size that only depends on the (also fixed) display resolution defined in the Device Tree Blob. That buffer can be considered part of the CRTC state, and for this reason makes more sense to do its allocation in the CRTC .atomic_check callback. The other allocated buffer (used to store a conversion from the emulated XR24 format to the native R1 format) is part of the plane's state, since it will be optional once the driver supports R1 and allows user-space to set that pixel format. So let's keep the allocation for it in the plane's .atomic_check callback, this can't be moved to the CRTC's .atomic_check because changing a format does not trigger a CRTC mode set. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icNxumZcZOPwT9Q_QiogNQ@mail.gmail.com/ Signed-off-by: Javier Martinez Canillas Acked-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20230913052938.1114651-1-javierm@redhat.com Stable-dep-of: 36d9579fed6c ("drm/solomon: Fix page start when updating rectangle in page addressing mode") Signed-off-by: Sasha Levin

drm/ssd130x: Use bool for ssd130x_deviceinfo flags

2026-03-25T10:05:38+00:00

[ Upstream commit 15d30b46573d75f5cb58cfacded8ebab9c76a2b0 ] The .need_pwm and .need_chargepump fields in struct ssd130x_deviceinfo are flags that can have only two possible values: 0 and 1. Reduce kernel size by changing their types from int to bool. Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/285005ff361969eff001386c5f97990f0e703838.1692888745.git.geert@linux-m68k.org Stable-dep-of: 36d9579fed6c ("drm/solomon: Fix page start when updating rectangle in page addressing mode") Signed-off-by: Sasha Levin

pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()

2024-06-12T09:12:24+00:00

[ Upstream commit c748a6d77c06a78651030e17da6beb278a1c9470 ] In order to introduce a pwm api which can be used from atomic context, we will need two functions for applying pwm changes: int pwm_apply_might_sleep(struct pwm *, struct pwm_state *); int pwm_apply_atomic(struct pwm *, struct pwm_state *); This commit just deals with renaming pwm_apply_state(), a following commit will introduce the pwm_apply_atomic() function. Acked-by: Uwe Kleine-König Acked-by: Guenter Roeck Acked-by: Mark Brown Acked-by: Dmitry Torokhov # for input Acked-by: Hans de Goede Acked-by: Jani Nikula Acked-by: Lee Jones Signed-off-by: Sean Young Signed-off-by: Thierry Reding Stable-dep-of: 974afccd3794 ("leds: pwm: Disable PWM when going to suspend") Signed-off-by: Sasha Levin

drm/ssd130x: Fix screen clearing

2023-11-20T10:59:09+00:00

[ Upstream commit 4dbce3d6fea59e1df1d1a35aacea0c186f72107a ] Due to the reuse of buffers, ssd130x_clear_screen() no longers clears the screen, but merely redraws the last image that is residing in the intermediate buffer. As there is no point in clearing the intermediate buffer and transposing an all-black image, fix this by just clearing the HW format buffer, and writing it to the panel. Fixes: 49d7d581ceaf4cf8 ("drm/ssd130x: Don't allocate buffers on each plane update") Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/c19cd5a57205597bb38a446c3871092993498f01.1692888745.git.geert@linux-m68k.org Signed-off-by: Sasha Levin

drm/ssd130x: clean up some inconsistent indenting

2023-07-31T08:07:31+00:00

No functional modification involved. drivers/gpu/drm/solomon/ssd130x.c:715 ssd130x_primary_plane_duplicate_state() warn: inconsistent indenting. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6034 Signed-off-by: Jiapeng Chong Reviewed-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230731074927.22755-1-jiapeng.chong@linux.alibaba.com

drm/ssd130x: Use shadow-buffer helpers when managing plane's state

2023-07-27T15:44:41+00:00

The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") moved the buffers allocation to be done in the primary plane's .atomic_check() callback. But it missed that since the driver uses a shadow-buffered plane, the __drm_gem_{reset,duplicate,destroy}_shadow_plane() helper functions must be used in the struct drm_plane_funcs handlers. This was missed because the mentioned commit did not remove the macro DRM_GEM_SHADOW_PLANE_FUNCS, which leads to the custom plane's atomic state management handlers to not be used. Fixes: 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/dri-devel/20230727122412.2464210-1-arnd@kernel.org Suggested-by: Thomas Zimmermann Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230727140453.577445-1-javierm@redhat.com

drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback

2023-07-26T14:33:19+00:00

Drivers are not allowed to fail after drm_atomic_helper_swap_state() has been called and the new atomic state is stored into the current sw state. Since the struct ssd130x_device .data_array is allocated in the encoder's .atomic_enable callback, the operation can fail and this is after the new state has been stored. So it can break an atomic mode settings assumption. Fix this by having custom helpers to allocate, duplicate and destroy the plane state, that will take care of allocating and freeing these buffers. Suggested-by: Maxime Ripard Signed-off-by: Javier Martinez Canillas Acked-by: Maxime Ripard Tested-by: Geert Uytterhoeven Link: https://patchwork.freedesktop.org/patch/msgid/20230726105433.389740-2-javierm@redhat.com

drm/ssd130x: Inline the ssd130x_buf_{alloc, free}() function helpers

2023-07-26T14:33:18+00:00

There is only a single caller for both helper functions and these don't do much other than allocate and free two buffers, so let's just inline them. Suggested-by: Geert Uytterhoeven Signed-off-by: Javier Martinez Canillas Reviewed-by: Geert Uytterhoeven Link: https://patchwork.freedesktop.org/patch/msgid/20230726105433.389740-1-javierm@redhat.com