From: Tony Lindgren <tony@atomide.com>
To: linux-arm-kernel@lists.infradead.org
Cc: Imre Deak <imre.deak@nokia.com>,
Sergio Aguirre <saaguirre@ti.com>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
Tomi Valkeinen <tomi.valkeinen@nokia.com>
Subject: [PATCH 6/8] omapfb: Condition mutex acquisition
Date: Fri, 02 Oct 2009 15:44:13 -0700 [thread overview]
Message-ID: <20091002224413.11962.12302.stgit@localhost> (raw)
In-Reply-To: <20091002223510.11962.21751.stgit@localhost>
From: Sergio Aguirre <saaguirre@ti.com>
This fixes a bug introduced by this commit ID:
commit 537a1bf059fa312355696fa6db80726e655e7f17
Author: Krzysztof Helt <krzysztof.h1@wp.pl>
Date: Tue Jun 30 11:41:29 2009 -0700
fbdev: add mutex for fb_mmap locking
In which a mutex was added when changing smem_start and smem_len fields,
so the mutex inside the fb_mmap() call is actually used.
The problem was that set_fb_fix, which modifies the above 2 fields,
was called before and after registering the framebuffer,
which when used before registration, lead to a failed attempt to
use an uninitialized mutex.
Solution: Don't use mutex before framebuffer registration.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/video/omap/omapfb_main.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..0d0c8c8 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -393,7 +393,7 @@ static void omapfb_sync(struct fb_info *fbi)
* Set fb_info.fix fields and also updates fbdev.
* When calling this fb_info.var must be set up already.
*/
-static void set_fb_fix(struct fb_info *fbi)
+static void set_fb_fix(struct fb_info *fbi, int from_init)
{
struct fb_fix_screeninfo *fix = &fbi->fix;
struct fb_var_screeninfo *var = &fbi->var;
@@ -403,10 +403,16 @@ static void set_fb_fix(struct fb_info *fbi)
rg = &plane->fbdev->mem_desc.region[plane->idx];
fbi->screen_base = rg->vaddr;
- mutex_lock(&fbi->mm_lock);
- fix->smem_start = rg->paddr;
- fix->smem_len = rg->size;
- mutex_unlock(&fbi->mm_lock);
+
+ if (!from_init) {
+ mutex_lock(&fbi->mm_lock);
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ mutex_unlock(&fbi->mm_lock);
+ } else {
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ }
fix->type = FB_TYPE_PACKED_PIXELS;
bpp = var->bits_per_pixel;
@@ -704,7 +710,7 @@ static int omapfb_set_par(struct fb_info *fbi)
int r = 0;
omapfb_rqueue_lock(fbdev);
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
r = ctrl_change_mode(fbi);
omapfb_rqueue_unlock(fbdev);
@@ -904,7 +910,7 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
if (old_size != size) {
if (size) {
memcpy(&fbi->var, new_var, sizeof(fbi->var));
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
} else {
/*
* Set these explicitly to indicate that the
@@ -1504,7 +1510,7 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
var->bits_per_pixel = fbdev->panel->bpp;
set_fb_var(info, var);
- set_fb_fix(info);
+ set_fb_fix(info, 1);
r = fb_alloc_cmap(&info->cmap, 16, 0);
if (r != 0)
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/8] omapfb: Condition mutex acquisition
Date: Fri, 02 Oct 2009 15:44:13 -0700 [thread overview]
Message-ID: <20091002224413.11962.12302.stgit@localhost> (raw)
In-Reply-To: <20091002223510.11962.21751.stgit@localhost>
From: Sergio Aguirre <saaguirre@ti.com>
This fixes a bug introduced by this commit ID:
commit 537a1bf059fa312355696fa6db80726e655e7f17
Author: Krzysztof Helt <krzysztof.h1@wp.pl>
Date: Tue Jun 30 11:41:29 2009 -0700
fbdev: add mutex for fb_mmap locking
In which a mutex was added when changing smem_start and smem_len fields,
so the mutex inside the fb_mmap() call is actually used.
The problem was that set_fb_fix, which modifies the above 2 fields,
was called before and after registering the framebuffer,
which when used before registration, lead to a failed attempt to
use an uninitialized mutex.
Solution: Don't use mutex before framebuffer registration.
Signed-off-by: Sergio Aguirre <saaguirre@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: Imre Deak <imre.deak@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/video/omap/omapfb_main.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index 125e605..0d0c8c8 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -393,7 +393,7 @@ static void omapfb_sync(struct fb_info *fbi)
* Set fb_info.fix fields and also updates fbdev.
* When calling this fb_info.var must be set up already.
*/
-static void set_fb_fix(struct fb_info *fbi)
+static void set_fb_fix(struct fb_info *fbi, int from_init)
{
struct fb_fix_screeninfo *fix = &fbi->fix;
struct fb_var_screeninfo *var = &fbi->var;
@@ -403,10 +403,16 @@ static void set_fb_fix(struct fb_info *fbi)
rg = &plane->fbdev->mem_desc.region[plane->idx];
fbi->screen_base = rg->vaddr;
- mutex_lock(&fbi->mm_lock);
- fix->smem_start = rg->paddr;
- fix->smem_len = rg->size;
- mutex_unlock(&fbi->mm_lock);
+
+ if (!from_init) {
+ mutex_lock(&fbi->mm_lock);
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ mutex_unlock(&fbi->mm_lock);
+ } else {
+ fix->smem_start = rg->paddr;
+ fix->smem_len = rg->size;
+ }
fix->type = FB_TYPE_PACKED_PIXELS;
bpp = var->bits_per_pixel;
@@ -704,7 +710,7 @@ static int omapfb_set_par(struct fb_info *fbi)
int r = 0;
omapfb_rqueue_lock(fbdev);
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
r = ctrl_change_mode(fbi);
omapfb_rqueue_unlock(fbdev);
@@ -904,7 +910,7 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
if (old_size != size) {
if (size) {
memcpy(&fbi->var, new_var, sizeof(fbi->var));
- set_fb_fix(fbi);
+ set_fb_fix(fbi, 0);
} else {
/*
* Set these explicitly to indicate that the
@@ -1504,7 +1510,7 @@ static int fbinfo_init(struct omapfb_device *fbdev, struct fb_info *info)
var->bits_per_pixel = fbdev->panel->bpp;
set_fb_var(info, var);
- set_fb_fix(info);
+ set_fb_fix(info, 1);
r = fb_alloc_cmap(&info->cmap, 16, 0);
if (r != 0)
next prev parent reply other threads:[~2009-10-02 22:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 22:36 [PATCH 0/8] Omap fixes for 2.6.32-rc2 Tony Lindgren
2009-10-02 22:36 ` Tony Lindgren
2009-10-02 22:37 ` [PATCH 1/8] omap: Fix incorrect 730 vs 850 detection Tony Lindgren
2009-10-02 22:37 ` Tony Lindgren
2009-10-02 22:38 ` [PATCH 2/8] omap: Lock DPLL5 at boot Tony Lindgren
2009-10-02 22:38 ` Tony Lindgren
2009-10-06 15:19 ` Paul Walmsley
2009-10-06 15:19 ` Paul Walmsley
2009-10-06 15:19 ` Paul Walmsley
2009-10-02 22:40 ` [PATCH 3/8] omap: SRAM: flush the right address after memcpy in omap_sram_push Tony Lindgren
2009-10-02 22:40 ` Tony Lindgren
2009-10-02 22:41 ` [PATCH 4/8] omap: iovmm: Fix incorrect spelling Tony Lindgren
2009-10-02 22:41 ` Tony Lindgren
2009-10-02 22:42 ` [PATCH 5/8] omap: iovmm: Add missing mutex_unlock Tony Lindgren
2009-10-02 22:42 ` Tony Lindgren
2009-10-02 22:44 ` Tony Lindgren [this message]
2009-10-02 22:44 ` [PATCH 6/8] omapfb: Condition mutex acquisition Tony Lindgren
2009-10-03 18:38 ` Cory Maccarrone
2009-10-03 18:38 ` Cory Maccarrone
2009-10-03 18:38 ` Cory Maccarrone
2009-10-02 22:45 ` [PATCH 7/8] omapfb: Blizzard: fix pointer to be const Tony Lindgren
2009-10-02 22:45 ` Tony Lindgren
2009-10-02 22:46 ` [PATCH 8/8] omapfb: Blizzard: constify register address tables Tony Lindgren
2009-10-02 22:46 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091002224413.11962.12302.stgit@localhost \
--to=tony@atomide.com \
--cc=imre.deak@nokia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=saaguirre@ti.com \
--cc=tomi.valkeinen@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.