* [PATCH v3 06/10] video: da8xx-fb: store clk rate even if !CPUFREQ
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
store lcd clk rate always, i.e. irrespective of whether CPUFREQ is
enabled or not. This can be used to get clk rate directly instead of
enquiring with clock framework with clk handle every time.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d060f14..f1d88ac 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -174,8 +174,8 @@ struct da8xx_fb_par {
unsigned int which_dma_channel_done;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
- unsigned int lcd_fck_rate;
#endif
+ unsigned int lcd_fck_rate;
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
struct fb_videomode mode;
@@ -1302,9 +1302,7 @@ static int fb_probe(struct platform_device *device)
par = da8xx_fb_info->par;
par->lcdc_clk = fb_clk;
-#ifdef CONFIG_CPU_FREQ
par->lcd_fck_rate = clk_get_rate(fb_clk);
-#endif
par->pxl_clk = lcdc_info->pixclock;
if (fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 05/10] video: da8xx-fb: store current display information
From: Afzal Mohammed @ 2013-01-15 13:44 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
store current videomode and controller data so that reconfiguring can
be done easily. Reconfiguring would be required in fb_set_par, which
is going to be added soon.
If these details are not stored, the work probe does to retrieve these
information would have to repeated at the place of reconfiguring and
modifying platform data would be necessary to handle controller data
changes like bpp.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 18834fa..d060f14 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -178,6 +178,8 @@ struct da8xx_fb_par {
#endif
void (*panel_power_ctrl)(int);
u32 pseudo_palette[16];
+ struct fb_videomode mode;
+ struct lcd_ctrl_config cfg;
};
static struct fb_var_screeninfo da8xx_fb_var;
@@ -1310,6 +1312,8 @@ static int fb_probe(struct platform_device *device)
}
fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
+ fb_var_to_videomode(&par->mode, &da8xx_fb_var);
+ par->cfg = *lcd_cfg;
if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
dev_err(&device->dev, "lcd_init failed\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 04/10] video: da8xx-fb: remove unneeded "var" initialization
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
modedb helper now updates "var" information based on the detected
panel, remove the unnecessary initialization.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index a1f6544..18834fa 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,10 +131,6 @@
#define WSI_TIMEOUT 50
#define PALETTE_SIZE 256
-#define LEFT_MARGIN 64
-#define RIGHT_MARGIN 64
-#define UPPER_MARGIN 32
-#define LOWER_MARGIN 32
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
@@ -184,23 +180,7 @@ struct da8xx_fb_par {
u32 pseudo_palette[16];
};
-/* Variable Screen Information */
-static struct fb_var_screeninfo da8xx_fb_var = {
- .xoffset = 0,
- .yoffset = 0,
- .transp = {0, 0, 0},
- .nonstd = 0,
- .activate = 0,
- .height = -1,
- .width = -1,
- .accel_flags = 0,
- .left_margin = LEFT_MARGIN,
- .right_margin = RIGHT_MARGIN,
- .upper_margin = UPPER_MARGIN,
- .lower_margin = LOWER_MARGIN,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED
-};
+static struct fb_var_screeninfo da8xx_fb_var;
static struct fb_fix_screeninfo da8xx_fb_fix = {
.id = "DA8xx FB Drv",
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 03/10] video: da8xx-fb: use modedb helper to update var
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
modedb structure is now used to store panel information, run modedb
helper over it for initial update of "var" information instead of
equating each fields.
While at it, remove redundant update of bits_per_pixel.
Note: pixclock is overridden with proper value using an existing code
as currently modedb is having it in Hz instead of ps, this would be
fixed in a later change and this overide would be removed.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 52977b1..a1f6544 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1329,6 +1329,8 @@ static int fb_probe(struct platform_device *device)
par->panel_power_ctrl(1);
}
+ fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
+
if (lcd_init(par, lcd_cfg, lcdc_info) < 0) {
dev_err(&device->dev, "lcd_init failed\n");
ret = -EFAULT;
@@ -1381,25 +1383,9 @@ static int fb_probe(struct platform_device *device)
goto err_release_pl_mem;
}
- /* Initialize par */
- da8xx_fb_info->var.bits_per_pixel = lcd_cfg->bpp;
-
- da8xx_fb_var.xres = lcdc_info->xres;
- da8xx_fb_var.xres_virtual = lcdc_info->xres;
-
- da8xx_fb_var.yres = lcdc_info->yres;
- da8xx_fb_var.yres_virtual = lcdc_info->yres * LCD_NUM_BUFFERS;
-
da8xx_fb_var.grayscale lcd_cfg->panel_shade = MONOCHROME ? 1 : 0;
da8xx_fb_var.bits_per_pixel = lcd_cfg->bpp;
-
- da8xx_fb_var.hsync_len = lcdc_info->hsync_len;
- da8xx_fb_var.vsync_len = lcdc_info->vsync_len;
- da8xx_fb_var.right_margin = lcdc_info->right_margin;
- da8xx_fb_var.left_margin = lcdc_info->left_margin;
- da8xx_fb_var.lower_margin = lcdc_info->lower_margin;
- da8xx_fb_var.upper_margin = lcdc_info->upper_margin;
da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/10] video: da8xx-fb: simplify lcd_reset
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
lcd_reset function doesn't require any arguement, remove it.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index d00dd17..52977b1 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -681,7 +681,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
}
#undef CNVT_TOHW
-static void lcd_reset(struct da8xx_fb_par *par)
+static void da8xx_fb_lcd_reset(void)
{
/* Disable the Raster if previously Enabled */
lcd_disable_raster(false);
@@ -721,7 +721,7 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- lcd_reset(par);
+ da8xx_fb_lcd_reset();
/* Calculate the divider */
lcd_calc_clk_divider(par);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 01/10] video: da8xx-fb: fb_check_var enhancement
From: Afzal Mohammed @ 2013-01-15 13:43 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <cover.1358250489.git.afzal@ti.com>
Check whether "struct fb_var_screeninfo" fields are sane, if not
update it to be within allowed limits.
If user sends down buggy "var" values, this will bring those within
allowable limits. And fb_set_par is not supposed to change "var"
values, fb_check_var has to ensure that values are proper.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
drivers/video/da8xx-fb.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0810939..d00dd17 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -888,6 +888,9 @@ static int fb_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
int err = 0;
+ struct da8xx_fb_par *par = info->par;
+ int bpp = var->bits_per_pixel >> 3;
+ unsigned long line_size = var->xres_virtual * bpp;
if (var->bits_per_pixel > 16 && lcd_revision = LCD_VERSION_1)
return -EINVAL;
@@ -955,6 +958,21 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->green.msb_right = 0;
var->blue.msb_right = 0;
var->transp.msb_right = 0;
+
+ if (line_size * var->yres_virtual > par->vram_size)
+ var->yres_virtual = par->vram_size / line_size;
+
+ if (var->yres > var->yres_virtual)
+ var->yres = var->yres_virtual;
+
+ if (var->xres > var->xres_virtual)
+ var->xres = var->xres_virtual;
+
+ if (var->xres + var->xoffset > var->xres_virtual)
+ var->xoffset = var->xres_virtual - var->xres;
+ if (var->yres + var->yoffset > var->yres_virtual)
+ var->yoffset = var->yres_virtual - var->yres;
+
return err;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 00/10] video: da8xx-fb: runtime timing configuration
From: Afzal Mohammed @ 2013-01-15 13:42 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Sekhar Nori,
linux-omap, linux-fbdev, linux-kernel
Hi,
This series makes da8xx-fb driver (device found on DaVinci and AM335x)
capable of handling runtime timing configuration by adding fb_set_par.
The last change adds actual fb_set_par support. Other preceeding
changes makes the way clear for it as well as does certain cleanup's
on the way.
This has been tested on da850 evm as is. This was also tested on
am335x-evm & am335x-evmsk with a series that adds DT support.
This is based on v3.8-rc3, this is the only change in this revision.
The new version of this series is being posted so that this series can
be applied easily (as __dev* are removed, there would be merge
conflicts with v2, which was based on -rc2).
series
Regards
Afzal
v3: rebased over -rc3, no functional changes
v2: disable raster in fb_set_par properly
Afzal Mohammed (10):
video: da8xx-fb: fb_check_var enhancement
video: da8xx-fb: simplify lcd_reset
video: da8xx-fb: use modedb helper to update var
video: da8xx-fb: remove unneeded "var" initialization
video: da8xx-fb: store current display information
video: da8xx-fb: store clk rate even if !CPUFREQ
video: da8xx-fb: pix clk and clk div handling cleanup
video: da8xx-fb: store struct device *
video: da8xx-fb: report correct pixclock
video: da8xx-fb: fb_set_par support
drivers/video/da8xx-fb.c | 185 ++++++++++++++++++++++++++--------------------
1 file changed, 105 insertions(+), 80 deletions(-)
--
1.7.9.5
^ permalink raw reply
* fb: Rework locking to fix lock ordering on takeover
From: Sedat Dilek @ 2013-01-13 15:14 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-fbdev, LKML, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Hi Andrew,
your patch from [1] - as far as I followed - misses a lot of
Reported-by#s and Tested-by#s (Boris, Jiri, etc.).
Just one new R-b I have seen yesterday.
I have the original patch from Alan plus the two follow-ups from you
in my patch-series against v3.8-{rc2,rc3} for quite a while.
So, please feel free to add a Tested-by.
Unfortunately, your patch has introduced some (unwanted) extra chars
like "_*" (comments only).
I appreciate one single (new) patch like this, but please in a proper way.
A disappeared/busy/not-answering maintainer is not an excuse for
handling serious regressions (even here in this case there are fixes
around),
Personally, I am still missing a mei-driver fix [2] and a libata-dev fix [3].
Both issues are not new to the maintainers.
Not sure if shouting louder is the best strategy here.
It would be great to have a place like a "board of arbitration" where
someone can send blames.
And I remember vaguely Rafael had a nice list of issues (w/ reference
to patches!).
This was a real cool helpful innoivation!
I can't remember why Rafael stopped his nice service to the
Linux-kernel community.
Have fun!
Regards,
- Sedat -
[1] https://patchwork.kernel.org/patch/1969391/
[2] http://git.kernel.org/?p=linux/kernel/git/gregkh/char-misc.git;a=commitdiff;h=e6028db0146cf5a68dbd1508225ea49840997880
[3] http://patchwork.ozlabs.org/patch/206897/
[-- Attachment #2: fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch --]
[-- Type: application/octet-stream, Size: 823 bytes --]
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 347bed0..1db1c8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3653,7 +3653,7 @@ int do_take_over_console(const struct consw *csw, int first, int last, int deflt
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- _* but not unregistered it.
+ * but not unregistered it.
*/
if (err == -EBUSY)
err = 0;
@@ -3679,7 +3679,7 @@ int take_over_console(const struct consw *csw, int first, int last, int deflt)
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- _* but not unregistered it.
+ * but not unregistered it.
*/
if (err == -EBUSY)
err = 0;
^ permalink raw reply related
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-13 12:24 UTC (permalink / raw)
To: Bernie Thompson
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <50F2A310.5010006@ahsoftware.de>
Am 13.01.2013 13:05, schrieb Alexander Holler:
> Am 12.01.2013 23:22, schrieb Bernie Thompson:
> I didn't test it extensively, but without the patch the driver isn't
> usable here. Maybe my previous patch which moves damages to a workqueue
To add some more explanations, I'm currently only testing it with a
statically linked udlfb (for fbcon) as that is what I'm mainly using the
device for (with otherwise headless boxes). When udlfb is a module, I
don't see those "schedule while atomic" messages (I don't know why), but
having a console only after the modules got loaded isn't always an option.
Regards,
Alexander
^ permalink raw reply
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-13 12:05 UTC (permalink / raw)
To: Bernie Thompson
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <CAF1V4O8UUgWB1XbS=3EsirBjhP9Lp7JQ8XK8MQxbe3ZkH8pd3Q@mail.gmail.com>
Am 12.01.2013 23:22, schrieb Bernie Thompson:
> Hi Alexander,
>
> On Sat, Jan 12, 2013 at 5:20 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>> When a device was disconnected the driver may hang at waiting for urbs it never
>> will get. Fix this by using a timeout while waiting for the used semaphore.
>
> The code used to be this way, but it used to cause nasty shutdown hangs:
> http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h\x1dd39a65001deb5a84088dfabb788d3274fbb6b6
>
> Which is why the code is the way it is today.
>
> Can you say under what situations you're hitting hangs on device
> disconnect? Have you tested extensively to confirm no shutdown hangs
> with your patch?
>
The driver almost always (2/3) hangs here when the device gets
disconnected. It is easy to see when the device gets attached again as
nothing will happen if the driver (already) hangs (in addition that a
shutdown isn't possible).
I didn't test it extensively, but without the patch the driver isn't
usable here. Maybe my previous patch which moves damages to a workqueue
is the reason that it's more likely that urbs get missing, but the
problem already existed because an urb might get missed on disconnect. I
don't know what problems existed before, maybe people just had a problem
with the BUG_ON(ret). If that _interrupted_ is really needed, it could
make sense to implement a down_timeout_interruptible() for semaphores.
> Stepping back, there was another recent patch from the community to
> udlfb to work around issues of sleeping in the wrong context. The fix
> involved introducing another scheduled workitem. This slows everything
> down when it's in the main path, and isn't really desirable if we can
> avoid it.
Do you mean the one I've recently posted? It is needed, at least for 3.7
(I don't know since when those "schedule while atomic" messages appear).
It might slow down refreshes, but it is needed, at least until someone
gets around those semaphores or removes the spinlocks in upper layers
(as Alan Cox suggested with the "I am crap" helper for printk).
Maybe using a WQ_HIGHPRI for the workqueue with the damages will speed
up things.
More optimizations might be doable too (e.g. combining multiple queued
damages).
> Another option to eliminate all these problems -- long considered but
> never implemented -- is to get rid of all semaphores and potential
> sleeps in udlfb entirely. That would require a strategy to throttle
> rendering in some way other than by waiting in kernel (without some
> throttling strategy, the USB bus can be a bottleneck which can flood
> the system with rendered but untransmitted pixels).
>
> Options might be:
>
> 1) When transfer buffers are full, keep track of dirty rectangles for
> the rest and pick up where we left off the next time we're entered
> (avoiding flooding by potentially having pixels in the dirty regions
> be written over multiple times before we get to rendering them once)
>
> 2 ) If we "bet" on page-fault-based defio dirty pixel detection, we
> could allocate buffers dynamically but increase the scheduling time to
> transfer as our outstanding buffer count grows, and reduce the latency
> only when the buffer count goes down (again, pixels will be
> potentially rendered many times before being transfered once, avoiding
> flooding).
>
> Any other ideas on the specific or general case are welcome. Also
> note that udlfb is being largely superceeded by the udl DRM driver -
> so any decisions here should also be considered in that codebase.
>
> In any case, thanks for giving the DisplayLink USB 2.0 graphics
> drivers attention - it's much appreciated!
Thanks for the sugestions, but I don't feel the need to spend a lot of
time here. I just wanted to use the console with the device and a kernel
3.7.x and neither udlfb nor udl currently worked (and I'm pretty sure
I've used one of them some time before, likely udlfb).
Btw, to see the console again after a disconnect and connect, I'm
currently using the following (necessary) quick&dirty hack:
---------
/* if clients still have us open, will be freed on last close */
- if (dev->fb_count = 0)
+// if (dev->fb_count = 0)
schedule_delayed_work(&dev->free_framebuffer_work, 0);
---------
Without that the framebuffer will never get unregistered (because just
unlinking it doesn't remove the fb-console which counts for one client)
with the result that the new one (after connecting the device again)
will not get the console.
Regards,
Alexander
^ permalink raw reply
* Re: [PATCH] fb: udlfb: fix hang at disconnect
From: Bernie Thompson @ 2013-01-12 22:22 UTC (permalink / raw)
To: Alexander Holler
Cc: linux-kernel, linux-fbdev, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, stable
In-Reply-To: <1357996822-13072-1-git-send-email-holler@ahsoftware.de>
Hi Alexander,
On Sat, Jan 12, 2013 at 5:20 AM, Alexander Holler <holler@ahsoftware.de> wrote:
> When a device was disconnected the driver may hang at waiting for urbs it never
> will get. Fix this by using a timeout while waiting for the used semaphore.
The code used to be this way, but it used to cause nasty shutdown hangs:
http://git.plugable.com/gitphp/index.php?p=udlfb&a=commitdiff&h\x1dd39a65001deb5a84088dfabb788d3274fbb6b6
Which is why the code is the way it is today.
Can you say under what situations you're hitting hangs on device
disconnect? Have you tested extensively to confirm no shutdown hangs
with your patch?
Stepping back, there was another recent patch from the community to
udlfb to work around issues of sleeping in the wrong context. The fix
involved introducing another scheduled workitem. This slows everything
down when it's in the main path, and isn't really desirable if we can
avoid it.
Another option to eliminate all these problems -- long considered but
never implemented -- is to get rid of all semaphores and potential
sleeps in udlfb entirely. That would require a strategy to throttle
rendering in some way other than by waiting in kernel (without some
throttling strategy, the USB bus can be a bottleneck which can flood
the system with rendered but untransmitted pixels).
Options might be:
1) When transfer buffers are full, keep track of dirty rectangles for
the rest and pick up where we left off the next time we're entered
(avoiding flooding by potentially having pixels in the dirty regions
be written over multiple times before we get to rendering them once)
2 ) If we "bet" on page-fault-based defio dirty pixel detection, we
could allocate buffers dynamically but increase the scheduling time to
transfer as our outstanding buffer count grows, and reduce the latency
only when the buffer count goes down (again, pixels will be
potentially rendered many times before being transfered once, avoiding
flooding).
Any other ideas on the specific or general case are welcome. Also
note that udlfb is being largely superceeded by the udl DRM driver -
so any decisions here should also be considered in that codebase.
In any case, thanks for giving the DisplayLink USB 2.0 graphics
drivers attention - it's much appreciated!
Bernie Thompson
http://plugable.com/
^ permalink raw reply
* [PATCH] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-12 13:20 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Bernie Thompson, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, Alexander Holler, stable
When a device was disconnected the driver may hang at waiting for urbs it never
will get. Fix this by using a timeout while waiting for the used semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/video/udlfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 86d449e..cc4a8d1 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1832,8 +1832,8 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout(&dev->urbs.limit_sem, GET_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
^ permalink raw reply related
* fb_image.data format for cursors?
From: Timur Tabi @ 2013-01-11 23:22 UTC (permalink / raw)
To: linux-fbdev
Is there any documentation for cursor support? I'm trying to add cursor
support to my framebuffer driver, and I'm having a really hard time find a
description of anything.
In particular, what is the format of the image data in the fb_image.data
buffer? For example, if fb_image.width = 12, and fb_image.height = 8,
how is the cursor data packed into the 'data' buffer? That is, what is in
data[0], data[1], etc?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [patch] sisfb: fix 1280x720 resolution support
From: Dan Carpenter @ 2013-01-11 6:52 UTC (permalink / raw)
To: linux-fbdev
It uses the wrong mode index because there is no break statement.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static checker fix. Untested.
diff --git a/drivers/video/sis/init.c b/drivers/video/sis/init.c
index f082ae5..0b71c53 100644
--- a/drivers/video/sis/init.c
+++ b/drivers/video/sis/init.c
@@ -651,6 +651,7 @@ SiS_GetModeID_LCD(int VGAEngine, unsigned int VBFlags, int HDisplay, int VDispla
switch(VDisplay) {
case 720:
ModeIndex = ModeIndex_1280x720[Depth];
+ break;
case 768:
if(VGAEngine = SIS_300_VGA) {
ModeIndex = ModeIndex_300_1280x768[Depth];
^ permalink raw reply related
* RE: [PATCHv16 0/7] of: add display helper
From: Mohammed, Afzal @ 2013-01-10 4:58 UTC (permalink / raw)
To: Steffen Trumtrar, devicetree-discuss@lists.ozlabs.org
Cc: Rob Herring, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, Laurent Pinchart, Thierry Reding,
Guennady Liakhovetski, linux-media@vger.kernel.org,
Valkeinen, Tomi, Stephen Warren, kernel@pengutronix.de,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala, Nori, Sekhar
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
SGkgU3RlZmZlbiwNCg0KT24gVGh1LCBKYW4gMTAsIDIwMTMgYXQgMDE6NDU6NDEsIFN0ZWZmZW4g
VHJ1bXRyYXIgd3JvdGU6DQoNCj4gSSB0aGluayB0aGUgc2VyaWVzIHdhcyB0ZXN0ZWQgYXQgbGVh
c3Qgd2l0aA0KPiAJLSBpbXg2cTogc2FicmVsaXRlLCBzYWJyZXNkDQo+IAktIGlteDUzOiB0cW1h
NTMvbWJhNTMNCj4gCS0gb21hcDogREE4NTAgRVZNLCBBTTMzNXggRVZNLCBFVk0tU0sNCg0KVG8g
Y2xhcmlmeSwNCg0KVGhpcyBzZXJpZXMgd2FzIHRlc3RlZCB3aXRoIERUIGJvb3QgKG1ha2luZyB1
c2Ugb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KcHJvdmlkZWQgYnkgdGhpcyBzZXJpZXMpIG9uIEFN
MzM1WCBFVk0gJiBBTTMzNVggRVZNLVNLLiBEQTg1MCBFVk0gd2FzDQp0ZXN0ZWQgd2l0aCBub24g
RFQgYm9vdCBhbG9uZyB3aXRoIHRoaXMgc2VyaWVzICh0byBtYWtlIHN1cmUgdGhhdA0Kbm9uLURU
IGJvb3Qgb24gREE4NTAgRVZNIGlzIG5vdCBicm9rZW4sIGFuZCBpdCBuZWVkZWQgdGhlIGFkZGl0
aW9uYWwNCmNoYW5nZSB0aGF0IHdhcyBtZW50aW9uZWQgZWFybGllcikNCg0KU29ycnkgdGhhdCBt
eSBpbml0aWFsIHJlcGx5IGRpZCBub3QgZXhwcmVzcyB3aGF0IEkgd2FudGVkIHRvLg0KDQpSZWdh
cmRzDQpBZnphbA0KDQoNCg=
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Leela Krishna Amudala @ 2013-01-10 2:52 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
Hi Steffen,
On Thu, Jan 10, 2013 at 1:45 AM, Steffen Trumtrar
<s.trumtrar@pengutronix.de> wrote:
>
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
> >
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
I tested V16 patches with Exynos: smdk5250 board and it works fine for me.
> Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
>
> Thanks,
> Steffen
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Marek Vasut @ 2013-01-09 20:59 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
Dear Steffen Trumtrar,
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
MX53QSB and another custom MX53 board.
> Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
>
> Thanks,
> Steffen
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Laurent Pinchart @ 2013-01-09 20:42 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev, Stephen Warren, devicetree-discuss,
Florian Tobias Schandinat, dri-devel, Tomi Valkeinen, Rob Herring,
kernel, Guennady Liakhovetski, linux-media
In-Reply-To: <20130109201541.GB4780@pengutronix.de>
On Wednesday 09 January 2013 21:15:41 Steffen Trumtrar wrote:
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using.
I've used the sh-mobile-lcdcfb driver.
> Those are the people I know from the top of my head, that use or at least
> did use the patches in one of its iterations. If I forgot anyone, please
> speak up and possibly add your new HW to the list of tested devices.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Thierry Reding @ 2013-01-09 20:37 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, David Airlie,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Florian Tobias Schandinat,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Rob Clark,
Tomi Valkeinen, Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20130109201541.GB4780-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
On Wed, Jan 09, 2013 at 09:15:41PM +0100, Steffen Trumtrar wrote:
> On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> > Hi!
> >
> > Finally, right in time before the end of the world on friday, v16 of the
> > display helpers.
> >
>
> So, any more criticism on the series? Any takers for the series as is?
> I guess it could be merged via the fbdev-tree if David Airlie can agree
> to the DRM patches ?! Does that sound about right?
>
> I think the series was tested at least with
> - imx6q: sabrelite, sabresd
> - imx53: tqma53/mba53
> - omap: DA850 EVM, AM335x EVM, EVM-SK
>
> I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
> are using. Those are the people I know from the top of my head, that use
> or at least did use the patches in one of its iterations. If I forgot
> anyone, please speak up and possibly add your new HW to the list of tested
> devices.
I tested earlier versions on Tegra. The latest one was v15 I think.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Steffen Trumtrar @ 2013-01-09 20:15 UTC (permalink / raw)
To: devicetree-discuss
Cc: Rob Herring, linux-fbdev, dri-devel, Laurent Pinchart,
Thierry Reding, Guennady Liakhovetski, linux-media,
Tomi Valkeinen, Stephen Warren, kernel, Florian Tobias Schandinat,
David Airlie, Rob Clark, Leela Krishna Amudala
In-Reply-To: <1355850256-16135-1-git-send-email-s.trumtrar@pengutronix.de>
On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote:
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
>
So, any more criticism on the series? Any takers for the series as is?
I guess it could be merged via the fbdev-tree if David Airlie can agree
to the DRM patches ?! Does that sound about right?
I think the series was tested at least with
- imx6q: sabrelite, sabresd
- imx53: tqma53/mba53
- omap: DA850 EVM, AM335x EVM, EVM-SK
I don't know what Laurent Pinchart, Marek Vasut and Leela Krishna Amudala
are using. Those are the people I know from the top of my head, that use
or at least did use the patches in one of its iterations. If I forgot
anyone, please speak up and possibly add your new HW to the list of tested
devices.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Marek Vasut @ 2013-01-09 19:56 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <20130109193953.GA4780@pengutronix.de>
Dear Steffen Trumtrar,
> Hi!
>
> On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> > Dear Steffen Trumtrar,
> >
> > I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After
> > adding the following piece of code (quick hack), this works just fine.
> > Thanks!
> >
> > diff --git a/drivers/staging/imx-drm/parallel-display.c
> > b/drivers/staging/imx- drm/parallel-display.c
> > index a8064fc..e45002a 100644
> > --- a/drivers/staging/imx-drm/parallel-display.c
> > +++ b/drivers/staging/imx-drm/parallel-display.c
> > @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct
> > drm_connector *connector)
> >
> > static int imx_pd_connector_get_modes(struct drm_connector *connector)
> > {
> >
> > struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> >
> > + struct device_node *np = imxpd->dev->of_node;
> >
> > int num_modes = 0;
> >
> > if (imxpd->edid) {
> >
> > @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct
> > drm_connector *connector)
> >
> > num_modes++;
> >
> > }
> >
> > + if (np) {
> > + struct drm_display_mode *mode > > drm_mode_create(connector->dev); +
> > of_get_drm_display_mode(np, &imxpd->mode, 0);
> > + drm_mode_copy(mode, &imxpd->mode);
> > + mode->type |= DRM_MODE_TYPE_DRIVER |
> > DRM_MODE_TYPE_PREFERRED, + drm_mode_probed_add(connector,
> > mode);
> > + num_modes++;
> > + }
> > +
> >
> > return num_modes;
> >
> > }
>
> Nice! I haven't tried the parallel display, but I think Philipp Zabel might
> already have a patch for it. If not, I will definitly keep your patch in my
> topic branch.
Works like charm here.
Make sure to adjust the patch and check for the return value of
of_get_drm_display_mode(np, &imxpd->mode, 0); call, that's probably the only
issue that needs fixing in that hack. Checking if np != NULL might not hurt
either. I can roll you a real patch if it helps.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Steffen Trumtrar @ 2013-01-09 19:39 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <201301092012.01985.marex@denx.de>
Hi!
On Wed, Jan 09, 2013 at 08:12:01PM +0100, Marek Vasut wrote:
> Dear Steffen Trumtrar,
>
> I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After adding
> the following piece of code (quick hack), this works just fine. Thanks!
>
> diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
> drm/parallel-display.c
> index a8064fc..e45002a 100644
> --- a/drivers/staging/imx-drm/parallel-display.c
> +++ b/drivers/staging/imx-drm/parallel-display.c
> @@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
> *connector)
> static int imx_pd_connector_get_modes(struct drm_connector *connector)
> {
> struct imx_parallel_display *imxpd = con_to_imxpd(connector);
> + struct device_node *np = imxpd->dev->of_node;
> int num_modes = 0;
>
> if (imxpd->edid) {
> @@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
> *connector)
> num_modes++;
> }
>
> + if (np) {
> + struct drm_display_mode *mode = drm_mode_create(connector->dev);
> + of_get_drm_display_mode(np, &imxpd->mode, 0);
> + drm_mode_copy(mode, &imxpd->mode);
> + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> + drm_mode_probed_add(connector, mode);
> + num_modes++;
> + }
> +
> return num_modes;
> }
>
Nice! I haven't tried the parallel display, but I think Philipp Zabel might
already have a patch for it. If not, I will definitly keep your patch in my
topic branch.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv16 0/7] of: add display helper
From: Marek Vasut @ 2013-01-09 19:12 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren, kernel,
Florian Tobias Schandinat, David Airlie, Rob Clark,
Leela Krishna Amudala
In-Reply-To: <1355850256-16135-1-git-send-email-s.trumtrar@pengutronix.de>
Dear Steffen Trumtrar,
> Hi!
>
> Finally, right in time before the end of the world on friday, v16 of the
> display helpers.
I tested this on 3.8-rc1 (next 20130103) with the imx drm driver. After adding
the following piece of code (quick hack), this works just fine. Thanks!
diff --git a/drivers/staging/imx-drm/parallel-display.c b/drivers/staging/imx-
drm/parallel-display.c
index a8064fc..e45002a 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -57,6 +57,7 @@ static void imx_pd_connector_destroy(struct drm_connector
*connector)
static int imx_pd_connector_get_modes(struct drm_connector *connector)
{
struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+ struct device_node *np = imxpd->dev->of_node;
int num_modes = 0;
if (imxpd->edid) {
@@ -72,6 +73,15 @@ static int imx_pd_connector_get_modes(struct drm_connector
*connector)
num_modes++;
}
+ if (np) {
+ struct drm_display_mode *mode = drm_mode_create(connector->dev);
+ of_get_drm_display_mode(np, &imxpd->mode, 0);
+ drm_mode_copy(mode, &imxpd->mode);
+ mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+ drm_mode_probed_add(connector, mode);
+ num_modes++;
+ }
+
return num_modes;
}
Best regards,
Marek Vasut
^ permalink raw reply related
* [PATCH v2] fb: udlfb: fix scheduling while atomic.
From: Alexander Holler @ 2013-01-09 13:47 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Bernie Thompson, Florian Tobias Schandinat, Alan Cox,
Steve Glendinning, Dave Airlie, Alexander Holler, stable
In-Reply-To: <50E9722D.2090602@ahsoftware.de>
The console functions are using spinlocks while calling fb-driver ops
but udlfb waits for a semaphore in many ops. This results in the BUG
"scheduling while atomic". One of those call flows is e.g.
vt_console_print() (spinlock printing_lock)
(...)
dlfb_ops_imageblit()
dlfb_handle_damage()
dlfb_get_urb()
down_timeout(semaphore)
BUG: scheduling while atomic
(...)
vt_console_print() (release spinlock printing_lock)
Fix this through a workqueue for dlfb_handle_damage().
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/video/udlfb.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
include/video/udlfb.h | 1 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 86d449e..4a90784 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -569,7 +569,7 @@ static int dlfb_render_hline(struct dlfb_data *dev, struct urb **urb_ptr,
return 0;
}
-int dlfb_handle_damage(struct dlfb_data *dev, int x, int y,
+int dlfb_handle_damage_queued(struct dlfb_data *dev, int x, int y,
int width, int height, char *data)
{
int i, ret;
@@ -630,6 +630,44 @@ error:
return 0;
}
+struct dlfb_handle_damage_work {
+ struct work_struct my_work;
+ struct dlfb_data *dev;
+ char *data;
+ int x, y, width, height;
+};
+
+static void dlfb_handle_damage_work(struct work_struct *work)
+{
+ struct dlfb_handle_damage_work *my_work + (struct dlfb_handle_damage_work *)work;
+
+ dlfb_handle_damage_queued(my_work->dev, my_work->x, my_work->y,
+ my_work->width, my_work->height, my_work->data);
+ kfree(work);
+ return;
+}
+
+void dlfb_handle_damage(struct dlfb_data *dev, int x, int y,
+ int width, int height, char *data)
+{
+ struct dlfb_handle_damage_work *work + kmalloc(sizeof(struct dlfb_handle_damage_work), GFP_KERNEL);
+
+ if (!work) {
+ pr_err("unable to allocate work\n");
+ return;
+ }
+ INIT_WORK((struct work_struct *)work, dlfb_handle_damage_work);
+ work->dev = dev;
+ work->x = x;
+ work->y = y;
+ work->width = width;
+ work->height = height;
+ work->data = data;
+ queue_work(dev->handle_damage_wq, (struct work_struct *)work);
+}
+
/*
* Path triggered by usermode clients who write to filesystem
* e.g. cat filename > /dev/fb1
@@ -945,6 +983,9 @@ static void dlfb_free_framebuffer(struct dlfb_data *dev)
unregister_framebuffer(info);
+ if (dev->handle_damage_wq)
+ destroy_workqueue(dev->handle_damage_wq);
+
if (info->cmap.len != 0)
fb_dealloc_cmap(&info->cmap);
if (info->monspecs.modedb)
@@ -1694,6 +1735,13 @@ static void dlfb_init_framebuffer_work(struct work_struct *work)
goto error;
}
+ dev->handle_damage_wq = alloc_workqueue("udlfb_damage",
+ WQ_MEM_RECLAIM, 0);
+ if (dev->handle_damage_wq = NULL) {
+ pr_err("unable to allocate workqueue\n");
+ goto error;
+ }
+
/* ready to begin using device */
atomic_set(&dev->usb_active, 1);
diff --git a/include/video/udlfb.h b/include/video/udlfb.h
index f9466fa..1e765f9 100644
--- a/include/video/udlfb.h
+++ b/include/video/udlfb.h
@@ -43,6 +43,7 @@ struct dlfb_data {
bool virtualized; /* true when physical usb device not present */
struct delayed_work init_framebuffer_work;
struct delayed_work free_framebuffer_work;
+ struct workqueue_struct *handle_damage_wq;
atomic_t usb_active; /* 0 = update virtual buffer, but no usb traffic */
atomic_t lost_pixels; /* 1 = a render op failed. Need screen refresh */
char *edid; /* null until we read edid from hw or get from sysfs */
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] video: exynos_mipi_dsi: Use devm_* APIs
From: Donghwa Lee @ 2013-01-09 10:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1357196444-8077-1-git-send-email-sachin.kamat@linaro.org>
Hi, Sachin Kamat,
I'm sorry I didn't see your mail.
It seems to more simple to me.
Acked-by: Donghwa Lee <dh09.lee@samsung.com>
Thank you,
Donghwa Lee
On 3 Jan 2013 16:00, Sachin Kamat wrote:
> devm_* APIs are device managed and make exit and cleanup code simpler.
> While at it also remove some unused labels and fix an error path.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> Compile tested using the latest linux-next tree.
> This patch should be applied on top of the following patch:
> http://www.spinics.net/lists/linux-fbdev/msg09303.html
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 68 ++++++++------------------------
> include/video/exynos_mipi_dsim.h | 1 -
> 2 files changed, 17 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
> index f623dfc..fac7df6 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi.c
> @@ -338,7 +338,8 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> struct mipi_dsim_ddi *dsim_ddi;
> int ret = -EINVAL;
>
> - dsim = kzalloc(sizeof(struct mipi_dsim_device), GFP_KERNEL);
> + dsim = devm_kzalloc(&pdev->dev, sizeof(struct mipi_dsim_device),
> + GFP_KERNEL);
> if (!dsim) {
> dev_err(&pdev->dev, "failed to allocate dsim object.\n");
> return -ENOMEM;
> @@ -352,13 +353,13 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> dsim_pd = (struct mipi_dsim_platform_data *)dsim->pd;
> if (dsim_pd = NULL) {
> dev_err(&pdev->dev, "failed to get platform data for dsim.\n");
> - goto err_clock_get;
> + return -EINVAL;
> }
> /* get mipi_dsim_config. */
> dsim_config = dsim_pd->dsim_config;
> if (dsim_config = NULL) {
> dev_err(&pdev->dev, "failed to get dsim config data.\n");
> - goto err_clock_get;
> + return -EINVAL;
> }
>
> dsim->dsim_config = dsim_config;
> @@ -366,41 +367,28 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
>
> mutex_init(&dsim->lock);
>
> - ret = regulator_bulk_get(&pdev->dev, ARRAY_SIZE(supplies), supplies);
> + ret = devm_regulator_bulk_get(&pdev->dev, ARRAY_SIZE(supplies),
> + supplies);
> if (ret) {
> dev_err(&pdev->dev, "Failed to get regulators: %d\n", ret);
> - goto err_clock_get;
> + return ret;
> }
>
> - dsim->clock = clk_get(&pdev->dev, "dsim0");
> + dsim->clock = devm_clk_get(&pdev->dev, "dsim0");
> if (IS_ERR(dsim->clock)) {
> dev_err(&pdev->dev, "failed to get dsim clock source\n");
> - ret = -ENODEV;
> - goto err_clock_get;
> + return -ENODEV;
> }
>
> clk_enable(dsim->clock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "failed to get io memory region\n");
> - ret = -ENODEV;
> - goto err_platform_get;
> - }
> -
> - dsim->res = request_mem_region(res->start, resource_size(res),
> - dev_name(&pdev->dev));
> - if (!dsim->res) {
> - dev_err(&pdev->dev, "failed to request io memory region\n");
> - ret = -ENOMEM;
> - goto err_mem_region;
> - }
>
> - dsim->reg_base = ioremap(res->start, resource_size(res));
> + dsim->reg_base = devm_request_and_ioremap(&pdev->dev, res);
> if (!dsim->reg_base) {
> dev_err(&pdev->dev, "failed to remap io region\n");
> ret = -ENOMEM;
> - goto err_ioremap;
> + goto error;
> }
>
> mutex_init(&dsim->lock);
> @@ -410,26 +398,27 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
> if (!dsim_ddi) {
> dev_err(&pdev->dev, "mipi_dsim_ddi object not found.\n");
> ret = -EINVAL;
> - goto err_bind;
> + goto error;
> }
>
> dsim->irq = platform_get_irq(pdev, 0);
> if (IS_ERR_VALUE(dsim->irq)) {
> dev_err(&pdev->dev, "failed to request dsim irq resource\n");
> ret = -EINVAL;
> - goto err_platform_get_irq;
> + goto error;
> }
>
> init_completion(&dsim_wr_comp);
> init_completion(&dsim_rd_comp);
> platform_set_drvdata(pdev, dsim);
>
> - ret = request_irq(dsim->irq, exynos_mipi_dsi_interrupt_handler,
> + ret = devm_request_irq(&pdev->dev, dsim->irq,
> + exynos_mipi_dsi_interrupt_handler,
> IRQF_SHARED, dev_name(&pdev->dev), dsim);
> if (ret != 0) {
> dev_err(&pdev->dev, "failed to request dsim irq\n");
> ret = -EINVAL;
> - goto err_bind;
> + goto error;
> }
>
> /* enable interrupts */
> @@ -471,22 +460,8 @@ done:
>
> return 0;
>
> -err_bind:
> - iounmap(dsim->reg_base);
> -
> -err_ioremap:
> - release_mem_region(dsim->res->start, resource_size(dsim->res));
> -
> -err_mem_region:
> - release_resource(dsim->res);
> -
> -err_platform_get:
> +error:
> clk_disable(dsim->clock);
> - clk_put(dsim->clock);
> -err_clock_get:
> - kfree(dsim);
> -
> -err_platform_get_irq:
> return ret;
> }
>
> @@ -496,13 +471,7 @@ static int exynos_mipi_dsi_remove(struct platform_device *pdev)
> struct mipi_dsim_ddi *dsim_ddi, *next;
> struct mipi_dsim_lcd_driver *dsim_lcd_drv;
>
> - iounmap(dsim->reg_base);
> -
> clk_disable(dsim->clock);
> - clk_put(dsim->clock);
> -
> - release_resource(dsim->res);
> - release_mem_region(dsim->res->start, resource_size(dsim->res));
>
> list_for_each_entry_safe(dsim_ddi, next, &dsim_ddi_list, list) {
> if (dsim_ddi) {
> @@ -518,9 +487,6 @@ static int exynos_mipi_dsi_remove(struct platform_device *pdev)
> }
> }
>
> - regulator_bulk_free(ARRAY_SIZE(supplies), supplies);
> - kfree(dsim);
> -
> return 0;
> }
>
> diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
> index 83ce5e6..89dc88a 100644
> --- a/include/video/exynos_mipi_dsim.h
> +++ b/include/video/exynos_mipi_dsim.h
> @@ -220,7 +220,6 @@ struct mipi_dsim_config {
> struct mipi_dsim_device {
> struct device *dev;
> int id;
> - struct resource *res;
> struct clk *clock;
> unsigned int irq;
> void __iomem *reg_base;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox