From: Chen-Yu Tsai wens@csie.org
Hi everyone,
This series adds support for SH1106 to the ssd130x OLED display driver.
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
This driver chip is found in some cheap 1.3" OLED panel modules. It acts as a substitute for the SSD1306.
Patch 1 adds an entry to the vendor prefixes for SINO WEALTH Eletronics Ltd.
Patch 2 adds an entry for SH1106 to the ssd1307fb binding.
Patch 3 adds support for the base "page addressing mode" to the ssd130x driver.
Patch 4 adds support for the SH1106 to the ssd130x driver.
Please have a look.
Thanks ChenYu
Chen-Yu Tsai (4): dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd. dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106 drm: ssd130x: Support page addressing mode drm: ssd130x: Add support for SINO WEALTH SH1106
.../bindings/display/solomon,ssd1307fb.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++ drivers/gpu/drm/solomon/ssd130x.c | 72 +++++++++++++++++-- drivers/gpu/drm/solomon/ssd130x.h | 2 + 5 files changed, 81 insertions(+), 7 deletions(-)
From: Chen-Yu Tsai wens@csie.org
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com).
Signed-off-by: Chen-Yu Tsai wens@csie.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..bb4ae59a3c89 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1128,6 +1128,8 @@ patternProperties: description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": description: Sinlinx Electronics Technology Co., LTD + "^sinowealth,.*": + description: SINO WEALTH Electronic Ltd. "^sinovoip,.*": description: SinoVoip Co., Ltd "^sipeed,.*":
Hello Chen-Yu,
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com).
Signed-off-by: Chen-Yu Tsai wens@csie.org
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Best regards, Javier
On 30/03/2022 21:08, Chen-Yu Tsai wrote:
From: Chen-Yu Tsai wens@csie.org
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com).
Signed-off-by: Chen-Yu Tsai wens@csie.org
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..bb4ae59a3c89 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1128,6 +1128,8 @@ patternProperties: description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": description: Sinlinx Electronics Technology Co., LTD
- "^sinowealth,.*":
Alphabetical order, so after sinovoip
- description: SINO WEALTH Electronic Ltd. "^sinovoip,.*": description: SinoVoip Co., Ltd "^sipeed,.*":
Best regards, Krzysztof
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add a compatible string for it.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..1ac016a2d847 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum: + - sinowealth,sh1106-i2c - solomon,ssd1305fb-i2c - solomon,ssd1306fb-i2c - solomon,ssd1307fb-i2c
Hello Chen-Yu,
Thanks a lot for your patch.
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add a compatible string for it.
Signed-off-by: Chen-Yu Tsai wens@csie.org
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..1ac016a2d847 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum:
- sinowealth,sh1106-i2c
I like that you didn't include a "fb" suffix for this, the existing ones are cargo culting from the previous fbdev driver to make existing DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Best regards, Javier
On Fri, Apr 1, 2022 at 5:32 PM Javier Martinez Canillas javier@dowhile0.org wrote:
Hello Chen-Yu,
Thanks a lot for your patch.
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add a compatible string for it.
Signed-off-by: Chen-Yu Tsai wens@csie.org
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..1ac016a2d847 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum:
- sinowealth,sh1106-i2cI like that you didn't include a "fb" suffix for this, the existing ones are cargo culting from the previous fbdev driver to make existing DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
I also thought about dropping the "-i2c" suffix, but then thought there might be a case where someone wanted to search the device tree specifically for an I2C connected node using said compatible string.
What do you think?
ChenYu
Hello Chen-Yu,
On 4/4/22 17:06, Chen-Yu Tsai wrote:
[snip]
enum:
- sinowealth,sh1106-i2cI like that you didn't include a "fb" suffix for this, the existing ones are cargo culting from the previous fbdev driver to make existing DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
I also thought about dropping the "-i2c" suffix, but then thought there might be a case where someone wanted to search the device tree specifically for an I2C connected node using said compatible string.
What do you think?
tl; dr: unfortunately we can't do it due how SPI and I2C report module aliases. Otherwise module auto loading will not work. I wrote a much longer explanation with some details not so long ago:
https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-...
BTW, I bought a SSD1306 SPI controller and go it working this weekend.
I plan to post the patches once yours land, to avoid in-flight series that may conflict. And what I did is mark the -fb as deprecated, then added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.
The WIP patches can be found here in case you are interested:
https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi
ChenYu
On Mon, Apr 4, 2022 at 11:48 PM Javier Martinez Canillas javierm@redhat.com wrote:
Hello Chen-Yu,
On 4/4/22 17:06, Chen-Yu Tsai wrote:
[snip]
enum:
- sinowealth,sh1106-i2cI like that you didn't include a "fb" suffix for this, the existing ones are cargo culting from the previous fbdev driver to make existing DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
I also thought about dropping the "-i2c" suffix, but then thought there might be a case where someone wanted to search the device tree specifically for an I2C connected node using said compatible string.
What do you think?
tl; dr: unfortunately we can't do it due how SPI and I2C report module aliases. Otherwise module auto loading will not work. I wrote a much longer explanation with some details not so long ago:
https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-...
Right. I think that crossed my mind at some point, but didn't stick. Thanks for raising it again. :)
BTW, I bought a SSD1306 SPI controller and go it working this weekend.
I plan to post the patches once yours land, to avoid in-flight series that may conflict. And what I did is mark the -fb as deprecated, then added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.
The WIP patches can be found here in case you are interested:
https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi
I took a quick look and a couple things stood out:
1. Would 3-wire SPI ever be considered? If so, might want to rename some of variables/functions as *_spi_4wire_* to begin with.
2. Maybe we should move the ssd130x_deviceinfo stuff into the core module, and define an enum to use for matching compatible strings across the modules to their respective device info entries? FYI we are doing this in drivers/mfd/axp20x* .
I think a friend of mine has a SPI based SH1106 module that I could borrow and test/work on, but that's a big if.
Regards ChenYu
On 4/4/22 18:11, Chen-Yu Tsai wrote:
[snip]
tl; dr: unfortunately we can't do it due how SPI and I2C report module aliases. Otherwise module auto loading will not work. I wrote a much longer explanation with some details not so long ago:
https://patchwork.kernel.org/project/dri-devel/patch/20220209091204.2513437-...
Right. I think that crossed my mind at some point, but didn't stick. Thanks for raising it again. :)
BTW, I bought a SSD1306 SPI controller and go it working this weekend.
I plan to post the patches once yours land, to avoid in-flight series that may conflict. And what I did is mark the -fb as deprecated, then added "ssd130x-i2c" and "ssd130x-spi" compatibles strings.
The WIP patches can be found here in case you are interested:
https://github.com/martinezjavier/linux/tree/drm-ssd130x-spi
I took a quick look and a couple things stood out:
- Would 3-wire SPI ever be considered? If so, might want to rename some of variables/functions as *_spi_4wire_* to begin with.
That's a good question and something that I considered too. I have to admit that never had a SPI device that uses the 3-wire scheme though so I don't know how common that is.
The ssd1306 datasheet mentions that the chip supports it but I could not find one to buy. Read that should be able to do it by soldering some pads in the board but that wold be more hustle that would like.
For that reason I just went with only supporting 4-wire and someone if really like could provide patches for 3-wire SPI.
- Maybe we should move the ssd130x_deviceinfo stuff into the core module, and define an enum to use for matching compatible strings across the modules to their respective device info entries? FYI we are doing this in drivers/mfd/axp20x* .
Yes, that's a good idea. I'll add that refactoring as a part of the SPI series. Thanks a lot for the suggestion, it was very useful.
I think a friend of mine has a SPI based SH1106 module that I could borrow and test/work on, but that's a big if.
Cool. If it uses 4-wire too then I believe that would mostly work out-of-the-box if you add a compatible string for it. I didn't have to do any change in the core ssd103x driver for the ssd1306 SPI to work.
Regards ChenYu
On 30/03/2022 21:08, Chen-Yu Tsai wrote:
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add a compatible string for it.
Signed-off-by: Chen-Yu Tsai wens@csie.org
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..1ac016a2d847 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum:
- sinowealth,sh1106-i2c - solomon,ssd1305fb-i2c - solomon,ssd1306fb-i2c - solomon,ssd1307fb-i2c
Please update the allOf:if: blocks.
Best regards, Krzysztof
From: Chen-Yu Tsai wens@csie.org
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306, only the basic page addressing mode is supported. This addressing mode is not as easy to use compared to the currently supported horizontal addressing mode, as the page address has to be set prior to writing out each page, and each page must be written out separately as a result. Also, there is no way to force the column address to wrap around early, thus the column address must also be reset for each page to be accurate.
Add support for this addressing mode, with a flag to choose it. This flag is designed to be set from the device info data structure, but can be extended to be explicitly forced on through a device tree property if such a need arises.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- drivers/gpu/drm/solomon/ssd130x.c | 72 ++++++++++++++++++++++++++++--- drivers/gpu/drm/solomon/ssd130x.h | 2 + 2 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c index d08d86ef07bc..21040d8bf9d1 100644 --- a/drivers/gpu/drm/solomon/ssd130x.c +++ b/drivers/gpu/drm/solomon/ssd130x.c @@ -42,6 +42,8 @@ #define SSD130X_DATA 0x40 #define SSD130X_COMMAND 0x80
+#define SSD130X_PAGE_COL_START_LOW 0x00 +#define SSD130X_PAGE_COL_START_HIGH 0x10 #define SSD130X_SET_ADDRESS_MODE 0x20 #define SSD130X_SET_COL_RANGE 0x21 #define SSD130X_SET_PAGE_RANGE 0x22 @@ -61,6 +63,10 @@ #define SSD130X_SET_COM_PINS_CONFIG 0xda #define SSD130X_SET_VCOMH 0xdb
+#define SSD130X_PAGE_COL_START_MASK GENMASK(3, 0) +#define SSD130X_PAGE_COL_START_SET(val) FIELD_PREP(SSD130X_PAGE_COL_START_MASK, (val)) +#define SSD130X_START_PAGE_ADDRESS_MASK GENMASK(2, 0) +#define SSD130X_START_PAGE_ADDRESS_SET(val) FIELD_PREP(SSD130X_START_PAGE_ADDRESS_MASK, (val)) #define SSD130X_SET_SEG_REMAP_MASK GENMASK(0, 0) #define SSD130X_SET_SEG_REMAP_SET(val) FIELD_PREP(SSD130X_SET_SEG_REMAP_MASK, (val)) #define SSD130X_SET_COM_SCAN_DIR_MASK GENMASK(3, 3) @@ -130,6 +136,7 @@ static int ssd130x_write_cmd(struct ssd130x_device *ssd130x, int count, return ret; }
+/* Set address range for horizontal/vertical addressing modes */ static int ssd130x_set_col_range(struct ssd130x_device *ssd130x, u8 col_start, u8 cols) { @@ -166,6 +173,26 @@ static int ssd130x_set_page_range(struct ssd130x_device *ssd130x, return 0; }
+/* Set page and column start address for page addressing mode */ +static int ssd130x_set_page_pos(struct ssd130x_device *ssd130x, + u8 page_start, u8 col_start) +{ + int ret; + u32 page, col_low, col_high; + + page = SSD130X_START_PAGE_ADDRESS | + SSD130X_START_PAGE_ADDRESS_SET(page_start); + col_low = SSD130X_PAGE_COL_START_LOW | + SSD130X_PAGE_COL_START_SET(col_start & 0xf); + col_high = SSD130X_PAGE_COL_START_HIGH | + SSD130X_PAGE_COL_START_SET((col_start >> 4) & 0xf); + ret = ssd130x_write_cmd(ssd130x, 3, page, col_low, col_high); + if (ret < 0) + return ret; + + return 0; +} + static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x) { struct device *dev = ssd130x->dev; @@ -342,6 +369,11 @@ static int ssd130x_init(struct ssd130x_device *ssd130x) } }
+ /* Switch to page addressing mode */ + if (ssd130x->page_address_mode) + return ssd130x_write_cmd(ssd130x, 2, SSD130X_SET_ADDRESS_MODE, + SSD130X_SET_ADDRESS_MODE_PAGE); + /* Switch to horizontal addressing mode */ return ssd130x_write_cmd(ssd130x, 2, SSD130X_SET_ADDRESS_MODE, SSD130X_SET_ADDRESS_MODE_HORIZONTAL); @@ -393,13 +425,16 @@ static int ssd130x_update_rect(struct ssd130x_device *ssd130x, u8 *buf, * (5) A4 B4 C4 D4 E4 F4 G4 H4 */
- ret = ssd130x_set_col_range(ssd130x, ssd130x->col_offset + x, width); - if (ret < 0) - goto out_free; + if (!ssd130x->page_address_mode) { + /* Set address range for horizontal addressing mode */ + ret = ssd130x_set_col_range(ssd130x, ssd130x->col_offset + x, width); + if (ret < 0) + goto out_free;
- ret = ssd130x_set_page_range(ssd130x, ssd130x->page_offset + y / 8, pages); - if (ret < 0) - goto out_free; + ret = ssd130x_set_page_range(ssd130x, ssd130x->page_offset + y / 8, pages); + if (ret < 0) + goto out_free; + }
for (i = y / 8; i < y / 8 + pages; i++) { int m = 8; @@ -418,9 +453,29 @@ static int ssd130x_update_rect(struct ssd130x_device *ssd130x, u8 *buf, } data_array[array_idx++] = data; } + + /* + * In page addressing mode, the start address needs to be reset, + * and each page then needs to be written out separately. + */ + if (ssd130x->page_address_mode) { + ret = ssd130x_set_page_pos(ssd130x, + ssd130x->page_offset + i, + ssd130x->col_offset + x); + if (ret < 0) + goto out_free; + + ret = ssd130x_write_data(ssd130x, data_array, width); + if (ret < 0) + goto out_free; + + array_idx = 0; + } }
- ret = ssd130x_write_data(ssd130x, data_array, width * pages); + /* Write out update in one go if we aren't using page addressing mode */ + if (!ssd130x->page_address_mode) + ret = ssd130x_write_data(ssd130x, data_array, width * pages);
out_free: kfree(data_array); @@ -796,6 +851,9 @@ struct ssd130x_device *ssd130x_probe(struct device *dev, struct regmap *regmap) ssd130x->regmap = regmap; ssd130x->device_info = device_get_match_data(dev);
+ if (ssd130x->device_info->page_mode_only) + ssd130x->page_address_mode = 1; + ssd130x_parse_properties(ssd130x);
ret = ssd130x_get_resources(ssd130x); diff --git a/drivers/gpu/drm/solomon/ssd130x.h b/drivers/gpu/drm/solomon/ssd130x.h index cd21cdccb566..f5b062576fdf 100644 --- a/drivers/gpu/drm/solomon/ssd130x.h +++ b/drivers/gpu/drm/solomon/ssd130x.h @@ -24,6 +24,7 @@ struct ssd130x_deviceinfo { u32 default_dclk_frq; int need_pwm; int need_chargepump; + bool page_mode_only; };
struct ssd130x_device { @@ -38,6 +39,7 @@ struct ssd130x_device {
const struct ssd130x_deviceinfo *device_info;
+ unsigned page_address_mode : 1; unsigned area_color_enable : 1; unsigned com_invdir : 1; unsigned com_lrremap : 1;
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306, only the basic page addressing mode is supported. This addressing mode is not as easy to use compared to the currently supported horizontal addressing mode, as the page address has to be set prior to writing out each page, and each page must be written out separately as a result. Also, there is no way to force the column address to wrap around early, thus the column address must also be reset for each page to be accurate.
Thanks for including this explanation, it's very informative.
Add support for this addressing mode, with a flag to choose it. This flag is designed to be set from the device info data structure, but can be extended to be explicitly forced on through a device tree property if such a need arises.
Agreed. Unless an OLED controller supports both page addressing modes, I don't see what could be an advantage of having that property in the device tree. And even if that's the case, we could just always make it default to use horizontal addressing mode.
[snip]
+/* Set address range for horizontal/vertical addressing modes */
Thanks for adding these comments.
static int ssd130x_set_col_range(struct ssd130x_device *ssd130x, u8 col_start, u8 cols) { @@ -166,6 +173,26 @@ static int ssd130x_set_page_range(struct ssd130x_device *ssd130x, return 0; }
+/* Set page and column start address for page addressing mode */ +static int ssd130x_set_page_pos(struct ssd130x_device *ssd130x,
u8 page_start, u8 col_start)+{
int ret;u32 page, col_low, col_high;page = SSD130X_START_PAGE_ADDRESS |SSD130X_START_PAGE_ADDRESS_SET(page_start);col_low = SSD130X_PAGE_COL_START_LOW |SSD130X_PAGE_COL_START_SET(col_start & 0xf);col_high = SSD130X_PAGE_COL_START_HIGH |SSD130X_PAGE_COL_START_SET((col_start >> 4) & 0xf);
Maybe instead we should define SSD130X_PAGE_COL_START_{HIGH,LOW}_{MASK,SET} to be consistent with how the other fields are set and not using bitwise operations explicitly here ?
Other than that, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Best regards, Javier
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add support for this display driver. The default values for some of the hardware settings are taken from the datasheet.
Signed-off-by: Chen-Yu Tsai wens@csie.org --- drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c b/drivers/gpu/drm/solomon/ssd130x-i2c.c index 3126aeda4ced..d099b241dd3f 100644 --- a/drivers/gpu/drm/solomon/ssd130x-i2c.c +++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c @@ -53,6 +53,13 @@ static void ssd130x_i2c_shutdown(struct i2c_client *client) ssd130x_shutdown(ssd130x); }
+static struct ssd130x_deviceinfo ssd130x_sh1106_deviceinfo = { + .default_vcomh = 0x40, + .default_dclk_div = 1, + .default_dclk_frq = 5, + .page_mode_only = 1, +}; + static struct ssd130x_deviceinfo ssd130x_ssd1305_deviceinfo = { .default_vcomh = 0x34, .default_dclk_div = 1, @@ -80,6 +87,10 @@ static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = { };
static const struct of_device_id ssd130x_of_match[] = { + { + .compatible = "sinowealth,sh1106-i2c", + .data = &ssd130x_sh1106_deviceinfo, + }, { .compatible = "solomon,ssd1305fb-i2c", .data = &ssd130x_ssd1305_deviceinfo,
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add support for this display driver. The default values for some of the hardware settings are taken from the datasheet.
Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++++++++++
Thanks a lot for this patch. It's very nice to see that another variant of the OLED controller is being supported!
I wonder if we should also list SH1106 in the drivers/gpu/drm/solomon/Kconfig file so people can find it ?
ah, one comment I forgot in 3/4 but that also applies to this patch, I believe the convention in DRM is for the subject line to be "drm/ssd130x:" instead of "drm: ssd130x:"
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Best regards, Javier
On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas javier@dowhile0.org wrote:
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wens@kernel.org wrote:
From: Chen-Yu Tsai wens@csie.org
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes.
Add support for this display driver. The default values for some of the hardware settings are taken from the datasheet.
Signed-off-by: Chen-Yu Tsai wens@csie.org
drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++++++++++
Thanks a lot for this patch. It's very nice to see that another variant of the OLED controller is being supported!
I wonder if we should also list SH1106 in the drivers/gpu/drm/solomon/Kconfig file so people can find it ?
I can add it to the help text if that helps?
Recently someone mentioned that users are more likely to find drivers via compatible strings though. And I believe there's also a tool in-tree that finds all drivers given a device tree.
ah, one comment I forgot in 3/4 but that also applies to this patch, I believe the convention in DRM is for the subject line to be "drm/ssd130x:" instead of "drm: ssd130x:"
Ack.
Reviewed-by: Javier Martinez Canillas javierm@redhat.com
Thanks ChenYu
On 4/4/22 18:35, Chen-Yu Tsai wrote:
On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas javier@dowhile0.org wrote:
[snip]
I wonder if we should also list SH1106 in the drivers/gpu/drm/solomon/Kconfig file so people can find it ?
I can add it to the help text if that helps?
No strong opinion really, it was an honest question.
Recently someone mentioned that users are more likely to find drivers via compatible strings though. And I believe there's also a tool in-tree that finds all drivers given a device tree.
Yeah I guess so. Looking at existing DTS and drivers' device tables is certainly what I personally do when searching it a device is supported.
dri-devel@lists.freedesktop.org
-
Chen-Yu Tsai -
Javier Martinez Canillas -
Javier Martinez Canillas -
Krzysztof Kozlowski