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>
* Utilize DT_HAS_<COMPAT>_ENABLED for devicetree based drivers
* Move to using 'select SPI' instead of 'depends on'
(see commit df81fef944 for
more details)
Signed-off-by: Kumar Gala <galak@kernel.org>
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>
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>
