[PATCH 0/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[PATCH 0/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Chen-Yu Tsai]

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(-)

-- 
2.34.1

[PATCH 1/4] dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.

[Chen-Yu Tsai]

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,.*":
-- 
2.34.1

Re: [PATCH 1/4] dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.

[Javier Martinez Canillas]

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

Re: [PATCH 1/4] dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.

[Krzysztof Kozlowski]

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

[PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Chen-Yu Tsai]

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
-- 
2.34.1

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Javier Martinez Canillas]

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

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Chen-Yu Tsai]

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-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>

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

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Javier Martinez Canillas]

Hello Chen-Yu,

On 4/4/22 17:06, Chen-Yu Tsai wrote:

[snip]

>>>      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>
> 
> 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-1-javierm@redhat.com/#24730793

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
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Chen-Yu Tsai]

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-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>
> >
> > 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-1-javierm@redhat.com/#24730793

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

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Javier Martinez Canillas]

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-1-javierm@redhat.com/#24730793
> 
> 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.
>

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.

> 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* .
> 

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
> 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106

[Krzysztof Kozlowski]

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

[PATCH 3/4] drm: ssd130x: Support page addressing mode

[Chen-Yu Tsai]

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;
-- 
2.34.1

Re: [PATCH 3/4] drm: ssd130x: Support page addressing mode

[Javier Martinez Canillas]

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

[PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Chen-Yu Tsai]

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,
-- 
2.34.1

Re: [PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Javier Martinez Canillas]

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

Re: [PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Chen-Yu Tsai]

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

Re: [PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106

[Javier Martinez Canillas]

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.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat