* [PATCH v3 08/11] fblog: cache framebuffer BLANK and SUSPEND states
From: David Herrmann @ 2012-07-15 19:04 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Tobias Schandinat, Andrew Morton, Greg Kroah-Hartman,
linux-fbdev, linux-serial, Alan Cox, David Herrmann
In-Reply-To: <1342379086-7583-1-git-send-email-dh.herrmann@googlemail.com>
We must cache these states so we will never draw to the framebuffer while
it is suspended or blanked.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 5519f91..9b975bc 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -33,6 +33,8 @@
enum fblog_flags {
FBLOG_KILLED,
FBLOG_OPEN,
+ FBLOG_SUSPENDED,
+ FBLOG_BLANKED,
};
struct fblog_fb {
@@ -257,6 +259,7 @@ static int fblog_event(struct notifier_block *self, unsigned long action,
struct fb_event *event = data;
struct fb_info *info = event->info;
struct fblog_fb *fb;
+ int *blank;
switch(action) {
case FB_EVENT_FB_REGISTERED:
@@ -284,6 +287,44 @@ static int fblog_event(struct notifier_block *self, unsigned long action,
if (fb)
fblog_close(fb, true);
break;
+ case FB_EVENT_SUSPEND:
+ /* This is called when the low-level display driver suspends the
+ * video system. We should not access the video system while it
+ * is suspended. This is called with the console lock held. */
+ mutex_lock(&fblog_registration_lock);
+ fb = fblog_fbs[info->node];
+ mutex_unlock(&fblog_registration_lock);
+
+ if (fb)
+ set_bit(FBLOG_SUSPENDED, &fb->flags);
+ break;
+ case FB_EVENT_RESUME:
+ /* This is called when the low-level display driver resumes
+ * operating. It is called with the console lock held. */
+ mutex_lock(&fblog_registration_lock);
+ fb = fblog_fbs[info->node];
+ mutex_unlock(&fblog_registration_lock);
+
+ if (fb)
+ clear_bit(FBLOG_SUSPENDED, &fb->flags);
+ break;
+ case FB_EVENT_BLANK:
+ /* This gets called _after_ the framebuffer was successfully
+ * blanked. The console-lock is always held while fb_blank is
+ * called and during this callback. */
+ mutex_lock(&fblog_registration_lock);
+ fb = fblog_fbs[info->node];
+ mutex_unlock(&fblog_registration_lock);
+
+ if (!fb)
+ break;
+
+ blank = (int*)event->data;
+ if (*blank = FB_BLANK_UNBLANK)
+ clear_bit(FBLOG_BLANKED, &fb->flags);
+ else
+ set_bit(FBLOG_BLANKED, &fb->flags);
+ break;
}
return 0;
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 09/11] fblog: register console driver
From: David Herrmann @ 2012-07-15 19:04 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Tobias Schandinat, Andrew Morton, Greg Kroah-Hartman,
linux-fbdev, linux-serial, Alan Cox, David Herrmann
In-Reply-To: <1342379086-7583-1-git-send-email-dh.herrmann@googlemail.com>
We want to print the kernel log to all FBs so we need a console driver.
This registers the driver on startup and writes all messages to all
registered fblog instances.
We cannot share a console buffer between FBs because they might have
different resolutions. Therefore, we create one buffer per object. We
destroy the buffer during close() so we do not waste memory if it is not
used.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 150 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 150 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 9b975bc..ae01742 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -25,11 +25,34 @@
#define pr_fmt(_fmt) KBUILD_MODNAME ": " _fmt
+#include <linux/console.h>
#include <linux/device.h>
#include <linux/fb.h>
#include <linux/module.h>
#include <linux/mutex.h>
+/**
+ * struct fblog_buf: Console text buffer
+ *
+ * Each framebuffer has its own text buffer which contains all characters that
+ * are currently printed on screen. The buffers might have different sizes and
+ * can be resized during runtime. When the buffer content changes, we redraw the
+ * screen.
+ *
+ * width: Width of buffer in characters
+ * height: Height of buffer in characters
+ * lines: Array of lines
+ * pos_x: Cursor x-position
+ * pos_y: Cursor y-position
+ */
+struct fblog_buf {
+ size_t width;
+ size_t height;
+ u16 **lines;
+ size_t pos_x;
+ size_t pos_y;
+};
+
enum fblog_flags {
FBLOG_KILLED,
FBLOG_OPEN,
@@ -42,6 +65,7 @@ struct fblog_fb {
struct fb_info *info;
struct device dev;
struct mutex lock;
+ struct fblog_buf buf;
};
static DEFINE_MUTEX(fblog_registration_lock);
@@ -50,6 +74,106 @@ static bool active = 1;
#define to_fblog_dev(_d) container_of(_d, struct fblog_fb, dev)
+static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
+ size_t height)
+{
+ u16 **lines = NULL;
+ size_t i, j, minw, minh;
+
+ if (buf->height = height && buf->width = width)
+ return;
+
+ if (width && height) {
+ lines = kzalloc(height * sizeof(char *), GFP_KERNEL);
+ if (!lines)
+ return;
+
+ for (i = 0; i < height; ++i) {
+ lines[i] = kzalloc(width * sizeof(u16), GFP_KERNEL);
+ if (!lines[i]) {
+ while (i--)
+ kfree(lines[i]);
+ return;
+ }
+ }
+
+ /* copy old lines */
+ minw = min(width, buf->width);
+ minh = min(height, buf->height);
+ if (height >= buf->height)
+ i = 0;
+ else
+ i = buf->height - height;
+
+ for (j = 0; j < minh; ++i, ++j)
+ memcpy(lines[j], buf->lines[i], minw * sizeof(u16));
+ } else {
+ width = 0;
+ height = 0;
+ }
+
+ for (i = 0; i < buf->height; ++i)
+ kfree(buf->lines[i]);
+ kfree(buf->lines);
+
+ buf->lines = lines;
+ buf->width = width;
+ buf->height = height;
+}
+
+static void fblog_buf_deinit(struct fblog_buf *buf)
+{
+ fblog_buf_resize(buf, 0, 0);
+}
+
+static void fblog_buf_rotate(struct fblog_buf *buf)
+{
+ u16 *line;
+
+ if (!buf->height)
+ return;
+
+ line = buf->lines[0];
+ memset(line, 0, sizeof(u16) * buf->width);
+
+ memmove(buf->lines, &buf->lines[1], sizeof(char*) * (buf->height - 1));
+ buf->lines[buf->height - 1] = line;
+}
+
+static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
+{
+ char c;
+
+ if (!buf->height)
+ return;
+
+ while (len--) {
+ c = *str++;
+
+ if (c = 0)
+ c = '?';
+
+ if (c = '\n') {
+ buf->pos_x = 0;
+ if (++buf->pos_y >= buf->height) {
+ buf->pos_y = buf->height - 1;
+ fblog_buf_rotate(buf);
+ }
+ } else {
+ if (buf->pos_x >= buf->width) {
+ buf->pos_x = 0;
+ ++buf->pos_y;
+ }
+ if (buf->pos_y >= buf->height) {
+ buf->pos_y = buf->height - 1;
+ fblog_buf_rotate(buf);
+ }
+
+ buf->lines[buf->pos_y][buf->pos_x++] = c;
+ }
+ }
+}
+
/*
* fblog_open/close()
* These functions manage access to the underlying framebuffer. While opened, we
@@ -64,6 +188,7 @@ static bool active = 1;
static int fblog_open(struct fblog_fb *fb)
{
+ static const char init_str[] = "Framebuffer log initialized\n";
int ret;
mutex_lock(&fb->lock);
@@ -88,6 +213,8 @@ static int fblog_open(struct fblog_fb *fb)
goto out_unref;
}
+ fblog_buf_resize(&fb->buf, 80, 24);
+ fblog_buf_write(&fb->buf, init_str, sizeof(init_str) - 1);
set_bit(FBLOG_OPEN, &fb->flags);
mutex_unlock(&fb->lock);
return 0;
@@ -110,6 +237,7 @@ static void fblog_close(struct fblog_fb *fb, bool kill_dev)
fb->info->fbops->fb_release(fb->info, 0);
module_put(fb->info->fbops->owner);
clear_bit(FBLOG_OPEN, &fb->flags);
+ fblog_buf_deinit(&fb->buf);
}
if (kill_dev)
@@ -372,6 +500,26 @@ static struct notifier_block fblog_notifier = {
.notifier_call = fblog_event,
};
+static void fblog_con_write(struct console *con, const char *buf,
+ unsigned int len)
+{
+ int i;
+
+ mutex_lock(&fblog_registration_lock);
+ for (i = 0; i < FB_MAX; ++i) {
+ if (fblog_fbs[i]) {
+ fblog_buf_write(&fblog_fbs[i]->buf, buf, len);
+ }
+ }
+ mutex_unlock(&fblog_registration_lock);
+}
+
+static struct console fblog_con_driver = {
+ .name = "fblog",
+ .write = fblog_con_write,
+ .flags = CON_PRINTBUFFER | CON_ENABLED,
+};
+
static int __init fblog_init(void)
{
int ret;
@@ -383,6 +531,7 @@ static int __init fblog_init(void)
}
fblog_scan();
+ register_console(&fblog_con_driver);
return 0;
}
@@ -392,6 +541,7 @@ static void __exit fblog_exit(void)
unsigned int i;
struct fb_info *info;
+ unregister_console(&fblog_con_driver);
fb_unregister_client(&fblog_notifier);
/* We scan through the whole registered_fb array here instead of
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 10/11] fblog: draw console to framebuffers
From: David Herrmann @ 2012-07-15 19:04 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Tobias Schandinat, Andrew Morton, Greg Kroah-Hartman,
linux-fbdev, linux-serial, Alan Cox, David Herrmann
In-Reply-To: <1342379086-7583-1-git-send-email-dh.herrmann@googlemail.com>
If not disabled or suspended, we now blit the console data to each
framebuffer. We only redraw on changes to avoid consuming too much CPU
power.
This isn't optimized for speed, currently. However, fblog is mainly used
for debugging purposes so this can be optimized later.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 107 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 106 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index ae01742..81b0b42 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -28,8 +28,11 @@
#include <linux/console.h>
#include <linux/device.h>
#include <linux/fb.h>
+#include <linux/font.h>
+#include <linux/kd.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include "fbdraw.h"
/**
* struct fblog_buf: Console text buffer
@@ -66,6 +69,7 @@ struct fblog_fb {
struct device dev;
struct mutex lock;
struct fblog_buf buf;
+ struct console_font font;
};
static DEFINE_MUTEX(fblog_registration_lock);
@@ -174,6 +178,58 @@ static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
}
}
+static void fblog_redraw_clear(struct fblog_fb *fb)
+{
+ struct fb_fillrect region;
+ struct fb_info *info = fb->info;
+
+ region.color = 0;
+ region.dx = 0;
+ region.dy = 0;
+ region.width = info->var.xres;
+ region.height = info->var.yres;
+ region.rop = ROP_COPY;
+
+ info->fbops->fb_fillrect(info, ®ion);
+}
+
+static void fblog_redraw(struct fblog_fb *fb)
+{
+ size_t i;
+
+ mutex_lock(&fb->lock);
+ if (!test_bit(FBLOG_OPEN, &fb->flags) ||
+ test_bit(FBLOG_SUSPENDED, &fb->flags) ||
+ test_bit(FBLOG_BLANKED, &fb->flags)) {
+ mutex_unlock(&fb->lock);
+ return;
+ }
+
+ fblog_redraw_clear(fb);
+
+ for (i = 0; i < fb->buf.height; ++i) {
+ fbdraw_font(fb->info, &fb->font, false, 0, i, 7, 0, 0,
+ fb->buf.lines[i], fb->buf.width);
+ }
+
+ mutex_unlock(&fb->lock);
+}
+
+static void fblog_refresh(struct fblog_fb *fb)
+{
+ unsigned int width, height;
+
+ mutex_lock(&fb->lock);
+ if (test_bit(FBLOG_OPEN, &fb->flags)) {
+ width = fb->info->var.xres / fb->font.width;
+ height = fb->info->var.yres / fb->font.height;
+ fblog_buf_resize(&fb->buf, width, height);
+ }
+ mutex_unlock(&fb->lock);
+
+ fblog_redraw(fb);
+}
+
/*
* fblog_open/close()
* These functions manage access to the underlying framebuffer. While opened, we
@@ -190,6 +246,10 @@ static int fblog_open(struct fblog_fb *fb)
{
static const char init_str[] = "Framebuffer log initialized\n";
int ret;
+ struct fb_var_screeninfo var;
+ const struct fb_videomode *mode;
+ unsigned int width, height;
+ const struct font_desc *font;
mutex_lock(&fb->lock);
@@ -203,6 +263,13 @@ static int fblog_open(struct fblog_fb *fb)
goto unlock;
}
+ font = get_default_font(var.xres, var.yres, fb->info->pixmap.blit_x,
+ fb->info->pixmap.blit_y);
+ if (!font) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
if (!try_module_get(fb->info->fbops->owner)) {
ret = -ENODEV;
goto out_killed;
@@ -213,10 +280,22 @@ static int fblog_open(struct fblog_fb *fb)
goto out_unref;
}
- fblog_buf_resize(&fb->buf, 80, 24);
+ var = fb->info->var;
+ mode = fb_find_best_mode(&var, &fb->info->modelist);
+ var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+ fb_set_var(fb->info, &var);
+
+ fb->font.width = font->width;
+ fb->font.height = font->height;
+ fb->font.data = (void*)font->data;
+
+ width = var.xres / fb->font.width;
+ height = var.yres / fb->font.height;
+ fblog_buf_resize(&fb->buf, width, height);
fblog_buf_write(&fb->buf, init_str, sizeof(init_str) - 1);
set_bit(FBLOG_OPEN, &fb->flags);
mutex_unlock(&fb->lock);
+ fblog_redraw(fb);
return 0;
out_unref:
@@ -453,6 +532,31 @@ static int fblog_event(struct notifier_block *self, unsigned long action,
else
set_bit(FBLOG_BLANKED, &fb->flags);
break;
+ case FB_EVENT_MODE_DELETE:
+ /* This is sent when a video mode is removed. The current video
+ * mode is never removed! The console lock is held while this is
+ * called. */
+ /* fallthrough */
+ case FB_EVENT_NEW_MODELIST:
+ /* This is sent when the modelist got changed. The console-lock
+ * is held and we should reset the mode. */
+ /* fallthrough */
+ case FB_EVENT_MODE_CHANGE_ALL:
+ /* This is the same as below but notifies us that the user used
+ * the FB_ACTIVATE_ALL flag when setting the video mode. */
+ /* fallthrough */
+ case FB_EVENT_MODE_CHANGE:
+ /* This is called when the _user_ changes the video mode via
+ * ioctls. It is not sent, when the kernel changes the mode
+ * internally. This callback is called inside fb_set_var() so
+ * the console lock is held. */
+ mutex_lock(&fblog_registration_lock);
+ fb = fblog_fbs[info->node];
+ mutex_unlock(&fblog_registration_lock);
+
+ if (fb)
+ fblog_refresh(fb);
+ break;
}
return 0;
@@ -509,6 +613,7 @@ static void fblog_con_write(struct console *con, const char *buf,
for (i = 0; i < FB_MAX; ++i) {
if (fblog_fbs[i]) {
fblog_buf_write(&fblog_fbs[i]->buf, buf, len);
+ fblog_redraw(fblog_fbs[i]);
}
}
mutex_unlock(&fblog_registration_lock);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 11/11] MAINTAINERS: add fblog entry
From: David Herrmann @ 2012-07-15 19:04 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Tobias Schandinat, Andrew Morton, Greg Kroah-Hartman,
linux-fbdev, linux-serial, Alan Cox, David Herrmann
In-Reply-To: <1342379086-7583-1-git-send-email-dh.herrmann@googlemail.com>
Add myself as maintainer for the fblog driver to the MAINTAINERS file.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 719f57f..227d5ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2854,6 +2854,12 @@ F: drivers/video/
F: include/video/
F: include/linux/fb.h
+FRAMEBUFFER LOG DRIVER
+M: David Herrmann <dh.herrmann@googlemail.com>
+L: linux-serial@vger.kernel.org
+S: Maintained
+F: drivers/video/console/fblog.c
+
FREESCALE DMA DRIVER
M: Li Yang <leoli@freescale.com>
M: Zhang Wei <zw@zh-kernel.org>
--
1.7.11.2
^ permalink raw reply related
* Re: Device tree binding for DVFS table
From: Mark Brown @ 2012-07-15 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50006935.2080606@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Sat, Jul 14, 2012 at 12:00:14AM +0530, Prashant Gaikwad wrote:
> On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote:
> >About repeating frequencies, operating voltage for a frequency
> >would be the highest one mapped in the table.
This sounds very surprising... that would generally just result in
higher power consumption.
> >I know this makes reading difficult but it provides flexibility,
> Does this explanation help?
The loss of comprehensibility seems like a really major disadvantage for
very little practical gain here. Big arrays in DT are already hard
enough to read without adding extra complexity on top of that.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Rob Herring @ 2012-07-15 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FFE4DD0.7020407@nvidia.com>
On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>>> cpu-dvfs-table : dvfs-table {
>> This should be located with the node that the frequencies correspond to.
>>
>
> With CAR node?
With the power domain it corresponds to or the cpu nodes.
>
>>> compatible = "nvidia,tegra30-dvfs-table";
>>> reg_id =<&sm0>;
>>> #address-cells =<1>;
>>> #size-cells =<0>;
>>> voltage-array =<750 775 800 825 850 875 900 925 950 975
>>> 1000 1025 1050 1100 1125>;
>> The SOC is really characterized at all these voltages?
>
> Not really, but different processes of single SoC are characterized for
> different voltages and this array covers all those voltages.
>
>>> };
>>>
>>> device {
>>> dvfs =<&cpu-dvfs-table>;
>>> frequency-table@102 {
>>> reg =<0x102>;
>>> frequencies =<314 314 314 456 456 456 608 608 608
>>> 760 817 817 912 1000>;
>> I don't see the point of repeating frequencies.
>>> };
>>> frequency-table@002 {
>>> reg =<0x002>;
>>> frequencies =<598 598 750 750 893 893 1000>;
>>> };
>> How do you determine the voltage for a frequency on table 2?
>>
>> I'd expect a single property with freq/volt pairs or 2 properties for
>> freq and voltage where there is a 1:1 relationship (freq N uses
>> voltage N).
>
>
> How this will work:
>
> voltage-array =<750 775 800 825 850 875 900 925 950 975 1000 1025 1050
> 1100 1125>
> frequencies-1 =<314 314 314 456 456 456 608 608 608 760 817 817 912
> 1000>;
> frequencies-2 =<598 598 750 750 893 893 1000>;
>
I don't see the point trying to share a voltage range. Not sharing it is
fewer array elements (22 vs 36):
voltage-array-1 =<750 825 900 975 1000 1050 1100>;
frequencies-1 =<314 456 608 760 817 912 1000>;
voltage-array-2 =<750 800 850 900>
frequencies-2 =<598 750 893 1000>;
Rob
>
> Freq and voltage has 1:1 relationship but as single voltage table is
> used for different processes we have more entries in voltage table than
> freq table.
> Frequency table 1 is mapped till 1100mV while frequency table 2 is
> mapped till 900mV only, it maintains 1:1 relationship.
>
> About repeating frequencies, operating voltage for a frequency would be
> the highest one mapped in the table.
> For example, in frequency table 2 operating voltage for 750MHz would be
> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
> replaced with 0 to make reading better.
>
> Advantage it provides is single voltage table used for multiple
> frequency tables, as can be observed from above tables, operating
> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
> in table 2 at that voltage.
>
> I know this makes reading difficult but it provides flexibility,
>
> I hope it explains the implementation.
>
>> Rob
>>
>>> };
>>>
>>> Thanks& Regards,
>>> Prashant G
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
^ permalink raw reply
* Fwd: video/fbmem.c: Fix __u32 >= 0 condition in fb_do_show_logo.
From: Geert Uytterhoeven @ 2012-07-16 7:44 UTC (permalink / raw)
To: Levin Du; +Cc: linux-kernel, Linux Fbdev development list
In-Reply-To: <CAN6cQGOtUn7y6hEBzjPuBpJPLCKi_kq=AhAbXay74Tc8fDROvA@mail.gmail.com>
Never reached lkml due to the HTML.
Resending, with a CC to linux-fbdev added.
---------- Forwarded message ----------
From: Levin Du <zslevin@gmail.com>
Date: 2012/7/12
Subject: video/fbmem.c: Fix __u32 >= 0 condition in fb_do_show_logo.
To: linux-kernel@vger.kernel.org
Cc: brad@neruo.com
Dear all,
Since dx or dy in struct fb_image is unsigned 32 bit integer:
struct fb_image {
__u32 dx; /* Where to place image */
__u32 dy;
...
}
In fb_do_show_logo(), image->dx or image->dy will always meet the >= 0
condition.
if the logo is large enough (same as to the whole screen, for example) and
rotate is UD or CCW, and image->dx or image->dy will results in a
large value which
makes info->fbops->fb_imageblit fail miserably.
Here is the raw patch:
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ad93629..34a0ba3 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -419,6 +419,7 @@ static void fb_do_show_logo(struct fb_info *info,
struct fb_image *image,
int rotate, unsigned int num)
{
unsigned int x;
+ long d;
if (rotate = FB_ROTATE_UR) {
for (x = 0;
@@ -428,9 +429,10 @@ static void fb_do_show_logo(struct fb_info *info,
struct fb_image *image,
image->dx += image->width + 8;
}
} else if (rotate = FB_ROTATE_UD) {
- for (x = 0; x < num && image->dx >= 0; x++) {
+ d = image->dx;
+ for (x = 0; x < num && d >= 0; x++) {
info->fbops->fb_imageblit(info, image);
- image->dx -= image->width + 8;
+ d -= image->width + 8;
}
} else if (rotate = FB_ROTATE_CW) {
for (x = 0;
@@ -440,9 +442,10 @@ static void fb_do_show_logo(struct fb_info *info,
struct fb_image *image,
image->dy += image->height + 8;
}
} else if (rotate = FB_ROTATE_CCW) {
- for (x = 0; x < num && image->dy >= 0; x++) {
+ d = image->dy;
+ for (x = 0; x < num && d >= 0; x++) {
info->fbops->fb_imageblit(info, image);
- image->dy -= image->height + 8;
+ d -= image->height + 8;
}
}
}
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 related
* DT clock binding support build break
From: Prashant Gaikwad @ 2012-07-16 11:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rob,
DT clock binding support patch breaks build when CONFIG_COMMON_CLK is
not enabled.
/**
LD init/built-in.o
drivers/built-in.o: In function `of_clk_get':
/home/ldewangan/upstreaming/july09/linux-next/drivers/clk/clkdev.c:42:
undefined reference to `of_clk_get_from_provider'
make: *** [vmlinux] Error 1
**/
Any solution?
Thanks & Regards,
Prashant G
^ permalink raw reply
* Re: DT clock binding support build break
From: Rob Herring @ 2012-07-16 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5003F6DF.2010107@nvidia.com>
On 07/16/2012 06:11 AM, Prashant Gaikwad wrote:
> Hi Rob,
>
> DT clock binding support patch breaks build when CONFIG_COMMON_CLK is
> not enabled.
>
> /**
> LD init/built-in.o
> drivers/built-in.o: In function `of_clk_get':
> /home/ldewangan/upstreaming/july09/linux-next/drivers/clk/clkdev.c:42: undefined reference to `of_clk_get_from_provider'
> make: *** [vmlinux] Error 1
> **/
>
> Any solution?
I'll get a fix out today.
Rob
>
> Thanks & Regards,
> Prashant G
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Turquette, Mike @ 2012-07-16 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50035582.9070308@gmail.com>
On Sun, Jul 15, 2012 at 4:42 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
>> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>
>>>> cpu-dvfs-table : dvfs-table {
>>> This should be located with the node that the frequencies correspond to.
>>>
>>
>> With CAR node?
>
> With the power domain it corresponds to or the cpu nodes.
>
>>
>>>> compatible = "nvidia,tegra30-dvfs-table";
>>>> reg_id =<&sm0>;
>>>> #address-cells =<1>;
>>>> #size-cells =<0>;
>>>> voltage-array =<750 775 800 825 850 875 900 925 950 975
>>>> 1000 1025 1050 1100 1125>;
>>> The SOC is really characterized at all these voltages?
>>
>> Not really, but different processes of single SoC are characterized for
>> different voltages and this array covers all those voltages.
>>
>>>> };
>>>>
>>>> device {
>>>> dvfs =<&cpu-dvfs-table>;
>>>> frequency-table@102 {
>>>> reg =<0x102>;
>>>> frequencies =<314 314 314 456 456 456 608 608 608
>>>> 760 817 817 912 1000>;
>>> I don't see the point of repeating frequencies.
>>>> };
>>>> frequency-table@002 {
>>>> reg =<0x002>;
>>>> frequencies =<598 598 750 750 893 893 1000>;
>>>> };
>>> How do you determine the voltage for a frequency on table 2?
>>>
>>> I'd expect a single property with freq/volt pairs or 2 properties for
>>> freq and voltage where there is a 1:1 relationship (freq N uses
>>> voltage N).
>>
>>
>> How this will work:
>>
>> voltage-array =<750 775 800 825 850 875 900 925 950 975 1000 1025 1050
>> 1100 1125>
>> frequencies-1 =<314 314 314 456 456 456 608 608 608 760 817 817 912
>> 1000>;
>> frequencies-2 =<598 598 750 750 893 893 1000>;
>>
>
> I don't see the point trying to share a voltage range. Not sharing it is
> fewer array elements (22 vs 36):
>
> voltage-array-1 =<750 825 900 975 1000 1050 1100>;
> frequencies-1 =<314 456 608 760 817 912 1000>;
>
> voltage-array-2 =<750 800 850 900>
> frequencies-2 =<598 750 893 1000>;
>
This is significantly more readable.
Regards,
Mike
> Rob
>
>>
>> Freq and voltage has 1:1 relationship but as single voltage table is
>> used for different processes we have more entries in voltage table than
>> freq table.
>> Frequency table 1 is mapped till 1100mV while frequency table 2 is
>> mapped till 900mV only, it maintains 1:1 relationship.
>>
>> About repeating frequencies, operating voltage for a frequency would be
>> the highest one mapped in the table.
>> For example, in frequency table 2 operating voltage for 750MHz would be
>> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
>> replaced with 0 to make reading better.
>>
>> Advantage it provides is single voltage table used for multiple
>> frequency tables, as can be observed from above tables, operating
>> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
>> in table 2 at that voltage.
>>
>> I know this makes reading difficult but it provides flexibility,
>>
>> I hope it explains the implementation.
>>
>>> Rob
>>>
>>>> };
>>>>
>>>> Thanks& Regards,
>>>> Prashant G
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
>
>
^ permalink raw reply
* [PATCH] video: exynos_dp: check the only INTERLANE_ALIGN_DONE bit during Link Training
From: Jingoo Han @ 2012-07-17 8:44 UTC (permalink / raw)
To: linux-fbdev
The only INTERLANE_ALIGN_DONE bit should be checked for channel equalization
during Link Training. Previously, the other bits such as LINK_STATUS_UPDATED
were checked, and channel equalization procedure was repeated unnecessarily.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 9db7b9f..6ca8043 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -336,7 +336,7 @@ static int exynos_dp_channel_eq_ok(u8 link_status[6], int lane_count)
u8 lane_status;
lane_align = link_status[2];
- if ((lane_align = DPCD_INTERLANE_ALIGN_DONE) = 0)
+ if ((lane_align & DPCD_INTERLANE_ALIGN_DONE) = 0)
return -EINVAL;
for (lane = 0; lane < lane_count; lane++) {
--
1.7.1
^ permalink raw reply related
* Re: dma-buf/fbdev: one-to-many support
From: Laurent Pinchart @ 2012-07-17 10:39 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel, Sumit Semwal, linux-media, linux-fbdev
In-Reply-To: <CANq1E4SbippxHHTaqLhpGjJLG12y94kWUFdB7P_EAG14o50vrQ@mail.gmail.com>
Hi David,
On Saturday 14 July 2012 16:10:56 David Herrmann wrote:
> Hi
>
> I am currently working on fblog [1] (a replacement for fbcon without
> VT dependencies) but this questions does also apply to other fbdev
> users. Is there a way to share framebuffers between fbdev devices? I
> was thinking especially of USB devices like DisplayLink. If they share
> the same screen dimensions it would increase performance a lot if I
> could display a single buffer on all the devices instead of copying it
> into each framebuffer.
>
> I was told to have a look at the dma-buf framework to implement this.
> However, looking at the fbdev dma-buf support I think that this isn't
> currently possible. Each fbdev device takes the exporter-role and
> provides a single dma-buf object. However, if I wanted to share the
> buffers, I would need to be the exporter. Or there needs to be a way
> for the fbdev devices to import a dma-buf from other fbdev devices.
>
> I also took a short look at DRM prime support and noticed that it is
> capable of importing buffers (or at least it looks like it is).
> Therefore, I was wondering whether it does make sense to add an
> "import dma-buf" callback to fbdev devices and if the fbdev driver
> supports this, I can simply draw to a single dma-buf from one fbdev
> device and push it to all other fbdev devices that share the same
> dimensions.
The main issue is that fbdev has been designed with the implicit assumption
that an fbdev driver will always own the graphics memory it uses. All
components in the stack, from drivers to applications, have been designed
around that assumption.
We could of course fix this, revamp the fbdev API and turn it into a modern
graphics API, but I really wonder whether it would be worth it. DRM has been
getting quite a lot of attention lately, especially from embedded developers
and vendors, and the trend seems to me like the (Linux) world will gradually
move from fbdev to DRM.
Please feel free to disagree :-)
> It would also be nice to allow multiple buffer-owners or a way to
> transfer ownership. That is, if the owner/exporter of the dma-buf
> vanishes, I would pass it to another fbdev device which would pick it
> up so I don't have to create a new one.
>
> I think this is only interesting for DisplayLink-devices as they are
> currently the only way to get a bunch of displays connected to a
> single machine. Anyway, if you think that this isn't worth it, I will
> probably drop this idea.
>
> Regards
> David
>
> [1] fblog kernel driver: http://lwn.net/Articles/505965/
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: dma-buf/fbdev: one-to-many support
From: Alan Cox @ 2012-07-17 11:24 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Herrmann, linux-fbdev, Sumit Semwal, dri-devel, linux-media
In-Reply-To: <1497600.3Qx4Vx9if4@avalon>
> The main issue is that fbdev has been designed with the implicit assumption
> that an fbdev driver will always own the graphics memory it uses. All
> components in the stack, from drivers to applications, have been designed
> around that assumption.
>
> We could of course fix this, revamp the fbdev API and turn it into a modern
> graphics API, but I really wonder whether it would be worth it. DRM has been
> getting quite a lot of attention lately, especially from embedded developers
> and vendors, and the trend seems to me like the (Linux) world will gradually
> move from fbdev to DRM.
>
> Please feel free to disagree :-)
I would disagree on the "main issue" bit. All the graphics cards have
their own formats and cache management rules. Simply sharing a buffer
doesn't work - which is why all of the extra gloop will be needed.
Alan
^ permalink raw reply
* Re: dma-buf/fbdev: one-to-many support
From: David Herrmann @ 2012-07-17 12:23 UTC (permalink / raw)
To: Alan Cox
Cc: Laurent Pinchart, linux-fbdev, Sumit Semwal, dri-devel,
linux-media
In-Reply-To: <20120717122449.07489b50@pyramind.ukuu.org.uk>
Hi Laurent and Alan
On Tue, Jul 17, 2012 at 1:24 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The main issue is that fbdev has been designed with the implicit assumption
>> that an fbdev driver will always own the graphics memory it uses. All
>> components in the stack, from drivers to applications, have been designed
>> around that assumption.
>>
>> We could of course fix this, revamp the fbdev API and turn it into a modern
>> graphics API, but I really wonder whether it would be worth it. DRM has been
>> getting quite a lot of attention lately, especially from embedded developers
>> and vendors, and the trend seems to me like the (Linux) world will gradually
>> move from fbdev to DRM.
>>
>> Please feel free to disagree :-)
>
> I would disagree on the "main issue" bit. All the graphics cards have
> their own formats and cache management rules. Simply sharing a buffer
> doesn't work - which is why all of the extra gloop will be needed.
This is exactly why I suggested adding an "owner" field. A driver
could then check whether the buffer it is supposed to share/takeover
is from a compatible (or even the same) driver/device. If it is not,
it would simply reject using the buffer. Then again, if we have
multiple devices that are incompatible, we are still unable to share
the buffer. So this attempt would only be useful if we have tons of
DisplayLink devices attached that all use the same driver, for
example.
Regarding DRM: In user-space I prefer DRM over fbdev. With the
introduction of the dumb-buffers there isn't even the need to have
mesa installed. However, fblog runs in kernel space and currently
cannot use DRM as there is no in-kernel DRM API. I looked at
drm-fops.c whether it is easy to create a very simple in-kernel API
but then I dropped the idea as this might be too complex for a simple
debugging-only driver. Another attempt would be making the
drm-fb-helper more generic so we can use this layer as in-kernel DRM
API.
I had a deeper look into this this weekend and so as a summary I think
all in-kernel graphics access is probably not worth optimizing it.
fbcon is already working great and fblog is only used during boot and
oopses/panics and can be restricted to a single device. I will have
another look at the drivers in a few weeks but if you tell me that
this is not easy to implement, I will probably have to let this idea
go.
Thanks
David
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Prashant Gaikwad @ 2012-07-17 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJOA=zMKE1Z_AsYeWr22k58EDskx0eshEjv9VbLQHKFsA0uThw@mail.gmail.com>
On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:
> On Sun, Jul 15, 2012 at 4:42 PM, Rob Herring<robherring2@gmail.com> wrote:
>> On 07/11/2012 11:08 PM, Prashant Gaikwad wrote:
>>> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>>>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>>>>> cpu-dvfs-table : dvfs-table {
>>>> This should be located with the node that the frequencies correspond to.
>>>>
>>> With CAR node?
>> With the power domain it corresponds to or the cpu nodes.
>>
>>>>> compatible = "nvidia,tegra30-dvfs-table";
>>>>> reg_id =<&sm0>;
>>>>> #address-cells =<1>;
>>>>> #size-cells =<0>;
>>>>> voltage-array =<750 775 800 825 850 875 900 925 950 975
>>>>> 1000 1025 1050 1100 1125>;
>>>> The SOC is really characterized at all these voltages?
>>> Not really, but different processes of single SoC are characterized for
>>> different voltages and this array covers all those voltages.
>>>
>>>>> };
>>>>>
>>>>> device {
>>>>> dvfs =<&cpu-dvfs-table>;
>>>>> frequency-table@102 {
>>>>> reg =<0x102>;
>>>>> frequencies =<314 314 314 456 456 456 608 608 608
>>>>> 760 817 817 912 1000>;
>>>> I don't see the point of repeating frequencies.
>>>>> };
>>>>> frequency-table@002 {
>>>>> reg =<0x002>;
>>>>> frequencies =<598 598 750 750 893 893 1000>;
>>>>> };
>>>> How do you determine the voltage for a frequency on table 2?
>>>>
>>>> I'd expect a single property with freq/volt pairs or 2 properties for
>>>> freq and voltage where there is a 1:1 relationship (freq N uses
>>>> voltage N).
>>>
>>> How this will work:
>>>
>>> voltage-array =<750 775 800 825 850 875 900 925 950 975 1000 1025 1050
>>> 1100 1125>
>>> frequencies-1 =<314 314 314 456 456 456 608 608 608 760 817 817 912
>>> 1000>;
>>> frequencies-2 =<598 598 750 750 893 893 1000>;
>>>
>> I don't see the point trying to share a voltage range. Not sharing it is
>> fewer array elements (22 vs 36):
>>
>> voltage-array-1 =<750 825 900 975 1000 1050 1100>;
>> frequencies-1 =<314 456 608 760 817 912 1000>;
>>
>> voltage-array-2 =<750 800 850 900>
>> frequencies-2 =<598 750 893 1000>;
>>
> This is significantly more readable.
Instead of voltage array, I was thinking of following approach to
represent operating points for DVFS
reg : operating voltage in microvolt
tolerance : can be used to calculate required voltage. (optional, can be
replaced by other relevant parameter to calculate required voltage)
frequencies : Array of phandle, clock specifier and frequency for all
the clocks related to this rail.
opp@750000000 {
reg = <750000000>;
tolerance = <4>;
frequency-table@102 {
reg = <0x102>;
frequencies = <&osc 0 314000>, <&ref 1 500000>;
};
};
opp@800000000 {
reg = <800000000>;
tolerance = <4>;
frequency-table@102 {
reg = <0x102>;
frequencies = <&osc 0 456000>, <&ref 1 608000>;
};
frequency-table@002 {
reg = <0x002>;
frequencies = <&osc 0 400000>, <&ref 1 560000>;
};
};
It represents:
- 1:1 mapping for voltage/frequency pair.
- Voltage can be represented as range.
- relationships between clock domain and rail.
Only issue I see is, if there are large number of operating points it
will increase data in DT.
Any suggestions?
>
> Regards,
> Mike
>
>> Rob
>>
>>> Freq and voltage has 1:1 relationship but as single voltage table is
>>> used for different processes we have more entries in voltage table than
>>> freq table.
>>> Frequency table 1 is mapped till 1100mV while frequency table 2 is
>>> mapped till 900mV only, it maintains 1:1 relationship.
>>>
>>> About repeating frequencies, operating voltage for a frequency would be
>>> the highest one mapped in the table.
>>> For example, in frequency table 2 operating voltage for 750MHz would be
>>> 825mV while for 893MHz it would be 875mV. Unmapped entries could be
>>> replaced with 0 to make reading better.
>>>
>>> Advantage it provides is single voltage table used for multiple
>>> frequency tables, as can be observed from above tables, operating
>>> voltage for 314MHz in freq table 1 is 800mV while there is no frequency
>>> in table 2 at that voltage.
>>>
>>> I know this makes reading difficult but it provides flexibility,
>>>
>>> I hope it explains the implementation.
>>>
>>>> Rob
>>>>
>>>>> };
>>>>>
>>>>> Thanks& Regards,
>>>>> Prashant G
>>>>>
>>>>> _______________________________________________
>>>>> linux-arm-kernel mailing list
>>>>> linux-arm-kernel@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
^ permalink raw reply
* Re: [PATCH v2 11/11] MAINTAINERS: add fblog entry
From: Geert Uytterhoeven @ 2012-07-17 12:57 UTC (permalink / raw)
To: David Herrmann
Cc: linux-serial, linux-kernel, florianschandinat, linux-fbdev,
gregkh, alan, bonbons
In-Reply-To: <CANq1E4RyFpqxH=uG+dDA1=kfc3r8rCoEesZ31op9rCLjxyk6mQ@mail.gmail.com>
On Mon, Jul 9, 2012 at 8:38 PM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ae8fe46..249b02a 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2854,6 +2854,12 @@ F: drivers/video/
>>> F: include/video/
>>> F: include/linux/fb.h
>>>
>>> +FRAMEBUFFER LOG DRIVER
>>> +M: David Herrmann <dh.herrmann@googlemail.com>
>>> +L: linux-serial@vger.kernel.org
>>
>> Why linux-serial, and not linux-fbdev?
>
> I thought fbcon was maintained on linux-serial as it is very related
It has always been maintained on linux-fbdev.
> to the vt/tty layer. If linux-fbdev is the better place, I can move
> this. I CC'ed both lists, anyway.
> I have actually no idea where it fits in best.
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: [PATCH v2 11/11] MAINTAINERS: add fblog entry
From: David Herrmann @ 2012-07-17 13:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-serial, linux-kernel, florianschandinat, linux-fbdev,
gregkh, alan, bonbons
In-Reply-To: <CAMuHMdXFfMv-DV-89nueyDJ5AvFN3AXR_6ysWOfCMDFL46s-Cg@mail.gmail.com>
Hi Geert
On Tue, Jul 17, 2012 at 2:57 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jul 9, 2012 at 8:38 PM, David Herrmann
> <dh.herrmann@googlemail.com> wrote:
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index ae8fe46..249b02a 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -2854,6 +2854,12 @@ F: drivers/video/
>>>> F: include/video/
>>>> F: include/linux/fb.h
>>>>
>>>> +FRAMEBUFFER LOG DRIVER
>>>> +M: David Herrmann <dh.herrmann@googlemail.com>
>>>> +L: linux-serial@vger.kernel.org
>>>
>>> Why linux-serial, and not linux-fbdev?
>>
>> I thought fbcon was maintained on linux-serial as it is very related
>
> It has always been maintained on linux-fbdev.
Thanks! Then I will change this to linux-fbdev.
Regards
David
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Mark Brown @ 2012-07-17 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50055C83.7060700@nvidia.com>
On Tue, Jul 17, 2012 at 06:07:23PM +0530, Prashant Gaikwad wrote:
> On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:
> reg : operating voltage in microvolt
What happens if there's more than one supply that needs to be varied?
> tolerance : can be used to calculate required voltage. (optional,
> can be replaced by other relevant parameter to calculate required
> voltage)
What are the semantics of this field?
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Prashant Gaikwad @ 2012-07-17 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120717132032.GD27595@sirena.org.uk>
On Tuesday 17 July 2012 06:50 PM, Mark Brown wrote:
> On Tue, Jul 17, 2012 at 06:07:23PM +0530, Prashant Gaikwad wrote:
>> On Tuesday 17 July 2012 12:06 AM, Turquette, Mike wrote:
>> reg : operating voltage in microvolt
> What happens if there's more than one supply that needs to be varied?
Each rail's dvfs-table will have OPP nodes defined for different
voltages and each OPP node contains frequency for all clocks affecting
that rail.
Just for presentation:
In following example when <&ref 1> clock rate is set to 500000, sm0 need
to operate at 750000000 micrvolt and sm1 at 800000000.
dvfs-rail-1 {
reg_id = <&sm0>;
opp@750000000 {
frequency-table@102 {
frequencies = <&osc 0 314000>, <&ref 1 500000>;
};
};
};
dvfs-rail-2 {
reg_id = <&sm1>;
opp@800000000 {
frequency-table@102 {
frequencies = <&ref 1 5000000>;
};
};
};
>> tolerance : can be used to calculate required voltage. (optional,
>> can be replaced by other relevant parameter to calculate required
>> voltage)
> What are the semantics of this field?
I used "tolerance" just for example to derive the range of voltage.
May be as done for OMAP,
regulator_set_voltage(mpu_reg, volt - tol, volt + tol);
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Mark Brown @ 2012-07-17 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50057514.5070501@nvidia.com>
On Tue, Jul 17, 2012 at 07:52:12PM +0530, Prashant Gaikwad wrote:
> >What happens if there's more than one supply that needs to be varied?
> Each rail's dvfs-table will have OPP nodes defined for different
> voltages and each OPP node contains frequency for all clocks
> affecting that rail.
Right, but some systems have operating points which cover a combination
of voltages and frequencies in one operating point. Your binding seems
to define operating points per supply with no tie in between supplies.
^ permalink raw reply
* [PATCH 0/4] Add support for the OLED in the CFA10036
From: Maxime Ripard @ 2012-07-17 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This patchset adds support for the solomon SSD1307 OLED controller present
in the CFA-10036 board.
It first adds the framebuffer driver for this controller, and then the
needed bits to enable it in the cfa10036 dts.
Thanks,
Maxime
Maxime Ripard (4):
video: Add support for the Solomon SSD1307 OLED Controller
ARM: dts: mxs: Add alternative I2C muxing options for imx28
ARM: dts: mxs: Add pwm4 muxing options for imx28
ARM: dts: mxs: add oled support for the cfa-10036
.../devicetree/bindings/video/ssd1307fb.txt | 24 ++
arch/arm/boot/dts/imx28-cfa10036.dts | 20 +
arch/arm/boot/dts/imx28.dtsi | 17 +
drivers/video/Kconfig | 14 +
drivers/video/Makefile | 1 +
drivers/video/ssd1307fb.c | 414 ++++++++++++++++++++
6 files changed, 490 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt
create mode 100644 drivers/video/ssd1307fb.c
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/4] video: Add support for the Solomon SSD1307 OLED Controller
From: Maxime Ripard @ 2012-07-17 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1342540787-14930-1-git-send-email-maxime.ripard@free-electrons.com>
This patches adds support for the Solomon SSD1307 OLED
controller found on the Crystalfontz CFA10036 board.
It is a monochrome 128x39 display, that can operate over
I2C or SPI.
The current driver as only be tested on the CFA-10036,
that is using this controller over I2C to driver a 96x16
OLED screen.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
.../devicetree/bindings/video/ssd1307fb.txt | 24 ++
drivers/video/Kconfig | 14 +
drivers/video/Makefile | 1 +
drivers/video/ssd1307fb.c | 414 ++++++++++++++++++++
4 files changed, 453 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt
create mode 100644 drivers/video/ssd1307fb.c
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
new file mode 100644
index 0000000..73ba41c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -0,0 +1,24 @@
+* Solomon SSD1307 Framebuffer Driver
+
+Required properties:
+ - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
+ now is i2c.
+ - reg: Should contain address of the controller on the I2C bus. Most likely
+ 0x3c or 0x3d
+ - pwm: Should contain the pwm to use according to the OF device tree PWM
+ specification [0]
+ - oled-reset-gpios: Should contain the GPIO used to reset the OLED display
+
+Optional properties:
+ - reset-active-low: Is the reset gpio is active on physical low?
+
+[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+
+Examples:
+ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ oled-reset-gpios = <&gpio2 7 1>;
+ reset-active-low;
+};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..21ae6dd 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2469,4 +2469,18 @@ config FB_SH_MOBILE_MERAM
Up to 4 memory channels can be configured, allowing 4 RGB or
2 YCbCr framebuffers to be configured.
+
+config FB_SSD1307
+ tristate "Solomon SSD1307 framebuffer support"
+ depends on FB && I2C
+ select FB_SYS_FOPS
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_DEFERRED_IO
+ select PWM
+ help
+ This driver implements support for the Solomon SSD1307
+ OLED controller over I2C.
+
endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..6bbb72c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
obj-$(CONFIG_FB_MXS) += mxsfb.o
+obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL) += vfb.o
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
new file mode 100644
index 0000000..5d24360
--- /dev/null
+++ b/drivers/video/ssd1307fb.c
@@ -0,0 +1,414 @@
+/*
+ * Driver for the Solomon SSD1307 OLED controler
+ *
+ * Copyright 2012 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/fb.h>
+#include <linux/uaccess.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/pwm.h>
+#include <linux/delay.h>
+
+#define SSD1307FB_WIDTH 96
+#define SSD1307FB_HEIGHT 16
+
+#define SSD1307FB_DATA 0x40
+#define SSD1307FB_COMMAND 0x80
+
+#define SSD1307FB_CONTRAST 0x81
+#define SSD1307FB_SEG_REMAP_ON 0xa1
+#define SSD1307FB_DISPLAY_OFF 0xae
+#define SSD1307FB_DISPLAY_ON 0xaf
+#define SSD1307FB_START_PAGE_ADDRESS 0xb0
+
+struct ssd1307fb_par {
+ struct i2c_client *client;
+ struct fb_info *info;
+ struct pwm_device *pwm;
+ u32 pwm_period;
+ int reset;
+};
+
+static struct fb_fix_screeninfo ssd1307fb_fix __devinitdata = {
+ .id = "Solomon SSD1307",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_MONO10,
+ .xpanstep = 0,
+ .ypanstep = 0,
+ .ywrapstep = 0,
+ .line_length = SSD1307FB_WIDTH / 8,
+ .accel = FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo ssd1307fb_var __devinitdata = {
+ .xres = SSD1307FB_WIDTH,
+ .yres = SSD1307FB_HEIGHT,
+ .xres_virtual = SSD1307FB_WIDTH,
+ .yres_virtual = SSD1307FB_HEIGHT,
+ .bits_per_pixel = 1,
+};
+
+static int ssd1307fb_write_cmd_array(struct i2c_client *client, u8* cmd, u32 len)
+{
+ u8 *buf;
+ int ret;
+
+ buf = kzalloc(len + 1, GFP_KERNEL);
+ if (!buf) {
+ dev_err(&client->dev, "Couldn't allocate sending buffer.\n");
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buf[0] = SSD1307FB_COMMAND;
+ memcpy(buf + 1, cmd, len);
+
+ ret = i2c_master_send(client, buf, len + 1);
+ if (ret != len + 1) {
+ dev_err(&client->dev, "Couldn't send I2C command.\n");
+ goto error;
+ }
+
+ kfree(buf);
+ return 0;
+
+error:
+ kfree(buf);
+ return ret;
+}
+
+static inline int ssd1307fb_write_cmd(struct i2c_client *client, u8 cmd)
+{
+ return ssd1307fb_write_cmd_array(client, &cmd, 1);
+}
+
+static int ssd1307fb_write_data_array(struct i2c_client *client, u8* cmd, u32 len)
+{
+ u8 *buf;
+ int ret;
+
+ buf = kzalloc(len + 1, GFP_KERNEL);
+ if (!buf) {
+ dev_err(&client->dev, "Couldn't allocate sending buffer.\n");
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buf[0] = SSD1307FB_DATA;
+ memcpy(buf + 1, cmd, len);
+
+ ret = i2c_master_send(client, buf, len + 1);
+ if (ret != len + 1) {
+ dev_err(&client->dev, "Couldn't send I2C data.\n");
+ goto error;
+ }
+
+ kfree(buf);
+ return 0;
+
+error:
+ kfree(buf);
+ return ret;
+}
+
+static inline int ssd1307fb_write_data(struct i2c_client *client, u8 data)
+{
+ return ssd1307fb_write_data_array(client, &data, 1);
+}
+
+static int ssd1307fb_set(struct i2c_client *client, u8 value)
+{
+ int i, j, ret;
+
+ for (i = 1; i <= (SSD1307FB_HEIGHT / 8); i++) {
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_START_PAGE_ADDRESS + i);
+ if (ret)
+ goto i2c_error;
+
+ ret = ssd1307fb_write_cmd(client, 0x00);
+ if (ret)
+ goto i2c_error;
+
+ ret = ssd1307fb_write_cmd(client, 0x10);
+ if (ret)
+ goto i2c_error;
+
+ for (j = 0; j < SSD1307FB_WIDTH; j++)
+ ssd1307fb_write_data(client, value);
+ }
+
+ return 0;
+
+i2c_error:
+ dev_err(&client->dev, "Couldn't send i2c command: %d\n", ret);
+ return ret;
+}
+
+static void ssd1307fb_update_display(struct ssd1307fb_par *par)
+{
+ u8 *vmem = par->info->screen_base;
+ int i, j, k;
+
+ /*
+ * A page is 8 bit large and covers all the line. In order to
+ * update the screen, you have to send a byte, each byte
+ * containing a bit per pixel to set, on the same column. That
+ * way, by sending a byte, you will only portion of the screen
+ * that has a height of 8 bit and a width of 1, the right-most
+ * bit being on the top of this frame. So we have to do a bit
+ * of magic here...
+ */
+
+ for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
+ ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
+ ssd1307fb_write_cmd(par->client, 0x00);
+ ssd1307fb_write_cmd(par->client, 0x10);
+
+ for (j = 0; j < SSD1307FB_WIDTH; j++) {
+ u8 buf = 0;
+ for (k = 0; k < 8; k++) {
+ u32 page_length = SSD1307FB_WIDTH * i;
+ u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
+ u8 byte = *(vmem + index);
+ u8 bit = byte & (1 << (7 - (j % 8)));
+ bit = bit >> (7 - (j % 8));
+ buf |= bit << k;
+ }
+ ssd1307fb_write_data(par->client, buf);
+ }
+ }
+
+ return;
+}
+
+
+static ssize_t ssd1307fb_write(struct fb_info *info, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct ssd1307fb_par *par = info->par;
+ unsigned long p = *ppos;
+ void *dst;
+ int err = 0;
+
+ dst = (void __force *) (info->screen_base + p);
+
+ if (copy_from_user(dst, buf, count))
+ err = -EFAULT;
+
+ if (!err)
+ *ppos += count;
+
+ ssd1307fb_update_display(par);
+
+ return (err) ? err : count;
+}
+
+static void ssd1307fb_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_fillrect(info, rect);
+ ssd1307fb_update_display(par);
+}
+
+static void ssd1307fb_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_copyarea(info, area);
+ ssd1307fb_update_display(par);
+}
+
+static void ssd1307fb_imageblit(struct fb_info *info, const struct fb_image *image)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_imageblit(info, image);
+ ssd1307fb_update_display(par);
+}
+
+static struct fb_ops ssd1307fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_read = fb_sys_read,
+ .fb_write = ssd1307fb_write,
+ .fb_fillrect = ssd1307fb_fillrect,
+ .fb_copyarea = ssd1307fb_copyarea,
+ .fb_imageblit = ssd1307fb_imageblit,
+};
+
+static void ssd1307fb_deferred_io(struct fb_info *info,
+ struct list_head *pagelist)
+{
+ ssd1307fb_update_display(info->par);
+}
+
+static struct fb_deferred_io ssd1307fb_defio = {
+ .delay = HZ,
+ .deferred_io = ssd1307fb_deferred_io,
+};
+
+static int __devinit ssd1307fb_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct fb_info *info;
+ u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
+ struct ssd1307fb_par *par;
+ u8 *vmem;
+ int ret;
+
+ if (!client->dev.of_node) {
+ dev_err(&client->dev, "No device tree data found!\n");
+ ret = -EINVAL;
+ goto generic_error;
+ }
+
+ info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
+ if (!info) {
+ ret = -ENOMEM;
+ goto generic_error;
+ }
+
+ vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
+
+ info->fbops = &ssd1307fb_ops;
+ info->fix = ssd1307fb_fix;
+ info->fbdefio = &ssd1307fb_defio;
+
+ info->var = ssd1307fb_var;
+ info->var.red.length = 1;
+ info->var.red.offset = 0;
+ info->var.green.length = 1;
+ info->var.green.offset = 0;
+ info->var.blue.length = 1;
+ info->var.blue.offset = 0;
+
+ info->screen_base = (u8 __force __iomem *)vmem;
+ info->fix.smem_len = vmem_size;
+
+ fb_deferred_io_init(info);
+
+ par = info->par;
+ par->info = info;
+ par->client = client;
+
+ par->reset = of_get_named_gpio(client->dev.of_node,
+ "oled-reset-gpios", 0);
+ if (gpio_is_valid(par->reset)) {
+ int flags = GPIOF_OUT_INIT_HIGH;
+ if (of_get_property(client->dev.of_node,
+ "reset-active-low", NULL))
+ flags = GPIOF_OUT_INIT_LOW;
+ ret = devm_gpio_request_one(&client->dev, par->reset,
+ flags, "oled-reset");
+ if (ret) {
+ dev_err(&client->dev,
+ "failed to request gpio %d: %d\n",
+ par->reset, ret);
+ goto reset_oled_error;
+ }
+ }
+
+ par->pwm = pwm_get(&client->dev, NULL);
+ if (IS_ERR(par->pwm)) {
+ dev_err(&client->dev, "Could not get PWM from device tree!\n");
+ ret = PTR_ERR(par->pwm);
+ goto pwm_error;
+ }
+
+ par->pwm_period = pwm_get_period(par->pwm);
+
+ dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
+
+ ret = register_framebuffer(info);
+ if (ret) {
+ dev_err(&client->dev, "Couldn't register the framebuffer\n");
+ goto fbreg_error;
+ }
+
+ i2c_set_clientdata(client, info);
+
+ /* Reset the screen */
+ gpio_set_value(par->reset, 1);
+ udelay(4);
+ gpio_set_value(par->reset, 0);
+ udelay(4);
+
+ /* Enable the PWM */
+ pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+ pwm_enable(par->pwm);
+
+ /* Map column 127 of the OLED to segment 0 */
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
+ if (ret) {
+ dev_err(&client->dev, "Couldn't remap the screen.\n");
+ goto remap_error;
+ }
+
+ /* Turn on the display */
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
+ if (ret) {
+ dev_err(&client->dev, "Couldn't turn the display on.\n");
+ goto remap_error;
+ }
+
+ dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
+
+ return 0;
+
+remap_error:
+ unregister_framebuffer(info);
+ pwm_disable(par->pwm);
+fbreg_error:
+ pwm_put(par->pwm);
+pwm_error:
+reset_oled_error:
+ fb_deferred_io_cleanup(info);
+ framebuffer_release(info);
+generic_error:
+ return ret;
+}
+
+static int __devexit ssd1307fb_remove(struct i2c_client *client)
+{
+ struct fb_info *info = i2c_get_clientdata(client);
+ struct ssd1307fb_par *par = info->par;
+ unregister_framebuffer(info);
+ pwm_disable(par->pwm);
+ pwm_put(par->pwm);
+ fb_deferred_io_cleanup(info);
+ framebuffer_release(info);
+
+ return 0;
+}
+
+static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+ { "ssd1307fb", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
+
+static const struct of_device_id ssd1307fb_of_match[] = {
+ { .compatible = "solomon,ssd1307fb-i2c" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+
+static struct i2c_driver ssd1307fb_driver = {
+ .probe = ssd1307fb_probe,
+ .remove = __devexit_p(ssd1307fb_remove),
+ .id_table = ssd1307fb_i2c_id,
+ .driver = {
+ .name = "ssd1307fb",
+ .of_match_table = of_match_ptr(ssd1307fb_of_match),
+ .owner = THIS_MODULE,
+ },
+};
+
+module_i2c_driver(ssd1307fb_driver);
+
+MODULE_DESCRIPTION("FB driver for the Solomon SSD1307 OLED controler");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_LICENSE("GPL");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: mxs: Add alternative I2C muxing options for imx28
From: Maxime Ripard @ 2012-07-17 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1342540787-14930-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 915db89..44ce1fd 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -410,6 +410,14 @@
fsl,pull-up = <1>;
};
+ i2c0_pins_b: i2c0@1 {
+ reg = <1>;
+ fsl,pinmux-ids = <0x3001 0x3011>;
+ fsl,drive-strength = <1>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <1>;
+ };
+
saif0_pins_a: saif0@0 {
reg = <0>;
fsl,pinmux-ids = <
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: mxs: Add pwm4 muxing options for imx28
From: Maxime Ripard @ 2012-07-17 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1342540787-14930-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 44ce1fd..0a565ef 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -461,6 +461,15 @@
fsl,pull-up = <0>;
};
+ pwm4_pins_a: pwm4@0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x31d0 /* MX28_PAD_PWM4__PWM_4 */
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <0>;
+ };
+
lcdif_24bit_pins_a: lcdif-24bit@0 {
reg = <0>;
fsl,pinmux-ids = <
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: mxs: add oled support for the cfa-10036
From: Maxime Ripard @ 2012-07-17 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1342540787-14930-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28-cfa10036.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index c03a577..0a5c722 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -33,11 +33,31 @@
};
apbx@80040000 {
+ pwm: pwm@80064000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm4_pins_a>;
+ status = "okay";
+ };
+
duart: serial@80074000 {
pinctrl-names = "default";
pinctrl-0 = <&duart_pins_b>;
status = "okay";
};
+
+ i2c0: i2c@80058000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_b>;
+ status = "okay";
+
+ ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ oled-reset-gpios = <&gpio2 7 1>;
+ reset-active-low;
+ };
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
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