zephyr/boards/shields/waveshare_epaper/waveshare_epaper_gdeh0213b7...

73 lines
1.4 KiB
Plaintext
Raw Normal View History

/*
* Copyright (c) 2019, PHYTEC Messtechnik GmbH
*
* SPDX-License-Identifier: Apache-2.0
*/
#include "waveshare_epaper_common.dtsi"
/ {
chosen {
zephyr,display = &ssd16xx_waveshare_epaper_gdeh0213b72;
};
};
&arduino_spi {
ssd16xx_waveshare_epaper_gdeh0213b72: ssd16xxfb@0 {
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
compatible = "gooddisplay,gdeh0213b72", "solomon,ssd1675a";
spi-max-frequency = <4000000>;
reg = <0>;
width = <250>;
height = <120>;
dc-gpios = <&arduino_header 15 GPIO_ACTIVE_LOW>; /* D9 */
reset-gpios = <&arduino_header 14 GPIO_ACTIVE_LOW>; /* D8 */
busy-gpios = <&arduino_header 13 GPIO_ACTIVE_HIGH>; /* D7 */
full {
gdv = [15];
sdv = [41 a8 32];
vcom = <0x55>;
border-waveform = <0x03>;
dummy-line = <0x30>;
gate-line-width = <0x0a>;
lut = [
80 60 40 00 00 00 00
10 60 20 00 00 00 00
80 60 40 00 00 00 00
10 60 20 00 00 00 00
00 00 00 00 00 00 00
03 03 00 00 02
09 09 00 00 02
03 03 00 00 02
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
];
};
partial {
gdv = [15];
sdv = [41 a8 32];
vcom = <0x26>;
border-waveform = <0x01>;
dummy-line = <0x30>;
gate-line-width = <0x0a>;
lut = [
00 00 00 00 00 00 00
80 00 00 00 00 00 00
40 00 00 00 00 00 00
80 00 00 00 00 00 00
00 00 00 00 00 00 00
0A 00 00 00 04
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
];
};
};
};