* fbdev libraries
From: Ssagarr Patil @ 2015-01-07 20:50 UTC (permalink / raw)
To: linux-fbdev
Hi,
Are there any libraries/tools to test monochrome oleds which of which the driver is based on linux framebuffer framework.
Thanks,
Sagar
^ permalink raw reply
* Re: fbdev libraries
From: Geert Uytterhoeven @ 2015-01-08 7:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W48BA5EF24A525D43465BBED3460@phx.gbl>
On Wed, Jan 7, 2015 at 9:50 PM, Ssagarr Patil <hugarsagar@outlook.com> wrote:
> Are there any libraries/tools to test monochrome oleds which of which the driver is based on linux framebuffer framework.
https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply
* [PATCH 0/2] fbdev: ssd1307fb: fixes
From: Lad, Prabhakar @ 2015-01-08 8:17 UTC (permalink / raw)
To: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Maxime Ripard
Cc: LKML, Lad, Prabhakar
This patch series fixes trivial issues in ssd1307fb driver.
Lad, Prabhakar (2):
fbdev: ssd1307fb: set default height if not found in DT node
fbdev: ssd1307fb: check return value while setting offset
drivers/video/fbdev/ssd1307fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] fbdev: ssd1307fb: set default height if not found in DT node
From: Lad, Prabhakar @ 2015-01-08 8:17 UTC (permalink / raw)
To: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Maxime Ripard
Cc: LKML, Lad, Prabhakar
In-Reply-To: <1420705079-3741-1-git-send-email-prabhakar.csengg@gmail.com>
this patch sets the default height if its not found in DT.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index f4daa59..70e3ce8 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -460,7 +460,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
par->width = 96;
if (of_property_read_u32(node, "solomon,height", &par->height))
- par->width = 16;
+ par->height = 16;
if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
par->page_offset = 1;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Lad, Prabhakar @ 2015-01-08 8:17 UTC (permalink / raw)
To: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Maxime Ripard
Cc: LKML, Lad, Prabhakar
In-Reply-To: <1420705079-3741-1-git-send-email-prabhakar.csengg@gmail.com>
this patch checks the return value of write command while
setting the display offset.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 70e3ce8..a7ecaa6 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -342,7 +342,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
/* set display offset value */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
- ret = ssd1307fb_write_cmd(par->client, 0x20);
+ ret = ret & ssd1307fb_write_cmd(par->client, 0x20);
if (ret < 0)
return ret;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: ssd1307fb: set default height if not found in DT node
From: Maxime Ripard @ 2015-01-08 9:31 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen, LKML
In-Reply-To: <1420705079-3741-2-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
On Thu, Jan 08, 2015 at 08:17:58AM +0000, Lad, Prabhakar wrote:
> this patch sets the default height if its not found in DT.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Maxime Ripard @ 2015-01-08 9:32 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen, LKML
In-Reply-To: <1420705079-3741-3-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Thu, Jan 08, 2015 at 08:17:59AM +0000, Lad, Prabhakar wrote:
> this patch checks the return value of write command while
> setting the display offset.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2015-01-08 9:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Tue, Jan 06, 2015 at 06:30:01PM +0530, Ssagarr Patil wrote:
> > It's probably even easier with SPI. Have you considered reading
> > include/spi/spi.h?
> >
> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
You can't use it like that. It's a standard framebuffer, that is
represented as an array of pixels, so you need to use a font rendering
software if you want to output some text.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-08 18:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Maxim,
>>>
>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>
> You can't use it like that. It's a standard framebuffer, that is
> represented as an array of pixels, so you need to use a font rendering
> software if you want to output some text.
>
can fbtest (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/) be used to to draw something ?
Thanks And Regards,
Sagar
^ permalink raw reply
* Re: [PATCH v10 3/6] devicetree: mfd: Add new SKY81452 mfd binding
From: Gyungoh Yoo @ 2015-01-09 1:30 UTC (permalink / raw)
To: sameo-VuQAYsv1563Yd54FQh9/CA, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, jg1.han-Sze3O3UU22JBDgjK7y7TUQ,
cooloney-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, trivial-DgEjT+Ai2ygdnm+yROfE0A
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
jic23-DgEjT+Ai2ygdnm+yROfE0A,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
ktsai-GubuWUlQtMwciDkP5Hr2oA, hs-ynQEQJNshbs,
stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ,
matti.vaittinen-OYasijW0DpE, broonie-DgEjT+Ai2ygdnm+yROfE0A,
jason-NLaQJdtUoK4Be96aLqz0jA, heiko-4mtYJXux2i+zQB+pC5nmwQ,
shawn.guo-KZfg59tc24xl57MIdRCFDg, florian.vaussard-p8DiymsW2f8,
andrew-g2DYL2Zd6BY, antonynpavlov-Re5JQEeQqe8AvxtiuMwx3w,
hytszk-Re5JQEeQqe8AvxtiuMwx3w, plagnioj-sclMFOaUSTBWk0Htik3J/w,
tomi.valkeinen-l0cyMroinI0, jack.yoo-tjhQNA90jdKqndwCJWfcng,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420597167-3188-4-git-send-email-jack.yoo-tjhQNA90jdKqndwCJWfcng@public.gmane.org>
DT Ack please.
On Wed, Jan 07, 2015 at 11:19:24AM +0900, gyungoh@gmail.com wrote:
> From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
>
> Signed-off-by: Gyungoh Yoo <jack.yoo@skyworksinc.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
> Changes v10:
> Nothing
>
> Changes v9:
> Nothing
>
> Changes v8:
> Made up the example for backlight DT
>
> Changes v7:
> Nothing
>
> Changes v6:
> Nothing
>
> Changes v5:
> Changed DT for regulator : 'lout' node should be defined under 'regulator'
> Removed compatible string from sky81452-regulator driver
>
> Changes v4:
> Nothing
>
> Changes v3:
> Nothing
>
> Changes v2:
> Added reg attribute for I2C slave address
>
> Documentation/devicetree/bindings/mfd/sky81452.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt b/Documentation/devicetree/bindings/mfd/sky81452.txt
> new file mode 100644
> index 0000000..ab71473
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
> @@ -0,0 +1,36 @@
> +SKY81452 bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452"
> +- reg : I2C slave address
> +
> +Required child nodes:
> +- backlight : container node for backlight following the binding
> + in video/backlight/sky81452-backlight.txt
> +- regulator : container node for regulators following the binding
> + in regulator/sky81452-regulator.txt
> +
> +Example:
> +
> + sky81452@2c {
> + compatible = "skyworks,sky81452";
> + reg = <0x2c>;
> +
> + backlight {
> + compatible = "skyworks,sky81452-backlight";
> + name = "pwm-backlight";
> + skyworks,en-channels = <0x3f>;
> + skyworks,ignore-pwm;
> + skyworks,phase-shift;
> + skyworks,ovp-level = <20>;
> + skyworks,current-limit = <2300>;
> + };
> +
> + regulator {
> + lout {
> + regulator-name = "sky81452-lout";
> + regulator-min-microvolt = <4500000>;
> + regulator-max-microvolt = <8000000>;
> + };
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v10 4/6] devicetree: backlight: Add new SKY81452 backlight binding
From: Gyungoh Yoo @ 2015-01-09 1:31 UTC (permalink / raw)
To: sameo, lee.jones, grant.likely, robh+dt, jg1.han, cooloney,
pawel.moll, mark.rutland, ijc+devicetree, galak, trivial
Cc: akpm, jic23, thomas.petazzoni, ktsai, hs, stwiss.opensource,
matti.vaittinen, broonie, jason, heiko, shawn.guo,
florian.vaussard, andrew, antonynpavlov, hytszk, plagnioj,
tomi.valkeinen, jack.yoo, linux-fbdev, linux-kernel, devicetree
In-Reply-To: <1420597167-3188-5-git-send-email-jack.yoo@skyworksinc.com>
DT Ack please.
On Wed, Jan 07, 2015 at 11:19:25AM +0900, gyungoh@gmail.com wrote:
> From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
>
> Signed-off-by: Gyungoh Yoo <jack.yoo@skyworksinc.com>
> Acked-by: Bryan Wu <cooloney@gmail.com>
> ---
> Changes v10:
> Nothing
>
> Changes v9:
> Nothing
>
> Changes v8:
> Renamed property names for backlight with vendor prefix
> Modified gpio-enable property to generic property for GPIO
> Made up the example for backlight DT
>
> Changes v7:
> Nothing
>
> Changes v6:
> Nothing
>
> Changes v5:
> Nothing
>
> Changes v4:
> Nothing
>
> Changes v3:
> Nothing
>
> Changes v2:
> Added reg attribute for I2C slave address
>
> .../video/backlight/sky81452-backlight.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> new file mode 100644
> index 0000000..8daebf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> @@ -0,0 +1,29 @@
> +SKY81452-backlight bindings
> +
> +Required properties:
> +- compatible : Must be "skyworks,sky81452-backlight"
> +
> +Optional properties:
> +- name : Name of backlight device. Default is 'lcd-backlight'.
> +- gpios : GPIO to use to EN pin.
> + See Documentation/devicetree/bindings/gpio/gpio.txt
> +- skyworks,en-channels : Enable mask for current sink channel 1 to 6.
> +- skyworks,ignore-pwm : Ignore both PWM input
> +- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming.
> +- skyworks,phase-shift : Enable phase shift mode
> +- skyworks,ovp-level : Over-voltage protection level.
> + Should be between 14 or 28V.
> +- skyworks,short-detection-threshold : It should be one of 4, 5, 6 and 7V.
> +- skyworks,current-limit : It should be 2300mA or 2750mA.
> +
> +Example:
> +
> + backlight {
> + compatible = "skyworks,sky81452-backlight";
> + name = "pwm-backlight";
> + skyworks,en-channels = <0x3f>;
> + skyworks,ignore-pwm;
> + skyworks,phase-shift;
> + skyworks,ovp-level = <20>;
> + skyworks,current-limit = <2300>;
> + };
> --
> 1.9.1
>
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-09 10:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Maxime,
>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>
>> You can't use it like that. It's a standard framebuffer, that is
>> represented as an array of pixels, so you need to use a font rendering
>> software if you want to output some text.
>>
> can fbtest (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/) be used to to draw something ?
>
how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
Thanks And Regards,
Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2015-01-09 11:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
>
> Hi Maxime,
>
> >>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> >>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
> >>
> >> You can't use it like that. It's a standard framebuffer, that is
> >> represented as an array of pixels, so you need to use a font rendering
> >> software if you want to output some text.
> >>
> > can fbtest
> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> > be used to to draw something ?
> >
> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
Last time I tried, fbtest didn't support monochrome display.
And you'll find anything you need in the documentation.
https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
>
> Thanks And Regards,
> Sagar
>
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-09 12:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Maxime,
Thanks for your response!
> On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
>>
>> Hi Maxime,
>>
>>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>>>
>>>> You can't use it like that. It's a standard framebuffer, that is
>>>> represented as an array of pixels, so you need to use a font rendering
>>>> software if you want to output some text.
>>>>
>>> can fbtest
>>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>>> be used to to draw something ?
>>>
>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>
> Last time I tried, fbtest didn't support monochrome display.
>
> And you'll find anything you need in the documentation.
> https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
>
In my case I see that init is done but I dont see any pixels on the screen at all.
I am now concerned if the driver was tested in first place ?
Thanks And Regards,
Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Geert Uytterhoeven @ 2015-01-09 13:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Maxime,
On Fri, Jan 9, 2015 at 12:03 PM, maxime.ripard@free-electrons.com
<maxime.ripard@free-electrons.com> wrote:
>> > can fbtest
>> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>> > be used to to draw something ?
>> >
>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>
> Last time I tried, fbtest didn't support monochrome display.
Really?
On ARAnyM:
atari:~# fbset -i
mode "640x480-60"
# D: 25.176 MHz, H: 31.470 kHz, V: 59.943 Hz
geometry 640 480 640 972 1
timings 39720 42 18 31 11 100 3
rgba 1/0,1/0,1/0,0/0
endmode
Frame buffer device information:
Name : Atari Builtin
Address : 0x67a000
Size : 311296
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 32
YPanStep : 1
YWrapStep : 0
LineLength : 80
Accelerator : Atari Blitter
atari:~# ./m68k-linux-gnu-fbtest
Using drawops planar (monochrome and (interleaved) bitplanes)
Available visuals:
Monochrome
Grayscale 2
Pseudocolor 2
Using visops pseudocolor
Running all tests
test001: PASSED
test002: PASSED
test004: PASSED
test005: PASSED
test006: PASSED
test009: PASSED
test011: PASSED
Benchmarking... 10x10 squares: 17.25 Mpixels/s
Benchmarking... 20x20 squares: 40.96 Mpixels/s
Benchmarking... 50x50 squares: 102.41 Mpixels/s
Benchmarking... 100x100 squares: 195.06 Mpixels/s
Benchmarking... 200x200 squares: 348.61 Mpixels/s
Benchmarking... 500x500 squares: 742.07 Mpixels/s
test012: PASSED
Benchmarking... triangles of max size 10: 139444.38 triangles/s
Benchmarking... triangles of max size 20: 107443.29 triangles/s
Benchmarking... triangles of max size 50: 71237.96 triangles/s
Benchmarking... triangles of max size 100: 40962.10 triangles/s
Benchmarking... triangles of max size 200: 23407.09 triangles/s
Benchmarking... triangles of max size 500: 9102.64 triangles/s
test013: PASSED
atari:~#
And the result did look good ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2015-01-09 22:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
On Fri, Jan 09, 2015 at 02:58:16PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Fri, Jan 9, 2015 at 12:03 PM, maxime.ripard@free-electrons.com
> <maxime.ripard@free-electrons.com> wrote:
> >> > can fbtest
> >> > (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> >> > be used to to draw something ?
> >> >
> >> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
> >
> > Last time I tried, fbtest didn't support monochrome display.
>
> Really?
>
> On ARAnyM:
>
> atari:~# fbset -i
>
> mode "640x480-60"
> # D: 25.176 MHz, H: 31.470 kHz, V: 59.943 Hz
> geometry 640 480 640 972 1
> timings 39720 42 18 31 11 100 3
> rgba 1/0,1/0,1/0,0/0
> endmode
>
> Frame buffer device information:
> Name : Atari Builtin
> Address : 0x67a000
> Size : 311296
> Type : PACKED PIXELS
> Visual : PSEUDOCOLOR
> XPanStep : 32
> YPanStep : 1
> YWrapStep : 0
> LineLength : 80
> Accelerator : Atari Blitter
> atari:~# ./m68k-linux-gnu-fbtest
> Using drawops planar (monochrome and (interleaved) bitplanes)
> Available visuals:
> Monochrome
> Grayscale 2
> Pseudocolor 2
> Using visops pseudocolor
> Running all tests
> test001: PASSED
> test002: PASSED
> test004: PASSED
> test005: PASSED
> test006: PASSED
> test009: PASSED
> test011: PASSED
> Benchmarking... 10x10 squares: 17.25 Mpixels/s
> Benchmarking... 20x20 squares: 40.96 Mpixels/s
> Benchmarking... 50x50 squares: 102.41 Mpixels/s
> Benchmarking... 100x100 squares: 195.06 Mpixels/s
> Benchmarking... 200x200 squares: 348.61 Mpixels/s
> Benchmarking... 500x500 squares: 742.07 Mpixels/s
> test012: PASSED
> Benchmarking... triangles of max size 10: 139444.38 triangles/s
> Benchmarking... triangles of max size 20: 107443.29 triangles/s
> Benchmarking... triangles of max size 50: 71237.96 triangles/s
> Benchmarking... triangles of max size 100: 40962.10 triangles/s
> Benchmarking... triangles of max size 200: 23407.09 triangles/s
> Benchmarking... triangles of max size 500: 9102.64 triangles/s
> test013: PASSED
> atari:~#
>
> And the result did look good ;-)
Ah, good to know :)
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2015-01-09 22:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Fri, Jan 09, 2015 at 06:13:43PM +0530, Ssagarr Patil wrote:
> Hi Maxime,
>
> Thanks for your response!
>
> > On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
> >>
> >> Hi Maxime,
> >>
> >>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
> >>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
> >>>>
> >>>> You can't use it like that. It's a standard framebuffer, that is
> >>>> represented as an array of pixels, so you need to use a font rendering
> >>>> software if you want to output some text.
> >>>>
> >>> can fbtest
> >>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
> >>> be used to to draw something ?
> >>>
> >> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
> >
> > Last time I tried, fbtest didn't support monochrome display.
> >
> > And you'll find anything you need in the documentation.
> > https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
> >
>
> In my case I see that init is done but I dont see any pixels on the
> screen at all.
>
> I am now concerned if the driver was tested in first place ?
No. I just submitted some good looking code that never ever got
tested.
More seriously, There's a few thing that comes to my mind:
- Your controller doesn't behave the same way than the ones already
supported.
- You haven't posted your changes yet, so maybe you're not doing the
transfers right
- Your SPI controller is doing something weird
What happens if you plug a logical analyzer on the bus?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-10 0:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 09.01.2015 23:31, skrev maxime.ripard@free-electrons.com:
> On Fri, Jan 09, 2015 at 06:13:43PM +0530, Ssagarr Patil wrote:
>> Hi Maxime,
>>
>> Thanks for your response!
>>
>>> On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
>>>> Hi Maxime,
>>>>
>>>>>>> Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
>>>>>>> but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
>>>>>> You can't use it like that. It's a standard framebuffer, that is
>>>>>> represented as an array of pixels, so you need to use a font rendering
>>>>>> software if you want to output some text.
>>>>>>
>>>>> can fbtest
>>>>> (https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
>>>>> be used to to draw something ?
>>>>>
>>>> how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
>>> Last time I tried, fbtest didn't support monochrome display.
>>>
>>> And you'll find anything you need in the documentation.
>>> https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
>>>
>> In my case I see that init is done but I dont see any pixels on the
>> screen at all.
>>
>> I am now concerned if the driver was tested in first place ?
> No. I just submitted some good looking code that never ever got
> tested.
>
> More seriously, There's a few thing that comes to my mind:
> - Your controller doesn't behave the same way than the ones already
> supported.
> - You haven't posted your changes yet, so maybe you're not doing the
> transfers right
> - Your SPI controller is doing something weird
>
> What happens if you plug a logical analyzer on the bus?
>
> Maxime
>
Hi,
The major difference between the SSD1306 SPI and I2C interfaces, is that
SPI uses a D/C pin to signal whether it's data or command coming in.
Looking at ssd1307fb, this Data/Command info is embedded as the first
byte in the i2c package/message.
Without looking up the datasheet, I would guess that this is the only
difference, the way the D/C bit is handled.
The rest of the package payload should be the same.
So:
dc=0, spi write command
dc=1, spi write data (optional)
Apart from that, I have SSD1306 SPI support in a project of mine:
This is the part writing the framebuffer:
https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
This writes commands (for many controllers):
https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
This is the SPI specific part:
https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
Project wiki: https://github.com/notro/fbtft/wiki
The code isn't particularly pretty, it was my first venture into the kernel.
It has recently been submitted for the staging tree:
https://github.com/notro/fbtft/issues/161#issuecomment-68431405
I'm currently rewriting the project armed with better knowledge of the
kernel and the various LCD controllers.
I haven't done the SSD1306 controller yet, but the principle is almost
the same for all these MIPI DBI like controllers.
The major difference is that it's monochrome and has a different
register map.
In my rewrite I have made an abstraction for the LCD register:
https://github.com/notro/fbdbi/blob/master/core/lcdreg.h#L46
SPI part matching several controller variations:
https://github.com/notro/fbdbi/blob/master/core/lcdreg-spi.c
In case you wonder: In my code I set the the window where the update is
to take place every time, whereas ssd1307fb does this only once in init.
I do this because controllers supporting higher resolutions can be sped
up using partial updates (set_addr_win).
Regards,
Noralf Trønnes
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-10 12:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
>>>
>>> I am now concerned if the driver was tested in first place ?
>> No. I just submitted some good looking code that never ever got
>> tested.
>>
>> More seriously, There's a few thing that comes to my mind:
>> - Your controller doesn't behave the same way than the ones already
>> supported.
>> - You haven't posted your changes yet, so maybe you're not doing the
>> transfers right
>> - Your SPI controller is doing something weird
>>
>> What happens if you plug a logical analyzer on the bus?
>>
>> Maxime
>>
> Hi,
>
> The major difference between the SSD1306 SPI and I2C interfaces, is that
> SPI uses a D/C pin to signal whether it's data or command coming in.
> Looking at ssd1307fb, this Data/Command info is embedded as the first
> byte in the i2c package/message.
> Without looking up the datasheet, I would guess that this is the only
> difference, the way the D/C bit is handled.
> The rest of the package payload should be the same.
> So:
> dc=0, spi write command
> dc=1, spi write data (optional)
>
I was working on ssd1306 itself.
>
> Apart from that, I have SSD1306 SPI support in a project of mine:
>
> This is the part writing the framebuffer:
> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
> This writes commands (for many controllers):
> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
> This is the SPI specific part:
> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
> Project wiki: https://github.com/notro/fbtft/wiki
>
Thanks for the pointers that was really helpful.
just a quick help the dc pin should be a gpio and be set as output pin
to control D/C ?
in my case for ssd1306 needs to be added as slave device in
board file since I dont have DT.
> The code isn't particularly pretty, it was my first venture into the kernel.
> It has recently been submitted for the staging tree:
> https://github.com/notro/fbtft/issues/161#issuecomment-68431405
>
hope it gets accepted soon.
Thanks,
--Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-10 13:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 10.01.2015 13:34, skrev Ssagarr Patil:
> Hi Noralf,
>
>>>> I am now concerned if the driver was tested in first place ?
>>> No. I just submitted some good looking code that never ever got
>>> tested.
>>>
>>> More seriously, There's a few thing that comes to my mind:
>>> - Your controller doesn't behave the same way than the ones already
>>> supported.
>>> - You haven't posted your changes yet, so maybe you're not doing the
>>> transfers right
>>> - Your SPI controller is doing something weird
>>>
>>> What happens if you plug a logical analyzer on the bus?
>>>
>>> Maxime
>>>
>> Hi,
>>
>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>> SPI uses a D/C pin to signal whether it's data or command coming in.
>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>> byte in the i2c package/message.
>> Without looking up the datasheet, I would guess that this is the only
>> difference, the way the D/C bit is handled.
>> The rest of the package payload should be the same.
>> So:
>> dc=0, spi write command
>> dc=1, spi write data (optional)
>>
> I was working on ssd1306 itself.
>
>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>
>> This is the part writing the framebuffer:
>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>> This writes commands (for many controllers):
>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>> This is the SPI specific part:
>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>> Project wiki: https://github.com/notro/fbtft/wiki
>>
> Thanks for the pointers that was really helpful.
>
> just a quick help the dc pin should be a gpio and be set as output pin
> to control D/C ?
Correct.
^ permalink raw reply
* Re: [PATCH v4 0/3] omapdss: Add video output support for gta04
From: Belisko Marek @ 2015-01-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1417642402-20538-1-git-send-email-marek@goldelico.com>
Tomi can you please pick up this series for 3.20 release? Thanks
On Wed, Dec 3, 2014 at 10:33 PM, Marek Belisko <marek@goldelico.com> wrote:
> changes from v3:
> - use GPL v2 instead GPL
> - fix wrong gpios property name in doc and DT
> - set gpio to NULL if invalid
> - drop unnecessary header
>
> changes from v2:
> - rename amplifier-opa362.c to encoder-opa362
> - drop inversion handlign from driver
> - add ti,invert-polarity to venc node
>
> I also drop devconf1 handling patches because discussion how to
> properly implement is not yet finished and this part is independent
> from video driver.
>
> changes from v1:
> - fix opa362 compilation error
> - fix opa362 DT documentation
> - move devconf1 definition to omap3.dtsi
> Marek Belisko (3):
> video: omapdss: Add opa362 driver
> Documentation: DT: Add documentation for ti,opa362 bindings
> arm: dts: omap3-gta04: Add handling for tv output
>
> .../devicetree/bindings/video/ti,opa362.txt | 38 +++
> arch/arm/boot/dts/omap3-gta04.dtsi | 49 ++++
> drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
> drivers/video/fbdev/omap2/displays-new/Makefile | 1 +
> .../fbdev/omap2/displays-new/encoder-opa362.c | 285 +++++++++++++++++++++
> 5 files changed, 379 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt
> create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
>
> --
> 1.9.1
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-10 21:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
> Date: Sat, 10 Jan 2015 14:50:09 +0100
> From: notro@tronnes.org
> To: hugarsagar@outlook.com
> CC: linux-fbdev@vger.kernel.org
> Subject: Re: SSD1306 OLED driver
>
> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>> Hi Noralf,
>>
>>>>> I am now concerned if the driver was tested in first place ?
>>>> No. I just submitted some good looking code that never ever got
>>>> tested.
>>>>
>>>> More seriously, There's a few thing that comes to my mind:
>>>> - Your controller doesn't behave the same way than the ones already
>>>> supported.
>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>> transfers right
>>>> - Your SPI controller is doing something weird
>>>>
>>>> What happens if you plug a logical analyzer on the bus?
>>>>
>>>> Maxime
>>>>
>>> Hi,
>>>
>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>> byte in the i2c package/message.
>>> Without looking up the datasheet, I would guess that this is the only
>>> difference, the way the D/C bit is handled.
>>> The rest of the package payload should be the same.
>>> So:
>>> dc=0, spi write command
>>> dc=1, spi write data (optional)
>>>
>> I was working on ssd1306 itself.
>>
>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>
>>> This is the part writing the framebuffer:
>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>> This writes commands (for many controllers):
>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>> This is the SPI specific part:
>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>
>> Thanks for the pointers that was really helpful.
>>
>> just a quick help the dc pin should be a gpio and be set as output pin
>> to control D/C ?
> Correct.
>
Thanks!
Is there any sample app/library to draw/test this driver?
Thanks,
--Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-11 14:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 10.01.2015 22:07, skrev Ssagarr Patil:
> Hi Noralf,
>
>> Date: Sat, 10 Jan 2015 14:50:09 +0100
>> From: notro@tronnes.org
>> To: hugarsagar@outlook.com
>> CC: linux-fbdev@vger.kernel.org
>> Subject: Re: SSD1306 OLED driver
>>
>> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>>> Hi Noralf,
>>>
>>>>>> I am now concerned if the driver was tested in first place ?
>>>>> No. I just submitted some good looking code that never ever got
>>>>> tested.
>>>>>
>>>>> More seriously, There's a few thing that comes to my mind:
>>>>> - Your controller doesn't behave the same way than the ones already
>>>>> supported.
>>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>>> transfers right
>>>>> - Your SPI controller is doing something weird
>>>>>
>>>>> What happens if you plug a logical analyzer on the bus?
>>>>>
>>>>> Maxime
>>>>>
>>>> Hi,
>>>>
>>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>>> byte in the i2c package/message.
>>>> Without looking up the datasheet, I would guess that this is the only
>>>> difference, the way the D/C bit is handled.
>>>> The rest of the package payload should be the same.
>>>> So:
>>>> dc=0, spi write command
>>>> dc=1, spi write data (optional)
>>>>
>>> I was working on ssd1306 itself.
>>>
>>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>>
>>>> This is the part writing the framebuffer:
>>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>>> This writes commands (for many controllers):
>>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>>> This is the SPI specific part:
>>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>>
>>> Thanks for the pointers that was really helpful.
>>>
>>> just a quick help the dc pin should be a gpio and be set as output pin
>>> to control D/C ?
>> Correct.
>>
> Thanks!
>
> Is there any sample app/library to draw/test this driver?
I find it easy to just use the framebuffer console for simple testing:
con2fbmap (or X windows)
I have also used Geert's fbtest.
Noralf.
^ permalink raw reply
* [PATCH 3/5] video: atafb: Remove obsolete IRQ_TYPE_PRIO
From: Geert Uytterhoeven @ 2015-01-12 8:40 UTC (permalink / raw)
To: David S. Miller, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Jaroslav Kysela, Takashi Iwai
Cc: linux-m68k, linux-kernel, Geert Uytterhoeven, linux-fbdev
In-Reply-To: <1421052021-12560-1-git-send-email-geert@linux-m68k.org>
IRQ_TYPE_PRIO is no longer used by the Atari platform interrupt code
since commit 734085651c9b80aa ("[PATCH] m68k: convert atari irq code")
in v2.6.18-rc1, so drop it.
Note that its value has been reused for a different purpose
(IRQ_TYPE_EDGE_FALLING) since commit 6a6de9ef5850d063 ("[PATCH] genirq:
core") in v2.6.18-rc1.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/atafb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index b2d38097a95718ce..7b231771a4b668b0 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -3121,8 +3121,7 @@ int __init atafb_init(void)
printk("atafb_init: initializing Falcon hw\n");
fbhw = &falcon_switch;
atafb_ops.fb_setcolreg = &falcon_setcolreg;
- error = request_irq(IRQ_AUTO_4, falcon_vbl_switcher,
- IRQ_TYPE_PRIO,
+ error = request_irq(IRQ_AUTO_4, falcon_vbl_switcher, 0,
"framebuffer:modeswitch",
falcon_vbl_switcher);
if (error)
--
1.9.1
^ permalink raw reply related
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-12 9:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
>>>> just a quick help the dc pin should be a gpio and be set as output pin
>>>> to control D/C ?
>>> Correct.
>>>
>> Thanks!
>>
>> Is there any sample app/library to draw/test this driver?
> I find it easy to just use the framebuffer console for simple testing:
> con2fbmap (or X windows)
> I have also used Geert's fbtest.
>
Thanks.
I got it compiled against my kernel, but not sure how to add it in my board file (My platform
has no DT support). Should it be registered as spi slave device , I tried adding the following,
{
.modalias = "fb_ssd1306",
.irq = -1,
.max_speed_hz = 16000000,
.bus_num = 2,
.chip_select = 0,
.mode = SPI_MODE_0,
},
But nothing came up how do I register ? any quick pointer would be helpful.
Thanks And Regards,
Sagar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox