OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/drivers/display/Kconfig.ssd16xx

18 lines
490 B
Plaintext
Raw Permalink Normal View History

kconfig: Clean up header comments and make them consistent Use this short header style in all Kconfig files: # <description> # <copyright> # <license> ... Also change all <description>s from # Kconfig[.extension] - Foo-related options to just # Foo-related options It's clear enough that it's about Kconfig. The <description> cleanup was done with this command, along with some manual cleanup (big letter at the start, etc.) git ls-files '*Kconfig*' | \ xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /' Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-01 20:45:29 +08:00
# SSD16XX display controller configuration options
drivers: ssd1673: rename driver to ssd16xx ssd1673 driver supports different controllers, rename it to more generic ssd16xx. Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2019-07-04 05:40:38 +08:00
# Copyright (c) 2018 Phytec Messtechnik GmbH
# SPDX-License-Identifier: Apache-2.0
kconfig: Turn pointless/confusing 'menuconfig's into 'config's Defining a symbol with 'menuconfig' just tells the menuconfig to display any dependent symbols that immediately follow it in a separate menu. 'menuconfig' has no effect on symbol values. Making a symbol that doesn't have any dependent symbols after it a 'menuconfig' should be avoided, because then you end up with an empty menu, which is shown as e.g. [*] Enable foo --- This is how it would be shown if there were children but they all happened to be invisible as well. With a regular 'config', it turns into [*] Enable foo Change all pointless 'menuconfig's to 'config's. See the section on 'menuconfig' on the Kconfig - Tips and Best Practices page as well. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-10-22 07:04:04 +08:00
config SSD16XX
drivers: ssd16xx: cleanup Kconfig Cleanup Kconfig. Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2019-07-13 03:16:42 +08:00
bool "SSD16XX compatible display controller driver"
drivers: display: Update Kconfig * Utilize DT_HAS_<COMPAT>_ENABLED for devicetree based drivers * Move to using 'select SPI' instead of 'depends on' (see commit df81fef94483da9f2811d48088affbcfd61ab18c for more details) Signed-off-by: Kumar Gala <galak@kernel.org>
2022-08-08 23:18:55 +08:00
default y
drivers: ssd16xx: Use device-specific compatibles The SSD16xx driver currently provides basic support for most chips in the Solomon Systech SSD16xx range of e-paper drivers. We currently use the SSD1608, SSD1673, SSD1675A, and SSD1681 in various boards supported by Zephyr. The main user-facing difference between the various SSD16xx chips is the resolution they support (sources & gates), but there are other differences as well. For example: * 8 or 16 bits used to represent x coordinates * 8 or 16 bits used to represent y coordinates * Differences in refresh configuration (SSD16XX_CMD_UPDATE_CTRL2) * Differences in LUT sizes The driver currently assumes that the user specifies the number of bits used to describe coordinates. However, as we add support for more chips, more of the differences will become apparent and need workaround. Comparing data sheets from different chips in the SSD16xx range suggests that there are (at least) two different generations present. These differ in the size of the LUTs they expect and the way they handle partial refresh. This impacts register layout where SSD16XX_CMD_UPDATE_CTRL2 uses bit 3 selects "mode 2" whereas older devices uses this for a mode referred to as "initial". In order to add support for partial refresh in newer devices, we need to be able to distinguish between the different generations of the chip. It might be possible to add a DT property to indicate the revision, but that seems like a bit of an anti-pattern and it would be hard for users to specify the correct chip generation. This change introduces chip-specific compatible strings instead of the generic SSD16xx. There is unfortunately clear pattern that can be used to distinguish different generations, so the full chip name must be specified. A benefit of this is that we don't need to specify the width of the fields describing coordinates in device trees. Signed-off-by: Andreas Sandberg <andreas@sandberg.uk>
2022-07-16 18:11:46 +08:00
depends on \
DT_HAS_SOLOMON_SSD1608_ENABLED || \
DT_HAS_SOLOMON_SSD1673_ENABLED || \
DT_HAS_SOLOMON_SSD1675A_ENABLED || \
drivers: ssd16xx: Add support for the ssd1680 Add support for the SSD1680 EPD driver chip with support for up to 296x176 pixel displays. Signed-off-by: Andreas Sandberg <andreas@sandberg.uk>
2022-07-22 16:26:37 +08:00
DT_HAS_SOLOMON_SSD1680_ENABLED || \
drivers: ssd16xx: Use device-specific compatibles The SSD16xx driver currently provides basic support for most chips in the Solomon Systech SSD16xx range of e-paper drivers. We currently use the SSD1608, SSD1673, SSD1675A, and SSD1681 in various boards supported by Zephyr. The main user-facing difference between the various SSD16xx chips is the resolution they support (sources & gates), but there are other differences as well. For example: * 8 or 16 bits used to represent x coordinates * 8 or 16 bits used to represent y coordinates * Differences in refresh configuration (SSD16XX_CMD_UPDATE_CTRL2) * Differences in LUT sizes The driver currently assumes that the user specifies the number of bits used to describe coordinates. However, as we add support for more chips, more of the differences will become apparent and need workaround. Comparing data sheets from different chips in the SSD16xx range suggests that there are (at least) two different generations present. These differ in the size of the LUTs they expect and the way they handle partial refresh. This impacts register layout where SSD16XX_CMD_UPDATE_CTRL2 uses bit 3 selects "mode 2" whereas older devices uses this for a mode referred to as "initial". In order to add support for partial refresh in newer devices, we need to be able to distinguish between the different generations of the chip. It might be possible to add a DT property to indicate the revision, but that seems like a bit of an anti-pattern and it would be hard for users to specify the correct chip generation. This change introduces chip-specific compatible strings instead of the generic SSD16xx. There is unfortunately clear pattern that can be used to distinguish different generations, so the full chip name must be specified. A benefit of this is that we don't need to specify the width of the fields describing coordinates in device trees. Signed-off-by: Andreas Sandberg <andreas@sandberg.uk>
2022-07-16 18:11:46 +08:00
DT_HAS_SOLOMON_SSD1681_ENABLED
drivers: display: ssd16xx: convert to MIPI DBI API Convert SSD16XX display driver to use MIPI DBI API. This commit also updates in tree board devicetrees to include the emulated MIPI DBI SPI driver. Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
2024-06-08 03:48:50 +08:00
select MIPI_DBI
drivers: ssd1673: rename driver to ssd16xx ssd1673 driver supports different controllers, rename it to more generic ssd16xx. Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2019-07-04 05:40:38 +08:00
help
drivers: ssd16xx: cleanup Kconfig Cleanup Kconfig. Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2019-07-13 03:16:42 +08:00
Enable driver for SSD16XX compatible controller.