linux-toradex.git/drivers/video/fbdev/ssd1307fb.c, branch v5.5

video: ssd1307fb: Add devicetree configuration of display setup

2019-07-23T15:26:56+00:00

Various displays have differences that only mean initializing the display
driver IC with different fixed register values. Defining these in
devicetree offers easier way to adapt the driver to new displays than
requiring a patch to the kernel.

This adds devicetree properties needed to make the initialization match
the example setup as offered by Densitron for their 128x36 display.

It also makes some old one bit parameter handling a little cleaner.

Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
[b.zolnierkie: fix parenthesis alignment]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-7-marko.kohtala@okoko.fi

video: ssd1307fb: Handle width and height that are not multiple of 8

2019-07-23T15:18:19+00:00

Some displays have dimensions that are not multiple of eight, for example
height of 36, but the driver divided the dimensions by 8. Defining display
to the next multiple of 8 is not good as then the display registers get
configured to dimensions that do not match. This contradicts intructions
by some display manufacturers.

Use DIV_ROUND_UP to multiple of 8 when needed so correct values can be
used.

The ssd1307fb_update_display bit reordering receives a simplification in
the process.

Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-5-marko.kohtala@okoko.fi

video: ssd1307fb: Start page range at page_offset

2019-07-23T15:18:06+00:00

The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range display
expected.

Fixes: 301bc0675b67 ("video: ssd1307fb: Make use of horizontal addressing mode")
Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-4-marko.kohtala@okoko.fi

video: ssd1307fb: Remove unneeded semicolons

2019-07-23T15:17:53+00:00

coccicheck reported unneeded semicolons. Remove them.

Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-3-marko.kohtala@okoko.fi

video: ssd1307fb: Use screen_buffer instead of screen_base

2019-07-23T15:17:37+00:00

sparse reported incorrect type due to different address spaces.
The screen_base is __iomem, but the memory is not from a device so we can
use screen_buffer instead and avoid some type casts.

Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-2-marko.kohtala@okoko.fi

video: fbdev: don't print error message on framebuffer_alloc() failure

2019-06-28T10:30:08+00:00

framebuffer_alloc() can fail only on kzalloc() memory allocation
failure and since kzalloc() will print error message in such case
we can omit printing extra error message in drivers (which BTW is
what the majority of framebuffer_alloc() users is doing already).

Cc: "Bruno Prémont" 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Signed-off-by: Bartlomiej Zolnierkiewicz

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 71

2019-05-24T15:36:47+00:00

Based on 1 normalized pattern(s):

  licensed under the gplv2 or later

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 5 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Richard Fontana 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520071859.659568621@linutronix.de
Signed-off-by: Greg Kroah-Hartman

video: ssd1307fb: Do not hard code active-low reset sequence

2019-02-08T18:24:48+00:00

The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that users are forced to
define reset-gpios as GPIO_ACTIVE_HIGH in DT to make the reset work.

Do not hard code the active-low sequence into the driver but instead
allow the user to specify the gpio as GPIO_ACTIVE_LOW to reflect
the real world.

Reviewed-by: Rob Herring 
Reviewed-by: Alexandre Belloni 
Cc: Shawn Guo 
Cc: Fabio Estevam 
Cc: Maxime Ripard ,
Signed-off-by: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz

Revert "video: ssd1307fb: Do not hard code active-low reset sequence"

2018-10-09T13:18:42+00:00

This reverts commit 9827f26374fb85e1811f2adbcc25c8a3992dbe7f.

On 10/09/2018 02:20 AM, Shawn Guo wrote:

> Well, it means the change breaks the ABI between kernel and device tree,
> e.g. the new kernel will not work with existing/installed DTBs.

Revert the change until DTB compatibility issue is resolved.

Signed-off-by: Bartlomiej Zolnierkiewicz

video: ssd1307fb: Do not hard code active-low reset sequence

2018-10-08T10:57:37+00:00

The SSD130x OLED display reset signal is active low. Now the reset
sequence is implemented in such a way that users are forced to
define reset-gpios as GPIO_ACTIVE_HIGH in DT to make the reset work.

Do not hard code the active-low sequence into the driver but instead
allow the user to specify the gpio as GPIO_ACTIVE_LOW to reflect
the real world.

Signed-off-by: Michal Vokáč 
Cc: Shawn Guo 
Cc: Rob Herring 
Signed-off-by: Bartlomiej Zolnierkiewicz