* 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
* [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: 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
* 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
* 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
* 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
* 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
* 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
* [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
* [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 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 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 07/11] fblog: allow selecting fbs via sysfs
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>
fblog is mainly useful during boot, reboot, panics and maintenance. In all
cases you often want to control which monitors are used for console
output. Moreover, in multi-seat environments it is desireable to reduce
system-overhead by not drawing the console to all framebuffers. Two
mechanisms to select framebuffers for fblog are added:
1) "active" module parameter: This parameter selects whether new
framebuffers are opened automatically. By default this is on, that is, all
framebuffers are automatically used by fblog during boot. By passing
fblog.active=0 you can deactivate this.
The init process can set this to 0 via
/sys/modules/fblog/parameters/active, too. However, this does not affect
already available and used framebuffers in any way.
2) "active" sysfs attribute for each fblog object. Reading this value
returns whether a framebuffer is currently active. Writing it opens/closes
the framebuffer. This allows runtime control which fbs are used. For
instance, init can set these to 0 after bootup.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 53 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 1c526c5..5519f91 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -44,6 +44,7 @@ struct fblog_fb {
static DEFINE_MUTEX(fblog_registration_lock);
static struct fblog_fb *fblog_fbs[FB_MAX];
+static bool active = 1;
#define to_fblog_dev(_d) container_of(_d, struct fblog_fb, dev)
@@ -115,6 +116,40 @@ static void fblog_close(struct fblog_fb *fb, bool kill_dev)
mutex_unlock(&fb->lock);
}
+static ssize_t fblog_dev_active_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct fblog_fb *fb = to_fblog_dev(dev);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n",
+ !!test_bit(FBLOG_OPEN, &fb->flags));
+}
+
+static ssize_t fblog_dev_active_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct fblog_fb *fb = to_fblog_dev(dev);
+ unsigned long num;
+ int ret = 0;
+
+ num = simple_strtoul(buf, NULL, 10);
+
+ mutex_lock(&fb->info->lock);
+ if (num)
+ ret = fblog_open(fb);
+ else
+ fblog_close(fb, false);
+ mutex_unlock(&fb->info->lock);
+
+ return ret ? ret : count;
+}
+
+static DEVICE_ATTR(active, S_IRUGO | S_IWUSR | S_IWGRP, fblog_dev_active_show,
+ fblog_dev_active_store);
+
/*
* fblog framebuffer list
* The fblog_fbs[] array contains all currently registered framebuffers. If a
@@ -148,6 +183,7 @@ static void fblog_do_unregister(struct fb_info *info)
fblog_fbs[info->node] = NULL;
fblog_close(fb, true);
+ device_remove_file(&fb->dev, &dev_attr_active);
device_del(&fb->dev);
put_device(&fb->dev);
}
@@ -156,6 +192,7 @@ static void fblog_do_register(struct fb_info *info, bool force)
{
struct fblog_fb *fb;
int ret;
+ bool do_open = true;
fb = fblog_fbs[info->node];
if (fb && fb->info != info) {
@@ -186,7 +223,18 @@ static void fblog_do_register(struct fb_info *info, bool force)
return;
}
- fblog_open(fb);
+ ret = device_create_file(&fb->dev, &dev_attr_active);
+ if (ret) {
+ pr_err("fblog: cannot create sysfs entry");
+ /* do not open fb if we cannot create control file */
+ do_open = false;
+ }
+
+ if (!active)
+ do_open = false;
+
+ if (do_open)
+ fblog_open(fb);
}
static void fblog_register(struct fb_info *info, bool force)
@@ -321,6 +369,9 @@ static void __exit fblog_exit(void)
}
}
+module_param(active, bool, S_IRUGO | S_IWUSR | S_IWGRP);
+MODULE_PARM_DESC(active, "Activate fblog by default");
+
module_init(fblog_init);
module_exit(fblog_exit);
MODULE_LICENSE("GPL");
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 06/11] fblog: open fb on registration
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>
This opens the framebuffer upon registration so we can use it for
drawing-operations. On unregistration we close it again.
While opening/closing or accessing the fb in any other way, we must hold
the fb-mutex. However, since the notifiers are often called with the mutex
already held, we cannot lock it _after_ taking the
fblog_registration_lock. Therefore, we require the caller to make sure the
fb-mutex is held.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 94 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 279f4d8..1c526c5 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -32,12 +32,14 @@
enum fblog_flags {
FBLOG_KILLED,
+ FBLOG_OPEN,
};
struct fblog_fb {
unsigned long flags;
struct fb_info *info;
struct device dev;
+ struct mutex lock;
};
static DEFINE_MUTEX(fblog_registration_lock);
@@ -46,6 +48,74 @@ static struct fblog_fb *fblog_fbs[FB_MAX];
#define to_fblog_dev(_d) container_of(_d, struct fblog_fb, dev)
/*
+ * fblog_open/close()
+ * These functions manage access to the underlying framebuffer. While opened, we
+ * have a valid reference to the fb and can use it for drawing operations. When
+ * the fb is unregistered, we drop our reference and close the fb so it can get
+ * deleted properly. We also mark it as dead so no further fblog_open() call
+ * will succeed.
+ * Both functions must be called with the fb->info->lock mutex held! But make
+ * sure to lock it _before_ locking the fblog-registration-lock. Otherwise, we
+ * will dead-lock with fb-registration.
+ */
+
+static int fblog_open(struct fblog_fb *fb)
+{
+ int ret;
+
+ mutex_lock(&fb->lock);
+
+ if (test_bit(FBLOG_KILLED, &fb->flags)) {
+ ret = -ENODEV;
+ goto unlock;
+ }
+
+ if (test_bit(FBLOG_OPEN, &fb->flags)) {
+ ret = 0;
+ goto unlock;
+ }
+
+ if (!try_module_get(fb->info->fbops->owner)) {
+ ret = -ENODEV;
+ goto out_killed;
+ }
+
+ if (fb->info->fbops->fb_open && fb->info->fbops->fb_open(fb->info, 0)) {
+ ret = -EIO;
+ goto out_unref;
+ }
+
+ set_bit(FBLOG_OPEN, &fb->flags);
+ mutex_unlock(&fb->lock);
+ return 0;
+
+out_unref:
+ module_put(fb->info->fbops->owner);
+out_killed:
+ set_bit(FBLOG_KILLED, &fb->flags);
+unlock:
+ mutex_unlock(&fb->lock);
+ return ret;
+}
+
+static void fblog_close(struct fblog_fb *fb, bool kill_dev)
+{
+ mutex_lock(&fb->lock);
+
+ if (test_bit(FBLOG_OPEN, &fb->flags)) {
+ if (fb->info->fbops->fb_release)
+ fb->info->fbops->fb_release(fb->info, 0);
+ module_put(fb->info->fbops->owner);
+ clear_bit(FBLOG_OPEN, &fb->flags);
+ }
+
+ if (kill_dev)
+ set_bit(FBLOG_KILLED, &fb->flags);
+
+ mutex_unlock(&fb->lock);
+}
+
+/*
* fblog framebuffer list
* The fblog_fbs[] array contains all currently registered framebuffers. If a
* framebuffer is in that list, we always must make sure that we own a reference
@@ -77,6 +147,7 @@ static void fblog_do_unregister(struct fb_info *info)
fblog_fbs[info->node] = NULL;
+ fblog_close(fb, true);
device_del(&fb->dev);
put_device(&fb->dev);
}
@@ -99,6 +170,7 @@ static void fblog_do_register(struct fb_info *info, bool force)
return;
fb->info = info;
+ mutex_init(&fb->lock);
__module_get(THIS_MODULE);
device_initialize(&fb->dev);
fb->dev.class = fb_class;
@@ -113,6 +185,8 @@ static void fblog_do_register(struct fb_info *info, bool force)
put_device(&fb->dev);
return;
}
+
+ fblog_open(fb);
}
static void fblog_register(struct fb_info *info, bool force)
@@ -134,6 +208,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;
switch(action) {
case FB_EVENT_FB_REGISTERED:
@@ -145,8 +220,21 @@ static int fblog_event(struct notifier_block *self, unsigned long action,
case FB_EVENT_FB_UNREGISTERED:
/* This is called when a low-level system driver unregisters a
* framebuffer. The registration lock is held but the console
- * lock might not be held. */
+ * lock might not be held. The fb-lock is not held, either! */
+ mutex_lock(&info->lock);
fblog_unregister(info);
+ mutex_unlock(&info->lock);
+ break;
+ case FB_EVENT_FB_UNBIND:
+ /* Called directly before unregistering an FB. The FB is still
+ * valid here and the registration lock is held but the console
+ * lock might not be held (really?). */
+ mutex_lock(&fblog_registration_lock);
+ fb = fblog_fbs[info->node];
+ mutex_unlock(&fblog_registration_lock);
+
+ if (fb)
+ fblog_close(fb, true);
break;
}
@@ -163,7 +251,9 @@ static void fblog_scan(void)
if (!info || IS_ERR(info))
continue;
+ mutex_lock(&info->lock);
fblog_register(info, false);
+ mutex_unlock(&info->lock);
/* There is a very subtle race-condition. Even though we might
* own a reference to the fb, it may still get unregistered
@@ -224,7 +314,9 @@ static void __exit fblog_exit(void)
if (!info || IS_ERR(info))
continue;
+ mutex_lock(&info->lock);
fblog_unregister(info);
+ mutex_unlock(&info->lock);
put_fb_info(info);
}
}
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 05/11] fblog: register one fblog object per framebuffer
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>
One fblog object is associated to each registered framebuffer. This way,
we can draw the console to each framebuffer. When a framebuffer driver
unregisters a framebuffer, we also unregister our fblog object. That is,
our lifetime is coupled to the lifetime of the framebuffer. However, this
does not mean that we are always active. On the contrary, we do not even
own a reference to the framebuffer. We don't need it as we are notified
_before_ the last reference is dropped.
However, if other users have a reference to our object, we simply mark it
as dead when the associated framebuffer dies and leave it alone. When the
last reference is dropped, it will be automatically freed.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 195 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 195 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index fb39737..279f4d8 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -23,15 +23,210 @@
* all fblog instances before running other graphics applications.
*/
+#define pr_fmt(_fmt) KBUILD_MODNAME ": " _fmt
+
+#include <linux/device.h>
+#include <linux/fb.h>
#include <linux/module.h>
+#include <linux/mutex.h>
+
+enum fblog_flags {
+ FBLOG_KILLED,
+};
+
+struct fblog_fb {
+ unsigned long flags;
+ struct fb_info *info;
+ struct device dev;
+};
+
+static DEFINE_MUTEX(fblog_registration_lock);
+static struct fblog_fb *fblog_fbs[FB_MAX];
+
+#define to_fblog_dev(_d) container_of(_d, struct fblog_fb, dev)
+
+/*
+ * fblog framebuffer list
+ * The fblog_fbs[] array contains all currently registered framebuffers. If a
+ * framebuffer is in that list, we always must make sure that we own a reference
+ * to it. If it is added through the notifier callbacks, then this is always
+ * guaranteed.
+ * We are only interested in registered framebuffers. That is, if a driver calls
+ * unregister_framebuffer() we directly unlink it from our list. This guarantees
+ * that the associated fb_info is always valid. However, we might still have
+ * pending users so we mark it as dead so no further framebuffer actions are
+ * done. If the last user then drops a reference, the memory gets freed
+ * automatically.
+ */
+
+static void fblog_release(struct device *dev)
+{
+ struct fblog_fb *fb = to_fblog_dev(dev);
+
+ kfree(fb);
+ module_put(THIS_MODULE);
+}
+
+static void fblog_do_unregister(struct fb_info *info)
+{
+ struct fblog_fb *fb;
+
+ fb = fblog_fbs[info->node];
+ if (!fb || fb->info != info)
+ return;
+
+ fblog_fbs[info->node] = NULL;
+
+ device_del(&fb->dev);
+ put_device(&fb->dev);
+}
+
+static void fblog_do_register(struct fb_info *info, bool force)
+{
+ struct fblog_fb *fb;
+ int ret;
+
+ fb = fblog_fbs[info->node];
+ if (fb && fb->info != info) {
+ if (!force)
+ return;
+
+ fblog_do_unregister(fb->info);
+ }
+
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (!fb)
+ return;
+
+ fb->info = info;
+ __module_get(THIS_MODULE);
+ device_initialize(&fb->dev);
+ fb->dev.class = fb_class;
+ fb->dev.release = fblog_release;
+ dev_set_name(&fb->dev, "fblog%d", info->node);
+ fblog_fbs[info->node] = fb;
+
+ ret = device_add(&fb->dev);
+ if (ret) {
+ fblog_fbs[info->node] = NULL;
+ set_bit(FBLOG_KILLED, &fb->flags);
+ put_device(&fb->dev);
+ return;
+ }
+}
+
+static void fblog_register(struct fb_info *info, bool force)
+{
+ mutex_lock(&fblog_registration_lock);
+ fblog_do_register(info, force);
+ mutex_unlock(&fblog_registration_lock);
+}
+
+static void fblog_unregister(struct fb_info *info)
+{
+ mutex_lock(&fblog_registration_lock);
+ fblog_do_unregister(info);
+ mutex_unlock(&fblog_registration_lock);
+}
+
+static int fblog_event(struct notifier_block *self, unsigned long action,
+ void *data)
+{
+ struct fb_event *event = data;
+ struct fb_info *info = event->info;
+
+ switch(action) {
+ case FB_EVENT_FB_REGISTERED:
+ /* This is called when a low-level system driver registers a new
+ * framebuffer. The registration lock is held but the console
+ * lock might not be held when this is called. */
+ fblog_register(info, true);
+ break;
+ case FB_EVENT_FB_UNREGISTERED:
+ /* This is called when a low-level system driver unregisters a
+ * framebuffer. The registration lock is held but the console
+ * lock might not be held. */
+ fblog_unregister(info);
+ break;
+ }
+
+ return 0;
+}
+
+static void fblog_scan(void)
+{
+ unsigned int i;
+ struct fb_info *info, *tmp;
+
+ for (i = 0; i < FB_MAX; ++i) {
+ info = get_fb_info(i);
+ if (!info || IS_ERR(info))
+ continue;
+
+ fblog_register(info, false);
+
+ /* There is a very subtle race-condition. Even though we might
+ * own a reference to the fb, it may still get unregistered
+ * between our call from get_fb_info() and fblog_register().
+ * Therefore, we simply check whether the same fb still is
+ * registered by calling get_fb_info() again. Only if they
+ * differ we know that it got unregistered, therefore, we
+ * call fblog_unregister() with the old pointer. */
+
+ tmp = get_fb_info(i);
+ if (tmp && !IS_ERR(tmp))
+ put_fb_info(tmp);
+ if (tmp != info)
+ fblog_unregister(info);
+
+ /* Here we either called fblog_unregister() and therefore do not
+ * need any reference to the fb, or we can be sure that the FB
+ * is registered and FB_EVENT_FB_UNREGISTERED will be called
+ * before the last reference is dropped. Hence, we can drop our
+ * reference here. */
+
+ put_fb_info(info);
+ }
+}
+
+static struct notifier_block fblog_notifier = {
+ .notifier_call = fblog_event,
+};
static int __init fblog_init(void)
{
+ int ret;
+
+ ret = fb_register_client(&fblog_notifier);
+ if (ret) {
+ pr_err("cannot register framebuffer notifier\n");
+ return ret;
+ }
+
+ fblog_scan();
+
return 0;
}
static void __exit fblog_exit(void)
{
+ unsigned int i;
+ struct fb_info *info;
+
+ fb_unregister_client(&fblog_notifier);
+
+ /* We scan through the whole registered_fb array here instead of
+ * fblog_fbs because we need to get the device lock _before_ the
+ * fblog-registration-lock. */
+
+ for (i = 0; i < FB_MAX; ++i) {
+ info = get_fb_info(i);
+ if (!info || IS_ERR(info))
+ continue;
+
+ fblog_unregister(info);
+ put_fb_info(info);
+ }
}
module_init(fblog_init);
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 04/11] fbdev: export get_fb_info()/put_fb_info()
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>
When adding other internal users of the framebuffer subsystem, we need a
way to get references to framebuffers. These two functions already exist
so export them.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/fbmem.c | 6 ++++--
include/linux/fb.h | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 0dff12a..1312ba2 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -46,7 +46,7 @@ static DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
int num_registered_fb __read_mostly;
-static struct fb_info *get_fb_info(unsigned int idx)
+struct fb_info *get_fb_info(unsigned int idx)
{
struct fb_info *fb_info;
@@ -61,14 +61,16 @@ static struct fb_info *get_fb_info(unsigned int idx)
return fb_info;
}
+EXPORT_SYMBOL_GPL(get_fb_info);
-static void put_fb_info(struct fb_info *fb_info)
+void put_fb_info(struct fb_info *fb_info)
{
if (!atomic_dec_and_test(&fb_info->count))
return;
if (fb_info->fbops->fb_destroy)
fb_info->fbops->fb_destroy(fb_info);
}
+EXPORT_SYMBOL_GPL(put_fb_info);
int lock_fb_info(struct fb_info *info)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ac3f1c6..2d51c0e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -1033,6 +1033,9 @@ static inline void unlock_fb_info(struct fb_info *info)
mutex_unlock(&info->lock);
}
+extern struct fb_info *get_fb_info(unsigned int idx);
+extern void put_fb_info(struct fb_info *fb_info);
+
static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
u8 *src, u32 s_pitch, u32 height)
{
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 03/11] fblog: new framebuffer kernel log dummy 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>
Fblog displays all kernel log messages on all connected framebuffers. It
replaces fbcon when CONFIG_VT=n is selected. Its main purpose is to debug
boot problems by displaying the whole boot log on the screen. This patch
provides the first dummy module-init/deinit functions.
As it uses all the font and fb functions I placed it in
drivers/video/console. However, this means that we need to move the check
for CONFIG_VT in Makefile/Kconfig from drivers/video into
drivers/video/console as fblog does not depend on CONFIG_VT.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/Kconfig | 5 +----
drivers/video/Makefile | 2 +-
drivers/video/console/Kconfig | 37 +++++++++++++++++++++++++++++--------
drivers/video/console/Makefile | 1 +
drivers/video/console/fblog.c | 41 +++++++++++++++++++++++++++++++++++++++++
5 files changed, 73 insertions(+), 13 deletions(-)
create mode 100644 drivers/video/console/fblog.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..e8fd53d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2448,10 +2448,7 @@ source "drivers/video/omap/Kconfig"
source "drivers/video/omap2/Kconfig"
source "drivers/video/exynos/Kconfig"
source "drivers/video/backlight/Kconfig"
-
-if VT
- source "drivers/video/console/Kconfig"
-endif
+source "drivers/video/console/Kconfig"
if FB || SGI_NEWPORT_CONSOLE
source "drivers/video/logo/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..9f8a7f0 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -11,7 +11,7 @@ fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
fb-objs := $(fb-y)
-obj-$(CONFIG_VT) += console/
+obj-y += console/
obj-$(CONFIG_LOGO) += logo/
obj-y += backlight/
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index e2c96d0..7374362 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -6,7 +6,7 @@ menu "Console display driver support"
config VGA_CONSOLE
bool "VGA text console" if EXPERT || !X86
- depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
+ depends on VT && !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
default y
help
Saying Y here will allow you to use Linux in text mode through a
@@ -45,7 +45,7 @@ config VGACON_SOFT_SCROLLBACK_SIZE
screenfuls of scrollback buffer
config MDA_CONSOLE
- depends on !M68K && !PARISC && ISA
+ depends on VT && !M68K && !PARISC && ISA
tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
---help---
Say Y here if you have an old MDA or monochrome Hercules graphics
@@ -61,14 +61,14 @@ config MDA_CONSOLE
config SGI_NEWPORT_CONSOLE
tristate "SGI Newport Console support"
- depends on SGI_IP22
+ depends on VT && SGI_IP22
help
Say Y here if you want the console on the Newport aka XL graphics
card of your Indy. Most people say Y here.
config DUMMY_CONSOLE
bool
- depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y
+ depends on VT && (VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y)
default y
config DUMMY_CONSOLE_COLUMNS
@@ -89,7 +89,7 @@ config DUMMY_CONSOLE_ROWS
config FRAMEBUFFER_CONSOLE
tristate "Framebuffer Console support"
- depends on FB
+ depends on VT && FB
select CRC32
help
Low-level framebuffer-based console driver.
@@ -122,16 +122,37 @@ config FRAMEBUFFER_CONSOLE_ROTATION
config STI_CONSOLE
bool "STI text console"
- depends on PARISC
+ depends on VT && PARISC
default y
help
The STI console is the builtin display/keyboard on HP-PARISC
machines. Say Y here to build support for it into your kernel.
The alternative is to use your primary serial port as a console.
+config FBLOG
+ tristate "Framebuffer Kernel Log Driver"
+ depends on !VT && FB
+ default n
+ help
+ This driver displays all kernel log messages on all connected
+ framebuffers. It is mutually exclusive with CONFIG_FRAMEBUFFER_CONSOLE
+ and CONFIG_VT. It was mainly created for debugging purposes when
+ CONFIG_VT is not selected but you still want kernel boot messages on
+ the screen.
+
+ This driver overwrites all other graphics output on the framebuffer as
+ long as it is active so the kernel log will always be visible. You
+ need to disable this driver via sysfs to be able to start another
+ graphics application.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will
+ be called fblog.
+
config FONTS
bool "Select compiled-in fonts"
- depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
+ depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE || FBLOG
help
Say Y here if you would like to use fonts other than the default
your frame buffer console usually use.
@@ -158,7 +179,7 @@ config FONT_8x8
config FONT_8x16
bool "VGA 8x16 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
+ depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON || FBLOG
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index 9a52226..ec0e155 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -20,6 +20,7 @@ font-objs += $(font-objs-y)
# Each configuration option enables a list of files.
+obj-$(CONFIG_FBLOG) += fblog.o font.o
obj-$(CONFIG_DUMMY_CONSOLE) += dummycon.o
obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
new file mode 100644
index 0000000..fb39737
--- /dev/null
+++ b/drivers/video/console/fblog.c
@@ -0,0 +1,41 @@
+/*
+ * Framebuffer Kernel Log Driver
+ * Copyright (c) 2012 David Herrmann <dh.herrmann@googlemail.com>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * Framebuffer Kernel Log
+ * This driver prints the kernel log to all connected display devices. It
+ * replaces CONFIG_VT and cannot run simultaneously with it. It does not provide
+ * any virtual-terminal, though. It should only be used to get kernel boot
+ * messages to debug kernel errors.
+ * Hence, this driver is neither optimized for speed, nor does it provide any
+ * fancy features like colored text output.
+ * This driver forcibly writes to the framebuffer while active, therefore, you
+ * cannot run other graphics applications simultaneously. You need to disable
+ * all fblog instances before running other graphics applications.
+ */
+
+#include <linux/module.h>
+
+static int __init fblog_init(void)
+{
+ return 0;
+}
+
+static void __exit fblog_exit(void)
+{
+}
+
+module_init(fblog_init);
+module_exit(fblog_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Herrmann <dh.herrmann@googlemail.com>");
+MODULE_DESCRIPTION("Framebuffer Kernel Log Driver");
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 02/11] fbcon: move bit_putcs() into separate source file
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 we want to use font-draw-operations in other modules than fbcon, we
need to split this function off of fbcon headers and sources. This also
makes bit_putcs() totally independent of vc_* and fbcon_* structures.
As scr_read() cannot be called inside of non-fbcon/vt functions, we need
to assemble the buffer before passing it to fbdraw_font(). This slows down
this operations a little bit but my rough benchmark showed that it didn't
really matter. Anyway, if it does, we can still put it into VT_BUF_HAVE_RW
conditions so platforms that don't use it won't be affected. And for other
platforms we can add the buffer to the vc-struct so we can reuse it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/bitblit.c | 127 ++++------------------------------------
drivers/video/console/fbdraw.c | 125 +++++++++++++++++++++++++++++++++++++++
drivers/video/console/fbdraw.h | 4 ++
3 files changed, 139 insertions(+), 117 deletions(-)
diff --git a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
index 6ec2905..c5d897b 100644
--- a/drivers/video/console/bitblit.c
+++ b/drivers/video/console/bitblit.c
@@ -54,132 +54,25 @@ static void bit_clear(struct vc_data *vc, struct fb_info *info, int sy,
info->fbops->fb_fillrect(info, ®ion);
}
-static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info,
- const u16 *s, u32 attr, u32 cnt,
- u32 d_pitch, u32 s_pitch, u32 cellsize,
- struct fb_image *image, u8 *buf, u8 *dst)
-{
- u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
- u32 idx = vc->vc_font.width >> 3;
- u8 *src;
-
- while (cnt--) {
- src = vc->vc_font.data + (scr_readw(s++)&
- charmask)*cellsize;
-
- if (attr) {
- fbdraw_update_attr(buf, src, attr, &vc->vc_font);
- src = buf;
- }
-
- if (likely(idx = 1))
- __fb_pad_aligned_buffer(dst, d_pitch, src, idx,
- image->height);
- else
- fb_pad_aligned_buffer(dst, d_pitch, src, idx,
- image->height);
-
- dst += s_pitch;
- }
-
- info->fbops->fb_imageblit(info, image);
-}
-
-static inline void bit_putcs_unaligned(struct vc_data *vc,
- struct fb_info *info, const u16 *s,
- u32 attr, u32 cnt, u32 d_pitch,
- u32 s_pitch, u32 cellsize,
- struct fb_image *image, u8 *buf,
- u8 *dst)
-{
- u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff;
- u32 shift_low = 0, mod = vc->vc_font.width % 8;
- u32 shift_high = 8;
- u32 idx = vc->vc_font.width >> 3;
- u8 *src;
-
- while (cnt--) {
- src = vc->vc_font.data + (scr_readw(s++)&
- charmask)*cellsize;
-
- if (attr) {
- fbdraw_update_attr(buf, src, attr, &vc->vc_font);
- src = buf;
- }
-
- fb_pad_unaligned_buffer(dst, d_pitch, src, idx,
- image->height, shift_high,
- shift_low, mod);
- shift_low += mod;
- dst += (shift_low >= 8) ? s_pitch : s_pitch - 1;
- shift_low &= 7;
- shift_high = 8 - shift_low;
- }
-
- info->fbops->fb_imageblit(info, image);
-
-}
-
static void bit_putcs(struct vc_data *vc, struct fb_info *info,
const unsigned short *s, int count, int yy, int xx,
int fg, int bg)
{
- struct fb_image image;
- u32 width = DIV_ROUND_UP(vc->vc_font.width, 8);
- u32 cellsize = width * vc->vc_font.height;
- u32 maxcnt = info->pixmap.size/cellsize;
- u32 scan_align = info->pixmap.scan_align - 1;
- u32 buf_align = info->pixmap.buf_align - 1;
- u32 mod = vc->vc_font.width % 8, cnt, pitch, size;
+ u16 *buf;
+ int i;
u32 attribute = get_attribute(info, scr_readw(s));
- u8 *dst, *buf = NULL;
- image.fg_color = fg;
- image.bg_color = bg;
- image.dx = xx * vc->vc_font.width;
- image.dy = yy * vc->vc_font.height;
- image.height = vc->vc_font.height;
- image.depth = 1;
+ buf = kmalloc(sizeof(*buf) * count, GFP_KERNEL);
+ if (!buf)
+ return;
- if (attribute) {
- buf = kmalloc(cellsize, GFP_KERNEL);
- if (!buf)
- return;
- }
-
- while (count) {
- if (count > maxcnt)
- cnt = maxcnt;
- else
- cnt = count;
-
- image.width = vc->vc_font.width * cnt;
- pitch = DIV_ROUND_UP(image.width, 8) + scan_align;
- pitch &= ~scan_align;
- size = pitch * image.height + buf_align;
- size &= ~buf_align;
- dst = fb_get_buffer_offset(info, &info->pixmap, size);
- image.data = dst;
-
- if (!mod)
- bit_putcs_aligned(vc, info, s, attribute, cnt, pitch,
- width, cellsize, &image, buf, dst);
- else
- bit_putcs_unaligned(vc, info, s, attribute, cnt,
- pitch, width, cellsize, &image,
- buf, dst);
-
- image.dx += cnt * vc->vc_font.width;
- count -= cnt;
- s += cnt;
- }
+ for (i = 0; i < count; ++i)
+ buf[i] = scr_readw(s++);
- /* buf is always NULL except when in monochrome mode, so in this case
- it's a gain to check buf against NULL even though kfree() handles
- NULL pointers just fine */
- if (unlikely(buf))
- kfree(buf);
+ fbdraw_font(info, &vc->vc_font, vc->vc_hi_font_mask, xx, yy, fg, bg,
+ attribute, buf, count);
+ kfree(buf);
}
static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
diff --git a/drivers/video/console/fbdraw.c b/drivers/video/console/fbdraw.c
index aa18f7e..f7c3da7 100644
--- a/drivers/video/console/fbdraw.c
+++ b/drivers/video/console/fbdraw.c
@@ -41,6 +41,131 @@ void fbdraw_update_attr(u8 *dst, const u8 *src, int attribute,
}
EXPORT_SYMBOL_GPL(fbdraw_update_attr);
+static inline void bit_putcs_aligned(struct fb_info *info, bool hi_font,
+ struct console_font *font, u32 attribute,
+ u32 d_pitch, u32 s_pitch, u32 cellsize,
+ struct fb_image *image, u8 *buf, u8 *dst,
+ const u16 *chars, size_t cnt)
+{
+ u16 charmask = hi_font ? 0x1ff : 0xff;
+ u32 idx = font->width >> 3;
+ u8 *src;
+
+ while (cnt--) {
+ src = font->data + ((*chars++) & charmask) * cellsize;
+
+ if (attribute) {
+ fbdraw_update_attr(buf, src, attribute, font);
+ src = buf;
+ }
+
+ if (likely(idx = 1))
+ __fb_pad_aligned_buffer(dst, d_pitch, src, idx,
+ image->height);
+ else
+ fb_pad_aligned_buffer(dst, d_pitch, src, idx,
+ image->height);
+
+ dst += s_pitch;
+ }
+
+ info->fbops->fb_imageblit(info, image);
+}
+
+static inline void bit_putcs_unaligned(struct fb_info *info, bool hi_font,
+ struct console_font *font, u32 attribute,
+ u32 d_pitch, u32 s_pitch, u32 cellsize,
+ struct fb_image *image, u8 *buf, u8 *dst,
+ const u16 *chars, size_t cnt)
+{
+ u16 charmask = hi_font ? 0x1ff : 0xff;
+ u32 shift_low = 0, mod = font->width % 8;
+ u32 shift_high = 8;
+ u32 idx = font->width >> 3;
+ u8 *src;
+
+ while (cnt--) {
+ src = font->data + ((*chars++) & charmask) * cellsize;
+
+ if (attribute) {
+ fbdraw_update_attr(buf, src, attribute, font);
+ src = buf;
+ }
+
+ fb_pad_unaligned_buffer(dst, d_pitch, src, idx,
+ image->height, shift_high,
+ shift_low, mod);
+ shift_low += mod;
+ dst += (shift_low >= 8) ? s_pitch : s_pitch - 1;
+ shift_low &= 7;
+ shift_high = 8 - shift_low;
+ }
+
+ info->fbops->fb_imageblit(info, image);
+}
+
+void fbdraw_font(struct fb_info *info, struct console_font *font, bool hi_font,
+ unsigned int xpos, unsigned int ypos, int fg, int bg,
+ u32 attribute, const u16 *chars, size_t count)
+{
+ struct fb_image image;
+ u32 width = DIV_ROUND_UP(font->width, 8);
+ u32 cellsize = width * font->height;
+ u32 maxcnt = info->pixmap.size / cellsize;
+ u32 scan_align = info->pixmap.scan_align - 1;
+ u32 buf_align = info->pixmap.buf_align - 1;
+ u32 mod = font->width % 8, cnt, pitch, size;
+ u8 *dst, *buf = NULL;
+
+ image.fg_color = fg;
+ image.bg_color = bg;
+ image.dx = xpos * font->width;
+ image.dy = ypos * font->height;
+ image.height = font->height;
+ image.depth = 1;
+
+ if (attribute) {
+ buf = kmalloc(cellsize, GFP_KERNEL);
+ if (!buf)
+ return;
+ }
+
+ while (count) {
+ if (count > maxcnt)
+ cnt = maxcnt;
+ else
+ cnt = count;
+
+ image.width = font->width * cnt;
+ pitch = DIV_ROUND_UP(image.width, 8) + scan_align;
+ pitch &= ~scan_align;
+ size = pitch * image.height + buf_align;
+ size &= ~buf_align;
+ dst = fb_get_buffer_offset(info, &info->pixmap, size);
+ image.data = dst;
+
+ if (!mod)
+ bit_putcs_aligned(info, hi_font, font, attribute,
+ pitch, width, cellsize, &image, buf,
+ dst, chars, cnt);
+ else
+ bit_putcs_unaligned(info, hi_font, font, attribute,
+ pitch, width, cellsize, &image, buf,
+ dst, chars, cnt);
+
+ image.dx += cnt * font->width;
+ count -= cnt;
+ chars += cnt;
+ }
+
+ /* buf is always NULL except when in monochrome mode, so in this case
+ it's a gain to check buf against NULL even though kfree() handles
+ NULL pointers just fine */
+ if (unlikely(buf))
+ kfree(buf);
+}
+EXPORT_SYMBOL_GPL(fbdraw_font);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("David Herrmann <dh.herrmann@googlemail.com>");
MODULE_DESCRIPTION("Framebuffer helpers for image draw-operations");
diff --git a/drivers/video/console/fbdraw.h b/drivers/video/console/fbdraw.h
index 77edd7f..b9f1ffa 100644
--- a/drivers/video/console/fbdraw.h
+++ b/drivers/video/console/fbdraw.h
@@ -23,4 +23,8 @@
void fbdraw_update_attr(u8 *dst, const u8 *src, int attribute,
struct console_font *font);
+void fbdraw_font(struct fb_info *info, struct console_font *font, bool hi_font,
+ unsigned int xpos, unsigned int ypos, int fg, int bg,
+ u32 attribute, const u16 *chars, size_t count);
+
#endif /* _VIDEO_FBDRAW_H */
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 01/11] fbcon: move update_attr() into separate source file
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 we want to use update_attr() independently from fbcon, we need to split
it off from bitblit.c and fbcon.h. Therefore, introduce a new header and
source file (fbdraw.[ch]) which does not depende on vc_* and fbcon_*
structures in any way.
This does not introduce any new code nor does it make the paths deeper,
it simply splits the function off.
The other update_attr() functions (inside the rotation sources) seem
similar but are significantly different and I haven't found a way to merge
them efficiently (which is probably the reason why they are split off
now). Furthermore, I do not intend to use them in the coming code so there
is no need to split them off.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/Makefile | 3 ++-
drivers/video/console/bitblit.c | 26 +++--------------------
drivers/video/console/fbcon.h | 5 +----
drivers/video/console/fbdraw.c | 46 +++++++++++++++++++++++++++++++++++++++++
drivers/video/console/fbdraw.h | 26 +++++++++++++++++++++++
5 files changed, 78 insertions(+), 28 deletions(-)
create mode 100644 drivers/video/console/fbdraw.c
create mode 100644 drivers/video/console/fbdraw.h
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index a862e91..9a52226 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -25,7 +25,8 @@ obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
-obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o
+obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o \
+ fbdraw.o
ifeq ($(CONFIG_FB_TILEBLITTING),y)
obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
endif
diff --git a/drivers/video/console/bitblit.c b/drivers/video/console/bitblit.c
index 28b1a83..6ec2905 100644
--- a/drivers/video/console/bitblit.c
+++ b/drivers/video/console/bitblit.c
@@ -22,26 +22,6 @@
/*
* Accelerated handlers.
*/
-static void update_attr(u8 *dst, u8 *src, int attribute,
- struct vc_data *vc)
-{
- int i, offset = (vc->vc_font.height < 10) ? 1 : 2;
- int width = DIV_ROUND_UP(vc->vc_font.width, 8);
- unsigned int cellsize = vc->vc_font.height * width;
- u8 c;
-
- offset = cellsize - (offset * width);
- for (i = 0; i < cellsize; i++) {
- c = src[i];
- if (attribute & FBCON_ATTRIBUTE_UNDERLINE && i >= offset)
- c = 0xff;
- if (attribute & FBCON_ATTRIBUTE_BOLD)
- c |= c >> 1;
- if (attribute & FBCON_ATTRIBUTE_REVERSE)
- c = ~c;
- dst[i] = c;
- }
-}
static void bit_bmove(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int dy, int dx, int height, int width)
@@ -88,7 +68,7 @@ static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info,
charmask)*cellsize;
if (attr) {
- update_attr(buf, src, attr, vc);
+ fbdraw_update_attr(buf, src, attr, &vc->vc_font);
src = buf;
}
@@ -123,7 +103,7 @@ static inline void bit_putcs_unaligned(struct vc_data *vc,
charmask)*cellsize;
if (attr) {
- update_attr(buf, src, attr, vc);
+ fbdraw_update_attr(buf, src, attr, &vc->vc_font);
src = buf;
}
@@ -275,7 +255,7 @@ static void bit_cursor(struct vc_data *vc, struct fb_info *info, int mode,
return;
kfree(ops->cursor_data);
ops->cursor_data = dst;
- update_attr(dst, src, attribute, vc);
+ fbdraw_update_attr(dst, src, attribute, &vc->vc_font);
src = dst;
}
diff --git a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
index 6bd2e0c..8623bac 100644
--- a/drivers/video/console/fbcon.h
+++ b/drivers/video/console/fbcon.h
@@ -16,6 +16,7 @@
#include <linux/vt_kern.h>
#include <asm/io.h>
+#include "fbdraw.h"
#define FBCON_FLAGS_INIT 1
#define FBCON_FLAGS_CURSOR_TIMER 2
@@ -219,10 +220,6 @@ extern void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info);
extern void fbcon_set_bitops(struct fbcon_ops *ops);
extern int soft_cursor(struct fb_info *info, struct fb_cursor *cursor);
-#define FBCON_ATTRIBUTE_UNDERLINE 1
-#define FBCON_ATTRIBUTE_REVERSE 2
-#define FBCON_ATTRIBUTE_BOLD 4
-
static inline int real_y(struct display *p, int ypos)
{
int rows = p->vrows;
diff --git a/drivers/video/console/fbdraw.c b/drivers/video/console/fbdraw.c
new file mode 100644
index 0000000..aa18f7e
--- /dev/null
+++ b/drivers/video/console/fbdraw.c
@@ -0,0 +1,46 @@
+/*
+ * Framebuffer helpers for image draw-operations
+ *
+ * Copyright (c) 2004 Antonino Daplas <adaplas @pol.net>
+ * Copyright (c) 2012 David Herrmann <dh.herrmann@googlemail.com>
+ *
+ * Originally from drivers/video/console/bitblit.c which itself originally is
+ * from the 'accel_*' routines in drivers/video/console/fbcon.c.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include <linux/console.h>
+#include <linux/fb.h>
+#include <linux/kd.h>
+#include <linux/module.h>
+#include <linux/string.h>
+#include "fbdraw.h"
+
+void fbdraw_update_attr(u8 *dst, const u8 *src, int attribute,
+ struct console_font *font)
+{
+ int i, offset = (font->height < 10) ? 1 : 2;
+ int width = DIV_ROUND_UP(font->width, 8);
+ unsigned int cellsize = font->height * width;
+ u8 c;
+
+ offset = cellsize - (offset * width);
+ for (i = 0; i < cellsize; i++) {
+ c = src[i];
+ if (attribute & FBCON_ATTRIBUTE_UNDERLINE && i >= offset)
+ c = 0xff;
+ if (attribute & FBCON_ATTRIBUTE_BOLD)
+ c |= c >> 1;
+ if (attribute & FBCON_ATTRIBUTE_REVERSE)
+ c = ~c;
+ dst[i] = c;
+ }
+}
+EXPORT_SYMBOL_GPL(fbdraw_update_attr);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Herrmann <dh.herrmann@googlemail.com>");
+MODULE_DESCRIPTION("Framebuffer helpers for image draw-operations");
diff --git a/drivers/video/console/fbdraw.h b/drivers/video/console/fbdraw.h
new file mode 100644
index 0000000..77edd7f
--- /dev/null
+++ b/drivers/video/console/fbdraw.h
@@ -0,0 +1,26 @@
+/*
+ * Framebuffer helpers for image draw-operations
+ *
+ * Copyright (c) 2012 David Herrmann <dh.herrmann@googlemail.com>
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#ifndef _VIDEO_FBDRAW_H
+#define _VIDEO_FBDRAW_H
+
+#include <linux/console.h>
+#include <linux/fb.h>
+#include <linux/kd.h>
+
+/* fbcon character attributes */
+#define FBCON_ATTRIBUTE_UNDERLINE 1
+#define FBCON_ATTRIBUTE_REVERSE 2
+#define FBCON_ATTRIBUTE_BOLD 4
+
+void fbdraw_update_attr(u8 *dst, const u8 *src, int attribute,
+ struct console_font *font);
+
+#endif /* _VIDEO_FBDRAW_H */
--
1.7.11.2
^ permalink raw reply related
* [PATCH v3 00/11] fblog: Framebuffer kernel log driver v3
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
Hi
This is revision 3 of the fblog driver. This driver is a replacement for fbcon
for systems that do not want/need CONFIG_VT. It simply prints the kernel log to
all connected framebuffers. Previous versions are available here:
v2: http://thread.gmane.org/gmane.linux.serial/8133
v1: http://marc.info/?l=linux-kernel&m\x133988465602225&w=2
This patchset is against linux-next from last week (Wednesday or Thursday).
I've fixed all issues that were reported last week. They were all minor
nitpicks:
- Changed EXPORT_SYMBOL to EXPORT_SYMBOL_GPL for exported fbdev functions
- Removed FBLOG_STR
- Added pr_fmt()
- Fixed two minor coding-style issues
- Fixed one possible subtle deadlock in device registration (switched locking
order)
If you want to test it but don't want to disable CONFIG_VT, simply remove the
dependency to !VT of fblog. This will cause both fblog and fbcon to draw to the
framebuffers but both draw only on changes so it will still be possible to debug
and test fblog.
It would be nice if someone could tell me what tree this will go through or how
I can get it into linux-next as I have no idea who is maintaining fbcon. If
there are other major or minor issues, please tell me so I can work on them.
I am also working on improving the render-path by using dma-buf and partial
redraws like fbcon. Furthermore, I will add a panic-handler so fblog draws
oopses/panics to the framebuffers even though it is disabled. However, I want to
get this basic driver in before making it more complex and making review too
hard.
Thanks! Regards
David
David Herrmann (11):
fbcon: move update_attr() into separate source file
fbcon: move bit_putcs() into separate source file
fblog: new framebuffer kernel log dummy driver
fbdev: export get_fb_info()/put_fb_info()
fblog: register one fblog object per framebuffer
fblog: open fb on registration
fblog: allow selecting fbs via sysfs
fblog: cache framebuffer BLANK and SUSPEND states
fblog: register console driver
fblog: draw console to framebuffers
MAINTAINERS: add fblog entry
MAINTAINERS | 6 +
drivers/video/Kconfig | 5 +-
drivers/video/Makefile | 2 +-
drivers/video/console/Kconfig | 37 ++-
drivers/video/console/Makefile | 4 +-
drivers/video/console/bitblit.c | 149 +--------
drivers/video/console/fbcon.h | 5 +-
drivers/video/console/fbdraw.c | 171 ++++++++++
drivers/video/console/fbdraw.h | 30 ++
drivers/video/console/fblog.c | 675 ++++++++++++++++++++++++++++++++++++++++
drivers/video/fbmem.c | 6 +-
include/linux/fb.h | 3 +
12 files changed, 935 insertions(+), 158 deletions(-)
create mode 100644 drivers/video/console/fbdraw.c
create mode 100644 drivers/video/console/fbdraw.h
create mode 100644 drivers/video/console/fblog.c
--
1.7.11.2
^ permalink raw reply
* [PATCH] fb: epson1355fb: Fix section mismatch
From: Alexander Shiyan @ 2012-07-15 7:32 UTC (permalink / raw)
To: linux-fbdev
This patch fixes "section mismatch" warning in the epson1355fb driver.
WARNING: vmlinux.o(.devinit.text+0x184): Section mismatch in reference from the function epson1355fb_probe() to the function .init.text:fetch_hw_state()
The function __devinit epson1355fb_probe() references
a function __init fetch_hw_state().
If fetch_hw_state is only used by epson1355fb_probe then
annotate fetch_hw_state with a matching annotation.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/video/epson1355fb.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/epson1355fb.c b/drivers/video/epson1355fb.c
index a268cbf..68b9b51 100644
--- a/drivers/video/epson1355fb.c
+++ b/drivers/video/epson1355fb.c
@@ -477,11 +477,11 @@ static __init unsigned int get_fb_size(struct fb_info *info)
return size;
}
-static int epson1355_width_tab[2][4] __initdata +static int epson1355_width_tab[2][4] __devinitdata { {4, 8, 16, -1}, {9, 12, 16, -1} };
-static int epson1355_bpp_tab[8] __initdata = { 1, 2, 4, 8, 15, 16 };
+static int epson1355_bpp_tab[8] __devinitdata = { 1, 2, 4, 8, 15, 16 };
-static void __init fetch_hw_state(struct fb_info *info, struct epson1355_par *par)
+static void __devinit fetch_hw_state(struct fb_info *info, struct epson1355_par *par)
{
struct fb_var_screeninfo *var = &info->var;
struct fb_fix_screeninfo *fix = &info->fix;
@@ -601,7 +601,7 @@ static int epson1355fb_remove(struct platform_device *dev)
return 0;
}
-int __devinit epson1355fb_probe(struct platform_device *dev)
+static int __devinit epson1355fb_probe(struct platform_device *dev)
{
struct epson1355_par *default_par;
struct fb_info *info;
--
1.7.3.4
^ permalink raw reply related
* dma-buf/fbdev: one-to-many support
From: David Herrmann @ 2012-07-14 14:10 UTC (permalink / raw)
To: dri-devel; +Cc: Sumit Semwal, linux-media, linux-fbdev
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.
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/
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Prashant Gaikwad @ 2012-07-13 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FFE4DD0.7020407@nvidia.com>
Hi,
On Thursday 12 July 2012 09:38 AM, Prashant Gaikwad wrote:
> On Wednesday 11 July 2012 07:33 PM, Rob Herring wrote:
>> On 07/11/2012 07:56 AM, Prashant Gaikwad wrote:
>>> Hi,
>>>
>>> I am working on DT binding for Tegra DVFS.
<snip>
>>> 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>;
>
>
> 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.
>
Does this explanation help?
Regards,
Prashant G
>> 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: Device tree binding for DVFS table
From: Mike Turquette @ 2012-07-13 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120713103408.GF9437@tbergstrom-lnx.Nvidia.com>
On 20120713-13:34, Peter De Schrijver wrote:
> Hi Mike,
>
> >
> > Peter,
> >
> > I agree with your observations in general, but I think some specificity
> > is needed:
> >
> > > + frequency/voltage relationships
> >
> > We should be clear that the voltage does NOT belong to the clock, but to
> > the device/module/IP block that consumes that clock. This is an
> > important detail since it means that a clock does not have a
> > corresponding table of voltages (e.g. one table per clock), but instead
> > a device has a table of voltages corresponding to each clock.
> >
>
> Or the other way around, a table of clock frequencies, 1 for each voltage.
>
ACK
You said what I meant to say. Some previous iterations of an
omap-specific dvfs api tried to use voltage as the unique key for
accessing frequency/voltage tables, and that can get really ugly for a
variety of reasons. Plus device drivers typically request performance
in Hertz (e.g. clk_set_rate), so exposing a voltage-centric interface to
them is generally useless.
The OPP library does some of this right (drivers/base/power/opp.c). It
keeps a list of tables on a per-device bases, which is a big step in the
right direction. Unfortunately it is lacking in other areas, such as
not specifying which clock corresponds to the to table. Thus a device
can only have one table and that table does not encode any information
about which clock to use (which is important for devices that use a mux
to change rate). The dvfs DT bindings should not repeat those mistakes.
> > This is very necessary when a single clock drives multiple devices which
> > are driven by separate voltage rails.
> >
>
> Ah ok. How does this work in practice? A device can only run at a given clock
> rate if all the rails are at a certain voltage?
>
More like an adjustable rate clock higher up the tree affects the rate
of multiple devices downstream, and those devices happen to be on
separate rails. Either way I think that the design should account for
this possibility.
Regards,
Mike
> > > + power rail constraints (eg voltage difference limit between 2 rails)
> >
> > This should come from regulator DT data and not anything DVFS-specific,
> > correct?
> >
>
> That's true. I think it can even be open-coded as this is a SoC internal
> thing. All boards using this SoC will have the same limits, so I see little
> reason to move this info to DT.
>
> > > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
> > > frequency)
> >
> > Yeah, after sending my email above yesterday I instantly regretted it.
> > It is true that *functional* clock dependencies are really the purview
> > of the device driver. E.g. for Device X to operate at FAST_SPEED, scale
> > functional_clk up to 200MHz and l3_ddr_clk up to 100MHz. On OMAP our
> > display subsystem block also has clock ratio rules that must be honored,
> > but it just open-coded.
> >
> > It is possible to model those in DT if we really want, but shouldn't be
> > a priority for these dvfs-specific bindings.
> >
>
> Agreed.
>
> Cheers,
>
> Peter.
^ permalink raw reply
* Re: Device tree binding for DVFS table
From: Peter De Schrijver @ 2012-07-13 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120712171016.GL2772@gmail.com>
Hi Mike,
>
> Peter,
>
> I agree with your observations in general, but I think some specificity
> is needed:
>
> > + frequency/voltage relationships
>
> We should be clear that the voltage does NOT belong to the clock, but to
> the device/module/IP block that consumes that clock. This is an
> important detail since it means that a clock does not have a
> corresponding table of voltages (e.g. one table per clock), but instead
> a device has a table of voltages corresponding to each clock.
>
Or the other way around, a table of clock frequencies, 1 for each voltage.
> This is very necessary when a single clock drives multiple devices which
> are driven by separate voltage rails.
>
Ah ok. How does this work in practice? A device can only run at a given clock
rate if all the rails are at a certain voltage?
> > + power rail constraints (eg voltage difference limit between 2 rails)
>
> This should come from regulator DT data and not anything DVFS-specific,
> correct?
>
That's true. I think it can even be open-coded as this is a SoC internal
thing. All boards using this SoC will have the same limits, so I see little
reason to move this info to DT.
> > + clock constraints (eg. clock x frequency must be a fixed ratio of clock y
> > frequency)
>
> Yeah, after sending my email above yesterday I instantly regretted it.
> It is true that *functional* clock dependencies are really the purview
> of the device driver. E.g. for Device X to operate at FAST_SPEED, scale
> functional_clk up to 200MHz and l3_ddr_clk up to 100MHz. On OMAP our
> display subsystem block also has clock ratio rules that must be honored,
> but it just open-coded.
>
> It is possible to model those in DT if we really want, but shouldn't be
> a priority for these dvfs-specific bindings.
>
Agreed.
Cheers,
Peter.
^ 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