Re: [PATCHv6 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
On Tue, Mar 31, 2015 at 08:27:10PM +0200, Thomas Niederprüm wrote: > The 130X controllers are very similar from the configuration point of view. > The configuration registers for the SSD1305/6/7 are bit identical (except the > the VHCOM register and the the default values for clock setup register). This > patch unifies the init code of the controller and adds hardware specific > properties to DT that are needed to correctly initialize the device. > > The SSD130X can be wired to the OLED panel in various ways. Even for the > same controller this wiring can differ from one display module to another > and can not be probed by software. The added DT properties reflect these > hardware decisions of the display module manufacturer. > The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different > possibilities for the COM signals pin configuration and readout direction > of the video memory. The 'segment-no-remap' allows the inversion of the > memory-to-pin mapping ultimately inverting the order of the controllers > output pins. The 'prechargepX' values need to be adapted according to the > capacitance of the OLEDs pixel cells. > > So far these hardware specific bits are hard coded in the init code, making > the driver usable only for one certain wiring of the controller. This patch > makes the driver usable with all possible hardware setups, given a valid hw > description in DT. If these values are not set in DT the default values, > as they are set in the ssd1307 init code right now, are used. This implies > that without the corresponding DT property "segment-no-remap" the segment > remap of the ssd130X controller gets activated. Even though this is not the > default behaviour according to the datasheet it maintains backward > compatibility with older DTBs. > > Note that the SSD1306 does not seem to be using the configuration written to > the registers at all. Therefore this patch does not try to maintain these > values without changes in DT. For reference an example is added to the DT > bindings documentation that reproduces the configuration that is set in the > current init code. > > Signed-off-by: Thomas Niederprüm > Tested-by: Olliver Schinagl Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCHv6 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
On Tue, Mar 31, 2015 at 08:27:10PM +0200, Thomas Niederprüm wrote: The 130X controllers are very similar from the configuration point of view. The configuration registers for the SSD1305/6/7 are bit identical (except the the VHCOM register and the the default values for clock setup register). This patch unifies the init code of the controller and adds hardware specific properties to DT that are needed to correctly initialize the device. The SSD130X can be wired to the OLED panel in various ways. Even for the same controller this wiring can differ from one display module to another and can not be probed by software. The added DT properties reflect these hardware decisions of the display module manufacturer. The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different possibilities for the COM signals pin configuration and readout direction of the video memory. The 'segment-no-remap' allows the inversion of the memory-to-pin mapping ultimately inverting the order of the controllers output pins. The 'prechargepX' values need to be adapted according to the capacitance of the OLEDs pixel cells. So far these hardware specific bits are hard coded in the init code, making the driver usable only for one certain wiring of the controller. This patch makes the driver usable with all possible hardware setups, given a valid hw description in DT. If these values are not set in DT the default values, as they are set in the ssd1307 init code right now, are used. This implies that without the corresponding DT property segment-no-remap the segment remap of the ssd130X controller gets activated. Even though this is not the default behaviour according to the datasheet it maintains backward compatibility with older DTBs. Note that the SSD1306 does not seem to be using the configuration written to the registers at all. Therefore this patch does not try to maintain these values without changes in DT. For reference an example is added to the DT bindings documentation that reproduces the configuration that is set in the current init code. Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de Tested-by: Olliver Schinagl o.schin...@ultimaker.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCHv6 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
The 130X controllers are very similar from the configuration point of view.
The configuration registers for the SSD1305/6/7 are bit identical (except the
the VHCOM register and the the default values for clock setup register). This
patch unifies the init code of the controller and adds hardware specific
properties to DT that are needed to correctly initialize the device.
The SSD130X can be wired to the OLED panel in various ways. Even for the
same controller this wiring can differ from one display module to another
and can not be probed by software. The added DT properties reflect these
hardware decisions of the display module manufacturer.
The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different
possibilities for the COM signals pin configuration and readout direction
of the video memory. The 'segment-no-remap' allows the inversion of the
memory-to-pin mapping ultimately inverting the order of the controllers
output pins. The 'prechargepX' values need to be adapted according to the
capacitance of the OLEDs pixel cells.
So far these hardware specific bits are hard coded in the init code, making
the driver usable only for one certain wiring of the controller. This patch
makes the driver usable with all possible hardware setups, given a valid hw
description in DT. If these values are not set in DT the default values,
as they are set in the ssd1307 init code right now, are used. This implies
that without the corresponding DT property "segment-no-remap" the segment
remap of the ssd130X controller gets activated. Even though this is not the
default behaviour according to the datasheet it maintains backward
compatibility with older DTBs.
Note that the SSD1306 does not seem to be using the configuration written to
the registers at all. Therefore this patch does not try to maintain these
values without changes in DT. For reference an example is added to the DT
bindings documentation that reproduces the configuration that is set in the
current init code.
Signed-off-by: Thomas Niederprüm
Tested-by: Olliver Schinagl
---
.../devicetree/bindings/video/ssd1307fb.txt| 21 +++
drivers/video/fbdev/ssd1307fb.c| 177 -
2 files changed, 125 insertions(+), 73 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 7a12542..635efa3 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -15,6 +15,16 @@ Required properties:
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
+ - solomon,segment-no-remap: Display needs normal (non-inverted) data column
+ to segment mapping
+ - solomon,com-seq: Display uses sequential COM pin configuration
+ - solomon,com-lrremap: Display uses left-right COM pin remap
+ - solomon,com-invdir: Display uses inverted COM pin scan direction
+ - solomon,com-offset: Number of the COM pin wired to the first display line
+ - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles.
+ - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
+ This needs to be the higher, the higher the
capacitance
+ of the OLED's pixels is
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -26,3 +36,14 @@ ssd1307: oled@3c {
reset-gpios = < 7>;
reset-active-low;
};
+
+ssd1306: oled@3c {
+compatible = "solomon,ssd1306fb-i2c";
+reg = <0x3c>;
+pwms = < 4 3000>;
+reset-gpios = < 7>;
+reset-active-low;
+solomon,com-lrremap;
+solomon,com-invdir;
+solomon,com-offset = <32>;
+};
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8d34c56..8667c77 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -40,20 +40,34 @@
struct ssd1307fb_par;
-struct ssd1307fb_ops {
- int (*init)(struct ssd1307fb_par *);
- int (*remove)(struct ssd1307fb_par *);
+struct ssd1307fb_deviceinfo {
+ u32 default_vcomh;
+ u32 default_dclk_div;
+ u32 default_dclk_frq;
+ int need_pwm;
+ int need_chargepump;
};
struct ssd1307fb_par {
+ u32 com_invdir;
+ u32 com_lrremap;
+ u32 com_offset;
+ u32 com_seq;
+ u32 contrast;
+ u32 dclk_div;
+ u32 dclk_frq;
+ struct ssd1307fb_deviceinfo *device_info;
struct i2c_client *client;
u32 height;
struct fb_info *info;
- struct ssd1307fb_ops *ops;
u32 page_offset;
+ u32 prechargep1;
+ u32 prechargep2;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 seg_remap;
+ u32 vcomh;
u32 width;
};
@@ -254,69 +268,46 @@ static struct fb_deferred_io ssd1307fb_defio = {
.deferred_io=
[PATCHv6 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
The 130X controllers are very similar from the configuration point of view.
The configuration registers for the SSD1305/6/7 are bit identical (except the
the VHCOM register and the the default values for clock setup register). This
patch unifies the init code of the controller and adds hardware specific
properties to DT that are needed to correctly initialize the device.
The SSD130X can be wired to the OLED panel in various ways. Even for the
same controller this wiring can differ from one display module to another
and can not be probed by software. The added DT properties reflect these
hardware decisions of the display module manufacturer.
The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different
possibilities for the COM signals pin configuration and readout direction
of the video memory. The 'segment-no-remap' allows the inversion of the
memory-to-pin mapping ultimately inverting the order of the controllers
output pins. The 'prechargepX' values need to be adapted according to the
capacitance of the OLEDs pixel cells.
So far these hardware specific bits are hard coded in the init code, making
the driver usable only for one certain wiring of the controller. This patch
makes the driver usable with all possible hardware setups, given a valid hw
description in DT. If these values are not set in DT the default values,
as they are set in the ssd1307 init code right now, are used. This implies
that without the corresponding DT property segment-no-remap the segment
remap of the ssd130X controller gets activated. Even though this is not the
default behaviour according to the datasheet it maintains backward
compatibility with older DTBs.
Note that the SSD1306 does not seem to be using the configuration written to
the registers at all. Therefore this patch does not try to maintain these
values without changes in DT. For reference an example is added to the DT
bindings documentation that reproduces the configuration that is set in the
current init code.
Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de
Tested-by: Olliver Schinagl o.schin...@ultimaker.com
---
.../devicetree/bindings/video/ssd1307fb.txt| 21 +++
drivers/video/fbdev/ssd1307fb.c| 177 -
2 files changed, 125 insertions(+), 73 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 7a12542..635efa3 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -15,6 +15,16 @@ Required properties:
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
+ - solomon,segment-no-remap: Display needs normal (non-inverted) data column
+ to segment mapping
+ - solomon,com-seq: Display uses sequential COM pin configuration
+ - solomon,com-lrremap: Display uses left-right COM pin remap
+ - solomon,com-invdir: Display uses inverted COM pin scan direction
+ - solomon,com-offset: Number of the COM pin wired to the first display line
+ - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles.
+ - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
+ This needs to be the higher, the higher the
capacitance
+ of the OLED's pixels is
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -26,3 +36,14 @@ ssd1307: oled@3c {
reset-gpios = gpio2 7;
reset-active-low;
};
+
+ssd1306: oled@3c {
+compatible = solomon,ssd1306fb-i2c;
+reg = 0x3c;
+pwms = pwm 4 3000;
+reset-gpios = gpio2 7;
+reset-active-low;
+solomon,com-lrremap;
+solomon,com-invdir;
+solomon,com-offset = 32;
+};
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8d34c56..8667c77 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -40,20 +40,34 @@
struct ssd1307fb_par;
-struct ssd1307fb_ops {
- int (*init)(struct ssd1307fb_par *);
- int (*remove)(struct ssd1307fb_par *);
+struct ssd1307fb_deviceinfo {
+ u32 default_vcomh;
+ u32 default_dclk_div;
+ u32 default_dclk_frq;
+ int need_pwm;
+ int need_chargepump;
};
struct ssd1307fb_par {
+ u32 com_invdir;
+ u32 com_lrremap;
+ u32 com_offset;
+ u32 com_seq;
+ u32 contrast;
+ u32 dclk_div;
+ u32 dclk_frq;
+ struct ssd1307fb_deviceinfo *device_info;
struct i2c_client *client;
u32 height;
struct fb_info *info;
- struct ssd1307fb_ops *ops;
u32 page_offset;
+ u32 prechargep1;
+ u32 prechargep2;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 seg_remap;
+ u32 vcomh;
u32 width;
};
@@ -254,69 +268,46 @@ static struct fb_deferred_io
