* [PATCH v10 4/6] devicetree: backlight: Add new SKY81452 backlight binding
From: gyungoh @ 2015-01-07 2:19 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-1-git-send-email-jack.yoo@skyworksinc.com>
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 related
* [PATCH v10 5/6] devicetree: Add vendor prefix for Skyworks Solutions, Inc.
From: gyungoh @ 2015-01-07 2:19 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-1-git-send-email-jack.yoo@skyworksinc.com>
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:
Nothing
Changes v7:
Nothing
Changes v6:
Nothing
Changes v5:
Nothing
Changes v4:
Nothing
Changes v3:
Nothing
Changes v2:
Added vendor prefix for Skyworks Solutions, Inc.
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a344ec2..68143f0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -140,6 +140,7 @@ sii Seiko Instruments, Inc.
silergy Silergy Corp.
sirf SiRF Technology, Inc.
sitronix Sitronix Technology Corporation
+skyworks Skyworks Solutions, Inc.
smsc Standard Microsystems Corporation
snps Synopsys, Inc.
solidrun SolidRun
--
1.9.1
^ permalink raw reply related
* [PATCH v10 6/6] devicetree: i2c: Add SKY81452 to the Trivial Devices list
From: gyungoh @ 2015-01-07 2:19 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-1-git-send-email-jack.yoo-tjhQNA90jdKqndwCJWfcng@public.gmane.org>
From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
Signed-off-by: Gyungoh Yoo <jack.yoo@skyworksinc.com>
---
Changes v10:
Nothing
Changes v9:
Nothing
Changes v8:
Nothing
Changes v7:
Nothing
Changes v6:
Nothing
Changes v5:
Nothing
Changes v4:
Nothing
Changes v3:
Nothing
Changes v2:
Add SKY81452 to the Trivial Devices list
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index fbde415..122fa1e 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -77,6 +77,7 @@ ramtron,24c64 i2c serial eeprom (24cxx)
ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
sii,s35390a 2-wire CMOS real-time clock
+skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
st-micro,24c256 i2c serial eeprom (24cxx)
stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] video: vt8500lcdfb: remove unneeded continue
From: Sudip Mukherjee @ 2015-01-07 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54AC2A0B.3040807@cogentembedded.com>
On Tue, Jan 06, 2015 at 09:31:39PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 01/06/2015 03:45 PM, Sudip Mukherjee wrote:
>
> >continue is not needed at the end of a for loop
>
> >Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> >---
> > drivers/video/fbdev/vt8500lcdfb.c | 1 -
> > 1 file changed, 1 deletion(-)
>
> >diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
> >index ffaf29e..6716bf5 100644
> >--- a/drivers/video/fbdev/vt8500lcdfb.c
> >+++ b/drivers/video/fbdev/vt8500lcdfb.c
> >@@ -115,7 +115,6 @@ static int vt8500lcd_set_par(struct fb_info *info)
> > for (i = 0; i < 8; i++) {
> > if (bpp_values[i] = info->var.bits_per_pixel) {
> > reg_bpp = i;
> >- continue;
> > }
>
> {} are not needed any more either. ;-)
i have noticed that but thought that will be again a different type of change in a single patch.
but now it seems that this patch will introduce a new checkpatch warning, so i should have corrected that in it.
i will send a v2.
thanks
sudip
>
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* [PATCH v2] video: vt8500lcdfb: remove unneeded continue
From: Sudip Mukherjee @ 2015-01-07 5:47 UTC (permalink / raw)
To: linux-arm-kernel
continue is not needed at the end of a for loop, also removed the
braces which were no longer required.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
v2: removed braces
drivers/video/fbdev/vt8500lcdfb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/vt8500lcdfb.c b/drivers/video/fbdev/vt8500lcdfb.c
index ffaf29e..1a1176b 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -113,10 +113,8 @@ static int vt8500lcd_set_par(struct fb_info *info)
}
for (i = 0; i < 8; i++) {
- if (bpp_values[i] = info->var.bits_per_pixel) {
+ if (bpp_values[i] = info->var.bits_per_pixel)
reg_bpp = i;
- continue;
- }
}
control0 = readl(fbi->regbase) & ~0xf;
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v2 0/7] imx-drm: ipuv3-crtc: Implement mode_fixup
From: Philipp Zabel @ 2015-01-07 18:27 UTC (permalink / raw)
To: Steve Longerbeam
Cc: dri-devel, linux-kernel, linux-fbdev, David Airlie,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Russell King,
Fabio Estevam, Shawn Guo, Denis Carikli, Jiada Wang,
Steve Longerbeam
In-Reply-To: <1418954426-21909-1-git-send-email-steve_longerbeam@mentor.com>
Am Donnerstag, den 18.12.2014, 18:00 -0800 schrieb Steve Longerbeam:
> This patchset implements ->mode_fixup() in the imx ipuv3-crtc driver,
> using a new support function ipu_di_adjust_videomode(). This new
> function needs to be subsystem independent, so it accepts a video
> mode as a 'struct videomode'. Hence ipu-crtc ->mode_fixup() needs
> another support function to convert a drm_display_mode to a videomode
> before passing the mode to ipu_di_adjust_videomode() for fixup.
>
> Also some related code cleanup: 'struct ipu_di_signal_cfg' should
> use 'struct videomode' for mode timings.
Alright, I have applied the series with
s/videomode_from_drm_display_mode/drm_display_mode_to_videomode/
thanks
Philipp
^ permalink raw reply
* 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
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