summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/solomon
AgeCommit message (Collapse)Author
2025-10-31drm: include drm_print.h where neededJani Nikula
There are a gazillion files that depend on drm_print.h being indirectly included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In preparation for removing those includes, explicitly include drm_print.h where needed. Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com
2025-09-26drm/solomon: Enforce one assignment per lineIker Pedrosa
The code contains several instances of chained assignments. The Linux kernel coding style generally favors clarity and simplicity over terse syntax. Refactor the code to use a separate line for each assignment. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://lore.kernel.org/r/20250920-improve-ssd130x-v2-5-77721e87ae08@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-26drm/solomon: Simplify get_modes() using DRM helperIker Pedrosa
The ssd130x_connector_get_modes function contains a manual implementation to manage modes. This pattern is common for simple displays, and the DRM core already provides the drm_connector_helper_get_modes_fixed() helper for this exact use case. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://lore.kernel.org/r/20250920-improve-ssd130x-v2-4-77721e87ae08@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-26drm/solomon: Simplify mode_valid() using DRM helperIker Pedrosa
The ssd130x_crtc_mode_valid() function contains a manual implementation to validate the display mode against the panel's single fixed resolution. This pattern is common for simple displays, and the DRM core already provides the drm_crtc_helper_mode_valid_fixed() helper for this exact use case. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://lore.kernel.org/r/20250920-improve-ssd130x-v2-3-77721e87ae08@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-26drm/solomon: Use drm_WARN_ON_ONCE instead of WARN_ONIker Pedrosa
To prevent log spam, convert all instances to the DRM-specific drm_WARN_ON_ONCE() macro. This ensures that a warning is emitted only the first time the condition is met for a given device instance, which is the desired behavior within the graphics subsystem. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://lore.kernel.org/r/20250920-improve-ssd130x-v2-2-77721e87ae08@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-26drm/solomon: Move calls to drm_gem_fb_end_cpu*()Iker Pedrosa
Calls to drm_gem_fb_end_cpu*() should be between the calls to drm_dev*(), and not hidden inside some other function. This way the critical section code is visible at a glance, keeping it short and improving maintainability. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com> Link: https://lore.kernel.org/r/20250920-improve-ssd130x-v2-1-77721e87ae08@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-17drm/ssd130x: Use kmalloc_array() instead of kmalloc()James Flowers
Documentation/process/deprecated.rst recommends against the use of kmalloc with dynamic size calculations due to the risk of overflow and smaller allocation being made than the caller was expecting. kmalloc_array avoids this issue. Signed-off-by: James Flowers <bold.zone2373@fastmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250914073841.69582-1-bold.zone2373@fastmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01drm/ssd130x: Remove the use of dev_err_probe()Liao Yuanhong
Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value[1]. The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. [1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/ Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250820131416.500048-1-liaoyuanhong@vivo.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-12drm/ssd130x: fix ssd132x_clear_screen() columnsJohn Keeping
The number of columns relates to the width, not the height. Use the correct variable. Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Link: https://lore.kernel.org/r/20250611111307.1814876-1-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-01-16drm/ssd130x: ensure ssd132x pitch is correctJohn Keeping
The bounding rectangle is adjusted to ensure it aligns to SSD132X_SEGMENT_WIDTH, which may adjust the pitch. Calculate the pitch after aligning the left and right edge. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-3-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-01-16drm/ssd130x: fix ssd132x encodingJohn Keeping
The ssd132x buffer is encoded one pixel per nibble, with two pixels in each byte. When encoding an 8-bit greyscale input, take the top 4-bits as the value and ensure the two pixels are distinct and do not overwrite each other. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115110139.1672488-2-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-01-08drm/ssd130x: Set SPI .id_table to prevent an SPI core warningJavier Martinez Canillas
The only reason for the ssd130x-spi driver to have an spi_device_id table is that the SPI core always reports an "spi:" MODALIAS, even when the SPI device has been registered via a Device Tree Blob. Without spi_device_id table information in the module's metadata, module autoloading would not work because there won't be an alias that matches the MODALIAS reported by the SPI core. This spi_device_id table is not needed for device matching though, since the of_device_id table is always used in this case. For this reason, the struct spi_driver .id_table member is currently not set in the SPI driver. Because the spi_device_id table is always required for module autoloading, the SPI core checks during driver registration that both an of_device_id table and a spi_device_id table are present and that they contain the same entries for all the SPI devices. Not setting the .id_table member in the driver then confuses the core and leads to the following warning when the ssd130x-spi driver is registered: [ 41.091198] SPI driver ssd130x-spi has no spi_device_id for sinowealth,sh1106 [ 41.098614] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1305 [ 41.105862] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1306 [ 41.113062] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1307 [ 41.120247] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1309 [ 41.127449] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1322 [ 41.134627] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1325 [ 41.141784] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1327 [ 41.149021] SPI driver ssd130x-spi has no spi_device_id for solomon,ssd1331 To prevent the warning, set the .id_table even though it's not necessary. Since the check is done even for built-in drivers, drop the condition to only define the ID table when the driver is built as a module. Finally, rename the variable to use the "_spi_id" convention used for ID tables. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241231114516.2063201-1-javierm@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2024-12-09Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst
The v6.13-rc2 release included a bunch of breaking changes, specifically the MODULE_IMPORT_NS commit. Backmerge in order to fix them before the next pull-request. Include the fix from Stephen Roswell. Caused by commit 25c3fd1183c0 ("drm/virtio: Add a helper to map and note the dma addrs and lengths") Interacting with commit cdd30ebb1b9f ("module: Convert symbol namespace to string literal") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://patchwork.freedesktop.org/patch/msgid/20241209121717.2abe8026@canb.auug.org.au Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2024-12-05drm: remove driver date from struct drm_driver and all driversJani Nikula
We stopped using the driver initialized date in commit 7fb8af6798e8 ("drm: deprecate driver date") and (eventually) started returning "0" for drm_version ioctl instead. Finish the job, and remove the unused date member from struct drm_driver, its initialization from drivers, along with the common DRIVER_DATE macros. v2: Also update drivers/accel (kernel test robot) Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Simon Ser <contact@emersion.fr> Acked-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # msm Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-02module: Convert symbol namespace to string literalPeter Zijlstra
Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-15drm/client: Move public client header to clients/ subdirectoryThomas Zimmermann
Move the public header file drm_client_setup.h to the clients/ subdirectory and update all drivers. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108154600.126162-3-tzimmermann@suse.de
2024-09-26drm/solomon: Run DRM default client setupThomas Zimmermann
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 solomon 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 <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924071734.98201-60-tzimmermann@suse.de
2024-05-02drm/solomon: Use fbdev-shmemThomas Zimmermann
Implement fbdev emulation with fbdev-shmem. Avoids the overhead of fbdev-generic's additional shadow buffering. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419083331.7761-14-tzimmermann@suse.de
2024-01-29Merge drm/drm-next into drm-misc-nextMaxime Ripard
Kickstart 6.9 development cycle. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-01-12Merge tag 'pwm/for-6.8-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This contains a bunch of cleanups and simplifications across the board, as well as a number of small fixes. Perhaps the most notable change here is the addition of an API that allows PWMs to be used in atomic contexts, which is useful when time- critical operations are involved, such as using a PWM to generate IR signals. Finally, I have decided to step down as PWM subsystem maintainer. Due to other responsibilities I have lately not been able to find the time that the subsystem deserves and Uwe, who has been helping out a lot for the past few years and has many things planned for the future, has kindly volunteered to take over. I have no doubt that he will be a suitable replacement" * tag 'pwm/for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits) MAINTAINERS: pwm: Thierry steps down, Uwe takes over pwm: linux/pwm.h: fix Excess kernel-doc description warning pwm: Add pwm_apply_state() compatibility stub pwm: cros-ec: Drop documentation for dropped struct member pwm: Drop two unused API functions pwm: lpc18xx-sct: Don't modify the cached period of other PWM outputs pwm: meson: Simplify using dev_err_probe() pwm: stmpe: Silence duplicate error messages pwm: Reduce number of pointer dereferences in pwm_device_request() pwm: crc: Use consistent variable naming for driver data pwm: omap-dmtimer: Drop locking dt-bindings: pwm: ti,pwm-omap-dmtimer: Update binding for yaml media: pwm-ir-tx: Trigger edges from hrtimer interrupt context pwm: bcm2835: Allow PWM driver to be used in atomic context pwm: Make it possible to apply PWM changes in atomic context pwm: renesas: Remove unused include pwm: Replace ENOTSUPP with EOPNOTSUPP pwm: Rename pwm_apply_state() to pwm_apply_might_sleep() pwm: Stop referencing pwm->chip pwm: Update kernel doc for struct pwm_chip ...
2024-01-01drm/ssd130x: Add support for the SSD133x OLED controller familyJavier Martinez Canillas
The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot matrix OLED panels, add a modesetting pipeline to support the chip family. The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths but only the 256-color mode (DRM_FORMAT_RGB332) is implemented for now. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231229112026.2797483-5-javierm@redhat.com
2023-12-20pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()Sean Young
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 <u.kleine-koenig@pengutronix.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2023-12-06drm/solomon: Do not include <drm/drm_plane_helper.h>Thomas Zimmermann
Remove unnecessary include statements for <drm/drm_plane_helper.h>. The file contains helpers for non-atomic code and should not be required by most drivers. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231204090852.1650-6-tzimmermann@suse.de
2023-11-14drm/ssd130x: Preallocate format-conversion buffer in atomic_checkThomas Zimmermann
Preallocate the format-conversion state's storage in the plane's atomic_check function if a format conversion is necessary. Allows the update to fail if no memory is available. Avoids the same allocation within atomic_update, which may not fail. v6: * update patch for ssd132x support Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231009141018.11291-8-tzimmermann@suse.de
2023-11-14drm/format-helper: Pass format-conversion state to helpersThomas Zimmermann
Pass an instance of struct drm_format_conv_state to DRM's format conversion helpers. Update all callers. Most drivers can use the format-conversion state from their shadow- plane state. The shadow plane's destroy function releases the allocated buffer. Drivers will later be able to allocate a buffer of appropriate size in their plane's atomic_check code. The gud driver uses a separate thread for committing updates. For now, the update worker contains its own format-conversion state. Images in the format-helper tests are small. The tests preallocate a static page for the temporary buffer. Unloading the module releases the memory. v6: * update patch for ssd132x support v5: * avoid using unusupported shadow-plane state in repaper (Noralf) * fix documentation (Noralf, kernel test robot) v3: * store buffer in shadow-plane state (Javier, Maxime) * replace ARRAY_SIZE() with sizeof() (Jani) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> # ssd130x Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231009141018.11291-4-tzimmermann@suse.de
2023-10-30drm/ssd130x: Fix possible uninitialized usage of crtc_state variableJavier Martinez Canillas
Avoid a possible uninitialized use of the crtc_state variable in function ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() error: uninitialized symbol 'crtc_state'. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/7dd6ca45-8263-44fe-a318-2fd9d761425d@moroto.mountain/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231020225338.1686974-1-javierm@redhat.com (cherry picked from commit 9e4db199e66d427c50458f4d72734cc4f0b92948) Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2023-10-27drm/ssd130x: Fix possible uninitialized usage of crtc_state variableJavier Martinez Canillas
Avoid a possible uninitialized use of the crtc_state variable in function ssd132x_primary_plane_atomic_check() and avoid the following Smatch warn: drivers/gpu/drm/solomon/ssd130x.c:921 ssd132x_primary_plane_atomic_check() error: uninitialized symbol 'crtc_state'. Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/dri-devel/7dd6ca45-8263-44fe-a318-2fd9d761425d@moroto.mountain/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231020225338.1686974-1-javierm@redhat.com
2023-10-18drm/ssd130x: Add support for the SSD132x OLED controller familyJavier Martinez Canillas
The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327) are used by 16 grayscale dot matrix OLED panels, extend the driver to also support this chip family. Instead adding an indirection level to allow the same modesetting pipeline to be used by both controller families, add another pipeline for SSD132x. This leads to some code duplication but it makes the driver easier to read and reason about. Once other controller families are added (e.g: SSD133x), some common code can be factored out in driver helpers to be shared by the different families. But that can be done later once these patterns emerge. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-5-javierm@redhat.com
2023-10-18drm/ssd130x: Rename commands that are shared across chip familiesJavier Martinez Canillas
There are some commands that are shared between the SSD130x and SSD132x controller families, define these as a common SSD13XX set of commands. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-4-javierm@redhat.com
2023-10-18drm/ssd130x: Add a controller family id to the device info dataJavier Martinez Canillas
To allow the driver to have a per Solomon display controller modesetting pipeline and support aother controller families besides SSD130x. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-3-javierm@redhat.com
2023-10-18drm/ssd130x: Replace .page_height field in device info with a constantJavier Martinez Canillas
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 <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-2-javierm@redhat.com
2023-10-13drm/ssd130x: Fix atomic_check for disabled planesThomas Zimmermann
The plane's atomic_check returns -EINVAL if the CRTC has not been set. This is the case for disabled planes, for which atomic_check should return 0. For disabled planes, it also omits the mandatory call to drm_atomic_helper_check_plane_state(). Replace the test with the boiler-plate code that first invokes drm_atomic_helper_check_plane_state() and then tests for the plane to be visible. Return early for non-visible planes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d51f9fbd98b6 ("drm/ssd130x: Store the HW buffer in the driver-private CRTC state") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231009141018.11291-7-tzimmermann@suse.de
2023-09-22drm/ssd130x: Drop _helper prefix from struct drm_*_helper_funcs callbacksJavier Martinez Canillas
The driver uses a naming convention where functions for struct drm_*_funcs callbacks are named ssd130x_$object_$operation, while the callbacks for struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation. The idea is that this helper_ prefix in the function names denote that are for struct drm_*_helper_funcs callbacks. This convention was copied from other drivers when ssd130x was written, but Maxime pointed out that is the exception rather than the norm. So let's get rid of the _helper prefixes from the function handlers names. Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914195138.1518065-1-javierm@redhat.com
2023-09-21drm/ssd130x: Call drm_atomic_helper_shutdown() at remove timeDouglas Anderson
Based on grepping through the source code, this driver appears to be missing a call to drm_atomic_helper_shutdown() at remove time. Let's add it. The fact that we should call drm_atomic_helper_shutdown() in the case of OS driver remove comes straight out of the kernel doc "driver instance overview" in drm_drv.c. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.4.I4752a39ad9f8fd08b32c2b78a8a3e40491bfb5eb@changeid
2023-09-14drm/ssd130x: Store the HW buffer in the driver-private CRTC stateJavier Martinez Canillas
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 <geert@linux-m68k.org> Closes: https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icNxumZcZOPwT9Q_QiogNQ@mail.gmail.com/ Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230913052938.1114651-1-javierm@redhat.com
2023-09-10drm/ssd130x: Use bool for ssd130x_deviceinfo flagsGeert Uytterhoeven
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 <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/285005ff361969eff001386c5f97990f0e703838.1692888745.git.geert@linux-m68k.org
2023-09-10drm/ssd130x: Fix screen clearingGeert Uytterhoeven
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 <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/c19cd5a57205597bb38a446c3871092993498f01.1692888745.git.geert@linux-m68k.org
2023-09-09drm/ssd130x: Print the PWM's label instead of its numberUwe Kleine-König
struct pwm_device::pwm is a write-only variable in the pwm core and used nowhere apart from this and another dev_dbg. So it isn't useful to identify the used PWM. Emit the PWM's label instead in the debug message. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230728145824.616687-2-u.kleine-koenig@pengutronix.de
2023-07-31drm/ssd130x: clean up some inconsistent indentingJiapeng Chong
No functional modification involved. drivers/gpu/drm/solomon/ssd130x.c:715 ssd130x_primary_plane_duplicate_state() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6034 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230731074927.22755-1-jiapeng.chong@linux.alibaba.com
2023-07-27drm/ssd130x: Use shadow-buffer helpers when managing plane's stateJavier Martinez Canillas
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 <arnd@arndb.de> Closes: https://lore.kernel.org/dri-devel/20230727122412.2464210-1-arnd@kernel.org Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230727140453.577445-1-javierm@redhat.com
2023-07-26drm/ssd130x: Allocate buffer in the plane's .atomic_check() callbackJavier Martinez Canillas
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 <mripard@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230726105433.389740-2-javierm@redhat.com
2023-07-26drm/ssd130x: Inline the ssd130x_buf_{alloc, free}() function helpersJavier Martinez Canillas
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 <geert@linux-m68k.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230726105433.389740-1-javierm@redhat.com
2023-07-22drm/ssd130x: Fix pitch calculation in ssd130x_fb_blit_rect()Geert Uytterhoeven
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 <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/54deec2ec533e90544faa8c60a0c2518c58f3e9c.1689252746.git.geert@linux-m68k.org
2023-07-13drm/ssd130x: Change pixel format used to compute the buffer sizeJavier Martinez Canillas
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 <geert@linux-m68k.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230713085859.907127-1-javierm@redhat.com
2023-06-15drm/ssd130x: Remove hardcoded bits-per-pixel in ssd130x_buf_alloc()Javier Martinez Canillas
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 <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-6-javierm@redhat.com
2023-06-15drm/ssd130x: Don't allocate buffers on each plane updateJavier Martinez Canillas
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 <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-5-javierm@redhat.com
2023-06-15drm/ssd130x: Set the page height value in the device info dataJavier Martinez Canillas
The driver only supports OLED controllers that have a page height of 8 but there are devices that have different page heights. So it is better to not hardcode this value and instead have it as a per controller data value. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-4-javierm@redhat.com
2023-06-15drm/ssd130x: Make default width and height to be controller dependentJavier Martinez Canillas
Currently the driver hardcodes the default values to 96x16 pixels but this default resolution depends on the controller. The datasheets for the chips describes the following display controller resolutions: - SH1106: 132 x 64 Dot Matrix OLED/PLED - SSD1305: 132 x 64 Dot Matrix OLED/PLED - SSD1306: 128 x 64 Dot Matrix OLED/PLED - SSD1307: 128 x 39 Dot Matrix OLED/PLED - SSD1309: 128 x 64 Dot Matrix OLED/PLED Add this information to the devices' info structures, and use it set as a default if not defined in DT rather than hardcoding to an arbitrary value. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230609170941.1150941-2-javierm@redhat.com
2023-05-30drm: Switch i2c drivers back to use .probe()Uwe Kleine-König
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("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: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230526090709.1517297-1-u.kleine-koenig@pengutronix.de
2023-05-15drm/ssd130x: Fix include guard nameJavier Martinez Canillas
This is a leftover from an early iteration of the driver when it was still named ssd1307 instead of ssd130x. Change it for consistency with the rest. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230512120232.304603-1-javierm@redhat.com
generated by cgit (git 2.34.1) at 2026-01-09 22:51:44 +0000