* Re: [RFC 00/10] fblog: framebuffer kernel log driver
From: David Herrmann @ 2012-06-18 19:06 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
Hi
On Sun, Jun 17, 2012 at 12:04 AM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Hi
>
> As some might know I am working on making CONFIG_VT obsolete. But as a developer
> it is often useful to have a kernel-log on the screen during boot to debug many
> common kernel(-config) errors. However, without CONFIG_VT we cannot use the
> VGA/framebbufer consoles either. Therefore, I am working on a small driver
> called "fblog".
>
> This driver simply writes the kernel log to all connected framebuffers. It works
> similar to fbcon but removes all the complexity of the virtual terminals. There
> is a sysfs attribute called "active" that allows to enable/disable fblog so
> user-space can start an xserver or similar.
>
> The main purpose is debugging kernel boot problems. Therefore, it is not
> optimized for speed and I tried keeping it simple. I splitted the patches
> into 10 small chunks to make review easier.
>
> I would be glad if someone could review this and tell me whether this is
> something we could include in mainline or not.
>
>
> There are still some issues but apart from them it works fine on my
> machine (x86):
> - I register the fblog device during module_init and need to call
> module_get(). However, this means it is impossible to call "rmmod fblog" as
> fblog has a reference to itself. Using "rmmod -f fblog" works fine but is a
> bit ugly. Is there a nice way to fix this? Otherwise I would need to call
> device_get() in module_exit() if there is a pending user of the fblog-device
> even though I unregistered it.
> - I redraw all framebuffers while holding the console-lock. This may slow down
> machines with more than 2 framebuffers (like 10 or 20). However, as this is
> supposed to be a debug driver, I think I can ignore this? If someone wants
> to improve the redraw logic to avoid redrawing the whole screen all the
> time, I would be glad to include it in this patchset :)
> - I am really no expert regarding the framebuffer subsystem. So I would
> appreciate it if someone could comment whether I need to handle the events
> in a different way or whether it is ok the way it is now.
One additional issue:
With udlfb.c we have hotplug capable framebuffers. However, fbcon and
fblog currently never close a framebuffer if not explicitely requested
by user-space. Therefore, if a framebuffer device is removed, the
FB_EVENT_FB_UNREGISTER event will never be sent because fbcon/fblog
still have a reference to the framebuffer(-driver). Therefore, the
number of available fbs will grow until there are no more free
indices.
See dlfb_usb_disconnect() in udlfb.c for an example. It does not
invoke unregister_framebuffer() unless the last user closed the FB.
udlfb disables the console on its framebuffer devices to avoid this,
but this doesn't seem to be a good solution.
How about sending an FB_EVENT_FB_DISCONNECT event during unlink_framebuffer()?
This still doesn't force user-space to close /dev/fbX but it at least
will make it possible to fblog/fbcon to close the framebuffer. fbmem.c
can then still be modified to mark the open file as dead so user-space
will also close the device hopefully.
Regards
David
^ permalink raw reply
* Re: [PATCH 05/10] fblog: add framebuffer helpers
From: David Herrmann @ 2012-06-18 18:50 UTC (permalink / raw)
To: Bruno Prémont
Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
linux-kernel, Greg Kroah-Hartman
In-Reply-To: <20120617003334.765f6226@neptune.home>
Hi Bruno
On Sun, Jun 17, 2012 at 12:33 AM, Bruno Prémont
<bonbons@linux-vserver.org> wrote:
> On Sun, 17 June 2012 David Herrmann <dh.herrmann@googlemail.com> wrote:
>> These helpers scan the system for all available framebuffers and register
>> or unregister them. This is needed during startup and stopping fblog so we
>> are aware of all connected displays.
>>
>> The third helper handles mode changes by rescanning the mode and adjusting
>> the buffer size.
>>
>> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
>> ---
>> drivers/video/console/fblog.c | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
>> index e790971..7d4032e 100644
>> --- a/drivers/video/console/fblog.c
>> +++ b/drivers/video/console/fblog.c
>> @@ -399,6 +399,35 @@ static void fblog_unregister(struct fblog_fb *fb)
>> kfree(fb);
>> }
>>
>> +static void fblog_register_all(void)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < FB_MAX; ++i)
>> + fblog_register(registered_fb[i]);
>
> You should take registration_lock mutex for accessing registered_fb[],
> even better would be to make use of get_fb_info() and put_fb_info()
Indeed, I will change it to use get_fb_info()/put_fb_info().
Btw., is it safe to call console_lock() during
FB_EVENT_FB_(UN)REGISTERED? I definitely need the console lock when
calling fblog_register() but I am not sure whether all fb-drivers lock
the console during "(un)register_framebuffer()". Otherwise, I would
have to avoid redrawing the console inside of fblog_register().
>> +}
>> +
>> +static void fblog_unregister_all(void)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < FB_MAX; ++i)
>> + fblog_unregister(fblog_info2fb(registered_fb[i]));
>
> Same here.
>
> Though for unregistering I'm wondering why you still scan through
> registered_fb[], you should just scan your fblog_fbs[] array!
Oops, you're right. I will change it.
> But here again, make sure to have proper locking to not get races with
> registration of new framebuffers or removal of existing ones via
> notifications.
>
>> +}
>> +
>> +static void fblog_refresh(struct fblog_fb *fb)
>> +{
>> + unsigned int width, height;
>> +
>> + if (!fb || !fb->font)
>> + return;
>> +
>> + width = fb->info->var.xres / fb->font->width;
>> + height = fb->info->var.yres / fb->font->height;
>> + fblog_buf_resize(&fb->buf, width, height);
>> + fblog_redraw(fb);
>> +}
>> +
>
> All these new functions are still unused, for easier following of your
> patch series it would be nice to have them connected when they are
> introduced as otherwise on has to search all following patches for
> finding possible users.
I have to admit the split was crap. I am sorry. I will recreate the
patchset with a proper split. Thanks!
>> static int __init fblog_init(void)
>> {
>> return 0;
>
> Bruno
Thanks for reviewing, regards
David
^ permalink raw reply
* Re: [PATCH 04/10] fblog: implement fblog_redraw()
From: David Herrmann @ 2012-06-18 18:36 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
linux-kernel, Greg Kroah-Hartman
In-Reply-To: <20120616233526.7f830890@pyramind.ukuu.org.uk>
Hi Alan
On Sun, Jun 17, 2012 at 12:35 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Sun, 17 Jun 2012 00:04:20 +0200
> David Herrmann <dh.herrmann@googlemail.com> wrote:
>
>> This mostly copies the functionality from drivers/video/console/bitblit.c
>> so we can draw the console content on all available framebuffers.
>>
>> All speed optimizations have been removed for simplicity. The original
>> code depends heavily on CONFIG_VT so we cannot share the codebase here.
>
> No. That means we've got two sets of code to maintain not one. Fix the
> dependancy.
>
> Pull the relevant subset of struct vc_data into another struct
> Make struct vc_data be
>
> struct vc_data {
> struct vc_whatever
> rest
> }
It's a bit more complex as we cannot call scr_read() either. Hence, I
need to assemble the array of printed characters before calling the
redraw functions. But that should be feasible, too. I just need to
figure out how to avoid heavy allocations during redraw to avoid
slowdowns.
If there are no objections I will send these patches as a separate
patchset as we can apply it without fblog.
> Alan
Thanks for reviewing
David
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 13:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340025071.4012.27.camel@deskari>
On 18 June 2012 18:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
>> On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>>
>> >> So preferably I would move request_threaded_irq() to after
>> >> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
>> >
>> > No, you can't move the check. If you move it, the HPD state could change
>> > between the check and the request_irq, and we'd miss it.
>> >
>> Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?
>
> No, if we haven't requested the irq yet. So what could happen:
>
> - initially the cable is unplugged
> - ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is
> done as cable is unplugged
> - cable plugged in
> - ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the
> cable's state doesn't change.
>
> We wouldn't know that cable is actually plugged in at that point.
>
I see, you mean physically (un)plugging the cable could race with phy_enable.
OK, I'll revise the changelog for this patch and submit another patch
converting the spinlock to mutex.
Thanks.
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 13:19 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340022276.4012.23.camel@deskari>
On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>> So preferably I would move request_threaded_irq() to after
>> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
>
> No, you can't move the check. If you move it, the HPD state could change
> between the check and the request_irq, and we'd miss it.
>
Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 13:11 UTC (permalink / raw)
To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhdoEjyf0ejjsJJpznt83bTJTR0UW3aqaYAZdcm01GBp_A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Mon, 2012-06-18 at 18:37 +0530, Jassi Brar wrote:
> On 18 June 2012 17:54, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
>
> >> So preferably I would move request_threaded_irq() to after
> >> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
> >
> > No, you can't move the check. If you move it, the HPD state could change
> > between the check and the request_irq, and we'd miss it.
> >
> Wouldn't we then get an irq, and hence another hdmi_check_hpd_state(), for that?
No, if we haven't requested the irq yet. So what could happen:
- initially the cable is unplugged
- ti_hdmi_4xxx_phy_enable() calls hdmi_check_hpd_state(), nothing is
done as cable is unplugged
- cable plugged in
- ti_hdmi_4xxx_phy_enable() calls request_irq. No irq raised, as the
cable's state doesn't change.
We wouldn't know that cable is actually plugged in at that point.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 12:24 UTC (permalink / raw)
To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhfJV6kYvSkU+4RGywv80A47=CxnoCy2rr-x=c2LFDGb7A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Mon, 2012-06-18 at 17:16 +0530, Jassi Brar wrote:
> On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
>
> >> BTW, coming to think about it, I am not sure what we need the
> >> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
> >> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> >> expensive and is already unprotected elsewhere.
> >
> > It's needed when enabling the hdmi output. In phy_enable() the irq is
> > requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> > So there's a chance to run hdmi_check_hpd_state() from both
> > hpd-interrupt and phy_enable() at the same time.
> >
> > The hdmi_set_phy_pwr() is not called in many places, but I think there's
> > indeed a problem there. It is called after free_irq(), but I think
> > (guess) the irq handler could still be running after free_irq. So those
> > should be protected by the same spinlock too.
> >
> You know TI HDMI better than I do, so I assume your concerns are valid.
> So preferably I would move request_threaded_irq() to after
> hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
No, you can't move the check. If you move it, the HPD state could change
between the check and the request_irq, and we'd miss it.
> spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
> want irqs disabled so long as it takes for phy to power on/off).
Yes, I guess a mutex is better.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 11:58 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340016865.4012.10.camel@deskari>
On 18 June 2012 16:24, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
>> BTW, coming to think about it, I am not sure what we need the
>> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
>> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
>> expensive and is already unprotected elsewhere.
>
> It's needed when enabling the hdmi output. In phy_enable() the irq is
> requested first, and then the phy_enable() runs hdmi_check_hpd_state().
> So there's a chance to run hdmi_check_hpd_state() from both
> hpd-interrupt and phy_enable() at the same time.
>
> The hdmi_set_phy_pwr() is not called in many places, but I think there's
> indeed a problem there. It is called after free_irq(), but I think
> (guess) the irq handler could still be running after free_irq. So those
> should be protected by the same spinlock too.
>
You know TI HDMI better than I do, so I assume your concerns are valid.
So preferably I would move request_threaded_irq() to after
hdmi_check_hpd_state() in ti_hdmi_4xxx_phy_enable() and convert the
spin_lock_irqsave() in hdmi_check_hpd_state() to some mutex (we don't
want irqs disabled so long as it takes for phy to power on/off).
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 10:54 UTC (permalink / raw)
To: Jassi Brar; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAJe_ZhdhBre8DUVNpawF6X5P+QSiMarkt3WUvbJ=RPcmpX3TPA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Mon, 2012-06-18 at 15:42 +0530, Jassi Brar wrote:
> On 18 June 2012 13:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >>
> >> Explicitly maintaining HDMI phy power state using a flag is prone to
> >> race and un-necessary when we have a zero-cost alternative of checking
> >> the state before trying to set it.
> >
> > Why would reading the value from the register be any less racy than
> > keeping it in memory?
> >
> Racy in the sense that h/w doesn't always hop states according to what
> a "state" variable would expect it to.
But I don't think the status register is any better. If I'm not
mistaken, when you set the phy pwr to, say, TXON, the status register
will still show the old value. The status register will be right only
after the HW is actually at TXON state.
In this case the hdmi_set_phy_pwr() function will anyway wait until the
HW has changed states, so both approaches should work just fine.
> Also in this case, phy_tx_enabled modification is unprotected in
> ti_hdmi_4xxx_phy_disable().
So is hdmi_set_phy_pwr(). Note that I'm not saying the current approach
is not racy, but your patch doesn't make it any less racy.
> BTW, coming to think about it, I am not sure what we need the
> spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
> can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
> expensive and is already unprotected elsewhere.
It's needed when enabling the hdmi output. In phy_enable() the irq is
requested first, and then the phy_enable() runs hdmi_check_hpd_state().
So there's a chance to run hdmi_check_hpd_state() from both
hpd-interrupt and phy_enable() at the same time.
The hdmi_set_phy_pwr() is not called in many places, but I think there's
indeed a problem there. It is called after free_irq(), but I think
(guess) the irq handler could still be running after free_irq. So those
should be protected by the same spinlock too.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jassi Brar @ 2012-06-18 10:24 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1340007094.1859.3.camel@lappyti>
On 18 June 2012 13:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> Explicitly maintaining HDMI phy power state using a flag is prone to
>> race and un-necessary when we have a zero-cost alternative of checking
>> the state before trying to set it.
>
> Why would reading the value from the register be any less racy than
> keeping it in memory?
>
Racy in the sense that h/w doesn't always hop states according to what
a "state" variable would expect it to.
Also in this case, phy_tx_enabled modification is unprotected in
ti_hdmi_4xxx_phy_disable().
BTW, coming to think about it, I am not sure what we need the
spin_lock_irqsave() protection for in hdmi_check_hpd_state() ? It
can't control HPD gpio state change and hdmi_set_phy_pwr() seems too
expensive and is already unprotected elsewhere.
> And reading from memory is probably much faster
> than reading from an HDMI register, so I'm not sure what you mean with
> zero-cost.
>
Zero-cost in terms of space and bother :)
> But I guess it is simpler, so in that sense the patch is ok. But please
> revise the description.
>
OK, will do.
Thanks.
^ permalink raw reply
* Re: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Tomi Valkeinen @ 2012-06-18 8:11 UTC (permalink / raw)
Cc: linux-omap, linux-fbdev, Jassi Brar
In-Reply-To: <1339797701-11540-1-git-send-email-jaswinder.singh@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
On Sat, 2012-06-16 at 03:31 +0530, jaswinder.singh@linaro.org wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
>
> Explicitly maintaining HDMI phy power state using a flag is prone to
> race and un-necessary when we have a zero-cost alternative of checking
> the state before trying to set it.
Why would reading the value from the register be any less racy than
keeping it in memory? And reading from memory is probably much faster
than reading from an HDMI register, so I'm not sure what you mean with
zero-cost.
But I guess it is simpler, so in that sense the patch is ok. But please
revise the description.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 1/1] video: exynos_dp: Fix compilation warning
From: Jingoo Han @ 2012-06-18 5:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1339995317-17788-1-git-send-email-sachin.kamat@linaro.org>
On Mon, June 18, 2012 at 1:55 PM, Sachin Kamat wrote:
> Fixes the following warning:
> drivers/video/exynos/exynos_dp_core.c: In function ‘exynos_dp_set_link_train’:
> drivers/video/exynos/exynos_dp_core.c:529:18: warning: ‘reg’ may be used uninitialized in this function
> [-Wuninitialized]
> drivers/video/exynos/exynos_dp_core.c:395:6: note: ‘reg’ was declared here
This warning was already reported and patch was submitted by Olof Johansson.
I will check and fix it later.
Thank you.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> 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 a36b2d2..017c727 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -392,7 +392,7 @@ static unsigned int exynos_dp_get_lane_link_training(
> struct exynos_dp_device *dp,
> int lane)
> {
> - u32 reg;
> + u32 reg = 0;
>
> switch (lane) {
> case 0:
> --
> 1.7.4.1
^ permalink raw reply
* [PATCH 1/1] video: exynos_dp: Fix compilation warning
From: Sachin Kamat @ 2012-06-18 5:07 UTC (permalink / raw)
To: linux-fbdev
Fixes the following warning:
drivers/video/exynos/exynos_dp_core.c: In function ‘exynos_dp_set_link_train’:
drivers/video/exynos/exynos_dp_core.c:529:18: warning: ‘reg’ may be used uninitialized in this function [-Wuninitialized]
drivers/video/exynos/exynos_dp_core.c:395:6: note: ‘reg’ was declared here
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
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 a36b2d2..017c727 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -392,7 +392,7 @@ static unsigned int exynos_dp_get_lane_link_training(
struct exynos_dp_device *dp,
int lane)
{
- u32 reg;
+ u32 reg = 0;
switch (lane) {
case 0:
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 4/6] pwm_backlight: Add deferred probe support
From: Simon Horman @ 2012-06-18 2:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1339773427-29508-5-git-send-email-laurent.pinchart@ideasonboard.com>
On Fri, Jun 15, 2012 at 05:17:05PM +0200, Laurent Pinchart wrote:
> If the PWM instance is not available yet at probe time, request a
> deferred probe.
>
> A better way to fix might be to create a PWM subsystem (possible
> integrated into the GPIO subsystem) to support generic PWM objects, and
> make sure the subsystem gets initialized first.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: linux-fbdev@vger.kernel.org
Tested-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* RE: [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: Jingoo Han @ 2012-06-17 23:44 UTC (permalink / raw)
To: jaswinder.singh, tomi.valkeinen
Cc: linux-omap, linux-fbdev, 'Mythri P K'
In-Reply-To: <1339797701-11540-1-git-send-email-jaswinder.singh@linaro.org>
On Saturday 16 June 2012 7:02:00 jaswinder.singh wrote:
> From: Jassi Brar <jaswinder.singh@linaro.org>
>
> Explicitly maintaining HDMI phy power state using a flag is prone to
> race and un-necessary when we have a zero-cost alternative of checking
> the state before trying to set it.
CC'ed 'Mythri P K' as the author for OMAP HDMI.
Hi Jassi, long time no see.
This patch looks good.
If there is no problem, checking register is better way.
Best regards,
Jingoo Han.
>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
> drivers/video/omap2/dss/ti_hdmi.h | 1 -
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 11 ++++-------
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/ti_hdmi.h b/drivers/video/omap2/dss/ti_hdmi.h
> index e734cb4..d174ca1 100644
> --- a/drivers/video/omap2/dss/ti_hdmi.h
> +++ b/drivers/video/omap2/dss/ti_hdmi.h
> @@ -177,7 +177,6 @@ struct hdmi_ip_data {
>
> /* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
> int hpd_gpio;
> - bool phy_tx_enabled;
> };
> int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
> void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
> diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> index 4dae1b2..3fa3d98 100644
> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> @@ -157,6 +157,10 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data)
> /* PHY_PWR_CMD */
> static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
> {
> + /* Return if already the state */
> + if (REG_GET(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, 5, 4) = val)
> + return 0;
> +
> /* Command for power control of HDMI PHY */
> REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
>
> @@ -241,11 +245,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
>
> hpd = gpio_get_value(ip_data->hpd_gpio);
>
> - if (hpd = ip_data->phy_tx_enabled) {
> - spin_unlock_irqrestore(&phy_tx_lock, flags);
> - return 0;
> - }
> -
> if (hpd)
> r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
> else
> @@ -257,7 +256,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
> goto err;
> }
>
> - ip_data->phy_tx_enabled = hpd;
> err:
> spin_unlock_irqrestore(&phy_tx_lock, flags);
> return r;
> @@ -327,7 +325,6 @@ void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data)
> free_irq(gpio_to_irq(ip_data->hpd_gpio), ip_data);
>
> hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
> - ip_data->phy_tx_enabled = false;
> }
>
> static int hdmi_core_ddc_init(struct hdmi_ip_data *ip_data)
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 4/6] pwm_backlight: Add deferred probe support
From: Jingoo Han @ 2012-06-17 23:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1339773427-29508-5-git-send-email-laurent.pinchart@ideasonboard.com>
On Saturday 16 June 2012 12:17:00 Laurent Pinchart wrote:
>
> If the PWM instance is not available yet at probe time, request a
> deferred probe.
>
> A better way to fix might be to create a PWM subsystem (possible
> integrated into the GPIO subsystem) to support generic PWM objects, and
> make sure the subsystem gets initialized first.
Cc'ed Grant Likely, Linus Walleij
Hi Laurent,
Yes, you're right. PWM subsystem is necessary to avoid the problem that PWM is not available at probe time.
Anyway, this patch looks good. Good luck.
Best regards,
Jingoo Han
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/backlight/pwm_bl.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 342b7d7..5df8b91 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -121,6 +121,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> if (IS_ERR(pb->pwm)) {
> dev_err(&pdev->dev, "unable to request PWM for backlight\n");
> ret = PTR_ERR(pb->pwm);
> + if (ret = -ENODEV)
> + ret = -EPROBE_DEFER;
> goto err_alloc;
> } else
> dev_dbg(&pdev->dev, "got pwm for backlight\n");
> --
> 1.7.3.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 04/10] fblog: implement fblog_redraw()
From: Alan Cox @ 2012-06-16 22:35 UTC (permalink / raw)
To: David Herrmann
Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
linux-kernel, Greg Kroah-Hartman
In-Reply-To: <1339884266-9201-5-git-send-email-dh.herrmann@googlemail.com>
On Sun, 17 Jun 2012 00:04:20 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> This mostly copies the functionality from drivers/video/console/bitblit.c
> so we can draw the console content on all available framebuffers.
>
> All speed optimizations have been removed for simplicity. The original
> code depends heavily on CONFIG_VT so we cannot share the codebase here.
No. That means we've got two sets of code to maintain not one. Fix the
dependancy.
Pull the relevant subset of struct vc_data into another struct
Make struct vc_data be
struct vc_data {
struct vc_whatever
rest
}
Alan
^ permalink raw reply
* Re: [PATCH 05/10] fblog: add framebuffer helpers
From: Bruno Prémont @ 2012-06-16 22:33 UTC (permalink / raw)
To: David Herrmann
Cc: linux-serial, Florian Tobias Schandinat, linux-fbdev,
linux-kernel, Greg Kroah-Hartman
In-Reply-To: <1339884266-9201-6-git-send-email-dh.herrmann@googlemail.com>
On Sun, 17 June 2012 David Herrmann <dh.herrmann@googlemail.com> wrote:
> These helpers scan the system for all available framebuffers and register
> or unregister them. This is needed during startup and stopping fblog so we
> are aware of all connected displays.
>
> The third helper handles mode changes by rescanning the mode and adjusting
> the buffer size.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> drivers/video/console/fblog.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
> index e790971..7d4032e 100644
> --- a/drivers/video/console/fblog.c
> +++ b/drivers/video/console/fblog.c
> @@ -399,6 +399,35 @@ static void fblog_unregister(struct fblog_fb *fb)
> kfree(fb);
> }
>
> +static void fblog_register_all(void)
> +{
> + int i;
> +
> + for (i = 0; i < FB_MAX; ++i)
> + fblog_register(registered_fb[i]);
You should take registration_lock mutex for accessing registered_fb[],
even better would be to make use of get_fb_info() and put_fb_info()
> +}
> +
> +static void fblog_unregister_all(void)
> +{
> + int i;
> +
> + for (i = 0; i < FB_MAX; ++i)
> + fblog_unregister(fblog_info2fb(registered_fb[i]));
Same here.
Though for unregistering I'm wondering why you still scan through
registered_fb[], you should just scan your fblog_fbs[] array!
But here again, make sure to have proper locking to not get races with
registration of new framebuffers or removal of existing ones via
notifications.
> +}
> +
> +static void fblog_refresh(struct fblog_fb *fb)
> +{
> + unsigned int width, height;
> +
> + if (!fb || !fb->font)
> + return;
> +
> + width = fb->info->var.xres / fb->font->width;
> + height = fb->info->var.yres / fb->font->height;
> + fblog_buf_resize(&fb->buf, width, height);
> + fblog_redraw(fb);
> +}
> +
All these new functions are still unused, for easier following of your
patch series it would be nice to have them connected when they are
introduced as otherwise on has to search all following patches for
finding possible users.
> static int __init fblog_init(void)
> {
> return 0;
Bruno
^ permalink raw reply
* [PATCH 10/10] fblog: add "activate" module parameter
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
This new parameter controls whether fblog is automatically activated when
it is loaded. This defaults to "true".
We can now compile with CONFIG_VT=n and CONFIG_FBLOG=y and control fblog
with fblog.activate=0/1 on the kernel command line to enable/disable
debugging.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 9d3b072..cabc550 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -94,6 +94,7 @@ struct fblog_fb {
static struct fblog_fb *fblog_fbs[FB_MAX];
static struct device *fblog_device;
static atomic_t fblog_active;
+static bool activate = 1;
static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
size_t height)
@@ -653,6 +654,12 @@ static int __init fblog_init(void)
register_console(&fblog_con_driver);
+ if (activate) {
+ console_lock();
+ fblog_activate();
+ console_unlock();
+ }
+
return 0;
err_fb:
@@ -677,6 +684,9 @@ static void __exit fblog_exit(void)
put_device(fblog_device);
}
+module_param(activate, bool, S_IRUGO);
+MODULE_PARM_DESC(activate, "Activate fblog by default");
+
module_init(fblog_init);
module_exit(fblog_exit);
MODULE_LICENSE("GPL");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/10] fblog: register all handlers on module-init
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
We now create a new "fblog" device when initializing the fblog module. We
register the "active" sysfs-file with it so user-space can now access
fblog. We also register the framebuffer-notifier and console-handler so
fblog is ready to go.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 59 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 79bfbcc..9d3b072 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -92,6 +92,7 @@ struct fblog_fb {
};
static struct fblog_fb *fblog_fbs[FB_MAX];
+static struct device *fblog_device;
static atomic_t fblog_active;
static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
@@ -609,13 +610,71 @@ static ssize_t fblog_dev_active_store(struct device *dev,
static DEVICE_ATTR(active, S_IRUGO | S_IWUSR | S_IWGRP, fblog_dev_active_show,
fblog_dev_active_store);
+static void fblog_dev_release(struct device *dev)
+{
+ kfree(dev);
+ module_put(THIS_MODULE);
+}
+
static int __init fblog_init(void)
{
+ int ret;
+
+ fblog_device = kzalloc(sizeof(*fblog_device), GFP_KERNEL);
+ if (!fblog_device) {
+ pr_err("fblog: cannot allocate device\n");
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ __module_get(THIS_MODULE);
+ device_initialize(fblog_device);
+ fblog_device->class = fb_class;
+ fblog_device->release = fblog_dev_release;
+ dev_set_name(fblog_device, "fblog");
+
+ ret = device_add(fblog_device);
+ if (ret) {
+ pr_err("fblog: cannot add device\n");
+ goto err_dev;
+ }
+
+ ret = fb_register_client(&fblog_notifier);
+ if (ret) {
+ pr_err("fblog: cannot register framebuffer notifier\n");
+ goto err_dev_rm;
+ }
+
+ ret = device_create_file(fblog_device, &dev_attr_active);
+ if (ret) {
+ pr_err("fblog: cannot create sysfs entry\n");
+ goto err_fb;
+ }
+
+ register_console(&fblog_con_driver);
+
return 0;
+
+err_fb:
+ fb_unregister_client(&fblog_notifier);
+err_dev_rm:
+ device_del(fblog_device);
+err_dev:
+ put_device(fblog_device);
+err_out:
+ return ret;
}
static void __exit fblog_exit(void)
{
+ unregister_console(&fblog_con_driver);
+ device_remove_file(fblog_device, &dev_attr_active);
+ device_del(fblog_device);
+ fb_unregister_client(&fblog_notifier);
+ console_lock();
+ fblog_deactivate();
+ console_unlock();
+ put_device(fblog_device);
}
module_init(fblog_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/10] fblog: react on framebuffer events
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
This provides an fb-notifier object that can be registered with the
framebuffer subsystem. We are then notified about events on all
framebuffers.
Most of the events are only of interest for fbcon so we can safely ignore
them. However, we need to handle REGISTERED/UNBIND to add new framebbufers
and we need to react on mode-changes (probably triggered by user-space).
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 113 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 113 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 5297eca..79bfbcc 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -449,6 +449,119 @@ static void fblog_deactivate(void)
fblog_unregister_all();
}
+static int fblog_event(struct notifier_block *self, unsigned long action,
+ void *data)
+{
+ struct fb_event *event = data;
+ struct fb_info *info = event->info;
+ struct fblog_fb *fb = fblog_info2fb(info);
+ int *blank;
+
+ if (action = 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 (really?). */
+ fblog_register(info);
+ return 0;
+ }
+
+ if (!fb)
+ return 0;
+
+ switch(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 (really?). */
+ /* ignore; see UNBIND */
+ 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?). */
+ fblog_unregister(fb);
+ 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. */
+ 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. */
+ clear_bit(FBLOG_SUSPENDED, &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. */
+ fblog_refresh(fb);
+ 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. */
+ blank = (int*)event->data;
+ if (*blank = FB_BLANK_UNBLANK)
+ clear_bit(FBLOG_BLANKED, &fb->flags);
+ else
+ set_bit(FBLOG_BLANKED, &fb->flags);
+ break;
+ case FB_EVENT_GET_REQ:
+ /* When fb_set_var() is called, this callback is called to get
+ * our display requirements. They are then compared with the
+ * display properties and only if they fulfill the requirements,
+ * the new mode is activated. The console-lock should be held
+ * while calling fb_set_var() so we can assume it is locked
+ * here. */
+ /* ignore */
+ break;
+ case FB_EVENT_CONBLANK:
+ /* This is sent by fbcon when doing a fake blank. That
+ * is, blanking the screen when the fb driver failed to perform
+ * an fb_blank(). It simply writes empty lines to the screen.
+ * We are not interested in this signal. We should also never
+ * run together with fbcon so this should never be catched. */
+ /* ignore */
+ break;
+ case FB_EVENT_GET_CONSOLE_MAP:
+ /* fallthrough */
+ case FB_EVENT_SET_CONSOLE_MAP:
+ /* Is there any reason why we should support this? We
+ * ignore it as we consider ourself not to be the classic linux
+ * console. Hence, this request is not targeted at us. */
+ /* ignore */
+ break;
+ case FB_EVENT_REMAP_ALL_CONSOLE:
+ /* What are we supposed to do here? Do we have to remap
+ * the primary device to the framebuffer given by \info? Like
+ * above we currently ignore it for the same reasons. */
+ /* ignore */
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block fblog_notifier = {
+ .notifier_call = fblog_event,
+};
+
static void fblog_con_write(struct console *con, const char *buf,
unsigned int len)
{
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/10] fblog: forward kernel log messages to all framebuffers
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
This provides a console-driver that forwards all log messages to all
framebuffers and redraws them.
To avoid redrawing multiple times in short intervals, we could use a
work-queue here by simply pushing the task onto the system work-queue.
However, fblog is not performance critical and only used for debugging so
we avoid the complexity for now. This may change in the future, though.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 9b05c56..5297eca 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -449,6 +449,25 @@ static void fblog_deactivate(void)
fblog_unregister_all();
}
+static void fblog_con_write(struct console *con, const char *buf,
+ unsigned int len)
+{
+ int i;
+
+ 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]);
+ }
+ }
+}
+
+static struct console fblog_con_driver = {
+ .name = "fblog",
+ .write = fblog_con_write,
+ .flags = CON_PRINTBUFFER | CON_ENABLED,
+};
+
static ssize_t fblog_dev_active_show(struct device *dev,
struct device_attribute *attr,
char *buf)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/10] fblog: allow enabling/disabling fblog on runtime
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
A sysfs file called "active" can be used to enable and disable fblog on
runtime. For example, the init-process can run "echo '0' >.../active"
after booting the system. This will allow other applications like X11 to
use the graphics subsystem. During shutdown, we can write '1' to get
system messages again.
When disabling fblog, we remove all framebuffers and will prevent new
hotplugged framebuffers from being added. When enabling fblog again, we
rescan the system for all framebuffers and resume operating.
The sysfs file is not registered, yet, as we do not have a "struct device"
yet. This will follow shortly, though.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
Documentation/ABI/testing/sysfs-fblog | 9 ++++++
drivers/video/console/fblog.c | 49 +++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-fblog
diff --git a/Documentation/ABI/testing/sysfs-fblog b/Documentation/ABI/testing/sysfs-fblog
new file mode 100644
index 0000000..596393c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-fblog
@@ -0,0 +1,9 @@
+What: /sys/class/graphics/fblog/active
+Date: June 2012
+KernelVersion: 3.6
+Contact: David Herrmann <dh.herrmann@googlemail.com>
+Description: Enable/Disable fblog. When setting this to 0, fblog will stop
+ writing to framebuffers and other applications can use the
+ graphics subsystem. When setting this to 1, fblog will rescan
+ the system for all framebuffers and resume drawing the kernel
+ log onto all framebuffers.
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 7d4032e..9b05c56 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -92,6 +92,7 @@ struct fblog_fb {
};
static struct fblog_fb *fblog_fbs[FB_MAX];
+static atomic_t fblog_active;
static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
size_t height)
@@ -338,6 +339,8 @@ static void fblog_register(struct fb_info *info)
const struct fb_videomode *mode;
unsigned int width, height;
+ if (!atomic_read(&fblog_active))
+ return;
if (!info || info->node < 0 || info->node >= FB_MAX)
return;
if (!registered_fb[info->node] || fblog_fbs[info->node])
@@ -428,6 +431,52 @@ static void fblog_refresh(struct fblog_fb *fb)
fblog_redraw(fb);
}
+static void fblog_activate(void)
+{
+ if (atomic_read(&fblog_active))
+ return;
+
+ atomic_set(&fblog_active, 1);
+ fblog_register_all();
+}
+
+static void fblog_deactivate(void)
+{
+ if (!atomic_read(&fblog_active))
+ return;
+
+ atomic_set(&fblog_active, 0);
+ fblog_unregister_all();
+}
+
+static ssize_t fblog_dev_active_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&fblog_active));
+}
+
+static ssize_t fblog_dev_active_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ unsigned long num;
+
+ num = simple_strtoul(buf, NULL, 10);
+ console_lock();
+ if (num)
+ fblog_activate();
+ else
+ fblog_deactivate();
+ console_unlock();
+
+ return count;
+}
+
+static DEVICE_ATTR(active, S_IRUGO | S_IWUSR | S_IWGRP, fblog_dev_active_show,
+ fblog_dev_active_store);
+
static int __init fblog_init(void)
{
return 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/10] fblog: add framebuffer helpers
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
These helpers scan the system for all available framebuffers and register
or unregister them. This is needed during startup and stopping fblog so we
are aware of all connected displays.
The third helper handles mode changes by rescanning the mode and adjusting
the buffer size.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index e790971..7d4032e 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -399,6 +399,35 @@ static void fblog_unregister(struct fblog_fb *fb)
kfree(fb);
}
+static void fblog_register_all(void)
+{
+ int i;
+
+ for (i = 0; i < FB_MAX; ++i)
+ fblog_register(registered_fb[i]);
+}
+
+static void fblog_unregister_all(void)
+{
+ int i;
+
+ for (i = 0; i < FB_MAX; ++i)
+ fblog_unregister(fblog_info2fb(registered_fb[i]));
+}
+
+static void fblog_refresh(struct fblog_fb *fb)
+{
+ unsigned int width, height;
+
+ if (!fb || !fb->font)
+ return;
+
+ width = fb->info->var.xres / fb->font->width;
+ height = fb->info->var.yres / fb->font->height;
+ fblog_buf_resize(&fb->buf, width, height);
+ fblog_redraw(fb);
+}
+
static int __init fblog_init(void)
{
return 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/10] fblog: implement fblog_redraw()
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
To: linux-serial
Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>
This mostly copies the functionality from drivers/video/console/bitblit.c
so we can draw the console content on all available framebuffers.
All speed optimizations have been removed for simplicity. The original
code depends heavily on CONFIG_VT so we cannot share the codebase here.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
drivers/video/console/fblog.c | 126 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 126 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 8038dcc..e790971 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -197,6 +197,131 @@ static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
}
}
+static void fblog_redraw_aligned(struct fblog_fb *fb, const char *s, u32 cnt,
+ u32 d_pitch, u32 s_pitch, u32 cellsize,
+ struct fb_image *image, u8 *dst)
+{
+ struct fb_info *info = fb->info;
+ const struct font_desc *font = fb->font;
+ u32 idx = font->width >> 3;
+ u8 *src;
+
+ while (cnt--) {
+ src = (void*)(font->data + (*s++ & 0xff) * cellsize);
+ fb_pad_aligned_buffer(dst, d_pitch, src, idx, image->height);
+ dst += s_pitch;
+ }
+
+ info->fbops->fb_imageblit(info, image);
+}
+
+static void fblog_redraw_unaligned(struct fblog_fb *fb, const char *s, u32 cnt,
+ u32 d_pitch, u32 s_pitch, u32 cellsize,
+ struct fb_image *image, u8 *dst)
+{
+ struct fb_info *info = fb->info;
+ const struct font_desc *font = fb->font;
+ u32 shift_low = 0, mod = font->width % 8;
+ u32 shift_high = 8;
+ u32 idx = font->width >> 3;
+ u8 *src;
+
+ while (cnt--) {
+ src = (void*)(font->data + (*s++ & 0xff) * cellsize);
+ 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 fblog_redraw_line(struct fblog_fb *fb, size_t line,
+ const char *str, size_t len)
+{
+ struct fb_info *info = fb->info;
+ const struct font_desc *font = fb->font;
+ 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;
+ u32 cnt, pitch, size;
+ u8 *dst;
+
+ image.fg_color = 7;
+ image.bg_color = 0;
+ image.dx = 0;
+ image.dy = line * font->height;
+ image.height = font->height;
+ image.depth = 1;
+
+ while (len) {
+ if (len > maxcnt)
+ cnt = maxcnt;
+ else
+ cnt = len;
+
+ 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)
+ fblog_redraw_aligned(fb, str, cnt, pitch, width,
+ cellsize, &image, dst);
+ else
+ fblog_redraw_unaligned(fb, str, cnt, pitch, width,
+ cellsize, &image, dst);
+
+ image.dx += cnt * font->width;
+ len -= cnt;
+ str += cnt;
+ }
+}
+
+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, len;
+
+ if (!fb || !fb->font || test_bit(FBLOG_KILLED, &fb->flags) ||
+ test_bit(FBLOG_SUSPENDED, &fb->flags) ||
+ test_bit(FBLOG_BLANKED, &fb->flags))
+ return;
+
+ fblog_redraw_clear(fb);
+
+ for (i = 0; i < fb->buf.height; ++i) {
+ len = strnlen(fb->buf.lines[i], fb->buf.width);
+ if (len)
+ fblog_redraw_line(fb, i, fb->buf.lines[i], len);
+ }
+}
+
static struct fblog_fb *fblog_info2fb(struct fb_info *info)
{
if (!info || info->node < 0 || info->node >= FB_MAX ||
@@ -244,6 +369,7 @@ static void fblog_register(struct fb_info *info)
width = info->var.xres / fb->font->width;
height = info->var.yres / fb->font->height;
fblog_buf_resize(&fb->buf, width, height);
+ fblog_redraw(fb);
}
return;
--
1.7.10.4
^ 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