drm/solomon: Add SSD130x OLED displays SPI support
Subsystems (4)
Javier Martinez Canillas
maintainercover drm/solomon: Add SSD130x OLED displays SPI support
Hello,
This series adds a ssd130x-spi driver that provides a 4-wire SPI transport support for SSD130x OLED controllers that can be accessed through a SPI.
The driver is quite similar to existing ssd130x-i2c driver that is used by I2C controllers, but there is a difference in the protocol used by SSD130x depending on the transport used. The details are in patch #4 description.
Patch #1 just makes the current ssd130x-i2c compatible strings in the DT binding to be deprecated, and add new ones that don't have an -fb suffix.
Patch #2 extends the DT binding with the compatible string and properties needed to support the ssd130x-spi devices.
Patch #3 adds the new compatible strings to the OF device ID table in the ssd130x-i2c DRM driver.
Patch #4 moves the device info for the different SSD130x variants from the ssd130x-i2c transport driver to the ssd130x core driver.
Finally patch #5 adds the ssd130x-spi DRM driver for the OLED controllers that come with a 4-wire SPI interface, instead of an I2C interface.
Best regards,
Javier
Javier Martinez Canillas (5):
dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
dt-bindings: display: ssd1307fb: Extend schema for SPI controllers drm/solomon: Add ssd130x-i2c compatible strings without an -fb suffix drm/solomon: Move device info from ssd130x-i2c to the core driver drm/solomon: Add SSD130x OLED displays SPI support
.../bindings/display/solomon,ssd1307fb.yaml | 117 ++++++++--- drivers/gpu/drm/solomon/Kconfig | 9 + drivers/gpu/drm/solomon/Makefile | 1 + drivers/gpu/drm/solomon/ssd130x-i2c.c | 60 +++--- drivers/gpu/drm/solomon/ssd130x-spi.c | 184 ++++++++++++++++++ drivers/gpu/drm/solomon/ssd130x.c | 60 +++++- drivers/gpu/drm/solomon/ssd130x.h | 13 ++ 7 files changed, 376 insertions(+), 68 deletions(-) create mode 100644 drivers/gpu/drm/solomon/ssd130x-spi.c
Signature · 1 line
2.35.1
Javier Martinez Canillas
maintainerPATCH 1/5 dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add a new enum that contains compatible strings that don't have a -fb suffix. These will be matched by the ssd130x-i2c DRM driver.
---
.../bindings/display/solomon,ssd1307fb.yaml | 36 ++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-)
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +24 -12
@@ -12,12 +12,24 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c + deprecated: true + + # SSD130x I2C controllers + - items: + - enum: + - sinowealth,sh1106-i2c + - solomon,ssd1305-i2c + - solomon,ssd1306-i2c + - solomon,ssd1307-i2c + - solomon,ssd1309-i2c reg: maxItems: 1
@@ -148,7 +160,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1305fb-i2c + const: solomon,ssd1305-i2c then: properties: solomon,dclk-div:
@@ -160,7 +172,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1306fb-i2c + const: solomon,ssd1306-i2c then: properties: solomon,dclk-div:
@@ -172,7 +184,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1307fb-i2c + const: solomon,ssd1307-i2c then: properties: solomon,dclk-div:
@@ -186,7 +198,7 @@ allOf: properties: compatible: contains: - const: solomon,ssd1309fb-i2c + const: solomon,ssd1309-i2c then: properties: solomon,dclk-div:
@@ -203,14 +215,14 @@ examples: #size-cells = <0>; ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; + compatible = "solomon,ssd1307-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; }; ssd1306: oled@3d { - compatible = "solomon,ssd1306fb-i2c"; + compatible = "solomon,ssd1306-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>;
Signature · 1 line
2.35.1
Rob Herring
maintainerRe: [PATCH 1/5] dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
Quoted 3 lines · Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
True, but compatible is just an identifier. There's no reason to deprecate unless the binding as a whole needs to be redone.
I imagine you also want 2 compatibles for 2 drivers. That's saying you should change your firmware to switch drivers. The fact that we have 2 drivers for the same h/w is a kernel problem. Don't bring DT into it.
Quoted 32 lines
Let's deprecate those compatible strings and add a new enum that contains compatible strings that don't have a -fb suffix. These will be matched by the ssd130x-i2c DRM driver.
Signed-off-by Javier Martinez Canillas <[email protected]>---
.../bindings/display/solomon,ssd1307fb.yaml | 36 ++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-)Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +8
-6@@ -12,12 +12,24 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml maintainers: · line 32
Quoted 10 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +10
-0+ deprecated: true + + # SSD130x I2C controllers + - items: + - enum: + - sinowealth,sh1106-i2c + - solomon,ssd1305-i2c + - solomon,ssd1306-i2c + - solomon,ssd1307-i2c + - solomon,ssd1309-i2c
There's also no reason to put the bus interface into the compatible as the same compatible will work on different buses. But since you want to add SPI, just using the 'i2c' one will confuse people. For that reason you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM. (You should also support the 'fb-i2c' variant in DRM IMO, but doubtful that I'll review that.)
Rob
Javier Martinez Canillas
maintainerRe: [PATCH 1/5] dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
Hello Rob,
Quoted 5 lines · Rob Herring
Quoted 3 lines · Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
Quoted 7 lines
True, but compatible is just an identifier. There's no reason to deprecate unless the binding as a whole needs to be redone.
I imagine you also want 2 compatibles for 2 drivers. That's saying you should change your firmware to switch drivers. The fact that we have 2 drivers for the same h/w is a kernel problem. Don't bring DT into it.
No, that's not what I meant. In fact, we currently have two drivers that match against the same set of compatible strings. These drivers are:
* drivers/video/fbdev/ssd1307fb.c
* drivers/gpu/drm/solomon/ssd130x-i2c.c
what I don't personally like about the current compatible strings is that the *driver* name was encoded on those, rather than the IC names. So for instance there's a "solomon,ssd1307fb-i2c" (notice the fb suffix) instead of just "solomon,ssd1307-i2c" or "solomon,ssd1307".
When I ported the fbdev driver to DRM, I considered using different values for the compatible strings but decided to just use the same for backward compatibility.
But now I want to add compatible strings for OLED controllers that use a SPI interface instead, and I don't really want to add a compatible string "solomon,ssd1307fb-spi" but just without the "fb".
I want the SPI compatible strings to be consistent with the I2C ones though, hence the deprecation so new DTS could just use the ones without a "fb".
Now, if you say that I can't do add new ones for I2C, then I will just add "solomon,ssd1307fb-spi" and similar even though I don't like the "fb" there.
And just to make clear, the DRM driver will continue matching against both compatible strings, but the fbdev will only match the old "fb" ones.
[snip]
Quoted 10 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml maintainers: · line 32
Quoted 9 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +9
-0+ + # SSD130x I2C controllers + - items: + - enum: + - sinowealth,sh1106-i2c + - solomon,ssd1305-i2c + - solomon,ssd1306-i2c + - solomon,ssd1307-i2c + - solomon,ssd1309-i2c
Quoted 4 lines
There's also no reason to put the bus interface into the compatible as the same compatible will work on different buses. But since you want to add SPI, just using the 'i2c' one will confuse people. For that reason you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM.
That's not really true. There's a reason to add per bus compatible strings at least in Linux. And is that there's no information about the bus types in module aliases that are reported to user-space for module auto-loading.
For example,
$ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-003c/modalias of:NoledT(null)Csolomon,ssd1306fb-i2c
$ cat /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-003c/uevent DRIVER=ssd130x-i2c OF_NAME=oled OF_FULLNAME=/soc/i2c@7e804000/oled@3c OF_COMPATIBLE_0=solomon,ssd1306fb-i2c OF_COMPATIBLE_N=1 MODALIAS=of:NoledT(null)Csolomon,ssd1306fb-i2c
and
$ modinfo ssd130x-i2c | grep alias alias: of:N*T*Csolomon,ssd1309fb-i2cC* alias: of:N*T*Csolomon,ssd1309fb-i2c alias: of:N*T*Csolomon,ssd1307fb-i2cC* alias: of:N*T*Csolomon,ssd1307fb-i2c alias: of:N*T*Csolomon,ssd1306fb-i2cC* alias: of:N*T*Csolomon,ssd1306fb-i2c alias: of:N*T*Csolomon,ssd1305fb-i2cC* alias: of:N*T*Csolomon,ssd1305fb-i2c alias: of:N*T*Csinowealth,sh1106-i2cC* alias: of:N*T*Csinowealth,sh1106-i2c
this module will match against any MODALIAS uevent that has one of the listed compatible strings in "C" and any node name in "N". But also for any type "T".
And even if the module alias was more restrictive and say only matched against 'of:N*Ti2cCsolomon,ssd1307fb-i2c', the type information is not filled by the bus drivers.
So, if we just had a "solomon,ssd1307" compatible string, then a device registered through OF could lead to the wrong kernel module to be loaded.
In other words, it's true that having a single compatible strings for all bus drivers will work for device -> driver matching but may not work for module auto-loading.
Quoted 3 lines
(You should also support the 'fb-i2c' variant in DRM IMO, but doubtful that I'll review that.)
As mentioned above, it does even after adding support for the new strings, for backward compatibility.
Quoted 2 lines
Rob
Signature · 5 lines
Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Javier Martinez Canillas
maintainerRe: [PATCH 1/5] dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
On 4/8/22 21:19, Javier Martinez Canillas wrote:
[snip]
Quoted 10 lines
Quoted 5 lines
There's also no reason to put the bus interface into the compatible as the same compatible will work on different buses. But since you want to add SPI, just using the 'i2c' one will confuse people. For that reason you could add 'solomon,ssd1305', etc. for both SPI support and I2C DRM.
That's not really true. There's a reason to add per bus compatible strings at least in Linux. And is that there's no information about the bus types in module aliases that are reported to user-space for module auto-loading.
Forgot to mention that in this particular case it will work but just because the SPI subsystem always report a module alias of the form "spi:device" even for devices that are registered through OF.
So having a single "solomon,ssd1306" would work because for I2C the module alias will be "of:NoledT(null)Csolomon,ssd1306" and for SPI it will be "spi:ssd1306".
But if ever the SPI subsystem is fixed to report proper OF module aliases things will break. And since the DT bindings is an ABI, it's safer to have "-i2c" and "-spi" compatible strings variants.
Signature · 5 lines
Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 1/5] dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
In reply to Javier Martinez CanillasHi Javier,
Quoted 20 lines · Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add a new enum that contains compatible strings that don't have a -fb suffix. These will be matched by the ssd130x-i2c DRM driver.
Signed-off-by Javier Martinez Canillas <[email protected]>Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +0
-4@@ -12,12 +12,24 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml maintainers: · line 22
Quoted 10 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +8
-2- - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c
Please drop the "-i2c" suffixes, too.
We already have plenty of IIO sensors and audio codecs using the same compatible value for spi and i2c, cfr.
'git grep compatible -- "*-[si][p2][ic].c"'
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Javier Martinez Canillas
maintainerRe: [PATCH 1/5] dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
Hello Geert,
Quoted 31 lines · Geert Uytterhoeven
Hi Javier,
Quoted 27 lines · Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add a new enum that contains compatible strings that don't have a -fb suffix. These will be matched by the ssd130x-i2c DRM driver.
Signed-off-by Javier Martinez Canillas <[email protected]>Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +5
-6@@ -12,12 +12,24 @@ maintainers: properties: compatible: - enum: - - sinowealth,sh1106-i2c - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + oneOf: + # Deprecated compatible strings + - items: + - enum: + - solomon,ssd1305fb-i2c
Quoted 9 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml maintainers: · line 22
Quoted 3 lines
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +3
-0+ - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2cPlease drop the "-i2c" suffixes, too.
We already have plenty of IIO sensors and audio codecs using the same compatible value for spi and i2c, cfr.
'git grep compatible -- "*-[si][p2][ic].c"'
Yes, I know but was worried about the potential issues that mentioned in a previous email in this thread. But after the discussion we had over IRC, I think that is safe to assume that the SPI subsystem won't change how the modaliases are reported, so there won't be conflict between I2C and SPI.
And if that is ever changed, there's a plan to add the bus type to the data reported by the modalias uevent so user-space could figure out what to load.
So I'll go ahead with Rob and yours suggestion, and just deprecate the old ones and drop both the "fb" and "-i2c" part of the compatible strings, to use the same compatible strings for both the I2C and SPI drivers.
After all, that's the correct way to describe the hardware and not encode any Linux implementation details in the DT binding.
Signature · 5 lines
Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Javier Martinez Canillas
maintainerPATCH 2/5 dt-bindings: display: ssd1307fb: Extend schema for SPI controllers
In reply to Javier Martinez CanillasThe Solomon SSD130x OLED displays can either have an I2C or SPI interface, add to the schema the compatible strings, properties and examples for SPI.
---
.../bindings/display/solomon,ssd1307fb.yaml | 89 +++++++++++++++---- 1 file changed, 71 insertions(+), 18 deletions(-)
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +71 -18
@@ -31,6 +31,15 @@ properties: - solomon,ssd1307-i2c - solomon,ssd1309-i2c + # SSD130x SPI controllers + - items: + - enum: + - sinowealth,sh1106-spi + - solomon,ssd1305-spi + - solomon,ssd1306-spi + - solomon,ssd1307-spi + - solomon,ssd1309-spi + reg: maxItems: 1
@@ -40,9 +49,14 @@ properties: reset-gpios: maxItems: 1 + dc-gpios: + maxItems: 1 + vbat-supply: description: The supply for VBAT + spi-max-frequency: true + solomon,height: $ref: /schemas/types.yaml#/definitions/uint32 default: 16
@@ -148,19 +162,10 @@ allOf: properties: compatible: contains: - const: sinowealth,sh1106-i2c - then: - properties: - solomon,dclk-div: - default: 1 - solomon,dclk-frq: - default: 5 - - - if: - properties: - compatible: - contains: - const: solomon,ssd1305-i2c + enum: + - sinowealth,sh1106-i2c + - solomon,ssd1305-i2c + - solomon,ssd1305-spi then: properties: solomon,dclk-div:
@@ -172,7 +177,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1306-i2c + enum: + - solomon,ssd1306-i2c + - solomon,ssd1306-spi then: properties: solomon,dclk-div:
@@ -184,7 +191,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1307-i2c + enum: + - solomon,ssd1307-i2c + - solomon,ssd1307-spi then: properties: solomon,dclk-div:
@@ -198,7 +207,9 @@ allOf: properties: compatible: contains: - const: solomon,ssd1309-i2c + enum: + - solomon,ssd1309-i2c + - solomon,ssd1309-spi then: properties: solomon,dclk-div:
@@ -206,6 +217,21 @@ allOf: solomon,dclk-frq: default: 10 + - if: + properties: + compatible: + contains: + enum: + - sinowealth,sh1106-spi + - solomon,ssd1305-spi + - solomon,ssd1306-spi + - solomon,ssd1307-spi + - solomon,ssd1309-spi + then: + required: + - spi-max-frequency + - dc-gpios + additionalProperties: false examples:
@@ -214,14 +240,14 @@ examples: #address-cells = <1>; #size-cells = <0>; - ssd1307: oled@3c { + ssd1307_i2c: oled@3c { compatible = "solomon,ssd1307-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; }; - ssd1306: oled@3d { + ssd1306_i2c: oled@3d { compatible = "solomon,ssd1306-i2c"; reg = <0x3c>; pwms = <&pwm 4 3000>;
@@ -232,3 +258,30 @@ examples: solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; }; }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + ssd1307_spi: oled@0 { + compatible = "solomon,ssd1307-spi"; + reg = <0x0>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + dc-gpios = <&gpio2 8>; + spi-max-frequency = <10000000>; + }; + + ssd1306_spi: oled@1 { + compatible = "solomon,ssd1306-spi"; + reg = <0x1>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + dc-gpios = <&gpio2 8>; + spi-max-frequency = <10000000>; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; + solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; + }; + };
Signature · 1 line
2.35.1
Javier Martinez Canillas
maintainerPATCH 3/5 drm/solomon: Add ssd130x-i2c compatible strings without an -fb suffix
In reply to Javier Martinez CanillasThe current compatible strings for SSD130x I2C controllers contain an -fb suffix, this seems to indicate that are for a fbdev driver. But the DT is supposed to describe the hardware and not Linux implementation details.
Let's deprecate those compatible strings and add new ones that don't have the -fb suffix. The old entries are still kept for backward compatibility.
---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/gpu/drm/solomon/ssd130x-i2c.c +17 -0
@@ -91,6 +91,23 @@ static const struct of_device_id ssd130x_of_match[] = { .compatible = "sinowealth,sh1106-i2c", .data = &ssd130x_sh1106_deviceinfo, }, + { + .compatible = "solomon,ssd1305-i2c", + .data = &ssd130x_ssd1305_deviceinfo, + }, + { + .compatible = "solomon,ssd1306-i2c", + .data = &ssd130x_ssd1306_deviceinfo, + }, + { + .compatible = "solomon,ssd1307-i2c", + .data = &ssd130x_ssd1307_deviceinfo, + }, + { + .compatible = "solomon,ssd1309-i2c", + .data = &ssd130x_ssd1309_deviceinfo, + }, + /* Deprecated but remain for backward compatibility */ { .compatible = "solomon,ssd1305fb-i2c", .data = &ssd130x_ssd1305_deviceinfo,
Signature · 1 line
2.35.1
Javier Martinez Canillas
maintainerPATCH 4/5 drm/solomon: Move device info from ssd130x-i2c to the core driver
In reply to Javier Martinez CanillasThese are declared in the ssd130x-i2c transport driver but the information is not I2C specific and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device into from an array.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control bytes. Since even though are used by the I2C interface, it could also be useful for other transport protocols such as SPI.
---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 51 ++++------------------- drivers/gpu/drm/solomon/ssd130x.c | 60 +++++++++++++++++++++++++-- drivers/gpu/drm/solomon/ssd130x.h | 13 ++++++ 3 files changed, 78 insertions(+), 46 deletions(-)
drivers/gpu/drm/solomon/ssd130x-i2c.c +9 -42
@@ -53,76 +53,43 @@ 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 , - .default_dclk_frq =7 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1306_deviceinfo = { - .default_vcomh =0x20 , - .default_dclk_div =1 , - .default_dclk_frq =8 , - .need_chargepump =1 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1307_deviceinfo = { - .default_vcomh =0x20 , - .default_dclk_div =2 , - .default_dclk_frq =12 , - .need_pwm =1 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = { - .default_vcomh =0x34 , - .default_dclk_div =1 , - .default_dclk_frq =10 , -}; -static const struct of_device_id ssd130x_of_match[] = { { .compatible ="sinowealth,sh1106-i2c" , - .data = &ssd130x_sh1106_deviceinfo, + .data =SH1106_ID , }, { .compatible ="solomon,ssd1305-i2c" , - .data = &ssd130x_ssd1305_deviceinfo, + .data = (void *)SSD1305_ID , }, { .compatible ="solomon,ssd1306-i2c" , - .data = &ssd130x_ssd1306_deviceinfo, + .data = (void *)SSD1306_ID , }, { .compatible ="solomon,ssd1307-i2c" , - .data = &ssd130x_ssd1307_deviceinfo, + .data = (void *)SSD1307_ID , }, { .compatible ="solomon,ssd1309-i2c" , - .data = &ssd130x_ssd1309_deviceinfo, + .data = (void *)SSD1309_ID , },/* Deprecated but remain for backward compatibility */ { .compatible ="solomon,ssd1305fb-i2c" , - .data = &ssd130x_ssd1305_deviceinfo, + .data = (void *)SSD1305_ID , }, { .compatible ="solomon,ssd1306fb-i2c" , - .data = &ssd130x_ssd1306_deviceinfo, + .data = (void *)SSD1306_ID , }, { .compatible ="solomon,ssd1307fb-i2c" , - .data = &ssd130x_ssd1307_deviceinfo, + .data = (void *)SSD1307_ID , }, { .compatible ="solomon,ssd1309fb-i2c" , - .data = &ssd130x_ssd1309_deviceinfo, + .data = (void *)SSD1309_ID , }, {/* sentinel */ } };
drivers/gpu/drm/solomon/ssd130x.c +56 -4
86 lines not on this page · raw message
drivers/gpu/drm/solomon/ssd130x.h +13 -0
@@ -18,7 +18,20 @@#include <linux/regmap.h> +#define SSD130X_DATA 0x40 +#define SSD130X_COMMAND 0x80 + +enum ssd130x_variants { +SH1106_ID , +SSD1305_ID , +SSD1306_ID , +SSD1307_ID , +SSD1309_ID , +NR_SSD130X_VARIANTS +}; +struct ssd130x_deviceinfo { +enum ssd130x_variants variant;u32 default_vcomh;u32 default_dclk_div;u32 default_dclk_frq;
Signature · 1 line
2.35.1
Re: [PATCH 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
Hi,
Quoted 127 lines · Javier Martinez Canillas
These are declared in the ssd130x-i2c transport driver but the information is not I2C specific and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device into from an array.
While being there, also move the
SSD130X_DATAandSSD130X_COMMANDcontrol bytes. Since even though are used by the I2C interface, it could also be useful for other transport protocols such as SPI.Suggested-by Chen-Yu Tsai <[email protected]>Signed-off-by Javier Martinez Canillas <[email protected]>---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 51 ++++------------------- drivers/gpu/drm/solomon/ssd130x.c | 60 +++++++++++++++++++++++++-- drivers/gpu/drm/solomon/ssd130x.h | 13 ++++++ 3 files changed, 78 insertions(+), 46 deletions(-)drivers/gpu/drm/solomon/ssd130x-i2c.c +9
-42@@ -53,76 +53,43 @@ 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 , - .default_dclk_frq =7 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1306_deviceinfo = { - .default_vcomh =0x20 , - .default_dclk_div =1 , - .default_dclk_frq =8 , - .need_chargepump =1 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1307_deviceinfo = { - .default_vcomh =0x20 , - .default_dclk_div =2 , - .default_dclk_frq =12 , - .need_pwm =1 , -}; - -static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = { - .default_vcomh =0x34 , - .default_dclk_div =1 , - .default_dclk_frq =10 , -}; -static const struct of_device_id ssd130x_of_match[] = { { .compatible ="sinowealth,sh1106-i2c" , - .data = &ssd130x_sh1106_deviceinfo, + .data =SH1106_ID , }, { .compatible ="solomon,ssd1305-i2c" , - .data = &ssd130x_ssd1305_deviceinfo, + .data = (void *)SSD1305_ID , }, { .compatible ="solomon,ssd1306-i2c" , - .data = &ssd130x_ssd1306_deviceinfo, + .data = (void *)SSD1306_ID , }, { .compatible ="solomon,ssd1307-i2c" , - .data = &ssd130x_ssd1307_deviceinfo, + .data = (void *)SSD1307_ID , }, { .compatible ="solomon,ssd1309-i2c" , - .data = &ssd130x_ssd1309_deviceinfo, + .data = (void *)SSD1309_ID , },/* Deprecated but remain for backward compatibility */ { .compatible ="solomon,ssd1305fb-i2c" , - .data = &ssd130x_ssd1305_deviceinfo, + .data = (void *)SSD1305_ID , }, { .compatible ="solomon,ssd1306fb-i2c" , - .data = &ssd130x_ssd1306_deviceinfo, + .data = (void *)SSD1306_ID , }, { .compatible ="solomon,ssd1307fb-i2c" , - .data = &ssd130x_ssd1307_deviceinfo, + .data = (void *)SSD1307_ID , }, { .compatible ="solomon,ssd1309fb-i2c" , - .data = &ssd130x_ssd1309_deviceinfo, + .data = (void *)SSD1309_ID , }, {/* sentinel */ } };drivers/gpu/drm/solomon/ssd130x.c +1
-3@@ -39,11 +39,9 @@#define DRIVER_MAJOR 1#define DRIVER_MINOR 0 -#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
drivers/gpu/drm/solomon/ssd130x.c line 101
Quoted 10 lines
drivers/gpu/drm/solomon/ssd130x.c +7
-0@@ -94,6 +92,55 @@#define MAX_CONTRAST 255 +static struct ssd130x_deviceinfo ssd130x_variants[] = { + { + .default_vcomh =0x40 , + .default_dclk_div =1 , + .default_dclk_frq =5 , + .page_mode_only =1 , + },
Why not [SH1106_ID] = {
and later:
if (variant < NR_SSD130X_VARIANTS)
ssd130x->device_info = ssd130x_variants[variant];
instead of less efficient ssd13x_variant_to_info ?
Quoted 81 lines
drivers/gpu/drm/solomon/ssd130x.c +48
-1+ { + .variant = SSD1305_ID, + .default_vcomh = 0x34, + .default_dclk_div = 1, + .default_dclk_frq = 7, + }, + { + .variant = SSD1306_ID, + .default_vcomh = 0x20, + .default_dclk_div = 1, + .default_dclk_frq = 8, + .need_chargepump = 1, + }, + { + .variant = SSD1307_ID, + .default_vcomh = 0x20, + .default_dclk_div = 2, + .default_dclk_frq = 12, + .need_pwm = 1, + }, + { + .variant = SSD1309_ID, + .default_vcomh = 0x34, + .default_dclk_div = 1, + .default_dclk_frq = 10, + } +}; + +static const struct ssd130x_deviceinfo *ssd13x_variant_to_info(enum ssd130x_variants variant) +{ + int i; + const struct ssd130x_deviceinfo *info; + + for (i = 0; i < ARRAY_SIZE(ssd130x_variants); i++) { + info = &ssd130x_variants[i]; + if (info->variant == variant) + return info; + } + + return NULL; +} + static inline struct ssd130x_device *drm_to_ssd130x(struct drm_device *drm) { return container_of(drm, struct ssd130x_device, drm);@@ -846,6 +893,7 @@ static int ssd130x_get_resources(struct ssd130x_device *ssd130x)struct ssd130x_device *ssd130x_probe (struct device *dev,struct regmap *regmap) {struct ssd130x_device *ssd130x; +enum ssd130x_variants variant;struct backlight_device *bl;struct drm_device *drm;int ret;@@ -860,7 +908,11 @@ struct ssd130x_device *ssd130x_probe(struct device *dev, struct regmap *regmap) ssd130x->dev = dev; ssd130x->regmap = regmap; - ssd130x->device_info =device_get_match_data (dev); + + variant = (enum ssd130x_variants )device_get_match_data (dev); + ssd130x->device_info =ssd13x_variant_to_info (variant); +if (!ssd130x->device_info) +return ERR_PTR (-EINVAL );if (ssd130x->device_info->page_mode_only) ssd130x->page_address_mode =1 ;drivers/gpu/drm/solomon/ssd130x.h +7
-0@@ -18,7 +18,20 @@#include <linux/regmap.h> +#define SSD130X_DATA 0x40 +#define SSD130X_COMMAND 0x80 + +enum ssd130x_variants { +SH1106_ID , +SSD1305_ID , +SSD1306_ID ,
drivers/gpu/drm/solomon/ssd130x.h line 37
Quoted 10 lines
drivers/gpu/drm/solomon/ssd130x.h +6
-0+SSD1307_ID , +SSD1309_ID , +NR_SSD130X_VARIANTS +}; +struct ssd130x_deviceinfo { +enum ssd130x_variants variant;u32 default_vcomh;u32 default_dclk_div;u32 default_dclk_frq;
Neil
Javier Martinez Canillas
maintainerRe: [PATCH 4/5] drm/solomon: Move device info from ssd130x-i2c to the core driver
Hello Neil,
Thanks for your feedback.
On 4/8/22 09:49, Neil Armstrong wrote:
[snip]
Quoted 11 lines
drivers/gpu/drm/solomon/ssd130x.c line 101
Quoted 8 lines
drivers/gpu/drm/solomon/ssd130x.c +7
-0+static struct ssd130x_deviceinfo ssd130x_variants[] = { + { + .default_vcomh =0x40 , + .default_dclk_div =1 , + .default_dclk_frq =5 , + .page_mode_only =1 , + },Why not [
SH1106_ID] = {
Quoted 7 lines
and later:
if (variant <
NR_SSD130X_VARIANTS)ssd130x->device_info = ssd130x_variants[variant];instead of less efficient
ssd13x_variant_to_info?
Indeed. I'll change that in v2.
Signature · 5 lines
Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Javier Martinez Canillas
maintainerPATCH 5/5 drm/solomon: Add SSD130x OLED displays SPI support
In reply to Javier Martinez CanillasThe ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory.
But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data.
For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed.
---
drivers/gpu/drm/solomon/Kconfig | 9 ++ drivers/gpu/drm/solomon/Makefile | 1 + drivers/gpu/drm/solomon/ssd130x-spi.c | 184 ++++++++++++++++++++++++++ 3 files changed, 194 insertions(+) create mode 100644 drivers/gpu/drm/solomon/ssd130x-spi.c
drivers/gpu/drm/solomon/Kconfig +9 -0
@@ -20,3 +20,12 @@ config DRM_SSD130X_I2C I2C bus. If M is selected the module will be called ssd130x-i2c. + +config DRM_SSD130X_SPI + tristate "DRM support for Solomon SSD130X OLED displays (SPI bus)" + depends on DRM_SSD130X && SPI + select REGMAP + help + Say Y here if the SSD130x OLED display is connected via SPI bus. + + If M is selected the module will be called ssd130x-spi.
drivers/gpu/drm/solomon/Makefile +1 -0
@@ -1,2 +1,3 @@ obj-$(CONFIG_DRM_SSD130X) += ssd130x.o obj-$(CONFIG_DRM_SSD130X_I2C) += ssd130x-i2c.o +obj-$(CONFIG_DRM_SSD130X_SPI) += ssd130x-spi.o
drivers/gpu/drm/solomon/ssd130x-spi.c new file +184 -0
184 lines not on this page · raw message
Signature · 1 line
2.35.1
Quoted 8 lines · Javier Martinez Canillas
The ssd130x driver only provides the core support for these devices but it does not have any bus transport logic. Add a driver to interface over SPI.
There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory.
Quoted 5 lines
But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data.
For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed.