* [PATCH 09/15] video: cg6: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/cg6.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/cg6.c b/drivers/video/cg6.c
index 3545dec..f070ec3 100644
--- a/drivers/video/cg6.c
+++ b/drivers/video/cg6.c
@@ -839,8 +839,6 @@ static int cg6_remove(struct platform_device *op)
framebuffer_release(info);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/15] video: ffb: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/ffb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/ffb.c b/drivers/video/ffb.c
index 6d27447..4c4ffa6 100644
--- a/drivers/video/ffb.c
+++ b/drivers/video/ffb.c
@@ -1035,8 +1035,6 @@ static int ffb_remove(struct platform_device *op)
framebuffer_release(info);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 11/15] video: p9100: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/p9100.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/p9100.c b/drivers/video/p9100.c
index 4b23af6..367cea8 100644
--- a/drivers/video/p9100.c
+++ b/drivers/video/p9100.c
@@ -339,8 +339,6 @@ static int p9100_remove(struct platform_device *op)
framebuffer_release(info);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 12/15] video: platinumfb: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/platinumfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/platinumfb.c b/drivers/video/platinumfb.c
index 3d86bac..b644037 100644
--- a/drivers/video/platinumfb.c
+++ b/drivers/video/platinumfb.c
@@ -639,7 +639,6 @@ static int platinumfb_probe(struct platform_device* odev)
iounmap(pinfo->frame_buffer);
iounmap(pinfo->platinum_regs);
iounmap(pinfo->cmap_regs);
- dev_set_drvdata(&odev->dev, NULL);
framebuffer_release(info);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 13/15] video: sunxvr1000: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/sunxvr1000.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/sunxvr1000.c b/drivers/video/sunxvr1000.c
index cc6f48b..58241b4 100644
--- a/drivers/video/sunxvr1000.c
+++ b/drivers/video/sunxvr1000.c
@@ -186,8 +186,6 @@ static int gfb_remove(struct platform_device *op)
framebuffer_release(info);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/15] video: tcx: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/tcx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/tcx.c b/drivers/video/tcx.c
index c000852..1f3a327 100644
--- a/drivers/video/tcx.c
+++ b/drivers/video/tcx.c
@@ -498,8 +498,6 @@ static int tcx_remove(struct platform_device *op)
framebuffer_release(info);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 15/15] video: xilinxfb: Remove redundant dev_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:44 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/xilinxfb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 84c664e..0e1dd33 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -369,7 +369,6 @@ err_fbmem:
err_region:
kfree(drvdata);
- dev_set_drvdata(dev, NULL);
return rc;
}
@@ -404,7 +403,6 @@ static int xilinxfb_release(struct device *dev)
#endif
kfree(drvdata);
- dev_set_drvdata(dev, NULL);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/1] video: grvga: Use module_platform_driver
From: Sachin Kamat @ 2013-09-20 6:47 UTC (permalink / raw)
To: linux-fbdev
module_platform_driver removes some boilerplate code and makes
it simple.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Kristoffer Glembo <kristoffer@gaisler.com>
---
drivers/video/grvga.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/video/grvga.c b/drivers/video/grvga.c
index 01fbcaf..c078701 100644
--- a/drivers/video/grvga.c
+++ b/drivers/video/grvga.c
@@ -555,19 +555,7 @@ static struct platform_driver grvga_driver = {
.remove = grvga_remove,
};
-
-static int __init grvga_init(void)
-{
- return platform_driver_register(&grvga_driver);
-}
-
-static void __exit grvga_exit(void)
-{
- platform_driver_unregister(&grvga_driver);
-}
-
-module_init(grvga_init);
-module_exit(grvga_exit);
+module_platform_driver(grvga_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Aeroflex Gaisler");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] backlight: l4f00242t03: Remove redundant spi_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:50 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/backlight/l4f00242t03.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/l4f00242t03.c b/drivers/video/backlight/l4f00242t03.c
index a35a38c..59eebe0 100644
--- a/drivers/video/backlight/l4f00242t03.c
+++ b/drivers/video/backlight/l4f00242t03.c
@@ -244,7 +244,6 @@ static int l4f00242t03_remove(struct spi_device *spi)
l4f00242t03_lcd_power_set(priv->ld, FB_BLANK_POWERDOWN);
lcd_device_unregister(priv->ld);
- spi_set_drvdata(spi, NULL);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] backlight: tosa: Remove redundant spi_set_drvdata
From: Sachin Kamat @ 2013-09-20 6:50 UTC (permalink / raw)
To: linux-fbdev
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/backlight/tosa_lcd.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c b/drivers/video/backlight/tosa_lcd.c
index bf08157..be5d636 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -198,7 +198,7 @@ static int tosa_lcd_probe(struct spi_device *spi)
ret = devm_gpio_request_one(&spi->dev, TOSA_GPIO_TG_ON,
GPIOF_OUT_INIT_LOW, "tg #pwr");
if (ret < 0)
- goto err_gpio_tg;
+ return ret;
mdelay(60);
@@ -219,8 +219,6 @@ static int tosa_lcd_probe(struct spi_device *spi)
err_register:
tosa_lcd_tg_off(data);
-err_gpio_tg:
- spi_set_drvdata(spi, NULL);
return ret;
}
@@ -235,8 +233,6 @@ static int tosa_lcd_remove(struct spi_device *spi)
tosa_lcd_tg_off(data);
- spi_set_drvdata(spi, NULL);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
From: Ryan Mallon @ 2013-09-20 7:06 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD, tomi.valkeinen
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Several video drivers open code the fb_write write function with code
which is very similar to fb_sys_write. Replace the open code versions
with calls to fb_sys_write. An fb_sync callback is added to each of
the drivers.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
---
diff --git a/drivers/video/auo_k190x.c b/drivers/video/auo_k190x.c
index 8d2499d..0eeeb26 100644
--- a/drivers/video/auo_k190x.c
+++ b/drivers/video/auo_k190x.c
@@ -362,50 +362,12 @@ out:
* framebuffer operations
*/
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it's inefficient to do anything less than a full screen draw
- */
-static ssize_t auok190xfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
+static int auok190xfb_sync(struct fb_info *info)
{
struct auok190xfb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = (void *)(info->screen_base + p);
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
par->update_all(par);
-
- return (err) ? err : count;
+ return 0;
}
static void auok190xfb_fillrect(struct fb_info *info,
@@ -565,7 +527,8 @@ static int auok190xfb_set_par(struct fb_info *info)
static struct fb_ops auok190xfb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
- .fb_write = auok190xfb_write,
+ .fb_write = fb_sys_write,
+ .fb_sync = auok190xfb_sync,
.fb_fillrect = auok190xfb_fillrect,
.fb_copyarea = auok190xfb_copyarea,
.fb_imageblit = auok190xfb_imageblit,
@@ -1066,6 +1029,7 @@ int auok190x_common_probe(struct platform_device *pdev,
memset(videomemory, 0, videomemorysize);
info->screen_base = (char *)videomemory;
+ info->screen_size = videomemorysize;
info->fix.smem_len = videomemorysize;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB;
diff --git a/drivers/video/broadsheetfb.c b/drivers/video/broadsheetfb.c
index b09701c..4d6231a 100644
--- a/drivers/video/broadsheetfb.c
+++ b/drivers/video/broadsheetfb.c
@@ -924,6 +924,14 @@ static void broadsheetfb_dpy_update(struct broadsheetfb_par *par)
mutex_unlock(&(par->io_lock));
}
+static int broadsheetfb_sync(struct fb_info *info)
+{
+ struct broadsheetfb_par *par = info->par;
+
+ broadsheetfb_dpy_update(par);
+ return 0;
+}
+
/* this is called back from the deferred io workqueue */
static void broadsheetfb_dpy_deferred_io(struct fb_info *info,
struct list_head *pagelist)
@@ -998,56 +1006,11 @@ static void broadsheetfb_imageblit(struct fb_info *info,
broadsheetfb_dpy_update(par);
}
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it's inefficient to do anything less than a full screen draw
- */
-static ssize_t broadsheetfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct broadsheetfb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = (void *)(info->screen_base + p);
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- broadsheetfb_dpy_update(par);
-
- return (err) ? err : count;
-}
-
static struct fb_ops broadsheetfb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
- .fb_write = broadsheetfb_write,
+ .fb_write = fb_sys_write,
+ .fb_sync = broadsheetfb_sync,
.fb_fillrect = broadsheetfb_fillrect,
.fb_copyarea = broadsheetfb_copyarea,
.fb_imageblit = broadsheetfb_imageblit,
@@ -1106,6 +1069,7 @@ static int broadsheetfb_probe(struct platform_device *dev)
goto err_fb_rel;
info->screen_base = (char *)videomemory;
+ info->screen_size = videomemorysize;
info->fbops = &broadsheetfb_ops;
broadsheetfb_var.xres = dpyw;
diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c
index 59d2318..e8361e1 100644
--- a/drivers/video/hecubafb.c
+++ b/drivers/video/hecubafb.c
@@ -114,6 +114,14 @@ static void hecubafb_dpy_update(struct hecubafb_par *par)
apollo_send_command(par, APOLLO_DISPLAY_IMG);
}
+static int hecubafb_sync(struct fb_info *info)
+{
+ struct hecubafb_par *par = info->par;
+
+ hecubafb_dpy_update(par);
+ return 0;
+}
+
/* this is called back from the deferred io workqueue */
static void hecubafb_dpy_deferred_io(struct fb_info *info,
struct list_head *pagelist)
@@ -151,56 +159,11 @@ static void hecubafb_imageblit(struct fb_info *info,
hecubafb_dpy_update(par);
}
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it's inefficient to do anything less than a full screen draw
- */
-static ssize_t hecubafb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct hecubafb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = (void __force *) (info->screen_base + p);
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- hecubafb_dpy_update(par);
-
- return (err) ? err : count;
-}
-
static struct fb_ops hecubafb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
- .fb_write = hecubafb_write,
+ .fb_write = fb_sys_write,
+ .fb_sync = hecubafb_sync,
.fb_fillrect = hecubafb_fillrect,
.fb_copyarea = hecubafb_copyarea,
.fb_imageblit = hecubafb_imageblit,
@@ -240,6 +203,7 @@ static int hecubafb_probe(struct platform_device *dev)
goto err_fballoc;
info->screen_base = (char __force __iomem *)videomemory;
+ info->screen_size = videomemorysize;
info->fbops = &hecubafb_ops;
info->var = hecubafb_var;
diff --git a/drivers/video/metronomefb.c b/drivers/video/metronomefb.c
index f30150d..7f79916 100644
--- a/drivers/video/metronomefb.c
+++ b/drivers/video/metronomefb.c
@@ -447,6 +447,14 @@ static void metronomefb_dpy_update(struct metronomefb_par *par)
metronome_display_cmd(par);
}
+static int metronomefb_sync(struct fb_info *info)
+{
+ struct metronomefb_par *par = info->par;
+
+ metronomefb_dpy_udpate(par);
+ return 0;
+}
+
static u16 metronomefb_dpy_update_page(struct metronomefb_par *par, int index)
{
int i;
@@ -510,55 +518,10 @@ static void metronomefb_imageblit(struct fb_info *info,
metronomefb_dpy_update(par);
}
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it is based on fb_sys_write
- */
-static ssize_t metronomefb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct metronomefb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (info->state != FBINFO_STATE_RUNNING)
- return -EPERM;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = (void __force *)(info->screen_base + p);
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- metronomefb_dpy_update(par);
-
- return (err) ? err : count;
-}
-
static struct fb_ops metronomefb_ops = {
.owner = THIS_MODULE,
- .fb_write = metronomefb_write,
+ .fb_write = fb_sys_write,
+ .fb_sync = metronomefb_sync,
.fb_fillrect = metronomefb_fillrect,
.fb_copyarea = metronomefb_copyarea,
.fb_imageblit = metronomefb_imageblit,
@@ -633,6 +596,7 @@ static int metronomefb_probe(struct platform_device *dev)
goto err_fb_rel;
info->screen_base = (char __force __iomem *)videomemory;
+ info->screen_size = videomemorysize;
info->fbops = &metronomefb_ops;
metronomefb_fix.line_length = fw;
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
index 44967c8..2b46790 100644
--- a/drivers/video/ssd1307fb.c
+++ b/drivers/video/ssd1307fb.c
@@ -198,36 +198,12 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
kfree(array);
}
-
-static ssize_t ssd1307fb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
+static int ssd1307fb_sync(struct fb_info *info)
{
struct ssd1307fb_par *par = info->par;
- unsigned long total_size;
- unsigned long p = *ppos;
- u8 __iomem *dst;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EINVAL;
-
- if (count + p > total_size)
- count = total_size - p;
-
- if (!count)
- return -EINVAL;
-
- dst = (void __force *) (info->screen_base + p);
-
- if (copy_from_user(dst, buf, count))
- return -EFAULT;
ssd1307fb_update_display(par);
-
- *ppos += count;
-
- return count;
+ return 0;
}
static void ssd1307fb_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
@@ -254,7 +230,8 @@ static void ssd1307fb_imageblit(struct fb_info *info, const struct fb_image *ima
static struct fb_ops ssd1307fb_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
- .fb_write = ssd1307fb_write,
+ .fb_write = fb_sys_write,
+ .fb_sync = ssd1307fb_sync,
.fb_fillrect = ssd1307fb_fillrect,
.fb_copyarea = ssd1307fb_copyarea,
.fb_imageblit = ssd1307fb_imageblit,
@@ -493,6 +470,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
+ info->screen_size = vmem_size;
info->fix.smem_start = (unsigned long)vmem;
info->fix.smem_len = vmem_size;
^ permalink raw reply related
* Re: [PATCH 01/15] video: atmel_lcdfb: Remove redundant dev_set_drvdata
From: Nicolas Ferre @ 2013-09-20 7:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658744-17113-2-git-send-email-sachin.kamat@linaro.org>
On 20/09/2013 08:32, Sachin Kamat :
> Driver core sets driver data to NULL upon failure or remove.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/video/atmel_lcdfb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 34e934d..70052e7 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -1318,7 +1318,6 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> return 0;
>
> reset_drvdata:
> - dev_set_drvdata(dev, NULL);
> fb_dealloc_cmap(&info->cmap);
> unregister_irqs:
> cancel_work_sync(&sinfo->task);
> @@ -1379,7 +1378,6 @@ static int __exit atmel_lcdfb_remove(struct platform_device *pdev)
> atmel_lcdfb_free_video_memory(sinfo);
> }
>
> - dev_set_drvdata(dev, NULL);
> framebuffer_release(info);
>
> return 0;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/2] framebuffer: Remove pmag-aa-fb
From: Geert Uytterhoeven @ 2013-09-20 7:33 UTC (permalink / raw)
To: Joe Perches, Maciej W. Rozycki
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org,
Linux MIPS Mailing List
In-Reply-To: <6f500d88eb23fd9a4cfc5583f5ca17bc5f58fe24.1379641901.git.joe@perches.com>
Adding Maciej and linux-mips
On Fri, Sep 20, 2013 at 3:53 AM, Joe Perches <joe@perches.com> wrote:
> This driver apparently hasn't compiled since 2.5 days as
> it uses a #define that isn't around anymore.
>
> Remove it.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/Kconfig | 10 -
> drivers/video/Makefile | 1 -
> drivers/video/pmag-aa-fb.c | 510 ---------------------------------------------
> 3 files changed, 521 deletions(-)
> delete mode 100644 drivers/video/pmag-aa-fb.c
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 14317b7..e92798e 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1821,16 +1821,6 @@ config FB_HIT
> This is the frame buffer device driver for the Hitachi HD64461 LCD
> frame buffer card.
>
> -config FB_PMAG_AA
> - bool "PMAG-AA TURBOchannel framebuffer support"
> - depends on (FB = y) && TC
> - select FB_CFB_FILLRECT
> - select FB_CFB_COPYAREA
> - select FB_CFB_IMAGEBLIT
> - help
> - Support for the PMAG-AA TURBOchannel framebuffer card (1280x1024x1)
> - used mainly in the MIPS-based DECstation series.
> -
> config FB_PMAG_BA
> tristate "PMAG-BA TURBOchannel framebuffer support"
> depends on FB && TC
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index e8bae8d..5c8b340 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -114,7 +114,6 @@ obj-$(CONFIG_FB_AU1100) += au1100fb.o
> obj-$(CONFIG_FB_AU1200) += au1200fb.o
> obj-$(CONFIG_FB_VT8500) += vt8500lcdfb.o
> obj-$(CONFIG_FB_WM8505) += wm8505fb.o
> -obj-$(CONFIG_FB_PMAG_AA) += pmag-aa-fb.o
> obj-$(CONFIG_FB_PMAG_BA) += pmag-ba-fb.o
> obj-$(CONFIG_FB_PMAGB_B) += pmagb-b-fb.o
> obj-$(CONFIG_FB_MAXINE) += maxinefb.o
> diff --git a/drivers/video/pmag-aa-fb.c b/drivers/video/pmag-aa-fb.c
> deleted file mode 100644
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/1] video: grvga: Use module_platform_driver
From: Tomi Valkeinen @ 2013-09-20 9:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379658938-18080-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On 20/09/13 09:35, Sachin Kamat wrote:
> module_platform_driver removes some boilerplate code and makes
> it simple.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Kristoffer Glembo <kristoffer@gaisler.com>
> ---
> drivers/video/grvga.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] radeon: Conditionally compile PM code
From: Tomi Valkeinen @ 2013-09-20 9:17 UTC (permalink / raw)
To: Thierry Reding, Benjamin Herrenschmidt,
Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1379508512-30155-1-git-send-email-treding@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
On 18/09/13 15:48, Thierry Reding wrote:
> The power management code is only used on X86 and PowerMac. To prevent
> the compiler from warning about unused code, only build when PM and one
> of X86 or PowerMac is selected.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Thanks, applied for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/19] video: use dev_get_platdata()
From: Tomi Valkeinen @ 2013-09-20 9:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <000401ceb361$d84c4600$88e4d200$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
On 17/09/13 07:53, Jingoo Han wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly. This is a cosmetic change
> to make the code simpler and enhance the readability.
>
> ---
> drivers/video/amba-clcd.c | 2 +-
> drivers/video/atmel_lcdfb.c | 4 ++--
> drivers/video/da8xx-fb.c | 4 ++--
> drivers/video/ep93xx-fb.c | 2 +-
> drivers/video/imxfb.c | 6 +++---
> drivers/video/mbx/mbxfb.c | 2 +-
> drivers/video/mx3fb.c | 4 ++--
> drivers/video/nuc900fb.c | 6 +++---
> drivers/video/omap/hwa742.c | 2 +-
> drivers/video/omap/omapfb_main.c | 4 ++--
> drivers/video/pxa168fb.c | 6 +++---
> drivers/video/pxafb.c | 16 ++++++++--------
> drivers/video/s1d13xxxfb.c | 12 ++++++------
> drivers/video/s3c-fb.c | 2 +-
> drivers/video/s3c2410fb.c | 6 +++---
> drivers/video/sa1100fb.c | 4 ++--
> drivers/video/sh_mobile_hdmi.c | 6 +++---
> drivers/video/simplefb.c | 4 ++--
> drivers/video/tmiofb.c | 10 +++++-----
> drivers/video/w100fb.c | 2 +-
> 20 files changed, 52 insertions(+), 52 deletions(-)
>
>
Thanks, applying for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver for Vybrid VF610 platform
From: Tomi Valkeinen @ 2013-09-20 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81BA6E5E0BC2344391CABCEE22D1B6D842FD6A@039-SN1MPN1-003.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
On 13/09/13 10:07, Wang Huan-B18965 wrote:
> My comments inline.
>
>> -----Original Message----- From: Tomi Valkeinen
>> [mailto:tomi.valkeinen@ti.com] Sent: Wednesday, September 04, 2013
>> 6:33 PM To: Wang Huan-B18965 Cc: plagnioj@jcrosoft.com;
>> linux-fbdev@vger.kernel.org; linux-arm- kernel@lists.infradead.org;
>> Jin Zhengxiong-R64188; Estevam Fabio-R49496; shawn.guo@linaro.org
>> Subject: Re: [PATCH v3 0/5] ARM: vf610: Add DCU framebuffer driver
>> for Vybrid VF610 platform
>>
>> Hi,
>>
>> On 03/09/13 11:21, Wang Huan-B18965 wrote:
>>> Hi, Jean-Christophe, Tomi,
>>>
>>> Could you please help to review these patches? Thanks!
>>
>> There seemed to be some strong opinions that there should be a drm
>> driver for this hardware, instead of an fb driver. So as there
>> seems to be disagreements about this, I'll leave this series to
>> Jean-Christophe, who's the primary maintainer.
> [Alison Wang]
>
> Thanks for Tomi's comments.
>
> I agree that we can implement the DRM driver for the DCU. As the
> bandwidth limitation, I suggest we use the fb driver firstly. On the
> other hand, the fb driver can meet the application requirement based
> on this SoC. We'll try to provide the DRM driver when this IP
> integrated into other SoC.
If you plan to move to DRM driver anyway, I would strongly suggest
merging only the DRM driver. If we merge the fb driver, and a bit later
the DRM driver for the same hardware, we'll have two drivers of which
the other is already deprecated.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:16 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk>
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Tejun Heo <tj@kernel.org>
The patch is pretty widely spread. I don't mind how it gets routed
but what's the plan?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Tejun Heo @ 2013-09-20 12:18 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, b43-dev, devel, devicetree, dri-devel, e1000-devel,
linux-arm-kernel, linux-crypto, linux-doc, linux-fbdev, linux-ide,
linux-media, linux-mmc, linux-nvme, linux-omap, linuxppc-dev,
linux-samsung-soc, linux-scsi, linux-tegra, linux-usb,
linux-wireless, netdev, Solarflare linux maintainers,
uclinux-dist-devel, Inki Dae, Joonyoung Shim, Seung-Woo Kim, Kyun
In-Reply-To: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
Hmm... maybe hte pata_ixp4xx_cf.c part should be moved to the one
which updates pata_octeon_cf.c?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing
From: Felipe Balbi @ 2013-09-20 13:11 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Felipe Balbi, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <E1VMnQk-0007sX-Ty@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> Use platform_device_register_full() for those drivers which can, to
> avoid messing directly with DMA masks. This can only be done when
> the driver does not need to access the allocated musb platform device
> from within its callbacks, which may be called during the musb
> device probing.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
you want me to carry this one through my tree or you prefer getting my
Acked-by ? Either way works for me:
Acked-by: Felipe Balbi <balbi@ti.com>
there's also the third option of me setting up a branch with only this
patch and we both merge it, that'd also work.
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing
From: Russell King - ARM Linux @ 2013-09-20 13:49 UTC (permalink / raw)
To: Felipe Balbi
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, linux-crypto,
Greg Kroah-Hartman, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130920131125.GO26101@radagast>
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does not need to access the allocated musb platform device
> > from within its callbacks, which may be called during the musb
> > device probing.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> you want me to carry this one through my tree or you prefer getting my
> Acked-by ? Either way works for me:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
>
> there's also the third option of me setting up a branch with only this
> patch and we both merge it, that'd also work.
I think this patch is sufficiently stand-alone that it should be fine
if you want to take it through your tree. That may be better in the
long run to avoid conflicts with this patch and any future work in
this area during this cycle.
Thanks.
^ permalink raw reply
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-20 14:00 UTC (permalink / raw)
To: Tejun Heo
Cc: alsa-devel, linux-doc, David Airlie, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, Joonyoung Shim,
linux-scsi, e1000-devel, Seung-Woo Kim, b43-dev, linux-media,
devicetree, Inki Dae, Kukjin Kim, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, Kyungmin Park
In-Reply-To: <20130920121652.GA7630@mtj.dyndns.org>
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> The patch is pretty widely spread. I don't mind how it gets routed
> but what's the plan?
The plan is... I'm going to try and avoid going through the hell of
re-posting this patch series to all the recipients another time...
(It's taken some 17 hours and lots of hand holding to get this patch
set out without exim jumping off a cliff into deep OOM - soo deep that
even the OOM killer doesn't run and the CPU is 100% idle because
every single process stuck in an uninterruptible sleep waiting for
every other process to free some memory - ouch!)
I know that dealing with this patch set will be a problem due to how
widespread this is, but much of the driver level changes come down to
depending on a couple of patches. One solution would be if I published
a branch with just the dependencies in, which subsystem maintainers
could pull, and then apply the appropriate patches on top.
Another would be if subsystem maintainers are happy that I carry them,
I can add the acks, and then later on towards the end of the cycle,
provide a branch subsystem maintainers could pull.
Or... if you can think of something easier...
^ permalink raw reply
* Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
From: Russell King - ARM Linux @ 2013-09-20 14:12 UTC (permalink / raw)
To: Ben Hutchings
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Solarflare linux maintainers, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Vinod Koul,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Rob Landley,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1379640097.2500.4.camel-/LGg1Z1CJKQ+9kgCwbf1HqK4ta4zdZpAajtMo4Cw6ucAvxtiuMwx3w@public.gmane.org>
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask will always be able to set the same or a
> > +smaller mask as the streaming mask. However for the rare case that a
> [...]
>
> The new wording doesn't make sense; a mask doesn't set itself. I would
> suggest:
>
> "The coherent mask can always be set to the same or a smaller mask than
> the streaming mask."
Yes, the original sentence is not particularly good, but I think even
your modified version can be interpreted as "a mask setting itself"
for all the same reasons that the original can be (which mask does "same"
refer to?)
Even so, I prefer your version. Thanks. :)
^ permalink raw reply
* [PATCH v4 1/2] video: ARM CLCD: Add DT support
From: Pawel Moll @ 2013-09-20 14:19 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Changes since v3:
- changed wording and order of interrupt-names and interrupts
properties documentation
- changed wording of arm,pl11x,framebuffer-base property
documentation
- cleaned up binding documentation indentation
Changes since v2:
- replaced video-ram phandle with arm,pl11x,framebuffer-base
- replaced panel-* properties with arm,pl11x,panel-data-pads
- replaced max-framebuffer-size with max-memory-bandwidth
- modified clcdfb_of_init_tft_panel() to use the pads
data and take differences between PL110 and PL110 into
account
Changes since v1:
- minor code cleanups as suggested by Sylwester Nawrocki
.../devicetree/bindings/video/arm,pl11x.txt | 145 +++++++++++
.../devicetree/bindings/video/arm,pl11x.txt | 146 +++++++++++
drivers/video/Kconfig | 1 +
drivers/video/amba-clcd.c | 268 +++++++++++++++++++++
3 files changed, 415 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 0000000..247e120
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,146 @@
+* ARM PrimeCell Color LCD Controller PL110/PL111
+
+See also Documentation/devicetree/bindings/arm/primecell.txt
+
+Required properties:
+
+- compatible: must be one of:
+ "arm,pl110", "arm,primecell"
+ "arm,pl111", "arm,primecell"
+
+- reg: base address and size of the control registers block
+
+- interrupt-names: either the single entry "combined" representing a
+ combined interrupt output (CLCDINTR), or the four entries
+ "mbe", "vcomp", "lnbu", "fuf" representing the individual
+ CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
+
+- interrupts: contains an interrupt specifier for each entry in
+ interrupt-names
+
+- clocks names: should contain "clcdclk" and "apb_pclk"
+
+- clocks: contains phandle and clock specifier pairs for the entries
+ in the clock-names property. See
+ Documentation/devicetree/binding/clock/clock-bindings.txt
+
+- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
+ a function of one of the CLD pads, starting from 0 up to 23;
+ each pad can be described by one of the following values:
+ - 0: reserved (not connected)
+ - 0x100-0x107: color upper STN panel data 0 to 7
+ - 0x110-0x117: color lower STN panel data 0 to 7
+ - 0x200-0x207: mono upper STN panel data 0 to 7
+ - 0x210-0x217: mono lower STN panel data 0 to 7
+ - 0x300-0x307: red component bit 0 to 7 of TFT panel data
+ - 0x310-0x317: green component bit 0 to 7 of TFT panel data
+ - 0x320-0x327: blue component bit 0 to 7 of TFT panel data
+ - 0x330: intensity bit of TFT panel data
+ Example sets of values for standard panel interfaces:
+ - PL110 single colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual colour STN panel:
+ <0x107 0x106 0x105 0x104 0x103 0x102 0x101 0x100>,
+ <0x117 0x116 0x115 0x114 0x113 0x112 0x111 0x110>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 single mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 4-bit STN panel:
+ <0x203 0x202 0x201 0x200>, <0 0 0 0>,
+ <0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 single mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL110 dual mono 8-bit STN panel:
+ <0x207 0x206 0x205 0x204 0x203 0x202 0x201 0x200>,
+ <0x217 0x216 0x215 0x214 0x213 0x212 0x211 0x210>,
+ <0 0 0 0 0 0 0 0>;
+ - PL110 TFT (1:)5:5:5 panel:
+ <0x330 0x300 0x301 0x302 0x303 0x304>,
+ <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0x330 0x320 0x321 0x322 0x323 0x324>,
+ <0 0 0 0 0 0>
+ - PL110 and PL111 TFT RGB 888 panel:
+ <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ - PL111 single colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual colour STN panel:
+ <0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107>,
+ <0x110 0x111 0x112 0x113 0x114 0x115 0x116 0x117>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 single mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 4-bit STN panel:
+ <0x200 0x201 0x202 0x203>, <0 0 0 0>,
+ <0x210 0x211 0x212 0x213>,
+ <0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 single mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>;
+ - PL111 dual mono 8-bit STN panel:
+ <0x200 0x201 0x202 0x203 0x204 0x205 0x206 0x207>,
+ <0x210 0x211 0x212 0x213 0x214 0x215 0x216 0x217>,
+ <0 0 0 0 0 0 0 0>;
+ - PL111 TFT 4:4:4 panel:
+ <0 0 0 0>, <0x300 0x301 0x302 0x303>,
+ <0 0 0 0>, <0x310 0x311 0x312 0x313>,
+ <0 0 0 0>, <0x320 0x321 0x322 0x323>;
+ - PL111 TFT 5:6:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x310 0x311 0x312 0x313 0x314 0x315>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+ - PL111 TFT (1):5:5:5 panel:
+ <0 0 0>, <0x300 0x301 0x302 0x303 0x304>,
+ <0 0>, <0x330 0x310 0x311 0x312 0x313 0x314>,
+ <0 0 0>, <0x320 0x321 0x322 0x323 0x324>;
+
+Optional properties:
+
+- arm,pl11x,framebuffer-base: a pair of two values, address and size,
+ defining the framebuffer that must be used; if not present, the
+ framebuffer may be located anywhere in the memory
+
+- max-memory-bandwidth: maximum bandwidth in bytes per second that the
+ cell's memory interface can handle
+
+- display-timings: standard display timings sub-node, defining possible
+ video modes of a connected panel; for details see
+ Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+ clcd@1f0000 {
+ compatible = "arm,pl111", "arm,primecell";
+ reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
+ interrupts = <14>;
+ clock-names = "clcdclk", "apb_pclk";
+ clocks = <&v2m_oscclk1>, <&smbclk>;
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 84b685f..b7d8c23 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -316,6 +316,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
help
This framebuffer device driver is for the ARM PrimeCell PL110
Colour LCD controller. ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..03420d1 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
#include <linux/amba/clcd.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
+#include <linux/dma-mapping.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <asm/sizes.h>
@@ -542,6 +547,266 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
}
+#ifdef CONFIG_OF
+
+#define CLCD_PADS_NUM 24
+
+#define CLCD_PAD_BIT(pad) ((pad) & 0xf)
+#define CLCD_PAD_TYPE(pad) (((pad) >> 8) & 0xf)
+
+#define CLCD_PAD_IS_TFT(pad) (CLCD_PAD_TYPE(pad) == 0x3)
+
+#define CLCD_PAD_RGB(pad) (((pad) >> 4) & 0xf)
+#define CLCD_PAD_R 0x0
+#define CLCD_PAD_G 0x1
+#define CLCD_PAD_B 0x2
+
+static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 *pads)
+{
+ static struct {
+ unsigned int part;
+ int r0, g0, b0;
+ u32 caps;
+ } panels[] = {
+ { 0x110, 1, 7, 13, CLCD_CAP_5551 },
+ { 0x110, 0, 8, 16, CLCD_CAP_888 },
+ { 0x111, 4, 14, 20, CLCD_CAP_444 },
+ { 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
+ { 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 },
+ { 0x111, 0, 8, 16, CLCD_CAP_444 | CLCD_CAP_5551 |
+ CLCD_CAP_565 | CLCD_CAP_888 },
+ };
+ int r = 0, g = 0, b = 0;
+ int r0 = -1, g0 = -1, b0 = -1;
+ int i;
+
+ /* Bypass pixel clock divider, data output on the falling edge */
+ fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+ /* TFT display, vert. comp. interrupt at the start of the back porch */
+ fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
+
+ fb->panel->caps = 0;
+
+ /*
+ * Find indices of the first component bits and make sure they
+ * are in correct order
+ */
+ for (i = 0; i < CLCD_PADS_NUM; i++) {
+ int bit;
+
+ if (!pads[i])
+ continue;
+ switch (CLCD_PAD_RGB(pads[i])) {
+ case CLCD_PAD_R:
+ r0 = r ? r0 : i;
+ bit = r++;
+ break;
+ case CLCD_PAD_G:
+ g0 = g ? g0 : i;
+ bit = g++;
+ break;
+ case CLCD_PAD_B:
+ b0 = b ? b0 : i;
+ bit = b++;
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (bit != CLCD_PAD_BIT(pads[i]) || !CLCD_PAD_IS_TFT(pads[i]))
+ return -EINVAL;
+ }
+
+ /* Match the setup with known variants */
+ for (i = 0; i < ARRAY_SIZE(panels) && !fb->panel->caps; i++) {
+ if (amba_part(fb->dev) != panels[i].part)
+ continue;
+ if (g0 != panels[i].g0)
+ continue;
+ if (r0 == panels[i].r0 && b0 == panels[i].b0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_RGB;
+ if (r0 == panels[i].b0 && b0 == panels[i].r0)
+ fb->panel->caps = panels[i].caps & CLCD_CAP_BGR;
+ }
+
+ return fb->panel->caps ? 0 : -EINVAL;
+}
+
+static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
+{
+ return snprintf(buf, size, "%ux%u@%u", mode->xres, mode->yres,
+ mode->refresh);
+}
+
+static int clcdfb_of_init_display(struct clcd_fb *fb)
+{
+ struct device_node *node = fb->dev->dev.of_node;
+ int err, len;
+ char *mode_name;
+ u32 max_bandwidth;
+ u32 pads[CLCD_PADS_NUM];
+ int i;
+
+ fb->panel = devm_kzalloc(&fb->dev->dev, sizeof(*fb->panel), GFP_KERNEL);
+ if (!fb->panel)
+ return -ENOMEM;
+
+ err = of_get_fb_videomode(node, &fb->panel->mode, OF_USE_NATIVE_MODE);
+ if (err)
+ return err;
+
+ len = clcdfb_snprintf_mode(NULL, 0, &fb->panel->mode);
+ mode_name = devm_kzalloc(&fb->dev->dev, len + 1, GFP_KERNEL);
+ clcdfb_snprintf_mode(mode_name, len + 1, &fb->panel->mode);
+ fb->panel->mode.name = mode_name;
+
+ err = of_property_read_u32(node, "max-memory-bandwidth",
+ &max_bandwidth);
+ if (!err)
+ fb->panel->bpp = 8 * max_bandwidth / (fb->panel->mode.xres *
+ fb->panel->mode.yres * fb->panel->mode.refresh);
+ else
+ fb->panel->bpp = 32;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ fb->panel->cntl |= CNTL_BEBO;
+#endif
+ fb->panel->width = -1;
+ fb->panel->height = -1;
+
+ err = of_property_read_u32_array(node, "arm,pl11x,panel-data-pads",
+ pads, ARRAY_SIZE(pads));
+ if (err)
+ return err;
+
+ /* Find first connected pad - its type determines the panel */
+ for (i = 0; i < CLCD_PADS_NUM; i++)
+ if (pads[i] && CLCD_PAD_IS_TFT(pads[i]))
+ return clcdfb_of_init_tft_panel(fb, pads);
+
+ return -EINVAL;
+}
+
+static int clcdfb_of_vram_setup(struct clcd_fb *fb)
+{
+ int err;
+ u32 values[2];
+ phys_addr_t phys_base;
+ size_t size;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ err = of_property_read_u32_array(fb->dev->dev.of_node,
+ "arm,pl11x,framebuffer-base",
+ values, ARRAY_SIZE(values));
+ if (err)
+ return err;
+
+ phys_base = values[0];
+ size = values[1];
+
+ fb->fb.screen_base = ioremap(phys_base, size);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = phys_base;
+ fb->fb.fix.smem_len = size;
+
+ return 0;
+}
+
+static int clcdfb_of_vram_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ unsigned long off, user_size, kernel_size;
+
+ off = vma->vm_pgoff << PAGE_SHIFT;
+ user_size = vma->vm_end - vma->vm_start;
+ kernel_size = fb->fb.fix.smem_len;
+
+ if (off >= kernel_size || user_size > (kernel_size - off))
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ __phys_to_pfn(fb->fb.fix.smem_start) + vma->vm_pgoff,
+ user_size,
+ pgprot_writecombine(vma->vm_page_prot));
+}
+
+static void clcdfb_of_vram_remove(struct clcd_fb *fb)
+{
+ iounmap(fb->fb.screen_base);
+}
+
+static int clcdfb_of_dma_setup(struct clcd_fb *fb)
+{
+ unsigned long framesize;
+ dma_addr_t dma;
+ int err;
+
+ err = clcdfb_of_init_display(fb);
+ if (err)
+ return err;
+
+ framesize = fb->panel->mode.xres * fb->panel->mode.yres *
+ fb->panel->bpp / 8;
+ fb->fb.screen_base = dma_alloc_writecombine(&fb->dev->dev, framesize,
+ &dma, GFP_KERNEL);
+ if (!fb->fb.screen_base)
+ return -ENOMEM;
+
+ fb->fb.fix.smem_start = dma;
+ fb->fb.fix.smem_len = framesize;
+
+ return 0;
+}
+
+static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+{
+ return dma_mmap_writecombine(&fb->dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+}
+
+static void clcdfb_of_dma_remove(struct clcd_fb *fb)
+{
+ dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+}
+
+static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
+{
+ struct clcd_board *board = devm_kzalloc(&dev->dev, sizeof(*board),
+ GFP_KERNEL);
+ struct device_node *node = dev->dev.of_node;
+
+ if (!board)
+ return NULL;
+
+ board->name = of_node_full_name(node);
+ board->caps = CLCD_CAP_ALL;
+ board->check = clcdfb_check;
+ board->decode = clcdfb_decode;
+ if (of_find_property(node, "arm,pl11x,framebuffer-base", NULL)) {
+ board->setup = clcdfb_of_vram_setup;
+ board->mmap = clcdfb_of_vram_mmap;
+ board->remove = clcdfb_of_vram_remove;
+ } else {
+ board->setup = clcdfb_of_dma_setup;
+ board->mmap = clcdfb_of_dma_mmap;
+ board->remove = clcdfb_of_dma_remove;
+ }
+
+ return board;
+}
+#else
+static struct clcd_board *clcdfb_of_get_board(struct amba_dev *dev)
+{
+ return NULL;
+}
+#endif
+
static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
{
struct clcd_board *board = dev->dev.platform_data;
@@ -549,6 +814,9 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
int ret;
if (!board)
+ board = clcdfb_of_get_board(dev);
+
+ if (!board)
return -EINVAL;
ret = amba_request_regions(dev, NULL);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v4 2/2] ARM: vexpress: Add CLCD Device Tree properties
From: Pawel Moll @ 2013-09-20 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379686800-27269-1-git-send-email-pawel.moll@arm.com>
... for V2M-P1 motherboard CLCD (limited to 640x480 16bpp and using
dedicated video RAM bank) and for V2P-CA9 (up to 1024x768 16bpp).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 23 ++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 23 ++++++++++++++++++++++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 20 ++++++++++++++++++++
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..19bef38 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -230,9 +230,30 @@
clcd@1f0000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f0000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x18000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -282,7 +303,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..14dd04a 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -229,9 +229,30 @@
clcd@1f000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x1f000 0x1000>;
+ interrupt-names = "combined";
interrupts = <14>;
clocks = <&v2m_oscclk1>, <&smbclk>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ arm,pl11x,framebuffer-base = <0x4c000000 0x00800000>;
+ max-memory-bandwidth = <36864000>; /* Bps, 640x480@60 16bpp */
+ display-timings {
+ native-mode = <&v2m_clcd_timing0>;
+ v2m_clcd_timing0: vga {
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ hback-porch = <40>;
+ hfront-porch = <24>;
+ hsync-len = <96>;
+ vactive = <480>;
+ vback-porch = <32>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
@@ -281,7 +302,7 @@
/* CLCD clock */
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 1>;
- freq-range = <23750000 63500000>;
+ freq-range = <23750000 65000000>;
#clock-cells = <0>;
clock-output-names = "v2m:oscclk1";
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
index 62d9b22..f80b48a 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
@@ -70,9 +70,29 @@
clcd@10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
+ interrupt-names = "combined";
interrupts = <0 44 4>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
+
+ arm,pl11x,panel-data-pads = <0x300 0x301 0x302 0x303 0x304 0x305 0x306 0x307>,
+ <0x310 0x311 0x312 0x313 0x314 0x315 0x316 0x317>,
+ <0x320 0x321 0x322 0x323 0x324 0x325 0x326 0x327>;
+ max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
+ display-timings {
+ native-mode = <&clcd_timing0>;
+ clcd_timing0: xga {
+ clock-frequency = <63500127>;
+ hactive = <1024>;
+ hback-porch = <152>;
+ hfront-porch = <48>;
+ hsync-len = <104>;
+ vactive = <768>;
+ vback-porch = <23>;
+ vfront-porch = <3>;
+ vsync-len = <4>;
+ };
+ };
};
memory-controller@100e0000 {
--
1.8.1.2
^ 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