#
b4299c93 |
|
28-Dec-2023 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Add support for the SSD133x OLED controller family 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
|
#
fdd591e0 |
|
14-Oct-2023 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Add support for the SSD132x OLED controller family 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
|
#
9081d21a |
|
14-Oct-2023 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Rename commands that are shared across chip families 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
|
#
e6663dd4 |
|
14-Oct-2023 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Add a controller family id to the device info data 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
|
#
6fc20a85 |
|
18-Jun-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Use new regmap bulk write support to drop custom bus Data writes for the ssd130x 4-wire SPI protocol need special handling, due the Data/Command control (D/C) pin having to be toggled prior to the write. The regmap API only allowed drivers to provide .reg_{read,write} callbacks to do per register read/write, but didn't provide a way for drivers to do the same for bulk read/writes. For this reason, a custom regmap bus was used by the driver just to define a bulk write callback that implements the D/C pin toggling. But the regmap API has been extended to support defining bulk read/write handlers, so the custom regmap bus is not needed anymore and could just be dropped. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220618174338.2253021-1-javierm@redhat.com
|
#
01ece651 |
|
30-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/ssd130x: Only define a SPI device ID table when built as a module The kernel test robot reports a compile warning due the ssd130x_spi_table variable being defined but not used. This happen when ssd130x-spi driver is built-in instead of being built as a module, i.e: CC drivers/gpu/drm/solomon/ssd130x-spi.o AR drivers/base/firmware_loader/built-in.a AR drivers/base/built-in.a CC kernel/trace/trace.o drivers/gpu/drm/solomon/ssd130x-spi.c:155:35: warning: ‘ssd130x_spi_table’ defined but not used [-Wunused-const-variable=] 155 | static const struct spi_device_id ssd130x_spi_table[] = { | ^~~~~~~~~~~~~~~~~ The driver shouldn't need a SPI device ID table and only have an OF device ID table, but the former is needed to workaround an issue in the SPI core. This always reports a MODALIAS of the form "spi:<device>" even for devices registered through Device Trees. But the table is only needed when the driver built as a module to populate the .ko alias info. It's not needed when the driver is built-in the kernel. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220530140246.742469-1-javierm@redhat.com
|
#
74373977 |
|
19-Apr-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
drm/solomon: Add SSD130x OLED displays SPI support The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI. There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory. But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data. For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-6-javierm@redhat.com
|