* Re: Possible deadlock when suspending framebuffer
From: Wanlong Gao @ 2011-06-15 6:22 UTC (permalink / raw)
To: Bruno Prémont
Cc: Francis Moreau, Paul Mundt, linux-fbdev,
Linux Kernel Mailing List, Linus Torvalds
In-Reply-To: <20110615075803.3348b4ec@pluto.restena.lu>
On Wed, Jun 15, 2011 at 1:58 PM, Bruno Prémont
<bonbons@linux-vserver.org> wrote:
>
> Hi,
>
> On Wed, 15 Jun 2011 09:09:24 Wanlong Gao <wanlong.gao@gmail.com> wrote:
> > <snip>
> > Hi Francis:
> > can you test this patch?
>
> Do you have a deadlock trace which you are trying to fix?
No, I just look at the code and try to fix this but I'm not sure.
Can you teach me how to have a deadlock trace here?
Thanks
>
> It's either the caller of unregister_framebuffer() which must be
> changed to not call unregister_framebuffer with info's lock held or
> the code reacting on the notification that must not try to acquire the
> lock again.
>
> The interesting par is if console semaphore has some relation to this
> deadlock as the order for taking both varies... It could be
> lock_fb_info(); console_lock() versus console_lock(); lock_fb_info()
>
I see, thanks
> Bruno
>
>
> > Thanks
> >
><snip>
>
> Not a good idea to stop taking fb_lock here.
> Pretty all calls of fb_notifier_call_chain are protected by info's
> lock, except the one for FB_EVENT_FB_UNREGISTERED a few lines further.
Yup, thanks
>
> IMHO it wou make sense to add the lock around that last one so all
> notifier chain calls are handled the same.
>
> <snip>
>
--
Best regards
Wanlong Gao
^ permalink raw reply
* Re: [PATCH v2 00/29] Use display information in info not in var for panning
From: Paul Mundt @ 2011-06-15 6:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1308043507-11083-1-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, Jun 14, 2011 at 11:24:38AM +0200, Laurent Pinchart wrote:
> I've split the fixes in one patch per driver for easier review and handling of
> potential problems. The patches can be squashed together if needed. I've tried
> to CC individual driver maintainers when possible, and Acked-by lines received
> in reply to the first version have been included.
>
> Compared to v1, I've fixed a couple of subject lines that mentioned the wrong
> driver name, and replaced var->bits_per_pixel in the mx3fb driver.
>
> Not all patches have been tested on real hardware and acked. Geert Uytterhoeven
> acked the overall idea, and I believe the patches are now ready to be applied.
>
This seems like a good direction in general, so it's certainly with
proceeding with. I've applied the series to the fbdev/panning-fixes topic
branch, which I will subsequently merge so it's possible to get wider
coverage via -next.
Individual driver authors have had a few weeks to ack/nack accordingly,
so it's fairly reasonable to expect that you're not likely to be
collecting much more feedback before the whole thing gets merged anyways.
If it ends up horribly breaking a number of drivers then it's still
trivial to revert the branch merge and convert drivers incrementally, but
I don't expect that to really be a problem.
^ permalink raw reply
* Re: Possible deadlock when suspending framebuffer
From: Bruno Prémont @ 2011-06-15 5:58 UTC (permalink / raw)
To: Wanlong Gao
Cc: Francis Moreau, Paul Mundt, linux-fbdev,
Linux Kernel Mailing List, Linus Torvalds
In-Reply-To: <1308100165.2113.4.camel@Tux>
Hi,
On Wed, 15 Jun 2011 09:09:24 Wanlong Gao <wanlong.gao@gmail.com> wrote:
> <snip>
> Hi Francis:
> can you test this patch?
Do you have a deadlock trace which you are trying to fix?
It's either the caller of unregister_framebuffer() which must be
changed to not call unregister_framebuffer with info's lock held or
the code reacting on the notification that must not try to acquire the
lock again.
The interesting par is if console semaphore has some relation to this
deadlock as the order for taking both varies... It could be
lock_fb_info(); console_lock() versus console_lock(); lock_fb_info()
Bruno
> Thanks
>
> From fe026c42af4cbdce053460a428a445e99071586a Mon Sep 17 00:00:00 2001
> From: Wanlong Gao <wanlong.gao@gmail.com>
> Date: Wed, 15 Jun 2011 09:03:41 +0800
> Subject: [PATCH] test
>
>
>
> Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
> ---
> drivers/video/fbmem.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 5aac00e..6e6cef3 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1642,11 +1642,8 @@ static int do_unregister_framebuffer(struct
> fb_info *fb_info)
> if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
> return -EINVAL;
>
> - if (!lock_fb_info(fb_info))
> - return -ENODEV;
> event.info = fb_info;
> ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
> - unlock_fb_info(fb_info);
Not a good idea to stop taking fb_lock here.
Pretty all calls of fb_notifier_call_chain are protected by info's
lock, except the one for FB_EVENT_FB_UNREGISTERED a few lines further.
IMHO it wou make sense to add the lock around that last one so all
notifier chain calls are handled the same.
> if (ret)
> return -EINVAL;
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_hdmi: fix regression: statically enable RTPM
From: Paul Mundt @ 2011-06-15 5:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1106141610430.19402@axis700.grange>
On Tue, Jun 14, 2011 at 04:27:22PM +0200, Guennadi Liakhovetski wrote:
> A recent modification to the runtime PM code on mach-shmobile made a wrong
> RTPM implementation in the sh_mobile_hdmi driver apparent, which broke
> HDMI hotplug detection support on ap4evb. This patch does not implement a
> proper dynamic RTPM support for sh_mobile_hdmi, instead it restores the
> previous working state by statically enabling it. A more power-efficient
> solution should be implemented for the next kernel version.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 08/29] fbdev: unicore32: use display information in
From: Guan Xuetao @ 2011-06-15 2:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1308043507-11083-9-git-send-email-laurent.pinchart@ideasonboard.com>
On Tue, 2011-06-14 at 11:24 +0200, Laurent Pinchart wrote:
> We must not use any information in the passed var besides xoffset,
> yoffset and vmode as otherwise applications might abuse it.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
> ---
> drivers/video/fb-puv3.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fb-puv3.c b/drivers/video/fb-puv3.c
> index 27f2c57..60a787f 100644
> --- a/drivers/video/fb-puv3.c
> +++ b/drivers/video/fb-puv3.c
> @@ -624,8 +624,8 @@ static int unifb_pan_display(struct fb_var_screeninfo *var,
> || var->xoffset)
> return -EINVAL;
> } else {
> - if (var->xoffset + var->xres > info->var.xres_virtual ||
> - var->yoffset + var->yres > info->var.yres_virtual)
> + if (var->xoffset + info->var.xres > info->var.xres_virtual ||
> + var->yoffset + info->var.yres > info->var.yres_virtual)
> return -EINVAL;
> }
> info->var.xoffset = var->xoffset;
Tested-and-Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Thanks.
Guan Xuetao
^ permalink raw reply
* Re: [PATCH] EFIFB: Fix error handling
From: Paul Mundt @ 2011-06-15 2:37 UTC (permalink / raw)
To: David Howells; +Cc: pjones, akpm, linux-kernel, linux-fbdev, stable
In-Reply-To: <20110615003817.18883.41030.stgit@warthog.procyon.org.uk>
On Wed, Jun 15, 2011 at 01:38:17AM +0100, David Howells wrote:
> Fix the error handling in the EFIFB driver if platform_driver_probe() fails.
> In that case, the code will pass the driver struct to the _device_
> unregistration function. It presumably should pass a pointer to the device
> struct instead.
>
> The compiler gives the following warning to indicate this:
>
> drivers/video/efifb.c: In function 'efifb_init':
> drivers/video/efifb.c:544:3: warning: passing argument 1 of 'platform_device_unregister' from incompatible pointer type
> include/linux/platform_device.h:40:13: note: expected 'struct platform_device *' but argument is of type 'struct platform_driver *'
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Peter Jones <pjones@redhat.com>
> cc: linux-fbdev@vger.kernel.org
> cc: stable@kernel.org
Thanks, I've already queued a fix for this.
^ permalink raw reply
* re:Possible deadlock when suspending framebuffer
From: Wanlong Gao @ 2011-06-15 1:09 UTC (permalink / raw)
To: Francis Moreau
Cc: Paul Mundt, linux-fbdev, Linux Kernel Mailing List,
Linus Torvalds
In-Reply-To: <BANLkTimny9nzr23TufH1kMcsk57M3NXuaA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
<snip>
Hi Francis:
can you test this patch?
Thanks
From fe026c42af4cbdce053460a428a445e99071586a Mon Sep 17 00:00:00 2001
From: Wanlong Gao <wanlong.gao@gmail.com>
Date: Wed, 15 Jun 2011 09:03:41 +0800
Subject: [PATCH] test
Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
---
drivers/video/fbmem.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 5aac00e..6e6cef3 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1642,11 +1642,8 @@ static int do_unregister_framebuffer(struct
fb_info *fb_info)
if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
return -EINVAL;
- if (!lock_fb_info(fb_info))
- return -ENODEV;
event.info = fb_info;
ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
- unlock_fb_info(fb_info);
if (ret)
return -EINVAL;
--
1.7.4.1
[-- Attachment #2: 0001-test.patch --]
[-- Type: text/x-patch, Size: 835 bytes --]
From fe026c42af4cbdce053460a428a445e99071586a Mon Sep 17 00:00:00 2001
From: Wanlong Gao <wanlong.gao@gmail.com>
Date: Wed, 15 Jun 2011 09:03:41 +0800
Subject: [PATCH] test
test
Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
---
drivers/video/fbmem.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 5aac00e..6e6cef3 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1642,11 +1642,8 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
return -EINVAL;
- if (!lock_fb_info(fb_info))
- return -ENODEV;
event.info = fb_info;
ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
- unlock_fb_info(fb_info);
if (ret)
return -EINVAL;
--
1.7.4.1
^ permalink raw reply related
* [PATCH] EFIFB: Fix error handling
From: David Howells @ 2011-06-15 0:38 UTC (permalink / raw)
To: pjones; +Cc: akpm, linux-kernel, David Howells, linux-fbdev, stable
Fix the error handling in the EFIFB driver if platform_driver_probe() fails.
In that case, the code will pass the driver struct to the _device_
unregistration function. It presumably should pass a pointer to the device
struct instead.
The compiler gives the following warning to indicate this:
drivers/video/efifb.c: In function 'efifb_init':
drivers/video/efifb.c:544:3: warning: passing argument 1 of 'platform_device_unregister' from incompatible pointer type
include/linux/platform_device.h:40:13: note: expected 'struct platform_device *' but argument is of type 'struct platform_driver *'
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Peter Jones <pjones@redhat.com>
cc: linux-fbdev@vger.kernel.org
cc: stable@kernel.org
---
drivers/video/efifb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index 69c49df..784139a 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -541,7 +541,7 @@ static int __init efifb_init(void)
*/
ret = platform_driver_probe(&efifb_driver, efifb_probe);
if (ret) {
- platform_device_unregister(&efifb_driver);
+ platform_device_unregister(&efifb_device);
return ret;
}
^ permalink raw reply related
* Re: Possible deadlock when suspending framebuffer
From: Florian Tobias Schandinat @ 2011-06-14 19:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Mundt, linux-fbdev, Linux Kernel Mailing List,
Francis Moreau
In-Reply-To: <BANLkTimny9nzr23TufH1kMcsk57M3NXuaA@mail.gmail.com>
Hi Linus,
On 06/14/2011 06:15 PM, Linus Torvalds wrote:
> Paul, fbdev people.. Comments? This was sent to me and lkml, the right
> people probably didn't see it.
Sounds very familiar. Indeed a quick glance at my archive revealed 2
approaches/patches dealing with similar issues
http://marc.info/?l=linux-fbdev&m\x129539210207429&w=2
http://marc.info/?l=linux-fbdev&m\x129700789632450&w=2
I did not have time to verify that those do actually get those things right
everywhere but the first one looks good and should also solve this issue I think.
Regards,
Florian Tobias Schandinat
>
> I doubt it's a big problem in practice, but..
>
> Linus
>
> On Tue, Jun 14, 2011 at 6:10 AM, Francis Moreau<francis.moro@gmail.com> wrote:
>> Hello,
>>
>> I noticed that a possible deadlock can happen when the current frame
>> buffering is being suspended and a new frambuffer device is being
>> registred at the same time.
>>
>> When suspending the current frambuffer by doing : echo 1
>>> /sys/class/graphics/fb0/state, the kernel actually takes the
>> following locks in that order: console_lock, lock_fb_info (see
>> store_fbstate()).
>>
>> However when a new framebuffer is coming in, the lock sequence is:
>> lock_fb_info (taken by do_remove_conflicting_framebuffer()),
>> console_lock() (taken by unbind_console).
>>
>> I don't know how this should be fixed though...
>>
>> Thanks
>> --
>> Francis
>>
> --
> 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: Possible deadlock when suspending framebuffer
From: Linus Torvalds @ 2011-06-14 18:15 UTC (permalink / raw)
To: Paul Mundt, linux-fbdev; +Cc: Linux Kernel Mailing List, Francis Moreau
In-Reply-To: <BANLkTiko+2AM8dq8jP5xjbTcCM63hBAK=A@mail.gmail.com>
Paul, fbdev people.. Comments? This was sent to me and lkml, the right
people probably didn't see it.
I doubt it's a big problem in practice, but..
Linus
On Tue, Jun 14, 2011 at 6:10 AM, Francis Moreau <francis.moro@gmail.com> wrote:
> Hello,
>
> I noticed that a possible deadlock can happen when the current frame
> buffering is being suspended and a new frambuffer device is being
> registred at the same time.
>
> When suspending the current frambuffer by doing : echo 1
>>/sys/class/graphics/fb0/state, the kernel actually takes the
> following locks in that order: console_lock, lock_fb_info (see
> store_fbstate()).
>
> However when a new framebuffer is coming in, the lock sequence is:
> lock_fb_info (taken by do_remove_conflicting_framebuffer()),
> console_lock() (taken by unbind_console).
>
> I don't know how this should be fixed though...
>
> Thanks
> --
> Francis
>
^ permalink raw reply
* [PATCH] fbdev: sh_mobile_hdmi: fix regression: statically enable
From: Guennadi Liakhovetski @ 2011-06-14 14:27 UTC (permalink / raw)
To: linux-fbdev
A recent modification to the runtime PM code on mach-shmobile made a wrong
RTPM implementation in the sh_mobile_hdmi driver apparent, which broke
HDMI hotplug detection support on ap4evb. This patch does not implement a
proper dynamic RTPM support for sh_mobile_hdmi, instead it restores the
previous working state by statically enabling it. A more power-efficient
solution should be implemented for the next kernel version.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/sh_mobile_hdmi.c | 18 +++++-------------
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 6ae40b6..7d54e2c 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -1127,23 +1127,16 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
struct fb_info *info = hdmi->info;
unsigned long parent_rate = 0, hdmi_rate;
- /* A device has been plugged in */
- pm_runtime_get_sync(hdmi->dev);
-
ret = sh_hdmi_read_edid(hdmi, &hdmi_rate, &parent_rate);
- if (ret < 0) {
- pm_runtime_put(hdmi->dev);
+ if (ret < 0)
goto out;
- }
hdmi->hp_state = HDMI_HOTPLUG_EDID_DONE;
/* Reconfigure the clock */
ret = sh_hdmi_clk_configure(hdmi, hdmi_rate, parent_rate);
- if (ret < 0) {
- pm_runtime_put(hdmi->dev);
+ if (ret < 0)
goto out;
- }
msleep(10);
sh_hdmi_configure(hdmi);
@@ -1191,7 +1184,6 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
fb_set_suspend(hdmi->info, 1);
console_unlock();
- pm_runtime_put(hdmi->dev);
}
out:
@@ -1312,7 +1304,7 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(&hdmi->edid_work, sh_hdmi_edid_work_fn);
pm_runtime_enable(&pdev->dev);
- pm_runtime_resume(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
/* Product and revision IDs are 0 in sh-mobile version */
dev_info(&pdev->dev, "Detected HDMI controller 0x%x:0x%x\n",
@@ -1340,7 +1332,7 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
ecodec:
free_irq(irq, hdmi);
ereqirq:
- pm_runtime_suspend(&pdev->dev);
+ pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
iounmap(hdmi->base);
emap:
@@ -1377,7 +1369,7 @@ static int __exit sh_hdmi_remove(struct platform_device *pdev)
free_irq(irq, hdmi);
/* Wait for already scheduled work */
cancel_delayed_work_sync(&hdmi->edid_work);
- pm_runtime_suspend(&pdev->dev);
+ pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
clk_disable(hdmi->hdmi_clk);
clk_put(hdmi->hdmi_clk);
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCHv2 01/28] OMAP: change get_context_loss_count ret value
From: Rajendra Nayak @ 2011-06-14 13:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Paul Walmsley, linux-fbdev, b-cousson, khilman,
linux-omap mailing list
In-Reply-To: <1308036257.1899.8.camel@deskari>
On 6/14/2011 12:54 PM, Tomi Valkeinen wrote:
> On Tue, 2011-06-14 at 01:13 -0600, Paul Walmsley wrote:
>> Hi Tomi
>>
>> On Mon, 13 Jun 2011, Tomi Valkeinen wrote:
>>
>>> Paul, can you take this patch and queue it for an rc?
>>
>> Generally I only queue regressions or fixes for major problems (crashes,
>> corruption, etc.) for -rc series. So probably this one should go in via
>> the normal merge window, unless it's been causing major disruptions?
>
> No, only disruptions for me as the DSS pm_runtime patches depend on this
> one to function correctly. So merge window is ok, I'll handle the DSS
> side somehow.
Hi Paul/Kevin,
I had a query, not directly related to this patch, but to the way
the omap_pm_get_dev_context_loss_count() api is implemented, which
this patch is trying to fix in some ways.
I see that the api relies on the pwrdm level state counters, which
in-turn seem to be getting updated only in the cpuidle/suspend path.
How are domains like DSS which can independently transition outside
of the cpuidle path handled?
What I mean is, if DSS on disabling its clocks transitions to OFF
state (it being an independent powerdomain) and tries to use this api
to know if it lost context the next time it is re-enabling clocks and
all this happens while there was no cpuidle being scheduled, where do
the pwrdm level state counters get updated, which tell DSS it did lose
context?
On another note, i was wondering if it even made any sense to drivers
like DSS, which have an independent power domain of its own on OMAP to
try and do a restore-only-if-needed kind of an implementation.
Would'nt it always lose context the moment it run-time idle's?
regards,
Rajendra
>
> Tomi
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH v2 29/29] staging: xgifb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnaud Patard <apatard@mandriva.com>
---
drivers/staging/xgifb/XGI_main_26.c | 22 ++++++----------------
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c
index cadec2a..e92f6fa 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -1365,26 +1365,16 @@ static int XGIfb_do_set_var(struct fb_var_screeninfo *var, int isactive,
}
#ifdef XGIFB_PAN
-static int XGIfb_pan_var(struct fb_var_screeninfo *var)
+static int XGIfb_pan_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
unsigned int base;
/* printk("Inside pan_var"); */
- if (var->xoffset > (var->xres_virtual - var->xres)) {
- /* printk("Pan: xo: %d xv %d xr %d\n",
- var->xoffset, var->xres_virtual, var->xres); */
- return -EINVAL;
- }
- if (var->yoffset > (var->yres_virtual - var->yres)) {
- /* printk("Pan: yo: %d yv %d yr %d\n",
- var->yoffset, var->yres_virtual, var->yres); */
- return -EINVAL;
- }
- base = var->yoffset * var->xres_virtual + var->xoffset;
+ base = var->yoffset * info->var.xres_virtual + var->xoffset;
/* calculate base bpp dep. */
- switch (var->bits_per_pixel) {
+ switch (info->var.bits_per_pixel) {
case 16:
base >>= 1;
break;
@@ -1682,9 +1672,9 @@ static int XGIfb_pan_display(struct fb_var_screeninfo *var,
/* printk("\nInside pan_display:\n"); */
- if (var->xoffset > (var->xres_virtual - var->xres))
+ if (var->xoffset > (info->var.xres_virtual - info->var.xres))
return -EINVAL;
- if (var->yoffset > (var->yres_virtual - var->yres))
+ if (var->yoffset > (info->var.yres_virtual - info->var.yres))
return -EINVAL;
if (var->vmode & FB_VMODE_YWRAP) {
@@ -1697,7 +1687,7 @@ static int XGIfb_pan_display(struct fb_var_screeninfo *var,
> info->var.yres_virtual)
return -EINVAL;
}
- err = XGIfb_pan_var(var);
+ err = XGIfb_pan_var(var, info);
if (err < 0)
return err;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 28/29] vt8623fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ondrej Zajicek <santiago@crfreenet.org>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/video/vt8623fb.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index f9b3e3d..4e74d26 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -620,13 +620,14 @@ static int vt8623fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *i
unsigned int offset;
/* Calculate the offset */
- if (var->bits_per_pixel = 0) {
- offset = (var->yoffset / 16) * var->xres_virtual + var->xoffset;
+ if (info->var.bits_per_pixel = 0) {
+ offset = (var->yoffset / 16) * info->var.xres_virtual
+ + var->xoffset;
offset = offset >> 3;
} else {
offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * var->bits_per_pixel / 8);
- offset = offset >> ((var->bits_per_pixel = 4) ? 2 : 1);
+ (var->xoffset * info->var.bits_per_pixel / 8);
+ offset = offset >> ((info->var.bits_per_pixel = 4) ? 2 : 1);
}
/* Set the offset */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 27/29] vt8500lcdfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alexey Charkov <alchark@gmail.com>
---
drivers/video/vt8500lcdfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 0e120d6..c13c246 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -210,8 +210,8 @@ static int vt8500lcd_pan_display(struct fb_var_screeninfo *var,
struct vt8500lcd_info *fbi = to_vt8500lcd_info(info);
writel((1 << 31)
- | (((var->xres_virtual - var->xres) * pixlen / 4) << 20)
- | (off >> 2), fbi->regbase + 0x20);
+ | (((info->var.xres_virtual - info->var.xres) * pixlen / 4) << 20)
+ | (off >> 2), fbi->regbase + 0x20);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 26/29] vga16fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Antonino A. Daplas <adaplas@gmail.com>
---
drivers/video/vga16fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 53b2c5a..148b3ee 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -207,7 +207,7 @@ static void vga16fb_pan_var(struct fb_info *info,
* granularity if someone supports xoffset in bit resolution */
vga_io_r(VGA_IS1_RC); /* reset flip-flop */
vga_io_w(VGA_ATT_IW, VGA_ATC_PEL);
- if (var->bits_per_pixel = 8)
+ if (info->var.bits_per_pixel = 8)
vga_io_w(VGA_ATT_IW, (xoffset & 3) << 1);
else
vga_io_w(VGA_ATT_IW, xoffset & 7);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 25/29] vfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/vfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/vfb.c b/drivers/video/vfb.c
index bc67251..bf2f780 100644
--- a/drivers/video/vfb.c
+++ b/drivers/video/vfb.c
@@ -395,8 +395,8 @@ static int vfb_pan_display(struct fb_var_screeninfo *var,
|| var->xoffset)
return -EINVAL;
} else {
- if (var->xoffset + var->xres > info->var.xres_virtual ||
- var->yoffset + var->yres > info->var.yres_virtual)
+ if (var->xoffset + info->var.xres > info->var.xres_virtual ||
+ var->yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
}
info->var.xoffset = var->xoffset;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 24/29] tridentfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/tridentfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/tridentfb.c b/drivers/video/tridentfb.c
index c6c7756..34cf019 100644
--- a/drivers/video/tridentfb.c
+++ b/drivers/video/tridentfb.c
@@ -987,8 +987,8 @@ static int tridentfb_pan_display(struct fb_var_screeninfo *var,
unsigned int offset;
debug("enter\n");
- offset = (var->xoffset + (var->yoffset * var->xres_virtual))
- * var->bits_per_pixel / 32;
+ offset = (var->xoffset + (var->yoffset * info->var.xres_virtual))
+ * info->var.bits_per_pixel / 32;
set_screen_start(par, offset);
debug("exit\n");
return 0;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 23/29] sm501fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Dooks <ben@simtec.co.uk>
---
drivers/video/sm501fb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 87f0be1..2c9e9d3 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -582,7 +582,7 @@ static int sm501fb_pan_crt(struct fb_var_screeninfo *var,
{
struct sm501fb_par *par = info->par;
struct sm501fb_info *fbi = par->info;
- unsigned int bytes_pixel = var->bits_per_pixel / 8;
+ unsigned int bytes_pixel = info->var.bits_per_pixel / 8;
unsigned long reg;
unsigned long xoffs;
@@ -614,10 +614,10 @@ static int sm501fb_pan_pnl(struct fb_var_screeninfo *var,
struct sm501fb_info *fbi = par->info;
unsigned long reg;
- reg = var->xoffset | (var->xres_virtual << 16);
+ reg = var->xoffset | (info->var.xres_virtual << 16);
smc501_writel(reg, fbi->regs + SM501_DC_PANEL_FB_WIDTH);
- reg = var->yoffset | (var->yres_virtual << 16);
+ reg = var->yoffset | (info->var.yres_virtual << 16);
smc501_writel(reg, fbi->regs + SM501_DC_PANEL_FB_HEIGHT);
sm501fb_sync_regs(fbi);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 22/29] sisfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:25 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Fix checkpatch.pl warnings in the surrounding code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
---
drivers/video/sis/sis_main.c | 30 ++++++++++--------------------
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
index 7525984..078ca21 100644
--- a/drivers/video/sis/sis_main.c
+++ b/drivers/video/sis/sis_main.c
@@ -1333,19 +1333,14 @@ sisfb_set_base_CRT2(struct sis_video_info *ivideo, unsigned int base)
}
static int
-sisfb_pan_var(struct sis_video_info *ivideo, struct fb_var_screeninfo *var)
+sisfb_pan_var(struct sis_video_info *ivideo, struct fb_info *info,
+ struct fb_var_screeninfo *var)
{
- if(var->xoffset > (var->xres_virtual - var->xres)) {
- return -EINVAL;
- }
- if(var->yoffset > (var->yres_virtual - var->yres)) {
- return -EINVAL;
- }
-
- ivideo->current_base = (var->yoffset * var->xres_virtual) + var->xoffset;
+ ivideo->current_base = var->yoffset * info->var.xres_virtual
+ + var->xoffset;
/* calculate base bpp dep. */
- switch(var->bits_per_pixel) {
+ switch (info->var.bits_per_pixel) {
case 32:
break;
case 16:
@@ -1635,20 +1630,15 @@ sisfb_pan_display(struct fb_var_screeninfo *var, struct fb_info* info)
struct sis_video_info *ivideo = (struct sis_video_info *)info->par;
int err;
- if(var->xoffset > (var->xres_virtual - var->xres))
- return -EINVAL;
-
- if(var->yoffset > (var->yres_virtual - var->yres))
- return -EINVAL;
-
- if(var->vmode & FB_VMODE_YWRAP)
+ if (var->vmode & FB_VMODE_YWRAP)
return -EINVAL;
- if(var->xoffset + info->var.xres > info->var.xres_virtual ||
- var->yoffset + info->var.yres > info->var.yres_virtual)
+ if (var->xoffset + info->var.xres > info->var.xres_virtual ||
+ var->yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
- if((err = sisfb_pan_var(ivideo, var)) < 0)
+ err = sisfb_pan_var(ivideo, info, var);
+ if (err < 0)
return err;
info->var.xoffset = var->xoffset;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 21/29] savagefb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:24 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it. Also use the
aligned fix.line_length and not the (possible) unaligned xres_virtual.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/savage/savagefb_driver.c | 16 +++++++---------
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
index 3b7f2f5..df9e061 100644
--- a/drivers/video/savage/savagefb_driver.c
+++ b/drivers/video/savage/savagefb_driver.c
@@ -1477,15 +1477,9 @@ static void savagefb_set_par_int(struct savagefb_par *par, struct savage_reg *r
vgaHWProtect(par, 0);
}
-static void savagefb_update_start(struct savagefb_par *par,
- struct fb_var_screeninfo *var)
+static void savagefb_update_start(struct savagefb_par *par, int base)
{
- int base;
-
- base = ((var->yoffset * var->xres_virtual + (var->xoffset & ~1))
- * ((var->bits_per_pixel+7) / 8)) >> 2;
-
- /* now program the start address registers */
+ /* program the start address registers */
vga_out16(0x3d4, (base & 0x00ff00) | 0x0c, par);
vga_out16(0x3d4, ((base & 0x00ff) << 8) | 0x0d, par);
vga_out8(0x3d4, 0x69, par);
@@ -1550,8 +1544,12 @@ static int savagefb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct savagefb_par *par = info->par;
+ int base;
+
+ base = (var->yoffset * info->fix.line_length
+ + (var->xoffset & ~1) * ((info->var.bits_per_pixel+7) / 8)) >> 2;
- savagefb_update_start(par, var);
+ savagefb_update_start(par, base);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 20/29] s3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:24 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/s3fb.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 4ca5d0c..0f9af1a 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1019,12 +1019,13 @@ static int s3fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
unsigned int offset;
/* Calculate the offset */
- if (var->bits_per_pixel = 0) {
- offset = (var->yoffset / 16) * (var->xres_virtual / 2) + (var->xoffset / 2);
+ if (info->var.bits_per_pixel = 0) {
+ offset = (var->yoffset / 16) * (info->var.xres_virtual / 2)
+ + (var->xoffset / 2);
offset = offset >> 2;
} else {
offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * var->bits_per_pixel / 8);
+ (var->xoffset * info->var.bits_per_pixel / 8);
offset = offset >> 2;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 19/29] s3c-fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:24 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0352afa..42b557c 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -884,7 +884,7 @@ static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
}
}
/* Offset in bytes to the end of the displayed area */
- end_boff = start_boff + var->yres * info->fix.line_length;
+ end_boff = start_boff + info->var.yres * info->fix.line_length;
/* Temporarily turn off per-vsync update from shadow registers until
* both start and end addresses are updated to prevent corruption */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 18/29] pm3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:24 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/pm3fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pm3fb.c b/drivers/video/pm3fb.c
index 6666f45..8221b5b 100644
--- a/drivers/video/pm3fb.c
+++ b/drivers/video/pm3fb.c
@@ -1147,9 +1147,9 @@ static int pm3fb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct pm3_par *par = info->par;
- const u32 xres = (var->xres + 31) & ~31;
+ const u32 xres = (info->var.xres + 31) & ~31;
- par->base = pm3fb_shift_bpp(var->bits_per_pixel,
+ par->base = pm3fb_shift_bpp(info->var.bits_per_pixel,
(var->yoffset * xres)
+ var->xoffset);
PM3_WAIT(par, 1);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 17/29] pm2fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-06-14 9:24 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/pm2fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index 27f93aa..f4f8ce8 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -973,8 +973,8 @@ static int pm2fb_pan_display(struct fb_var_screeninfo *var,
{
struct pm2fb_par *p = info->par;
u32 base;
- u32 depth = (var->bits_per_pixel + 7) & ~7;
- u32 xres = (var->xres + 31) & ~31;
+ u32 depth = (info->var.bits_per_pixel + 7) & ~7;
+ u32 xres = (info->var.xres + 31) & ~31;
depth = (depth > 32) ? 32 : depth;
base = to3264(var->yoffset * xres + var->xoffset, depth, 1);
--
1.7.3.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