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

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

drm/ssd130x: Fix pitch calculation in ssd130x_fb_blit_rect()

2023-07-21T22:33:49+00:00

The page height must be taken into account only for vertical coordinates and heights, not for horizontal coordinates and widths. Fixes: 179a790aaf2a ("drm/ssd130x: Set the page height value in the device info data") Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/54deec2ec533e90544faa8c60a0c2518c58f3e9c.1689252746.git.geert@linux-m68k.org

drm/ssd130x: Change pixel format used to compute the buffer size

2023-07-13T12:01:49+00:00

The commit e254b584dbc0 ("drm/ssd130x: Remove hardcoded bits-per-pixel in ssd130x_buf_alloc()") used a pixel format info rather than a hardcoded bpp to calculate the size of the buffer allocated to store the native pixels. But it wrongly used the DRM_FORMAT_C1 fourcc pixel format. That is for color-indexed frame buffer formats, while the ssd103x controllers don't support different single-channel colors nor a Color Lookup Table (CLUT). So the correct pixel format to use in this case is DRM_FORMAT_R1 instead. Since both formats use a eight pixels/byte, there is no functional change in practice by this patch. Still, the correct pixel format should be used. Suggested-by: Geert Uytterhoeven Signed-off-by: Javier Martinez Canillas Reviewed-by: Geert Uytterhoeven Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230713085859.907127-1-javierm@redhat.com

drm/ssd130x: Remove hardcoded bits-per-pixel in ssd130x_buf_alloc()

2023-06-15T21:50:46+00:00

The driver only supports OLED controllers that have a native DRM_FORMAT_C1 pixel format and that is why it has harcoded a division of the width by 8. But the driver might be extended to support devices that have a different pixel format. So it's better to use the struct drm_format_info helpers to compute the size of the buffer, used to store the pixels in native format. Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-6-javierm@redhat.com

drm/ssd130x: Don't allocate buffers on each plane update

2023-06-15T21:50:45+00:00

The resolutions for these panels are fixed and defined in the Device Tree, so there's no point to allocate the buffers on each plane update and that can just be done once. Let's do the allocation and free on the encoder enable and disable helpers since that's where others initialization and teardown operations are done. Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-5-javierm@redhat.com