* [PATCH 4/4] video: vt8500: Update descriptions in video/Kconfig
From: Tony Prisk @ 2013-01-02 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357158184-18213-1-git-send-email-linux@prisktech.co.nz>
This patch updates the descriptions for the VIA VT8500 and
Wondermedia WM8xxx-series framebuffer drivers to correctly reflect
which hardware they support.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/Kconfig | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6678daf..3bbb3c1 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1767,7 +1767,7 @@ config FB_AU1200
option au1200fb:panel=<name>.
config FB_VT8500
- bool "VT8500 LCD Driver"
+ bool "VIA VT8500 Framebuffer Driver"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
@@ -1777,14 +1777,15 @@ config FB_VT8500
controller.
config FB_WM8505
- bool "WM8505 frame buffer support"
+ bool "Wondermedia WM8xxx-series framebuffer support"
depends on (FB = y) && ARM && ARCH_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505/WM8650
- integrated LCD controller.
+ This is the framebuffer driver for WonderMedia WM8xxx-series
+ integrated LCD controller. This driver covers the WM8505, WM8650
+ and WM8850 SoCs.
config FB_WMT_GE_ROPS
bool "VT8500/WM8xxx accelerated raster ops support"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
From: Tony Prisk @ 2013-01-02 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357158184-18213-1-git-send-email-linux@prisktech.co.nz>
With the conversion to devicetree only for arch-vt8500, this
header is no longer required. This patch removes the #include
from the two framebuffer drivers that used it, and the header file.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/vt8500lcdfb.c | 2 --
drivers/video/wm8505fb.c | 2 --
include/linux/platform_data/video-vt8500lcdfb.h | 31 -----------------------
3 files changed, 35 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index e8853ac..b1fbe20 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -30,8 +30,6 @@
#include <linux/platform_device.h>
#include <linux/wait.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "vt8500lcdfb.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index a990708..f0185cd 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -32,8 +32,6 @@
#include <linux/of_fdt.h>
#include <linux/memblock.h>
-#include <linux/platform_data/video-vt8500lcdfb.h>
-
#include "wm8505fb_regs.h"
#ifdef CONFIG_FB_WMT_GE_ROPS
diff --git a/include/linux/platform_data/video-vt8500lcdfb.h b/include/linux/platform_data/video-vt8500lcdfb.h
deleted file mode 100644
index 7f399c3..0000000
--- a/include/linux/platform_data/video-vt8500lcdfb.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * VT8500/WM8505 Frame Buffer platform data definitions
- *
- * Copyright (C) 2010 Ed Spiridonov <edo.rus@gmail.com>
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef _VT8500FB_H
-#define _VT8500FB_H
-
-#include <linux/fb.h>
-
-struct vt8500fb_platform_data {
- struct fb_videomode mode;
- u32 xres_virtual;
- u32 yres_virtual;
- u32 bpp;
- unsigned long video_mem_phys;
- void *video_mem_virt;
- unsigned long video_mem_len;
-};
-
-#endif /* _VT8500FB_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] video: vt8500: Make wmt_ge_rops optional
From: Tony Prisk @ 2013-01-02 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357158184-18213-1-git-send-email-linux@prisktech.co.nz>
At the moment, accelerated raster ops are always enabled on VT8500
and WM8xxx series SoCs. This patch makes them optional.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/Kconfig | 23 +++++++++++++----------
drivers/video/vt8500lcdfb.c | 15 +++++++++++++++
drivers/video/wm8505fb.c | 15 +++++++++++++++
3 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e7068c5..6678daf 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -190,14 +190,6 @@ config FB_SYS_FOPS
depends on FB
default n
-config FB_WMT_GE_ROPS
- tristate
- depends on FB
- default n
- ---help---
- Include functions for accelerated rectangle filling and area
- copying using WonderMedia Graphics Engine operations.
-
config FB_DEFERRED_IO
bool
depends on FB
@@ -1777,7 +1769,8 @@ config FB_AU1200
config FB_VT8500
bool "VT8500 LCD Driver"
depends on (FB = y) && ARM && ARCH_VT8500
- select FB_WMT_GE_ROPS
+ select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+ select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
This is the framebuffer driver for VIA VT8500 integrated LCD
@@ -1786,12 +1779,22 @@ config FB_VT8500
config FB_WM8505
bool "WM8505 frame buffer support"
depends on (FB = y) && ARM && ARCH_VT8500
- select FB_WMT_GE_ROPS
+ select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
+ select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
help
This is the framebuffer driver for WonderMedia WM8505/WM8650
integrated LCD controller.
+config FB_WMT_GE_ROPS
+ bool "VT8500/WM8xxx accelerated raster ops support"
+ depends on (FB = y) && (FB_VT8500 || FB_WM8505)
+ default n
+ help
+ This adds support for accelerated raster operations on the
+ VIA VT8500 and Wondermedia 8xxx series SoCs.
+
+
source "drivers/video/geode/Kconfig"
config FB_HIT
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 9af8da7..e8853ac 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -33,7 +33,10 @@
#include <linux/platform_data/video-vt8500lcdfb.h>
#include "vt8500lcdfb.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
#include "wmt_ge_rops.h"
+#endif
#ifdef CONFIG_OF
#include <linux/of.h>
@@ -249,12 +252,24 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
return 0;
}
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+ return 0;
+}
+#endif
+
static struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
.fb_set_par = vt8500lcd_set_par,
.fb_setcolreg = vt8500lcd_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
.fb_fillrect = wmt_ge_fillrect,
.fb_copyarea = wmt_ge_copyarea,
+#else
+ .fb_fillrect = sys_fillrect,
+ .fb_copyarea = sys_copyarea,
+#endif
.fb_imageblit = sys_imageblit,
.fb_sync = wmt_ge_sync,
.fb_ioctl = vt8500lcd_ioctl,
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 77539c1..a990708 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -35,7 +35,10 @@
#include <linux/platform_data/video-vt8500lcdfb.h>
#include "wm8505fb_regs.h"
+
+#ifdef CONFIG_FB_WMT_GE_ROPS
#include "wmt_ge_rops.h"
+#endif
#define DRIVER_NAME "wm8505-fb"
@@ -248,12 +251,24 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
return 0;
}
+#ifndef CONFIG_FB_WMT_GE_ROPS
+static int wmt_ge_sync(struct fb_info *p)
+{
+ return 0;
+}
+#endif
+
static struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
+#ifdef CONFIG_FB_WMT_GE_ROPS
.fb_fillrect = wmt_ge_fillrect,
.fb_copyarea = wmt_ge_copyarea,
+#else
+ .fb_fillrect = sys_fillrect,
+ .fb_copyarea = sys_copyarea,
+#endif
.fb_imageblit = sys_imageblit,
.fb_sync = wmt_ge_sync,
.fb_pan_display = wm8505fb_pan_display,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] drivers/video/wm8505fb.c: use devm_ functions
From: Tony Prisk @ 2013-01-02 20:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other cleanups. First, the original code used
devm_kzalloc, but kfree. This would lead to a double free. The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):
// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>
The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.
The call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent. This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.
A semicolon is removed at the end of the error-handling code for the call
to dma_alloc_coherent.
The block of code calling fb_alloc_cmap is moved below the block of code
calling wm8505fb_set_par, so that the error-handing code of the call to
wm8505fb_set_par can just return ret. This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function. This was suggested by Tony Prisk.
The initializations of fbi and ret at the beginning of the function are not
necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/wm8505fb.c | 78 +++++++++++-----------------------------------
1 file changed, 19 insertions(+), 59 deletions(-)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 77539c1..1c3ce2c 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -274,15 +274,11 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
unsigned long fb_mem_len;
void *fb_mem_virt;
- ret = -ENOMEM;
- fbi = NULL;
-
fbi = devm_kzalloc(&pdev->dev, sizeof(struct wm8505fb_info) +
sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
- ret = -ENOMEM;
- goto failed;
+ return -ENOMEM;
}
strcpy(fbi->fb.fix.id, DRIVER_NAME);
@@ -308,31 +304,15 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
fbi->fb.pseudo_palette = addr;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res = NULL) {
- dev_err(&pdev->dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed_fbi;
- }
-
- res = request_mem_region(res->start, resource_size(res), DRIVER_NAME);
- if (res = NULL) {
- dev_err(&pdev->dev, "failed to request I/O memory\n");
- ret = -EBUSY;
- goto failed_fbi;
- }
- fbi->regbase = ioremap(res->start, resource_size(res));
- if (fbi->regbase = NULL) {
- dev_err(&pdev->dev, "failed to map I/O memory\n");
- ret = -EBUSY;
- goto failed_free_res;
- }
+ fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
+ if (fbi->regbase = NULL)
+ return -EBUSY;
np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
+ return -EINVAL;
}
/*
@@ -351,7 +331,7 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", &bpp);
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ return ret;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -365,12 +345,12 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
- fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+ fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
return -ENOMEM;
- };
+ }
fbi->fb.var.xres_virtual = of_mode.xres;
fbi->fb.var.yres_virtual = of_mode.yres * 2;
@@ -381,28 +361,29 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
fbi->fb.screen_base = fb_mem_virt;
fbi->fb.screen_size = fb_mem_len;
- if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
- dev_err(&pdev->dev, "Failed to allocate color map\n");
- ret = -ENOMEM;
- goto failed_free_io;
- }
-
- wm8505fb_init_hw(&fbi->fb);
-
fbi->contrast = 0x80;
ret = wm8505fb_set_par(&fbi->fb);
if (ret) {
dev_err(&pdev->dev, "Failed to set parameters\n");
- goto failed_free_cmap;
+ return ret;
}
+ if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
+ dev_err(&pdev->dev, "Failed to allocate color map\n");
+ return -ENOMEM;
+ }
+
+ wm8505fb_init_hw(&fbi->fb);
+
platform_set_drvdata(pdev, fbi);
ret = register_framebuffer(&fbi->fb);
if (ret < 0) {
dev_err(&pdev->dev,
"Failed to register framebuffer device: %d\n", ret);
- goto failed_free_cmap;
+ if (fbi->fb.cmap.len)
+ fb_dealloc_cmap(&fbi->fb.cmap);
+ return ret;
}
ret = device_create_file(&pdev->dev, &dev_attr_contrast);
@@ -416,25 +397,11 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
fbi->fb.fix.smem_start + fbi->fb.fix.smem_len - 1);
return 0;
-
-failed_free_cmap:
- if (fbi->fb.cmap.len)
- fb_dealloc_cmap(&fbi->fb.cmap);
-failed_free_io:
- iounmap(fbi->regbase);
-failed_free_res:
- release_mem_region(res->start, resource_size(res));
-failed_fbi:
- platform_set_drvdata(pdev, NULL);
- kfree(fbi);
-failed:
- return ret;
}
static int __devexit wm8505fb_remove(struct platform_device *pdev)
{
struct wm8505fb_info *fbi = platform_get_drvdata(pdev);
- struct resource *res;
device_remove_file(&pdev->dev, &dev_attr_contrast);
@@ -445,13 +412,6 @@ static int __devexit wm8505fb_remove(struct platform_device *pdev)
if (fbi->fb.cmap.len)
fb_dealloc_cmap(&fbi->fb.cmap);
- iounmap(fbi->regbase);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
-
- kfree(fbi);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: backlight_register_device can oops if name is null ?
From: devendra.aaru @ 2013-01-02 16:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAHdPZaMKfMA=Z6n-X+3NMR-CScfwQmKYuyoJHBeK2bYFn8EEdg@mail.gmail.com>
Hello,
Thanks :)
On Tue, Jan 1, 2013 at 7:44 PM, Jingoo Han <jg1.han@samsung.com> wrote:
> On Tuesday, January 01, 2013 6:05 AM, Devendra Naga wrote
>> Hello,
>>
>> while reading through the backlight_register_device function, there
>
> backlight_register_device -> backlight_device_register
>
i am sorry i would have really written correctly,
>> seems to be a problem if the new object name is null, the pr_debug
>> print goes and dereferences a null pointer causing an oops,
>>
>> the print should be removed or the check must be placed to ensure that
>> name is not null,
>
> Hi,
>
> If name is null in backlight_device_register(),
> pr_debug() will work properly and won't cause an oops.
>
so if i understand the code pr_debug code, i see a printk macro assignment,
is it something like printk or a wrapper macro around printk are
making sure that the strings are non null ?
i am sorry to ask this as i dont have proper tags in vim ubuntu, its
not allowing me to a tag list when i do in fedora :(,
> However, dev_set_name() will cause oops, instead of pr_debug().
> In this case, NULL check would be better.
>
the documentation of the backlight_device_register says that "name
must be same as the name of the respected frame buffer device", but do
we really add a check for the null to do dev_set_name? or fail the
registering ?
>
> Best regards,
> Jingoo Han
>
>>
>> any ideas?
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/1] video: exynos_mipi_dsi: Fix an error check condition
From: Sachin Kamat @ 2013-01-02 11:12 UTC (permalink / raw)
To: linux-fbdev
Checking an unsigned variable for negative value returns false.
Hence use the macro to fix it.
Fixes the following smatch warning:
drivers/video/exynos/exynos_mipi_dsi.c:417 exynos_mipi_dsi_probe()
warn: unsigned 'dsim->irq' is never less than zero.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/exynos/exynos_mipi_dsi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 4a17cdc..f623dfc 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -414,7 +414,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
}
dsim->irq = platform_get_irq(pdev, 0);
- if (dsim->irq < 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;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] backlight: lm3649_backlight: remove ret = -EIO at error paths of probe
From: gshark @ 2013-01-02 8:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1356977911-13521-1-git-send-email-devendra.aaru@gmail.com>
2013년 01월 02일 08:47, Jingoo Han 쓴 글:
> On Tuesday, January 01, 2013 3:19 AM, Devendra Naga wrote
>> the APIs are returning correctly the err codes, no need of assigning -EIO to the
>> ret again
>>
>> Cc: Daniel Jeong <daniel.jeong@ti.com>
>> Cc: G.Shark Jeong <gshark.jeong@gmail.com>
>> Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
> It looks good.
> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
>
> Best regards,
> Jingoo Han
>
>> ---
>> drivers/video/backlight/lm3639_bl.c | 5 +----
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/backlight/lm3639_bl.c b/drivers/video/backlight/lm3639_bl.c
>> index 7ab2d2a..053964d 100644
>> --- a/drivers/video/backlight/lm3639_bl.c
>> +++ b/drivers/video/backlight/lm3639_bl.c
>> @@ -350,14 +350,13 @@ static int lm3639_probe(struct i2c_client *client,
>> &lm3639_bled_ops, &props);
>> if (IS_ERR(pchip->bled)) {
>> dev_err(&client->dev, "fail : backlight register\n");
>> - ret = -EIO;
>> + ret = PTR_ERR(pchip->bled);
>> goto err_out;
>> }
>>
>> ret = device_create_file(&(pchip->bled->dev), &dev_attr_bled_mode);
>> if (ret < 0) {
>> dev_err(&client->dev, "failed : add sysfs entries\n");
>> - ret = -EIO;
>> goto err_bled_mode;
>> }
>>
>> @@ -369,7 +368,6 @@ static int lm3639_probe(struct i2c_client *client,
>> &client->dev, &pchip->cdev_flash);
>> if (ret < 0) {
>> dev_err(&client->dev, "fail : flash register\n");
>> - ret = -EIO;
>> goto err_flash;
>> }
>>
>> @@ -381,7 +379,6 @@ static int lm3639_probe(struct i2c_client *client,
>> &client->dev, &pchip->cdev_torch);
>> if (ret < 0) {
>> dev_err(&client->dev, "fail : torch register\n");
>> - ret = -EIO;
>> goto err_torch;
>> }
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you. This patch looks good for us.
lm3630 has same thing and I will fix it.
Acked-by: Daniel Jeong <daniel.jeong@ti.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: backlight_register_device can oops if name is null ?
From: Jingoo Han @ 2013-01-02 0:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAHdPZaMKfMA=Z6n-X+3NMR-CScfwQmKYuyoJHBeK2bYFn8EEdg@mail.gmail.com>
On Tuesday, January 01, 2013 6:05 AM, Devendra Naga wrote
> Hello,
>
> while reading through the backlight_register_device function, there
backlight_register_device -> backlight_device_register
> seems to be a problem if the new object name is null, the pr_debug
> print goes and dereferences a null pointer causing an oops,
>
> the print should be removed or the check must be placed to ensure that
> name is not null,
Hi,
If name is null in backlight_device_register(),
pr_debug() will work properly and won't cause an oops.
However, dev_set_name() will cause oops, instead of pr_debug().
In this case, NULL check would be better.
Best regards,
Jingoo Han
>
> any ideas?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] backlight: lm3649_backlight: remove ret = -EIO at error paths of probe
From: Jingoo Han @ 2013-01-01 23:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1356977911-13521-1-git-send-email-devendra.aaru@gmail.com>
T24gVHVlc2RheSwgSmFudWFyeSAwMSwgMjAxMyAzOjE5IEFNLCBEZXZlbmRyYSBOYWdhIHdyb3Rl
DQo+IHRoZSBBUElzIGFyZSByZXR1cm5pbmcgY29ycmVjdGx5IHRoZSBlcnIgY29kZXMsIG5vIG5l
ZWQgb2YgYXNzaWduaW5nIC1FSU8gdG8gdGhlDQo+IHJldCBhZ2Fpbg0KPiANCj4gQ2M6IERhbmll
bCBKZW9uZyA8ZGFuaWVsLmplb25nQHRpLmNvbT4NCj4gQ2M6IEcuU2hhcmsgSmVvbmcgPGdzaGFy
ay5qZW9uZ0BnbWFpbC5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IERldmVuZHJhIE5hZ2EgPGRldmVu
ZHJhLmFhcnVAZ21haWwuY29tPg0KDQpJdCBsb29rcyBnb29kLg0KQWNrZWQtYnk6IEppbmdvbyBI
YW4gPGpnMS5oYW5Ac2Ftc3VuZy5jb20+DQoNCg0KQmVzdCByZWdhcmRzLA0KSmluZ29vIEhhbg0K
DQo+IC0tLQ0KPiAgZHJpdmVycy92aWRlby9iYWNrbGlnaHQvbG0zNjM5X2JsLmMgfCAgICA1ICst
LS0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDQgZGVsZXRpb25zKC0pDQo+
IA0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9iYWNrbGlnaHQvbG0zNjM5X2JsLmMgYi9k
cml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9sbTM2MzlfYmwuYw0KPiBpbmRleCA3YWIyZDJhLi4wNTM5
NjRkIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9sbTM2MzlfYmwuYw0K
PiArKysgYi9kcml2ZXJzL3ZpZGVvL2JhY2tsaWdodC9sbTM2MzlfYmwuYw0KPiBAQCAtMzUwLDE0
ICszNTAsMTMgQEAgc3RhdGljIGludCBsbTM2MzlfcHJvYmUoc3RydWN0IGkyY19jbGllbnQgKmNs
aWVudCwNCj4gIAkJCQkgICAgICAmbG0zNjM5X2JsZWRfb3BzLCAmcHJvcHMpOw0KPiAgCWlmIChJ
U19FUlIocGNoaXAtPmJsZWQpKSB7DQo+ICAJCWRldl9lcnIoJmNsaWVudC0+ZGV2LCAiZmFpbCA6
IGJhY2tsaWdodCByZWdpc3RlclxuIik7DQo+IC0JCXJldCA9IC1FSU87DQo+ICsJCXJldCA9IFBU
Ul9FUlIocGNoaXAtPmJsZWQpOw0KPiAgCQlnb3RvIGVycl9vdXQ7DQo+ICAJfQ0KPiANCj4gIAly
ZXQgPSBkZXZpY2VfY3JlYXRlX2ZpbGUoJihwY2hpcC0+YmxlZC0+ZGV2KSwgJmRldl9hdHRyX2Js
ZWRfbW9kZSk7DQo+ICAJaWYgKHJldCA8IDApIHsNCj4gIAkJZGV2X2VycigmY2xpZW50LT5kZXYs
ICJmYWlsZWQgOiBhZGQgc3lzZnMgZW50cmllc1xuIik7DQo+IC0JCXJldCA9IC1FSU87DQo+ICAJ
CWdvdG8gZXJyX2JsZWRfbW9kZTsNCj4gIAl9DQo+IA0KPiBAQCAtMzY5LDcgKzM2OCw2IEBAIHN0
YXRpYyBpbnQgbG0zNjM5X3Byb2JlKHN0cnVjdCBpMmNfY2xpZW50ICpjbGllbnQsDQo+ICAJCQkJ
ICAgICZjbGllbnQtPmRldiwgJnBjaGlwLT5jZGV2X2ZsYXNoKTsNCj4gIAlpZiAocmV0IDwgMCkg
ew0KPiAgCQlkZXZfZXJyKCZjbGllbnQtPmRldiwgImZhaWwgOiBmbGFzaCByZWdpc3RlclxuIik7
DQo+IC0JCXJldCA9IC1FSU87DQo+ICAJCWdvdG8gZXJyX2ZsYXNoOw0KPiAgCX0NCj4gDQo+IEBA
IC0zODEsNyArMzc5LDYgQEAgc3RhdGljIGludCBsbTM2MzlfcHJvYmUoc3RydWN0IGkyY19jbGll
bnQgKmNsaWVudCwNCj4gIAkJCQkgICAgJmNsaWVudC0+ZGV2LCAmcGNoaXAtPmNkZXZfdG9yY2gp
Ow0KPiAgCWlmIChyZXQgPCAwKSB7DQo+ICAJCWRldl9lcnIoJmNsaWVudC0+ZGV2LCAiZmFpbCA6
IHRvcmNoIHJlZ2lzdGVyXG4iKTsNCj4gLQkJcmV0ID0gLUVJTzsNCj4gIAkJZ290byBlcnJfdG9y
Y2g7DQo+ICAJfQ0KPiANCj4gLS0NCj4gMS43LjEwLjQNCj4gDQo+IC0tDQo+IFRvIHVuc3Vic2Ny
aWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1mYmRl
diIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5v
cmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpv
cmRvbW8taW5mby5odG1sDQo
^ permalink raw reply
* backlight_register_device can oops if name is null ?
From: devendra.aaru @ 2012-12-31 21:04 UTC (permalink / raw)
To: linux-fbdev
Hello,
while reading through the backlight_register_device function, there
seems to be a problem if the new object name is null, the pr_debug
print goes and dereferences a null pointer causing an oops,
the print should be removed or the check must be placed to ensure that
name is not null,
any ideas?
^ permalink raw reply
* [PATCH] backlight: lm3649_backlight: remove ret = -EIO at error paths of probe
From: Devendra Naga @ 2012-12-31 18:18 UTC (permalink / raw)
To: linux-fbdev
the APIs are returning correctly the err codes, no need of assigning -EIO to the
ret again
Cc: Daniel Jeong <daniel.jeong@ti.com>
Cc: G.Shark Jeong <gshark.jeong@gmail.com>
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/video/backlight/lm3639_bl.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/backlight/lm3639_bl.c b/drivers/video/backlight/lm3639_bl.c
index 7ab2d2a..053964d 100644
--- a/drivers/video/backlight/lm3639_bl.c
+++ b/drivers/video/backlight/lm3639_bl.c
@@ -350,14 +350,13 @@ static int lm3639_probe(struct i2c_client *client,
&lm3639_bled_ops, &props);
if (IS_ERR(pchip->bled)) {
dev_err(&client->dev, "fail : backlight register\n");
- ret = -EIO;
+ ret = PTR_ERR(pchip->bled);
goto err_out;
}
ret = device_create_file(&(pchip->bled->dev), &dev_attr_bled_mode);
if (ret < 0) {
dev_err(&client->dev, "failed : add sysfs entries\n");
- ret = -EIO;
goto err_bled_mode;
}
@@ -369,7 +368,6 @@ static int lm3639_probe(struct i2c_client *client,
&client->dev, &pchip->cdev_flash);
if (ret < 0) {
dev_err(&client->dev, "fail : flash register\n");
- ret = -EIO;
goto err_flash;
}
@@ -381,7 +379,6 @@ static int lm3639_probe(struct i2c_client *client,
&client->dev, &pchip->cdev_torch);
if (ret < 0) {
dev_err(&client->dev, "fail : torch register\n");
- ret = -EIO;
goto err_torch;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC 0/6] Common Display Framework-T
From: Tomasz Figa @ 2012-12-31 11:36 UTC (permalink / raw)
To: dri-devel; +Cc: linux-fbdev, Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <13987428.Pqxt44thym@avalon>
Hi Laurent,
On Wednesday 26 of December 2012 13:14:46 Laurent Pinchart wrote:
> Hi Vikas,
>
> On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote:
> > On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote:
> > > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
> > >> Hi,
> > >>
> > >> I have been testing Common Display Framework on OMAP, and making
> > >> changes that I've discussed in the posts I've sent in reply to the
> > >> CDF series from Laurent. While my CDF code is rather hacky and not
> > >> at all ready, I wanted to post the code for comments and also as a
> > >> reference code to my posts.
> > >>
> > >> So here is CDF-T (Tomi-edition =).
> > >
> > > We've discussed your approach extensively face-to-face today so I
> > > won't
> > > review the patches in detail, but I will instead summarize our
> > > discussion to make sure we understood each other (and let other
> > > developers jump in).
> > >
> > > For the purpose of this discussion the term "display controller
> > > driver"
> > > (or just "display controller") refer to both the low-level driver
> > > layer
> > > that communicates directly with the display controller hardware, and
> > > to
> > > the higher- level driver layer that implements and exposes the
> > > userspace API (FBDEV, KMS and/or V4L). Those layers can be
> > > implemented in multiple kernel modules (such as in the OMAP DSS
> > > case, with omapdss for the low-level layer and omapdrm, omapfb and
> > > omapvout for the API-level layer) or a single kernel module.
> > >
> > > Control model
> > > -------------
> > >
> > > The figure at
> > > http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> > > model.png shows the CDF control model.
> > >
> > > The panel object depicted on the figure doesn't need to be a panel
> > > in the stricter sense but could be any chain of off-SoC (both
> > > on-board or off-board) display entities. It however helps thinking
> > > about it as a panel and doesn't hurt the model.
> > >
> > > The panel is controlled through abstract control requests. Those
> > > requests are used to retrieve panel information (such as the
> > > physical size, the supported video modes, EDID information, ...),
> > > set the panel
> > > configuration (such as the active video timings) or control the
> > > panel
> > > operation state (enabling/disabling the panel, controlling panel
> > > blanking and power management, ...). They are exposed by the panel
> > > using function pointers, and called by other kernel components in
> > > response to userspace requests (through the FBDEV, KMS or V4L2
> > > APIs) or in-kernel events (for instance hotplug notifications).
> > >
> > > In response to the control requests the panel driver will
> > > communicate with the panel through the panel control bus (I2C, SPI,
> > > DBI, DSI, GPIO, ..., not shown on the figure) and will control the
> > > video stream it receives on its input.
> > >
> > > The panel is connected at the hardware level to a video source
> > > (shown as a green hashed rectangle) that provides it with a video
> > > stream. The video stream flows from the video source to the panel
> > > and is directly controlled by its source, as shown by the green
> > > arrow from the display controller to the video stream. The video
> > > source exposes stream control operations as function pointers that
> > > are used by the panel to control the video stream, as shown by the
> > > green arrow from the panel to the video source.
> > >
> > > The figure at
> > > http://www.ideasonboard.org/media/cdf/cdf-panel-control-
> > > model-2.png shows the call flow across entities when the panel is a
> > > pipeline made of more than a single entity. In this case the SoC (on
> > > the left of the dashed line) outputs a video stream on a DSI bus
> > > connected to a DSI to LVDS transmitter. The output of the DSI to
> > > LVDS transmitter is connected to an LVDS panel (or, more
> > > accurately, an LVDS panel module made of an LVDS panel controller
> > > and a panel).
> > >
> > > The transmitter and panel module are seen by the display controller
> > > and
> > > userspace API implementations as a single entity that exposes
> > > control
> > > request operations and controls its input video stream. When a
> > > control
> > > request is performed (outermost green arrow) the DSI to LVDS
> > > transmitter will propagate it to the panel, possibly mangling the
> > > input parameters or the response. For panel operation state control
> > > requests the last entity in the pipeline will likely want to
> > > control the video stream it receives on its input. The video stream
> > > control calls will be propagated from right to left as shown by the
> > > red arrows.
> > >
> > > Every entity in the call stack can communicate with its hardware
> > > device
> > > through the corresponding control bus, and/or control the video
> > > stream it receives on its input.
> > >
> > > This model allows filtering out modes and timings supported by the
> > > panel but unsupported by the transmitter and mangling the modes and
> > > timings according to the transmitter limitations. It has no
> > > complexity drawback for simple devices, as the corresponding
> > > drivers can just forward the calls directly. Similar use cases
> > > could exist for other control operations than mode and information
> > > retrieval.
> > >
> > > Discovery
> > > ---------
> > >
> > > Before being able to issue control requests, panel devices need to
> > > be
> > > discovered and associated with the connected display controller(s).
> > >
> > > Panels and display controllers are cross-dependent. There is no way
> > > around that, as the display controller needs a reference to the
> > > panel to call control requests in response to userspace API, and
> > > the panel needs a reference to the display controller to call video
> > > stream control functions (in addition to requiring generic
> > > resources such as clocks, GPIOs or even regulators that could be
> > > provided by the display controller).
> > >
> > > As we can't probe the display controller and the panel together, a
> > > probe order needs to be defined. The decision was to consider video
> > > sources as resources and defer panel probing until all required
> > > resources (video stream source, clocks, GPIOs, regulators and more)
> > > are available. Display controller probing must succeed without the
> > > panel being available. This mimicks the hotpluggable monitor model
> > > (VGA, HDMI, DP) that doesn't prevent display controllers from being
> > > successfully probed without a connected monitor.
> > >
> > > Our design goal is to handle panel discovery in a similar (if not
> > > identical) way as HDMI/DP hotplug in order to implement a single
> > > display discovery method in display controller drivers. This might
> > > not be achievable, in which case we'll reconsider the design
> > > requirement.
> > >
> > > When the display controller driver probes the device it will
> > > register the video source(s) at the output of the display
> > > controller with the CDF core. Those sources will be identified by
> > > the display controller dev_name() and a source integer index. A new
> > > structure, likely called
> > > display_entity_port, will be used to represent a source or sink
> > > video port on a display entity.
> > >
> > > Panel drivers will handle video sources as resources. They will
> > > retrieve at probe time the video source the panel is connected to
> > > using a phandle or a source name (depending on whether the platform
> > > uses DT). If the source isn't available the probe function will
> > > return -EPROBE_DEFER.
> > >
> > > In addition to the video stream control operations mentioned above,
> > > ports will also expose a connect/disconnect operation use to notify
> > > them of connection/disconnection events. After retrieving the
> > > connected video source panel drivers call the connect/disconnect
> > > operation on the video source to notify it that the panel is
> > > available.
> > >
> > > When the panel is a pipeline made of more than a single entity,
> > > entities are probed in video source to video sink order.
> > > Out-of-order probe will result in probe deferral as explained above
> > > due to the video source not being available, resulting in the
> > > source to sink probe order. Entities should not call the connect
> > > operation of their video source at probe time in that case, but
> > > only when their own connect operation for the video source(s) they
> > > provide to the next entity is called by the next entity. Connect
> > > operations will thus be called in sink to source order starting at
> > > the entity at the end of the pipeline and going all the way back to
> > > the display controller.
> > >
> > > This notification system is a hotplug mechanism that replaces the
> > > display entity notifier system from my previous RFC. Alan Cox
> > > rightly objected to the notification system, arguing that such
> > > system-wide notifications were used by FBDEV and very subject to
> > > abuse. I agree with his argument, this new mechanism should result
> > > in a cleaner implementation as video sources will only be notified
> > > of connect/disconnect events for the entity they're connected to.
> > >
> > > DBI/DSI busses
> > > --------------
> > >
> > > My RFC introduced a DBI bus using the Linux device and bus model.
> > > Its
> > > purpose was multifold:
> > >
> > > - Support (un)registration, matching and binding of devices and
> > > drivers.
> > >
> > > - Provide power management (suspend/resume) services through the
> > > standard Linux PM bus/device model, to make sure that DBI devices
> > > will be suspended/resumed after/before their DBI bus controller.
> > >
> > > - Provide bus services to access the connected devices. For DBI that
> > > took the form of command read and data read/write functions.
> > >
> > > A DSI bus implementation using the same model was also planned.
> > >
> > > Tomi's patches removed the DBI bus and replaced DBI devices with
> > > platform devices, moving the bus services implementation to the
> > > video source. DBI and DSI busses are always either pure video or
> > > video + control busses (although controlling a DPI panel through
> > > DSI is conceivable, nobody in his right mind, not even a hardware
> > > engineer, would likely implement that), so there will always be a
> > > video source to provide the DBI/DSI control operations.
> > >
> > > (Un)registration, matching and binding of devices and drivers is
> > > provided by the platform device bus. Bus services to access
> > > connected devices are provided by the video source, wrapper
> > > functions will be used to handle serialization and locking, and
> > > possibly to offer higher level services (such as DCS for instance).
> > >
> > > One drawback of using the platform bus is that PM relationships
> > > between
> > > the bus master and slaves will not be taken into account during
> > > suspend/resume. However, a similar issue exists for DPI panels, and
> > > PM
> > > relationships at the video bus level for DBI and DSI are not handled
> > > by
> > > the DBI/DSI busses either. As we need a generic solution to handle
> > > those (likely through early suspend and late resume), the same
> > > solution can be used to handle DBI and DSI control bus PM
> > > relationships without requiring a Linux DBI or DSI bus.
> > >
> > > Even though I still like the idea of DBI and DSI busses, I agree
> > > with Tomi that they're not strictly needed and I will drop them.
> > >
> > > Entity model
> > > ------------
> > >
> > > Tomi's proposal split the display entities into video sources
> > > (struct
> > > video_source) and display entities (struct display_entity). To make
> > > generic pipeline operations easier, we agreed to merge the video
> > > source
> > > and the display entity back. struct display_entity thus models a
> > > display entity that has any number of sink and/or source ports,
> > > modeled as struct display_entity_port instances.
> >
> > Looking at Tomi's patchset, he has considered panel as "display
> > entity"
> > and MIPI DSI as "video source entity". So if we are planning to merge
> > it back how should we treat panel and MIPI DSI. i mean should we
> > consider both panel and MIPI DSI has 2 different display entities.
> > i.e, during the probe of each of these drivers, should we register a
> > display entity with CDF.
>
> Both the DSI encoder and the DSI panel would be modeled as display
> entities. The DSI encoder would have a source port that models its DSI
> video source, and the DSI panel would have a sink port.
>
> > > Video stream operations will be exposed by the display entity as
> > > function pointers and will take a port reference as argument (this
> > > could take the form of struct display_entity * and port index, or
> > > struct
> > > display_entity_port *). The DVI and DSI operations model proposed by
> > > Tomi in this patch series will be kept.
> >
> > so you mean you will be adding these "ops" as part of "struct display
> > entity" rather than video source ops,
>
> That's correct.
>
> > static const struct dsi_video_source_ops dsi_dsi_ops = {
> >
> > .update = dsi_bus_update,
> > .dcs_write = dsi_bus_dcs_write,
> > .dcs_read = dsi_bus_dcs_read,
> > .configure_pins = dsi_bus_configure_pins,
> > .set_clocks = dsi_bus_set_clocks,
> > .enable = dsi_bus_enable,
> > .disable = dsi_bus_disable,
> > .set_size = dsi_bus_set_size,
> > .set_operation_mode = dsi_bus_set_operation_mode,
> > .set_pixel_format = dsi_bus_set_pixel_format,
> > .enable_hs = dsi_bus_enable_hs,
> >
> > };
> >
> > if you can post CDF v3 patches early, it will give us more clarity
> > w.r.t to discussions you and Tomi had.
>
> I'm working on that.
May I ask you to add me on CC in v3?
This would allow me to track the development, without missing anything
like it happened with the discussion about bus-less design.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* Re: [PATCH fix-3.8] video: vt8500: Fix X crash when initializing framebuffer.
From: Sergei Shtylyov @ 2012-12-28 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356567943-3836-1-git-send-email-linux@prisktech.co.nz>
Hello.
On 12/27/2012 03:25 AM, Tony Prisk wrote:
> This patch adds support for .fb_check_var which is required when
> X attempts to initialize the framebuffer. The only supported
> resolution is the native resolution of the LCD panel, so we test
> against the resolution supplied from the DT panel definition.
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> drivers/video/wm8505fb.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 77539c1..c84e376 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
[...]
> @@ -248,8 +256,21 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
> return 0;
> }
>
> +static int wm8505fb_check_var(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
> + struct wm8505fb_info *fbi = to_wm8505fb_info(info);
> + if (!fbi) return -EINVAL;
> +
> + if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
> + if (info->var.xres != fbi->lcd_params.pixel_width) return -EINVAL;
> + if (info->var.yres != fbi->lcd_params.pixel_height) return -EINVAL;
> + return 0;
> +}
> +
[...]
$ scripts/checkpatch.pl
patches/video-vt8500-Fix-X-crash-when-initializing-framebuffer.patch
ERROR: code indent should use tabs where possible
#42: FILE: drivers/video/wm8505fb.c:263:
+ if (!fbi) return -EINVAL;$
WARNING: please, no spaces at the start of a line
#42: FILE: drivers/video/wm8505fb.c:263:
+ if (!fbi) return -EINVAL;$
ERROR: trailing statements should be on next line
#42: FILE: drivers/video/wm8505fb.c:263:
+ if (!fbi) return -EINVAL;
WARNING: line over 80 characters
#44: FILE: drivers/video/wm8505fb.c:265:
+ if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
ERROR: trailing statements should be on next line
#44: FILE: drivers/video/wm8505fb.c:265:
+ if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
ERROR: trailing statements should be on next line
#45: FILE: drivers/video/wm8505fb.c:266:
+ if (info->var.xres != fbi->lcd_params.pixel_width) return -EINVAL;
ERROR: trailing statements should be on next line
#46: FILE: drivers/video/wm8505fb.c:267:
+ if (info->var.yres != fbi->lcd_params.pixel_height) return -EINVAL;
total: 5 errors, 2 warnings, 49 lines checked
NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
scripts/cleanfile
patches/video-vt8500-Fix-X-crash-when-initializing-framebuffer.patch has style
problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WBR, Sergei
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Vikas Sajjan @ 2012-12-28 3:38 UTC (permalink / raw)
To: Tomasz Figa
Cc: Laurent Pinchart, dri-devel, Thomas Petazzoni, linux-fbdev,
Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec,
linux-media
In-Reply-To: <2529718.glQX8guWfJ@amdc1227>
On 27 December 2012 20:13, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Laurent,
>
> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
>> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
>> > > On 17 December 2012 20:55, Laurent Pinchart wrote:
>> > > > Hi Vikas,
>> > > >
>> > > > Sorry for the late reply. I now have more time to work on CDF, so
>> > > > delays should be much shorter.
>> > > >
>> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
>> > > > > Hi Laurent,
>> > > > >
>> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform,
>> > > > > what
>> > > > > I found is that, the exynos display controller is MIPI DSI based
>> > > > > controller.
>> > > > >
>> > > > > But if I look at CDF patches, it has only support for MIPI DBI
>> > > > > based
>> > > > > Display controller.
>> > > > >
>> > > > > So my question is, do we have any generic framework for MIPI DSI
>> > > > > based display controller? basically I wanted to know, how to go
>> > > > > about
>> > > > > porting CDF for such kind of display controller.
>> > > >
>> > > > MIPI DSI support is not available yet. The only reason for that is
>> > > > that I don't have any MIPI DSI hardware to write and test the code
>> > > > with :-)
>> > > >
>> > > > The common display framework should definitely support MIPI DSI. I
>> > > > think the existing MIPI DBI code could be used as a base, so the
>> > > > implementation shouldn't be too high.
>> > > >
>> > > > Yeah, i was also thinking in similar lines, below is my though for
>> > > > MIPI DSI support in CDF.
>> > >
>> > > o MIPI DSI support as part of CDF framework will expose
>> > > § mipi_dsi_register_device(mpi_device) (will be called
>> > > mach-xxx-dt.c
>> > > file )
>> > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
>> > > from
>> > > platform specific init driver call )
>> > > · bus ops will be
>> > > o read data
>> > > o write data
>> > > o write command
>> > > § MIPI DSI will be registered as bus_register()
>> > >
>> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI)
>> > > will
>> > > initialize the MIPI DSI HW IP.
>> > >
>> > > This probe will also parse the DT file for MIPI DSI based panel, add
>> > > the panel device (device_add() ) to kernel and register the display
>> > > entity with its control and video ops with CDF.
>> > >
>> > > I can give this a try.
>> >
>> > I am currently in progress of reworking Exynos MIPI DSIM code and
>> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I
>> > have most of the work done, I have just to solve several remaining
>> > problems.
>> Do you already have code that you can publish ? I'm particularly
>> interested (and I think Tomi Valkeinen would be as well) in looking at
>> the DSI operations you expose to DSI sinks (panels, transceivers, ...).
>
> Well, I'm afraid this might be little below your expectations, but here's
> an initial RFC of the part defining just the DSI bus. I need a bit more
> time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.
>
> The implementation is very simple and heavily based on your MIPI DBI
> support and existing Exynos MIPI DSIM framework. Provided operation set is
> based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately
> this is my only source of information about MIPI DSI.
>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
>
> From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001
> From: Tomasz Figa <t.figa@samsung.com>
> Date: Thu, 27 Dec 2012 12:36:15 +0100
> Subject: [RFC] video: display: Add generic MIPI DSI bus
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> ---
> drivers/video/display/Kconfig | 4 +
> drivers/video/display/Makefile | 1 +
> drivers/video/display/mipi-dsi-bus.c | 214
> +++++++++++++++++++++++++++++++++++
> include/video/display.h | 1 +
> include/video/mipi-dsi-bus.h | 98 ++++++++++++++++
> 5 files changed, 318 insertions(+)
> create mode 100644 drivers/video/display/mipi-dsi-bus.c
> create mode 100644 include/video/mipi-dsi-bus.h
>
> diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
> index 13b6aaf..dbaff9d 100644
> --- a/drivers/video/display/Kconfig
> +++ b/drivers/video/display/Kconfig
> @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI
> tristate
> default n
>
> +config DISPLAY_MIPI_DSI
> + tristate
> + default n
> +
> config DISPLAY_PANEL_DPI
> tristate "DPI (Parallel) Display Panels"
> ---help---
> diff --git a/drivers/video/display/Makefile
> b/drivers/video/display/Makefile
> index 482bec7..429b3ac8 100644
> --- a/drivers/video/display/Makefile
> +++ b/drivers/video/display/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_DISPLAY_CORE) += display-core.o
> obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
> +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o
> obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
> obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
> obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
> diff --git a/drivers/video/display/mipi-dsi-bus.c
> b/drivers/video/display/mipi-dsi-bus.c
> new file mode 100644
> index 0000000..2998522
> --- /dev/null
> +++ b/drivers/video/display/mipi-dsi-bus.c
> @@ -0,0 +1,214 @@
> +/*
> + * MIPI DSI Bus
> + *
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + * Contacts: Tomasz Figa <t.figa@samsung.com>
> + *
> + * Heavily based ond mipi-dbi-bus.c.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/export.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/pm.h>
> +#include <linux/pm_runtime.h>
> +
> +#include <video/mipi-dsi-bus.h>
> +
> +/*
> -----------------------------------------------------------------------------
> + * Bus operations
> + */
> +
> +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd,
> + const unsigned char *buf, unsigned int len)
> +{
> + return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_write_command);
> +
> +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd,
> + unsigned int addr, unsigned char *buf, unsigned int len)
> +{
> + return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf,
> len);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_read_command);
> +
> +/*
> -----------------------------------------------------------------------------
> + * Bus type
> + */
> +
> +static const struct mipi_dsi_device_id *
> +mipi_dsi_match_id(const struct mipi_dsi_device_id *id,
> + struct mipi_dsi_device *dev)
> +{
> + while (id->name[0]) {
> + if (strcmp(dev->name, id->name) = 0) {
> + dev->id_entry = id;
> + return id;
> + }
> + id++;
> + }
> + return NULL;
> +}
> +
> +static int mipi_dsi_match(struct device *_dev, struct device_driver
> *_drv)
> +{
> + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
> + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv);
> +
> + if (drv->id_table)
> + return mipi_dsi_match_id(drv->id_table, dev) != NULL;
> +
> + return (strcmp(dev->name, _drv->name) = 0);
> +}
> +
> +static ssize_t modalias_show(struct device *_dev, struct device_attribute
> *a,
> + char *buf)
> +{
> + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
> + int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n",
> + dev->name);
> +
> + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
> +}
> +
> +static struct device_attribute mipi_dsi_dev_attrs[] = {
> + __ATTR_RO(modalias),
> + __ATTR_NULL,
> +};
> +
> +static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env
> *env)
> +{
> + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
> +
> + add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX,
> + dev->name);
> + return 0;
> +}
> +
> +static const struct dev_pm_ops mipi_dsi_dev_pm_ops = {
> + .runtime_suspend = pm_generic_runtime_suspend,
> + .runtime_resume = pm_generic_runtime_resume,
> + .runtime_idle = pm_generic_runtime_idle,
> + .suspend = pm_generic_suspend,
> + .resume = pm_generic_resume,
> + .freeze = pm_generic_freeze,
> + .thaw = pm_generic_thaw,
> + .poweroff = pm_generic_poweroff,
> + .restore = pm_generic_restore,
> +};
> +
> +static struct bus_type mipi_dsi_bus_type = {
> + .name = "mipi-dsi",
> + .dev_attrs = mipi_dsi_dev_attrs,
> + .match = mipi_dsi_match,
> + .uevent = mipi_dsi_uevent,
> + .pm = &mipi_dsi_dev_pm_ops,
> +};
> +
> +/*
> -----------------------------------------------------------------------------
> + * Device and driver (un)registration
> + */
> +
> +/**
> + * mipi_dsi_device_register - register a DSI device
> + * @dev: DSI device we're registering
> + */
> +int mipi_dsi_device_register(struct mipi_dsi_device *dev,
> + struct mipi_dsi_bus *bus)
> +{
> + device_initialize(&dev->dev);
> +
> + dev->bus = bus;
> + dev->dev.bus = &mipi_dsi_bus_type;
> + dev->dev.parent = bus->dev;
> +
> + if (dev->id != -1)
> + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id);
> + else
> + dev_set_name(&dev->dev, "%s", dev->name);
> +
> + return device_add(&dev->dev);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_device_register);
> +
> +/**
> + * mipi_dsi_device_unregister - unregister a DSI device
> + * @dev: DSI device we're unregistering
> + */
> +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev)
> +{
> + device_del(&dev->dev);
> + put_device(&dev->dev);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister);
> +
> +static int mipi_dsi_drv_probe(struct device *_dev)
> +{
> + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver);
> + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
> +
> + return drv->probe(dev);
> +}
> +
> +static int mipi_dsi_drv_remove(struct device *_dev)
> +{
> + struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver);
> + struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
> +
> + return drv->remove(dev);
> +}
> +
> +/**
> + * mipi_dsi_driver_register - register a driver for DSI devices
> + * @drv: DSI driver structure
> + */
> +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
> +{
> + drv->driver.bus = &mipi_dsi_bus_type;
> + if (drv->probe)
> + drv->driver.probe = mipi_dsi_drv_probe;
> + if (drv->remove)
> + drv->driver.remove = mipi_dsi_drv_remove;
> +
> + return driver_register(&drv->driver);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_driver_register);
> +
> +/**
> + * mipi_dsi_driver_unregister - unregister a driver for DSI devices
> + * @drv: DSI driver structure
> + */
> +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv)
> +{
> + driver_unregister(&drv->driver);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister);
> +
> +/*
> -----------------------------------------------------------------------------
> + * Init/exit
> + */
> +
> +static int __init mipi_dsi_init(void)
> +{
> + return bus_register(&mipi_dsi_bus_type);
> +}
> +
As per the discussion what Laurent and Tomi had (
http://lists.freedesktop.org/archives/dri-devel/2012-December/032038.html),
both DSI and DBI doesn't need to be registered as real bus. Please
refer to Tomi's pacthset for DSI support. (
git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-cdf )
anyways i am working on Exynos MIPI DSI as per the new CDF proposed by
Tomi and Laurent.
> +static void __exit mipi_dsi_exit(void)
> +{
> + bus_unregister(&mipi_dsi_bus_type);
> +}
> +
> +module_init(mipi_dsi_init);
> +module_exit(mipi_dsi_exit)
> +
> +MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>");
> +MODULE_DESCRIPTION("MIPI DSI Bus");
> +MODULE_LICENSE("GPL");
> diff --git a/include/video/display.h b/include/video/display.h
> index 75ba270..f86ea6e 100644
> --- a/include/video/display.h
> +++ b/include/video/display.h
> @@ -70,6 +70,7 @@ enum display_entity_stream_state {
> enum display_entity_interface_type {
> DISPLAY_ENTITY_INTERFACE_DPI,
> DISPLAY_ENTITY_INTERFACE_DBI,
> + DISPLAY_ENTITY_INTERFACE_DSI,
> };
>
> struct display_entity_interface_params {
> diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h
> new file mode 100644
> index 0000000..3efcb39
> --- /dev/null
> +++ b/include/video/mipi-dsi-bus.h
> @@ -0,0 +1,98 @@
> +/*
> + * MIPI DSI Bus
> + *
> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
> + * Contacts: Tomasz Figa <t.figa@samsung.com>
> + *
> + * Heavily based ond mipi-dbi-bus.h.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __MIPI_DSI_BUS_H__
> +#define __MIPI_DSI_BUS_H__
> +
> +#include <linux/device.h>
> +
> +struct mipi_dsi_bus;
> +struct mipi_dsi_device;
> +
> +struct mipi_dsi_bus_ops {
> + int (*write_command)(struct mipi_dsi_bus *bus,
> + struct mipi_dsi_device *dev, unsigned int cmd,
> + const unsigned char *buf, unsigned int len);
> + int (*read_command)(struct mipi_dsi_bus *bus,
> + struct mipi_dsi_device *dev, unsigned int cmd,
> + unsigned int addr, unsigned char *buf,
> + unsigned int len);
> +};
> +
> +struct mipi_dsi_bus {
> + struct device *dev;
> + const struct mipi_dsi_bus_ops *ops;
> +};
> +
> +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"
> +#define MIPI_DSI_NAME_SIZE 32
> +
> +struct mipi_dsi_device_id {
> + char name[MIPI_DSI_NAME_SIZE];
> + __kernel_ulong_t driver_data /* Data private to the driver */
> + __aligned(sizeof(__kernel_ulong_t));
> +};
> +
> +struct mipi_dsi_device {
> + const char *name;
> + int id;
> + struct device dev;
> +
> + const struct mipi_dsi_device_id *id_entry;
> + struct mipi_dsi_bus *bus;
> +};
> +
> +#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device,
> dev)
> +
> +int mipi_dsi_device_register(struct mipi_dsi_device *dev,
> + struct mipi_dsi_bus *bus);
> +void mipi_dsi_device_unregister(struct mipi_dsi_device *dev);
> +
> +struct mipi_dsi_driver {
> + int(*probe)(struct mipi_dsi_device *);
> + int(*remove)(struct mipi_dsi_device *);
> + struct device_driver driver;
> + const struct mipi_dsi_device_id *id_table;
> +};
> +
> +#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver,
> driver)
> +
> +int mipi_dsi_driver_register(struct mipi_dsi_driver *drv);
> +void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv);
> +
> +static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device
> *dev)
> +{
> + return dev_get_drvdata(&dev->dev);
> +}
> +
> +static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev,
> + void *data)
> +{
> + dev_set_drvdata(&dev->dev, data);
> +}
> +
> +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do
> + * anything special in module init/exit. This eliminates a lot of
> + * boilerplate. Each module may only use this macro once, and
> + * calling it replaces module_init() and module_exit()
> + */
> +#define module_mipi_dsi_driver(__mipi_dsi_driver) \
> + module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \
> + mipi_dsi_driver_unregister)
> +
> +int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd,
> + const unsigned char *buf, unsigned int len);
> +int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd,
> + unsigned int addr, unsigned char *buf, unsigned int len);
> +
> +#endif /* __MIPI_DSI_BUS__ */
> --
> 1.8.0.2
>
>
--
Thanks and Regards
Vikas Sajjan
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer @ 2012-12-28 0:04 UTC (permalink / raw)
To: Rob Clark
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGtWOoNjKuUgu=AaZn3Jj8g_D807Ycyjtu5bro8ZLL1NNg@mail.gmail.com>
On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
> On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> >
> > This implies that the master driver knows all potential subdevices,
> > something which is not true for SoCs which have external i2c encoders
> > attached to unrelated i2c controllers.
>
> well, it can be brute-forced.. ie. drm driver calls common
> register_all_panels() fxn, which, well, registers all the
> panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
> defines. If you anyways aren't building the panels as separate
> modules, that would work. Maybe not the most *elegant* approach, but
> simple and functional.
>
> I guess it partly depends on the structure in devicetree. If you are
> assuming that the i2c encoder belongs inside the i2c bus, like:
>
> &i2cN {
> foo-i2c-encoder {
> ....
> };
> };
>
> and you are letting devicetree create the devices, then it doesn't
> quite work. I'm not entirely convinced you should do it that way.
> Really any device like that is going to be hooked up to at least a
> couple busses.. i2c, some sort of bus carrying pixel data, maybe some
> gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
> then use phandle stuff to link it to the various other busses it
> needs:
>
> mydrmdev {
> foo-i2c-encoder {
> i2c = <&i2cN>;
> gpio = <&gpioM 2 3>
> ...
> };
> };
This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.
It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.
I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.
Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.
>
> ok, admittedly that is a bit different from other proposals about how
> this all fits in devicetree.. but otoh, I'm not a huge believer in
> letting something that is supposed to make life easier (DT), actually
> make things harder or more complicated. Plus this CDF stuff all needs
> to also work on platforms not using OF/DT.
Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.
CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.
Sascha
--
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: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-27 19:57 UTC (permalink / raw)
To: Sascha Hauer
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Philipp Zabel, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <20121227191859.GX26326@pengutronix.de>
On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
>> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>> > Hi Rob,
>> >
>> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
>> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote:
>> >> >> Many developers showed interest in the first RFC, and I've had the
>> >> >> opportunity to discuss it with most of them. I would like to thank (in
>> >> >> no particular order) Tomi Valkeinen for all the time he spend helping me
>> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
>> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
>> >> >> discuss this topic.
>> >> >
>> >> > So this might be a bit off topic but this whole CDF triggered me
>> >> > looking at stuff I generally avoid:
>> >> >
>> >> > The biggest problem I'm having currently with the whole ARM graphics
>> >> > and output world is the proliferation of platform drivers for every
>> >> > little thing. The whole ordering of operations with respect to things
>> >> > like suspend/resume or dynamic power management is going to be a real
>> >> > nightmare if there are dependencies between the drivers. How do you
>> >> > enforce ordering of s/r operations between all the various components?
>> >>
>> >> I tend to think that sub-devices are useful just to have a way to probe hw
>> >> which may or may not be there, since on ARM we often don't have any
>> >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
>> >> they should really be treated as all one device. Especially to avoid
>> >> undefined suspend/resume ordering.
>> >
>> > I tend to agree, except that I try to reuse the existing PM infrastructure
>> > when possible to avoid reinventing the wheel. So far handling suspend/resume
>> > ordering related to data busses in early suspend/late resume operations and
>> > allowing the Linux PM core to handle control busses using the Linux device
>> > tree worked pretty well.
>> >
>> >> CDF or some sort of mechanism to share panel drivers between drivers is
>> >> useful. Keeping it within drm, is probably a good idea, if nothing else to
>> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
>> >> avoid dealing with merging changes across multiple trees. Treating them more
>> >> like shared libraries and less like sub-devices which can be dynamically
>> >> loaded/unloaded (ie. they should be not built as separate modules or
>> >> suspend/resumed or probed/removed independently of the master driver) is a
>> >> really good idea to avoid uncovering nasty synchronization issues later
>> >> (remove vs modeset or pageflip) or surprising userspace in bad ways.
>> >
>> > We've tried that in V4L2 years ago and realized that the approach led to a
>> > dead-end, especially when OF/DT got involved. With DT-based device probing,
>> > I2C camera sensors started getting probed asynchronously to the main camera
>> > device, as they are children of the I2C bus master. We will have similar
>> > issues with I2C HDMI transmitters or panels, so we should be prepared for it.
>>
>> What I've done to avoid that so far is that the master device
>> registers the drivers for it's output sub-devices before registering
>> it's own device. At least this way I can control that they are probed
>> first. Not the prettiest thing, but avoids even uglier problems.
>
> This implies that the master driver knows all potential subdevices,
> something which is not true for SoCs which have external i2c encoders
> attached to unrelated i2c controllers.
well, it can be brute-forced.. ie. drm driver calls common
register_all_panels() fxn, which, well, registers all the
panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
defines. If you anyways aren't building the panels as separate
modules, that would work. Maybe not the most *elegant* approach, but
simple and functional.
I guess it partly depends on the structure in devicetree. If you are
assuming that the i2c encoder belongs inside the i2c bus, like:
&i2cN {
foo-i2c-encoder {
....
};
};
and you are letting devicetree create the devices, then it doesn't
quite work. I'm not entirely convinced you should do it that way.
Really any device like that is going to be hooked up to at least a
couple busses.. i2c, some sort of bus carrying pixel data, maybe some
gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and
then use phandle stuff to link it to the various other busses it
needs:
mydrmdev {
foo-i2c-encoder {
i2c = <&i2cN>;
gpio = <&gpioM 2 3>
...
};
};
ok, admittedly that is a bit different from other proposals about how
this all fits in devicetree.. but otoh, I'm not a huge believer in
letting something that is supposed to make life easier (DT), actually
make things harder or more complicated. Plus this CDF stuff all needs
to also work on platforms not using OF/DT.
BR,
-R
> Sascha
>
> --
> 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 |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer @ 2012-12-27 19:19 UTC (permalink / raw)
To: Rob Clark
Cc: Laurent Pinchart, Jani Nikula, Maxime Ripard, Tomi Valkeinen,
Thomas Petazzoni, linux-fbdev, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel, Kyungmin Park, Benjamin Gaignard,
Vikas Sajjan, Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <CAF6AEGth+rriTf7X3AXytN+YXxjx4XqMB1ow6ZE2QUro-hqYgw@mail.gmail.com>
On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote:
> On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> >> It just seems to me that, at least from a DRM/KMS perspective, adding
> >> another layer (ÍF) for HDMI or DP (or legacy outputs) would be
> >> overengineering it. They are pretty well standardized, and I don't see there
> >> would be a need to write multiple display drivers for them. Each display
> >> controller has one, and can easily handle any chip specific requirements
> >> right there. It's my gut feeling that an additional framework would just get
> >> in the way. Perhaps there could be more common HDMI/DP helper style code in
> >> DRM to reduce overlap across KMS drivers, but that's another thing.
> >>
> >> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
> >> perspective? Or, put another way, is it more of an alternative to using DRM?
> >> Please enlighten me if there's some real benefit here that I fail to see!
> >
> > As Rob pointed out, you can have external HDMI/DP encoders, and even internal
> > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at
> > sharing a single driver between SoCs and boards for a given HDMI/DP encoder.
>
> just fwiw, drm already has something a bit like this.. the i2c
> encoder-slave. With support for a couple external i2c encoders which
> could in theory be shared between devices.
The problem with this code is that it only works when the i2c device is
registered by a master driver. Once the i2c device comes from the
devicetree there is no possibility to find it.
Sascha
--
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: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer @ 2012-12-27 19:18 UTC (permalink / raw)
To: Rob Clark
Cc: Laurent Pinchart, Thomas Petazzoni, Linux Fbdev development list,
Benjamin Gaignard, Tom Gall, Kyungmin Park,
dri-devel@lists.freedesktop.org, Ragesh Radhakrishnan,
Tomi Valkeinen, Philipp Zabel, Bryan Wu, Maxime Ripard,
Vikas Sajjan, Sumit Semwal, Sebastien Guiriec,
linux-media@vger.kernel.org
In-Reply-To: <CAF6AEGt+gwUq-xGze5bTgrKUMRijSBo_ORreq=Ot1RMD-WrbYQ@mail.gmail.com>
On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > Hi Rob,
> >
> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote:
> >> >> Many developers showed interest in the first RFC, and I've had the
> >> >> opportunity to discuss it with most of them. I would like to thank (in
> >> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> >> discuss this topic.
> >> >
> >> > So this might be a bit off topic but this whole CDF triggered me
> >> > looking at stuff I generally avoid:
> >> >
> >> > The biggest problem I'm having currently with the whole ARM graphics
> >> > and output world is the proliferation of platform drivers for every
> >> > little thing. The whole ordering of operations with respect to things
> >> > like suspend/resume or dynamic power management is going to be a real
> >> > nightmare if there are dependencies between the drivers. How do you
> >> > enforce ordering of s/r operations between all the various components?
> >>
> >> I tend to think that sub-devices are useful just to have a way to probe hw
> >> which may or may not be there, since on ARM we often don't have any
> >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
> >> they should really be treated as all one device. Especially to avoid
> >> undefined suspend/resume ordering.
> >
> > I tend to agree, except that I try to reuse the existing PM infrastructure
> > when possible to avoid reinventing the wheel. So far handling suspend/resume
> > ordering related to data busses in early suspend/late resume operations and
> > allowing the Linux PM core to handle control busses using the Linux device
> > tree worked pretty well.
> >
> >> CDF or some sort of mechanism to share panel drivers between drivers is
> >> useful. Keeping it within drm, is probably a good idea, if nothing else to
> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
> >> avoid dealing with merging changes across multiple trees. Treating them more
> >> like shared libraries and less like sub-devices which can be dynamically
> >> loaded/unloaded (ie. they should be not built as separate modules or
> >> suspend/resumed or probed/removed independently of the master driver) is a
> >> really good idea to avoid uncovering nasty synchronization issues later
> >> (remove vs modeset or pageflip) or surprising userspace in bad ways.
> >
> > We've tried that in V4L2 years ago and realized that the approach led to a
> > dead-end, especially when OF/DT got involved. With DT-based device probing,
> > I2C camera sensors started getting probed asynchronously to the main camera
> > device, as they are children of the I2C bus master. We will have similar
> > issues with I2C HDMI transmitters or panels, so we should be prepared for it.
>
> What I've done to avoid that so far is that the master device
> registers the drivers for it's output sub-devices before registering
> it's own device. At least this way I can control that they are probed
> first. Not the prettiest thing, but avoids even uglier problems.
This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.
Sascha
--
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: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-27 16:10 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Maxime Ripard, Jani Nikula, Tomi Valkeinen, Thomas Petazzoni,
Linux Fbdev development list, Philipp Zabel, Tom Gall,
Ragesh Radhakrishnan, dri-devel@lists.freedesktop.org,
Kyungmin Park, Benjamin Gaignard, Vikas Sajjan, Sumit Semwal,
Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <9229594.Uy6ivYUL5t@avalon>
On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
>> And, there are also external HDMI encoders (for example connected over
>> i2c) that can also be shared between boards. So I think there will be
>> a number of cases where CDF is appropriate for HDMI drivers. Although
>> trying to keep this all independent of DRM (as opposed to just
>> something similar to what drivers/gpu/i2c is today) seems a bit
>> overkill for me. Being able to use the helpers in drm and avoiding an
>> extra layer of translation seems like the better option to me. So my
>> vote would be drivers/gpu/cdf.
>
> I don't think there will be any need for translation (except perhaps between
> the DRM mode structures and the common video mode structure that is being
> discussed). Add a drm_ prefix to the existing CDF functions and structures,
> and there you go :-)
well, and translation for any properties that we'd want to expose to
userspace, etc, etc.. I see there being a big potential for a lot of
needless glue
BR,
-R
> The reason why I'd like to keep CDF separate from DRM (or at least not
> requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2
> drivers.
>
>> > For DSI panels (or DSI-to-whatever bridges) it's of course another
>> > story. You typically need a panel specific driver. And here I see the
>> > main point of the whole CDF: decoupling display controllers and the
>> > panel drivers, and sharing panel (and converter chip) specific drivers
>> > across display controllers. Making it easy to write new drivers, as
>> > there would be a model to follow. I'm definitely in favour of coming up
>> > with some framework that would tackle that.
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-27 16:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jani Nikula, Maxime Ripard, Tomi Valkeinen, Thomas Petazzoni,
linux-fbdev, Philipp Zabel, Tom Gall, Ragesh Radhakrishnan,
dri-devel, Kyungmin Park, Benjamin Gaignard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media
In-Reply-To: <2286035.iP368aB6Vk@avalon>
On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
>> It just seems to me that, at least from a DRM/KMS perspective, adding
>> another layer (ÍF) for HDMI or DP (or legacy outputs) would be
>> overengineering it. They are pretty well standardized, and I don't see there
>> would be a need to write multiple display drivers for them. Each display
>> controller has one, and can easily handle any chip specific requirements
>> right there. It's my gut feeling that an additional framework would just get
>> in the way. Perhaps there could be more common HDMI/DP helper style code in
>> DRM to reduce overlap across KMS drivers, but that's another thing.
>>
>> So is the HDMI/DP drivers using CDF a more interesting idea from a non-DRM
>> perspective? Or, put another way, is it more of an alternative to using DRM?
>> Please enlighten me if there's some real benefit here that I fail to see!
>
> As Rob pointed out, you can have external HDMI/DP encoders, and even internal
> HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at
> sharing a single driver between SoCs and boards for a given HDMI/DP encoder.
just fwiw, drm already has something a bit like this.. the i2c
encoder-slave. With support for a couple external i2c encoders which
could in theory be shared between devices.
BR,
-R
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-27 15:57 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Marcus Lorentzon, Dave Airlie, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
Archit Taneja, Benjamin Gaignard, Inki Dae, Jesse Barker,
Kyungmin Park, Maxime Ripard, Philipp Zabel, Ragesh Radhakrishnan,
Sascha Hauer, Sebastien Guiriec, Sumit Semwal, Thomas Petazzoni,
Tom Gall, Tomi Valkeinen, Vikas Sajjan <vikas.sa>
In-Reply-To: <5538783.cf2rXfYmRW@avalon>
On Mon, Dec 24, 2012 at 11:09 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On the topic of discussions, would anyone be interested in a
> BoF/brainstorming/whatever session during the FOSDEM ?
I will be at FOSDEM.. and from http://wiki.x.org/wiki/fosdem2013 it
looks like at least Daniel will be there. If enough others are, it
could be a good idea.
BR,
-R
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Rob Clark @ 2012-12-27 15:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Dave Airlie, Thomas Petazzoni, Linux Fbdev development list,
Philipp Zabel, Tom Gall, Ragesh Radhakrishnan,
dri-devel@lists.freedesktop.org, Kyungmin Park, Tomi Valkeinen,
Benjamin Gaignard, Bryan Wu, Maxime Ripard, Vikas Sajjan,
Sumit Semwal, Sebastien Guiriec, linux-media@vger.kernel.org
In-Reply-To: <9690842.n93imGlCHA@avalon>
On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Rob,
>
> On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
>> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote:
>> >> Many developers showed interest in the first RFC, and I've had the
>> >> opportunity to discuss it with most of them. I would like to thank (in
>> >> no particular order) Tomi Valkeinen for all the time he spend helping me
>> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
>> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
>> >> discuss this topic.
>> >
>> > So this might be a bit off topic but this whole CDF triggered me
>> > looking at stuff I generally avoid:
>> >
>> > The biggest problem I'm having currently with the whole ARM graphics
>> > and output world is the proliferation of platform drivers for every
>> > little thing. The whole ordering of operations with respect to things
>> > like suspend/resume or dynamic power management is going to be a real
>> > nightmare if there are dependencies between the drivers. How do you
>> > enforce ordering of s/r operations between all the various components?
>>
>> I tend to think that sub-devices are useful just to have a way to probe hw
>> which may or may not be there, since on ARM we often don't have any
>> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
>> they should really be treated as all one device. Especially to avoid
>> undefined suspend/resume ordering.
>
> I tend to agree, except that I try to reuse the existing PM infrastructure
> when possible to avoid reinventing the wheel. So far handling suspend/resume
> ordering related to data busses in early suspend/late resume operations and
> allowing the Linux PM core to handle control busses using the Linux device
> tree worked pretty well.
>
>> CDF or some sort of mechanism to share panel drivers between drivers is
>> useful. Keeping it within drm, is probably a good idea, if nothing else to
>> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
>> avoid dealing with merging changes across multiple trees. Treating them more
>> like shared libraries and less like sub-devices which can be dynamically
>> loaded/unloaded (ie. they should be not built as separate modules or
>> suspend/resumed or probed/removed independently of the master driver) is a
>> really good idea to avoid uncovering nasty synchronization issues later
>> (remove vs modeset or pageflip) or surprising userspace in bad ways.
>
> We've tried that in V4L2 years ago and realized that the approach led to a
> dead-end, especially when OF/DT got involved. With DT-based device probing,
> I2C camera sensors started getting probed asynchronously to the main camera
> device, as they are children of the I2C bus master. We will have similar
> issues with I2C HDMI transmitters or panels, so we should be prepared for it.
What I've done to avoid that so far is that the master device
registers the drivers for it's output sub-devices before registering
it's own device. At least this way I can control that they are probed
first. Not the prettiest thing, but avoids even uglier problems.
> On PC hardware the I2C devices are connected to an I2C master provided by the
> GPU, but on embedded devices they are usually connected to an independent I2C
> master. We thus can't have a single self-contained driver that controls
> everything internally, and need to interface with the rest of the SoC drivers.
>
> I agree that probing/removing devices independently of the master driver can
> lead to bad surprises, which is why I want to establish clear rules in CDF
> regarding what can and can't be done with display entities. Reference counting
> will be one way to make sure that devices don't disappear all of a sudden.
That at least helps cover some issues.. although it doesn't really
help userspace confusion.
Anyways, with enough work perhaps all problems could be solved..
otoh, there are plenty of other important problems to solve in the
world of gpus and kms, so my preference is always not to needlessly
over-complicate CDF and instead leave some time for other things
BR,
-R
>> > The other thing I'd like you guys to do is kill the idea of fbdev and
>> > v4l drivers that are "shared" with the drm codebase, really just
>> > implement fbdev and v4l on top of the drm layer, some people might
>> > think this is some sort of maintainer thing, but really nothing else
>> > makes sense, and having these shared display frameworks just to avoid
>> > having using drm/kms drivers seems totally pointless. Fix the drm
>> > fbdev emulation if an fbdev interface is needed. But creating a fourth
>> > framework because our previous 3 frameworks didn't work out doesn't
>> > seem like a situation I want to get behind too much.
>>
>> yeah, let's not have multiple frameworks to do the same thing.. For fbdev,
>> it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is
>> perhaps bit more flexible when it comes to random arbitrary hw pipelines
>> than kms. But to take advantage of that, your userspace isn't going to be
>> portable anyways, so you might as well use driver specific
>> properties/ioctls. But I tend to think that is more useful for cameras.
>> And from userspace perspective, kms planes are less painful to use for
>> output than v4l2, so lets stick to drm/kms for output (and not try to add
>> camera/capture support to kms)..
>
> Agreed. I've started to advocate the deprecation of FBDEV during LPC. The
> positive response has motivated me to continue doing so :-) For V4L2 the
> situation is a little bit different, I think V4L2 shouldn't be used for
> graphics and display hardware, but it still has use cases on the video output
> side for pure video devices (such as pass-through video pipelines with
> embedded processing for instance). As those can use subdevices found in
> display and graphics hardware, I'd like to avoid code duplication.
>
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC v2 0/5] Common Display Framework
From: Tomasz Figa @ 2012-12-27 14:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel, Vikas Sajjan, Thomas Petazzoni, linux-fbdev,
Benjamin Gaignard, Tom Gall, Kyungmin Park, Rob Clark,
Ragesh Radhakrishnan, Tomi Valkeinen, Philipp Zabel, Bryan Wu,
Maxime Ripard, sunil joshi, Sumit Semwal, Sebastien Guiriec,
linux-media
In-Reply-To: <3445117.L94DmxEvrl@avalon>
Hi Laurent,
On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > > On 17 December 2012 20:55, Laurent Pinchart wrote:
> > > > Hi Vikas,
> > > >
> > > > Sorry for the late reply. I now have more time to work on CDF, so
> > > > delays should be much shorter.
> > > >
> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > > > > Hi Laurent,
> > > > >
> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform,
> > > > > what
> > > > > I found is that, the exynos display controller is MIPI DSI based
> > > > > controller.
> > > > >
> > > > > But if I look at CDF patches, it has only support for MIPI DBI
> > > > > based
> > > > > Display controller.
> > > > >
> > > > > So my question is, do we have any generic framework for MIPI DSI
> > > > > based display controller? basically I wanted to know, how to go
> > > > > about
> > > > > porting CDF for such kind of display controller.
> > > >
> > > > MIPI DSI support is not available yet. The only reason for that is
> > > > that I don't have any MIPI DSI hardware to write and test the code
> > > > with :-)
> > > >
> > > > The common display framework should definitely support MIPI DSI. I
> > > > think the existing MIPI DBI code could be used as a base, so the
> > > > implementation shouldn't be too high.
> > > >
> > > > Yeah, i was also thinking in similar lines, below is my though for
> > > > MIPI DSI support in CDF.
> > >
> > > o MIPI DSI support as part of CDF framework will expose
> > > § mipi_dsi_register_device(mpi_device) (will be called
> > > mach-xxx-dt.c
> > > file )
> > > § mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
> > > from
> > > platform specific init driver call )
> > > · bus ops will be
> > > o read data
> > > o write data
> > > o write command
> > > § MIPI DSI will be registered as bus_register()
> > >
> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI)
> > > will
> > > initialize the MIPI DSI HW IP.
> > >
> > > This probe will also parse the DT file for MIPI DSI based panel, add
> > > the panel device (device_add() ) to kernel and register the display
> > > entity with its control and video ops with CDF.
> > >
> > > I can give this a try.
> >
> > I am currently in progress of reworking Exynos MIPI DSIM code and
> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I
> > have most of the work done, I have just to solve several remaining
> > problems.
> Do you already have code that you can publish ? I'm particularly
> interested (and I think Tomi Valkeinen would be as well) in looking at
> the DSI operations you expose to DSI sinks (panels, transceivers, ...).
Well, I'm afraid this might be little below your expectations, but here's
an initial RFC of the part defining just the DSI bus. I need a bit more
time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.
The implementation is very simple and heavily based on your MIPI DBI
support and existing Exynos MIPI DSIM framework. Provided operation set is
based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately
this is my only source of information about MIPI DSI.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001
From: Tomasz Figa <t.figa@samsung.com>
Date: Thu, 27 Dec 2012 12:36:15 +0100
Subject: [RFC] video: display: Add generic MIPI DSI bus
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
---
drivers/video/display/Kconfig | 4 +
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dsi-bus.c | 214
+++++++++++++++++++++++++++++++++++
include/video/display.h | 1 +
include/video/mipi-dsi-bus.h | 98 ++++++++++++++++
5 files changed, 318 insertions(+)
create mode 100644 drivers/video/display/mipi-dsi-bus.c
create mode 100644 include/video/mipi-dsi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 13b6aaf..dbaff9d 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI
tristate
default n
+config DISPLAY_MIPI_DSI
+ tristate
+ default n
+
config DISPLAY_PANEL_DPI
tristate "DPI (Parallel) Display Panels"
---help---
diff --git a/drivers/video/display/Makefile
b/drivers/video/display/Makefile
index 482bec7..429b3ac8 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DISPLAY_CORE) += display-core.o
obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
+obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-bus.o
obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/mipi-dsi-bus.c
b/drivers/video/display/mipi-dsi-bus.c
new file mode 100644
index 0000000..2998522
--- /dev/null
+++ b/drivers/video/display/mipi-dsi-bus.c
@@ -0,0 +1,214 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ * Contacts: Tomasz Figa <t.figa@samsung.com>
+ *
+ * Heavily based ond mipi-dbi-bus.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/pm.h>
+#include <linux/pm_runtime.h>
+
+#include <video/mipi-dsi-bus.h>
+
+/*
-----------------------------------------------------------------------------
+ * Bus operations
+ */
+
+int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd,
+ const unsigned char *buf, unsigned int len)
+{
+ return dev->bus->ops->write_command(dev->bus, dev, cmd, buf, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_write_command);
+
+int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd,
+ unsigned int addr, unsigned char *buf, unsigned int len)
+{
+ return dev->bus->ops->read_command(dev->bus, dev, cmd, addr, buf,
len);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_read_command);
+
+/*
-----------------------------------------------------------------------------
+ * Bus type
+ */
+
+static const struct mipi_dsi_device_id *
+mipi_dsi_match_id(const struct mipi_dsi_device_id *id,
+ struct mipi_dsi_device *dev)
+{
+ while (id->name[0]) {
+ if (strcmp(dev->name, id->name) = 0) {
+ dev->id_entry = id;
+ return id;
+ }
+ id++;
+ }
+ return NULL;
+}
+
+static int mipi_dsi_match(struct device *_dev, struct device_driver
*_drv)
+{
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_drv);
+
+ if (drv->id_table)
+ return mipi_dsi_match_id(drv->id_table, dev) != NULL;
+
+ return (strcmp(dev->name, _drv->name) = 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute
*a,
+ char *buf)
+{
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+ int len = snprintf(buf, PAGE_SIZE, MIPI_DSI_MODULE_PREFIX "%s\n",
+ dev->name);
+
+ return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute mipi_dsi_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL,
+};
+
+static int mipi_dsi_uevent(struct device *_dev, struct kobj_uevent_env
*env)
+{
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+
+ add_uevent_var(env, "MODALIAS=%s%s", MIPI_DSI_MODULE_PREFIX,
+ dev->name);
+ return 0;
+}
+
+static const struct dev_pm_ops mipi_dsi_dev_pm_ops = {
+ .runtime_suspend = pm_generic_runtime_suspend,
+ .runtime_resume = pm_generic_runtime_resume,
+ .runtime_idle = pm_generic_runtime_idle,
+ .suspend = pm_generic_suspend,
+ .resume = pm_generic_resume,
+ .freeze = pm_generic_freeze,
+ .thaw = pm_generic_thaw,
+ .poweroff = pm_generic_poweroff,
+ .restore = pm_generic_restore,
+};
+
+static struct bus_type mipi_dsi_bus_type = {
+ .name = "mipi-dsi",
+ .dev_attrs = mipi_dsi_dev_attrs,
+ .match = mipi_dsi_match,
+ .uevent = mipi_dsi_uevent,
+ .pm = &mipi_dsi_dev_pm_ops,
+};
+
+/*
-----------------------------------------------------------------------------
+ * Device and driver (un)registration
+ */
+
+/**
+ * mipi_dsi_device_register - register a DSI device
+ * @dev: DSI device we're registering
+ */
+int mipi_dsi_device_register(struct mipi_dsi_device *dev,
+ struct mipi_dsi_bus *bus)
+{
+ device_initialize(&dev->dev);
+
+ dev->bus = bus;
+ dev->dev.bus = &mipi_dsi_bus_type;
+ dev->dev.parent = bus->dev;
+
+ if (dev->id != -1)
+ dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id);
+ else
+ dev_set_name(&dev->dev, "%s", dev->name);
+
+ return device_add(&dev->dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_device_register);
+
+/**
+ * mipi_dsi_device_unregister - unregister a DSI device
+ * @dev: DSI device we're unregistering
+ */
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dev)
+{
+ device_del(&dev->dev);
+ put_device(&dev->dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_device_unregister);
+
+static int mipi_dsi_drv_probe(struct device *_dev)
+{
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver);
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+
+ return drv->probe(dev);
+}
+
+static int mipi_dsi_drv_remove(struct device *_dev)
+{
+ struct mipi_dsi_driver *drv = to_mipi_dsi_driver(_dev->driver);
+ struct mipi_dsi_device *dev = to_mipi_dsi_device(_dev);
+
+ return drv->remove(dev);
+}
+
+/**
+ * mipi_dsi_driver_register - register a driver for DSI devices
+ * @drv: DSI driver structure
+ */
+int mipi_dsi_driver_register(struct mipi_dsi_driver *drv)
+{
+ drv->driver.bus = &mipi_dsi_bus_type;
+ if (drv->probe)
+ drv->driver.probe = mipi_dsi_drv_probe;
+ if (drv->remove)
+ drv->driver.remove = mipi_dsi_drv_remove;
+
+ return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_driver_register);
+
+/**
+ * mipi_dsi_driver_unregister - unregister a driver for DSI devices
+ * @drv: DSI driver structure
+ */
+void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv)
+{
+ driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_driver_unregister);
+
+/*
-----------------------------------------------------------------------------
+ * Init/exit
+ */
+
+static int __init mipi_dsi_init(void)
+{
+ return bus_register(&mipi_dsi_bus_type);
+}
+
+static void __exit mipi_dsi_exit(void)
+{
+ bus_unregister(&mipi_dsi_bus_type);
+}
+
+module_init(mipi_dsi_init);
+module_exit(mipi_dsi_exit)
+
+MODULE_AUTHOR("Tomasz Figa <t.figa@samsung.com>");
+MODULE_DESCRIPTION("MIPI DSI Bus");
+MODULE_LICENSE("GPL");
diff --git a/include/video/display.h b/include/video/display.h
index 75ba270..f86ea6e 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -70,6 +70,7 @@ enum display_entity_stream_state {
enum display_entity_interface_type {
DISPLAY_ENTITY_INTERFACE_DPI,
DISPLAY_ENTITY_INTERFACE_DBI,
+ DISPLAY_ENTITY_INTERFACE_DSI,
};
struct display_entity_interface_params {
diff --git a/include/video/mipi-dsi-bus.h b/include/video/mipi-dsi-bus.h
new file mode 100644
index 0000000..3efcb39
--- /dev/null
+++ b/include/video/mipi-dsi-bus.h
@@ -0,0 +1,98 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ * Contacts: Tomasz Figa <t.figa@samsung.com>
+ *
+ * Heavily based ond mipi-dbi-bus.h.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MIPI_DSI_BUS_H__
+#define __MIPI_DSI_BUS_H__
+
+#include <linux/device.h>
+
+struct mipi_dsi_bus;
+struct mipi_dsi_device;
+
+struct mipi_dsi_bus_ops {
+ int (*write_command)(struct mipi_dsi_bus *bus,
+ struct mipi_dsi_device *dev, unsigned int cmd,
+ const unsigned char *buf, unsigned int len);
+ int (*read_command)(struct mipi_dsi_bus *bus,
+ struct mipi_dsi_device *dev, unsigned int cmd,
+ unsigned int addr, unsigned char *buf,
+ unsigned int len);
+};
+
+struct mipi_dsi_bus {
+ struct device *dev;
+ const struct mipi_dsi_bus_ops *ops;
+};
+
+#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"
+#define MIPI_DSI_NAME_SIZE 32
+
+struct mipi_dsi_device_id {
+ char name[MIPI_DSI_NAME_SIZE];
+ __kernel_ulong_t driver_data /* Data private to the driver */
+ __aligned(sizeof(__kernel_ulong_t));
+};
+
+struct mipi_dsi_device {
+ const char *name;
+ int id;
+ struct device dev;
+
+ const struct mipi_dsi_device_id *id_entry;
+ struct mipi_dsi_bus *bus;
+};
+
+#define to_mipi_dsi_device(d) container_of(d, struct mipi_dsi_device,
dev)
+
+int mipi_dsi_device_register(struct mipi_dsi_device *dev,
+ struct mipi_dsi_bus *bus);
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dev);
+
+struct mipi_dsi_driver {
+ int(*probe)(struct mipi_dsi_device *);
+ int(*remove)(struct mipi_dsi_device *);
+ struct device_driver driver;
+ const struct mipi_dsi_device_id *id_table;
+};
+
+#define to_mipi_dsi_driver(d) container_of(d, struct mipi_dsi_driver,
driver)
+
+int mipi_dsi_driver_register(struct mipi_dsi_driver *drv);
+void mipi_dsi_driver_unregister(struct mipi_dsi_driver *drv);
+
+static inline void *mipi_dsi_get_drvdata(const struct mipi_dsi_device
*dev)
+{
+ return dev_get_drvdata(&dev->dev);
+}
+
+static inline void mipi_dsi_set_drvdata(struct mipi_dsi_device *dev,
+ void *data)
+{
+ dev_set_drvdata(&dev->dev, data);
+}
+
+/* module_mipi_dsi_driver() - Helper macro for drivers that don't do
+ * anything special in module init/exit. This eliminates a lot of
+ * boilerplate. Each module may only use this macro once, and
+ * calling it replaces module_init() and module_exit()
+ */
+#define module_mipi_dsi_driver(__mipi_dsi_driver) \
+ module_driver(__mipi_dsi_driver, mipi_dsi_driver_register, \
+ mipi_dsi_driver_unregister)
+
+int mipi_dsi_write_command(struct mipi_dsi_device *dev, unsigned int cmd,
+ const unsigned char *buf, unsigned int len);
+int mipi_dsi_read_command(struct mipi_dsi_device *dev, unsigned int cmd,
+ unsigned int addr, unsigned char *buf, unsigned int len);
+
+#endif /* __MIPI_DSI_BUS__ */
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH fix-3.8] video: vt8500: Fix X crash when initializing framebuffer.
From: Florian Tobias Schandinat @ 2012-12-27 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356567943-3836-1-git-send-email-linux@prisktech.co.nz>
On 12/27/2012 12:25 AM, Tony Prisk wrote:
> This patch adds support for .fb_check_var which is required when
> X attempts to initialize the framebuffer. The only supported
> resolution is the native resolution of the LCD panel, so we test
> against the resolution supplied from the DT panel definition.
Nack. As far as I understand this driver behaves as it is supposed to do
according to drivers/video/skeletonfb.c. The frambuffer code seems to do
what is documented as well. If the X driver cannot cope with a different
var set than requested it needs to be fixed anyway as check_var is
always allowed to alter the parameters requested.
Strange, I thought I already saw X complaining about this when I added
30bpp mode to viafb.
Best regards,
Florian Tobias Schandinat
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> drivers/video/wm8505fb.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
> index 77539c1..c84e376 100644
> --- a/drivers/video/wm8505fb.c
> +++ b/drivers/video/wm8505fb.c
> @@ -41,10 +41,18 @@
>
> #define to_wm8505fb_info(__info) container_of(__info, \
> struct wm8505fb_info, fb)
> +
> +struct lcd_params {
> + u32 pixel_width;
> + u32 pixel_height;
> + u32 color_depth;
> +};
> +
> struct wm8505fb_info {
> struct fb_info fb;
> void __iomem *regbase;
> unsigned int contrast;
> + struct lcd_params lcd_params;
> };
>
>
> @@ -248,8 +256,21 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
> return 0;
> }
>
> +static int wm8505fb_check_var(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
> + struct wm8505fb_info *fbi = to_wm8505fb_info(info);
> + if (!fbi) return -EINVAL;
> +
> + if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
> + if (info->var.xres != fbi->lcd_params.pixel_width) return -EINVAL;
> + if (info->var.yres != fbi->lcd_params.pixel_height) return -EINVAL;
> + return 0;
> +}
> +
> static struct fb_ops wm8505fb_ops = {
> .owner = THIS_MODULE,
> + .fb_check_var = wm8505fb_check_var,
> .fb_set_par = wm8505fb_set_par,
> .fb_setcolreg = wm8505fb_setcolreg,
> .fb_fillrect = wmt_ge_fillrect,
> @@ -354,6 +375,10 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
> goto failed_free_res;
> }
>
> + fbi->lcd_params.pixel_width = of_mode.xres;
> + fbi->lcd_params.pixel_height = of_mode.yres;
> + fbi->lcd_params.color_depth = bpp;
> +
> of_mode.vmode = FB_VMODE_NONINTERLACED;
> fb_videomode_to_var(&fbi->fb.var, &of_mode);
>
^ permalink raw reply
* [PATCH fix-3.8] video: vt8500: Fix X crash when initializing framebuffer.
From: Tony Prisk @ 2012-12-27 0:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for .fb_check_var which is required when
X attempts to initialize the framebuffer. The only supported
resolution is the native resolution of the LCD panel, so we test
against the resolution supplied from the DT panel definition.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/video/wm8505fb.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 77539c1..c84e376 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -41,10 +41,18 @@
#define to_wm8505fb_info(__info) container_of(__info, \
struct wm8505fb_info, fb)
+
+struct lcd_params {
+ u32 pixel_width;
+ u32 pixel_height;
+ u32 color_depth;
+};
+
struct wm8505fb_info {
struct fb_info fb;
void __iomem *regbase;
unsigned int contrast;
+ struct lcd_params lcd_params;
};
@@ -248,8 +256,21 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
return 0;
}
+static int wm8505fb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ struct wm8505fb_info *fbi = to_wm8505fb_info(info);
+ if (!fbi) return -EINVAL;
+
+ if (info->var.bits_per_pixel != fbi->lcd_params.color_depth) return -EINVAL;
+ if (info->var.xres != fbi->lcd_params.pixel_width) return -EINVAL;
+ if (info->var.yres != fbi->lcd_params.pixel_height) return -EINVAL;
+ return 0;
+}
+
static struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
+ .fb_check_var = wm8505fb_check_var,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
.fb_fillrect = wmt_ge_fillrect,
@@ -354,6 +375,10 @@ static int __devinit wm8505fb_probe(struct platform_device *pdev)
goto failed_free_res;
}
+ fbi->lcd_params.pixel_width = of_mode.xres;
+ fbi->lcd_params.pixel_height = of_mode.yres;
+ fbi->lcd_params.color_depth = bpp;
+
of_mode.vmode = FB_VMODE_NONINTERLACED;
fb_videomode_to_var(&fbi->fb.var, &of_mode);
--
1.7.9.5
^ 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