* [PATCH] [trivial] radeon: Fix typo in radeon_gem.c
From: Masanari Iida @ 2012-02-27 14:28 UTC (permalink / raw)
To: benh, linux-fbdev; +Cc: trivial, linux-kernel, Masanari Iida
Correct spelling "withou" to "without" in
drivers/gpu/drm/radeon/radeon_gem.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
index 7337850..ff4ff23 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -117,7 +117,7 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
}
if (!domain) {
/* Do nothings */
- printk(KERN_WARNING "Set domain withou domain !\n");
+ printk(KERN_WARNING "Set domain without domain !\n");
return 0;
}
if (domain = RADEON_GEM_DOMAIN_CPU) {
--
1.7.9.2.262.gba998
^ permalink raw reply related
* [PATCH] video: s3c-fb: Add support EXYNOS5 FIMD
From: Jingoo Han @ 2012-02-28 7:55 UTC (permalink / raw)
To: linux-fbdev
This patch adds s3c_fb_driverdata s3c_fb_data_exynos5 for EXYNOS5
and adds extended timing control setting.
EXYNOS5 FIMD needs extended setting for video timing control.
Additional bits are added to VIDTCON2, VIDWxxADD2, VIDOSDxA and
VIDOSDxB registers in order to set timing value for lager resolution.
Also, address offset of VIDCONx registers is changed from 0x0
to 0x20000, thus variable type should be changed to int type
to handle the address offset of VIDCONx registers for EXYNOS5 FIMD.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/plat-samsung/include/plat/regs-fb.h | 24 ++++++++----
drivers/video/s3c-fb.c | 52 +++++++++++++++++++++++--
2 files changed, 63 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
index bbb16e0..9a78012 100644
--- a/arch/arm/plat-samsung/include/plat/regs-fb.h
+++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
@@ -167,15 +167,17 @@
#define VIDTCON1_HSPW(_x) ((_x) << 0)
#define VIDTCON2 (0x18)
+#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
#define VIDTCON2_LINEVAL_SHIFT (11)
#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
-#define VIDTCON2_LINEVAL(_x) ((_x) << 11)
+#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
+#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
#define VIDTCON2_HOZVAL_SHIFT (0)
#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
-#define VIDTCON2_HOZVAL(_x) ((_x) << 0)
+#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
/* WINCONx */
@@ -231,25 +233,29 @@
/* Local input channels (windows 0-2) */
#define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win)))
+#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_X(_x) ((_x) << 11)
+#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_Y(_x) ((_x) << 0)
+#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
+#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_X(_x) ((_x) << 11)
+#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_Y(_x) ((_x) << 0)
+#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
/* For VIDOSD[1..4]C */
#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
@@ -281,15 +287,17 @@
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
#define VIDW_BUF_SIZE(_buff) (0x100 + ((_buff) * 4))
+#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_OFFSET(_x) ((_x) << 13)
+#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
+#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_PAGEWIDTH(_x) ((_x) << 0)
+#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
/* Interrupt controls and status */
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 1fb7ddf..f310516 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -89,7 +89,7 @@ struct s3c_fb;
struct s3c_fb_variant {
unsigned int is_2443:1;
unsigned short nr_windows;
- unsigned short vidtcon;
+ unsigned int vidtcon;
unsigned short wincon;
unsigned short winmap;
unsigned short keycon;
@@ -568,7 +568,9 @@ static int s3c_fb_set_par(struct fb_info *info)
writel(data, regs + sfb->variant.vidtcon + 4);
data = VIDTCON2_LINEVAL(var->yres - 1) |
- VIDTCON2_HOZVAL(var->xres - 1);
+ VIDTCON2_HOZVAL(var->xres - 1) |
+ VIDTCON2_LINEVAL_E(var->yres - 1) |
+ VIDTCON2_HOZVAL_E(var->xres - 1);
writel(data, regs + sfb->variant.vidtcon + 8);
}
@@ -584,17 +586,23 @@ static int s3c_fb_set_par(struct fb_info *info)
pagewidth = (var->xres * var->bits_per_pixel) >> 3;
data = VIDW_BUF_SIZE_OFFSET(info->fix.line_length - pagewidth) |
- VIDW_BUF_SIZE_PAGEWIDTH(pagewidth);
+ VIDW_BUF_SIZE_PAGEWIDTH(pagewidth) |
+ VIDW_BUF_SIZE_OFFSET_E(info->fix.line_length - pagewidth) |
+ VIDW_BUF_SIZE_PAGEWIDTH_E(pagewidth);
writel(data, regs + sfb->variant.buf_size + (win_no * 4));
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0) |
+ VIDOSDxA_TOPLEFT_X_E(0) | VIDOSDxA_TOPLEFT_Y_E(0);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ VIDOSDxB_BOTRIGHT_Y(var->yres - 1) |
+ VIDOSDxB_BOTRIGHT_X_E(s3c_fb_align_word(var->bits_per_pixel,
+ var->xres - 1)) |
+ VIDOSDxB_BOTRIGHT_Y_E(var->yres - 1);
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -1903,6 +1911,37 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
.win[4] = &s3c_fb_data_s5p_wins[4],
};
+static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+ .has_shadowcon = 1,
+ .has_blendcon = 1,
+ .has_fixvclk = 1,
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+ .win[3] = &s3c_fb_data_s5p_wins[3],
+ .win[4] = &s3c_fb_data_s5p_wins[4],
+};
+
/* S3C2443/S3C2416 style hardware */
static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
.variant = {
@@ -1981,6 +2020,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "exynos4-fb",
.driver_data = (unsigned long)&s3c_fb_data_exynos4,
}, {
+ .name = "exynos5-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos5,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
}, {
--
1.7.1
^ permalink raw reply related
* PATCH V2] video: s3c-fb: Add support EXYNOS5 FIMD
From: Jingoo Han @ 2012-02-28 11:41 UTC (permalink / raw)
To: linux-fbdev
This patch adds s3c_fb_driverdata s3c_fb_data_exynos5 for EXYNOS5
and adds extended timing control setting.
EXYNOS5 FIMD needs extended setting for video timing control.
Additional bits are added to VIDTCON2, VIDWxxADD2, VIDOSDxA and
VIDOSDxB registers in order to set timing value for lager resolution.
Also, address offset of VIDTCONx registers is changed from 0x0
to 0x20000, thus variable type should be changed to int type
to handle the address offset of VIDTCONx registers for EXYNOS5 FIMD.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
v2: fix commit message from VIDCONx to VIDTCONx.
arch/arm/plat-samsung/include/plat/regs-fb.h | 24 ++++++++----
drivers/video/s3c-fb.c | 52 +++++++++++++++++++++++--
2 files changed, 63 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
index bbb16e0..9a78012 100644
--- a/arch/arm/plat-samsung/include/plat/regs-fb.h
+++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
@@ -167,15 +167,17 @@
#define VIDTCON1_HSPW(_x) ((_x) << 0)
#define VIDTCON2 (0x18)
+#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
#define VIDTCON2_LINEVAL_SHIFT (11)
#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
-#define VIDTCON2_LINEVAL(_x) ((_x) << 11)
+#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
+#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
#define VIDTCON2_HOZVAL_SHIFT (0)
#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
-#define VIDTCON2_HOZVAL(_x) ((_x) << 0)
+#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
/* WINCONx */
@@ -231,25 +233,29 @@
/* Local input channels (windows 0-2) */
#define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win)))
+#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_X(_x) ((_x) << 11)
+#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_Y(_x) ((_x) << 0)
+#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
+#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_X(_x) ((_x) << 11)
+#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_Y(_x) ((_x) << 0)
+#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
/* For VIDOSD[1..4]C */
#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
@@ -281,15 +287,17 @@
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
#define VIDW_BUF_SIZE(_buff) (0x100 + ((_buff) * 4))
+#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_OFFSET(_x) ((_x) << 13)
+#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
+#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_PAGEWIDTH(_x) ((_x) << 0)
+#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
/* Interrupt controls and status */
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 1fb7ddf..f310516 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -89,7 +89,7 @@ struct s3c_fb;
struct s3c_fb_variant {
unsigned int is_2443:1;
unsigned short nr_windows;
- unsigned short vidtcon;
+ unsigned int vidtcon;
unsigned short wincon;
unsigned short winmap;
unsigned short keycon;
@@ -568,7 +568,9 @@ static int s3c_fb_set_par(struct fb_info *info)
writel(data, regs + sfb->variant.vidtcon + 4);
data = VIDTCON2_LINEVAL(var->yres - 1) |
- VIDTCON2_HOZVAL(var->xres - 1);
+ VIDTCON2_HOZVAL(var->xres - 1) |
+ VIDTCON2_LINEVAL_E(var->yres - 1) |
+ VIDTCON2_HOZVAL_E(var->xres - 1);
writel(data, regs + sfb->variant.vidtcon + 8);
}
@@ -584,17 +586,23 @@ static int s3c_fb_set_par(struct fb_info *info)
pagewidth = (var->xres * var->bits_per_pixel) >> 3;
data = VIDW_BUF_SIZE_OFFSET(info->fix.line_length - pagewidth) |
- VIDW_BUF_SIZE_PAGEWIDTH(pagewidth);
+ VIDW_BUF_SIZE_PAGEWIDTH(pagewidth) |
+ VIDW_BUF_SIZE_OFFSET_E(info->fix.line_length - pagewidth) |
+ VIDW_BUF_SIZE_PAGEWIDTH_E(pagewidth);
writel(data, regs + sfb->variant.buf_size + (win_no * 4));
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0) |
+ VIDOSDxA_TOPLEFT_X_E(0) | VIDOSDxA_TOPLEFT_Y_E(0);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ VIDOSDxB_BOTRIGHT_Y(var->yres - 1) |
+ VIDOSDxB_BOTRIGHT_X_E(s3c_fb_align_word(var->bits_per_pixel,
+ var->xres - 1)) |
+ VIDOSDxB_BOTRIGHT_Y_E(var->yres - 1);
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -1903,6 +1911,37 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
.win[4] = &s3c_fb_data_s5p_wins[4],
};
+static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+ .has_shadowcon = 1,
+ .has_blendcon = 1,
+ .has_fixvclk = 1,
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+ .win[3] = &s3c_fb_data_s5p_wins[3],
+ .win[4] = &s3c_fb_data_s5p_wins[4],
+};
+
/* S3C2443/S3C2416 style hardware */
static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
.variant = {
@@ -1981,6 +2020,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "exynos4-fb",
.driver_data = (unsigned long)&s3c_fb_data_exynos4,
}, {
+ .name = "exynos5-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos5,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
}, {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] drivers/video/pxa168fb.c: use devm_ functions
From: Florian Tobias Schandinat @ 2012-02-28 15:54 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1329589169-18235-1-git-send-email-Julia.Lawall@lip6.fr>
On 02/18/2012 06:19 PM, Julia Lawall wrote:
> 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.
>
> By using devm_ioremap, it also removes a potential memory leak, because
> there was no call to iounmap in the probe function.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> drivers/video/pxa168fb.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
> index 8384b94..f146089 100644
> --- a/drivers/video/pxa168fb.c
> +++ b/drivers/video/pxa168fb.c
> @@ -21,6 +21,7 @@
> #include <linux/fb.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> +#include <linux/io.h>
> #include <linux/ioport.h>
> #include <linux/platform_device.h>
> #include <linux/dma-mapping.h>
> @@ -670,7 +671,8 @@ static int __devinit pxa168fb_probe(struct platform_device *pdev)
> /*
> * Map LCD controller registers.
> */
> - fbi->reg_base = ioremap_nocache(res->start, resource_size(res));
> + fbi->reg_base = devm_ioremap_nocache(&pdev->dev, res->start,
> + resource_size(res));
> if (fbi->reg_base = NULL) {
> ret = -ENOMEM;
> goto failed_free_info;
> @@ -739,8 +741,8 @@ static int __devinit pxa168fb_probe(struct platform_device *pdev)
> /*
> * Register irq handler.
> */
> - ret = request_irq(irq, pxa168fb_handle_irq, IRQF_SHARED,
> - info->fix.id, fbi);
> + ret = devm_request_irq(&pdev->dev, irq, pxa168fb_handle_irq,
> + IRQF_SHARED, info->fix.id, fbi);
> if (ret < 0) {
> dev_err(&pdev->dev, "unable to request IRQ\n");
> ret = -ENXIO;
> @@ -759,14 +761,12 @@ static int __devinit pxa168fb_probe(struct platform_device *pdev)
> if (ret < 0) {
> dev_err(&pdev->dev, "Failed to register pxa168-fb: %d\n", ret);
> ret = -ENXIO;
> - goto failed_free_irq;
> + goto failed_free_cmap;
> }
>
> platform_set_drvdata(pdev, fbi);
> return 0;
>
> -failed_free_irq:
> - free_irq(irq, fbi);
> failed_free_cmap:
> fb_dealloc_cmap(&info->cmap);
> failed_free_clk:
> @@ -808,13 +808,10 @@ static int __devexit pxa168fb_remove(struct platform_device *pdev)
> fb_dealloc_cmap(&info->cmap);
>
> irq = platform_get_irq(pdev, 0);
> - free_irq(irq, fbi);
>
> dma_free_writecombine(fbi->dev, PAGE_ALIGN(info->fix.smem_len),
> info->screen_base, info->fix.smem_start);
>
> - iounmap(fbi->reg_base);
> -
> clk_disable(fbi->clk);
> clk_put(fbi->clk);
>
>
>
^ permalink raw reply
* Re: [PATCH] video: s3c-fb: use devm_request_irq()
From: Florian Tobias Schandinat @ 2012-02-28 15:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <017101ccefbc$0ab90710$202b1530$%han@samsung.com>
On 02/20/2012 10:40 AM, Jingoo Han wrote:
> The devm_ functions allocate memory that is released when a driver
> detaches. This patch uses devm_request_irq of these functions.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index e22bf9d..1fb7ddf 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1433,7 +1433,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> goto err_lcd_clk;
> }
> sfb->irq_no = res->start;
> - ret = request_irq(sfb->irq_no, s3c_fb_irq,
> + ret = devm_request_irq(dev, sfb->irq_no, s3c_fb_irq,
> 0, "s3c_fb", sfb);
> if (ret) {
> dev_err(dev, "irq request failed\n");
> @@ -1499,7 +1499,6 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>
> err_pm_runtime:
> pm_runtime_put_sync(sfb->dev);
> - free_irq(sfb->irq_no, sfb);
>
> err_lcd_clk:
> pm_runtime_disable(sfb->dev);
> @@ -1535,8 +1534,6 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
> if (sfb->windows[win])
> s3c_fb_release_win(sfb, sfb->windows[win]);
>
> - free_irq(sfb->irq_no, sfb);
> -
> if (!sfb->variant.has_clksel) {
> clk_disable(sfb->lcd_clk);
> clk_put(sfb->lcd_clk);
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Florian Tobias Schandinat @ 2012-02-28 16:03 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev@vger.kernel.org, linux-omap mailing list
In-Reply-To: <1329988974.1820.62.camel@deskari>
On 02/23/2012 09:22 AM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Two fixes for OMAP DSS for 3.3:
>
> First one gets the HDMI output working again. Managing the clocks for
> OMAP4 is not very simple, and this patch circumvents the problems we
> have in the clock framework. It's a clean but rather hacky fix, but it
> shouldn't cause any side-effects. The issue will hopefully be fixed
> properly with DT when we'll get proper parent-child hierarchy for DSS HW
> submodules.
>
> The second one is a simple fix for HDMI hotplug detection, which I
> missed when I wrote the HDMI PHY fix
> (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd).
Merged. You would add
Cc: stable@vger.kernel.org
to patches if appropriate?
Thanks,
Florian Tobias Schandinat
>
> Tomi
>
> The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
>
> Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)
>
> are available in the git repository at:
> git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc
>
> Archit Taneja (1):
> OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
>
> Rob Clark (1):
> OMAPDSS: HDMI: hot plug detect fix
>
> drivers/video/omap2/dss/hdmi.c | 24 +++++++++++++++++++++++-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 9 +--------
> 2 files changed, 24 insertions(+), 9 deletions(-)
>
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Tomi Valkeinen @ 2012-02-28 16:08 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev@vger.kernel.org, linux-omap mailing list
In-Reply-To: <4F4CFAD1.1000301@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
On Tue, 2012-02-28 at 16:03 +0000, Florian Tobias Schandinat wrote:
> On 02/23/2012 09:22 AM, Tomi Valkeinen wrote:
> > Hi Florian,
> >
> > Two fixes for OMAP DSS for 3.3:
> >
> > First one gets the HDMI output working again. Managing the clocks for
> > OMAP4 is not very simple, and this patch circumvents the problems we
> > have in the clock framework. It's a clean but rather hacky fix, but it
> > shouldn't cause any side-effects. The issue will hopefully be fixed
> > properly with DT when we'll get proper parent-child hierarchy for DSS HW
> > submodules.
> >
> > The second one is a simple fix for HDMI hotplug detection, which I
> > missed when I wrote the HDMI PHY fix
> > (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd).
>
> Merged. You would add
> Cc: stable@vger.kernel.org
> to patches if appropriate?
Thanks. Yes, I have sent a separate mail to stable list, as the patches
needed some tuning to apply.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Florian Tobias Schandinat @ 2012-02-28 16:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1329983601-25335-1-git-send-email-olivier@sobrie.be>
[Cc'ing Bernie Thompson, the udlfb maintainer]
@Bernie: Why don't you add an entry for it in MAINTAINERS?
On 02/23/2012 07:53 AM, Olivier Sobrie wrote:
> Return a negative errno instead of zero in the write function of
> the sysfs entry in case of error.
> Also add a check on the return value of dlfb_setup_modes().
>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> ---
> drivers/video/udlfb.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index a197731..abbc3fe 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1427,19 +1427,22 @@ static ssize_t edid_store(
> struct device *fbdev = container_of(kobj, struct device, kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dev = fb_info->par;
> + int ret;
>
> /* We only support write of entire EDID at once, no offset*/
> if ((src_size != EDID_LENGTH) || (src_off != 0))
> - return 0;
> + return -EINVAL;
>
> - dlfb_setup_modes(dev, fb_info, src, src_size);
> + ret = dlfb_setup_modes(dev, fb_info, src, src_size);
> + if (ret)
> + return ret;
>
> if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
> pr_info("sysfs written EDID is new default\n");
> dlfb_ops_set_par(fb_info);
> return src_size;
> } else
> - return 0;
> + return -EINVAL;
> }
>
> static ssize_t metrics_reset_store(struct device *fbdev,
^ permalink raw reply
* RE: [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Jingoo Han @ 2012-02-29 1:18 UTC (permalink / raw)
To: 'Florian Tobias Schandinat', 'Tomi Valkeinen'
Cc: linux-fbdev, 'linux-omap mailing list'
In-Reply-To: <4F4CFAD1.1000301@gmx.de>
Hi.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-owner@vger.kernel.org] On Behalf Of Florian
> Tobias Schandinat
> Sent: Wednesday, February 29, 2012 1:03 AM
> To: Tomi Valkeinen
> Cc: linux-fbdev@vger.kernel.org; linux-omap mailing list
> Subject: Re: [GIT PULL] OMAP DSS fixes for 3.3-rc
>
> On 02/23/2012 09:22 AM, Tomi Valkeinen wrote:
> > Hi Florian,
> >
> > Two fixes for OMAP DSS for 3.3:
> >
> > First one gets the HDMI output working again. Managing the clocks for
> > OMAP4 is not very simple, and this patch circumvents the problems we
> > have in the clock framework. It's a clean but rather hacky fix, but it
> > shouldn't cause any side-effects. The issue will hopefully be fixed
> > properly with DT when we'll get proper parent-child hierarchy for DSS HW
> > submodules.
> >
> > The second one is a simple fix for HDMI hotplug detection, which I
> > missed when I wrote the HDMI PHY fix
> > (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd).
>
> Merged. You would add
> Cc: stable@vger.kernel.org
> to patches if appropriate?
I agree on Florian's opinion.
It would be good to add this patch to stable kernel. :)
>
>
> Thanks,
>
> Florian Tobias Schandinat
>
> >
> > Tomi
> >
> > The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
> >
> > Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)
> >
> > are available in the git repository at:
> > git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc
> >
> > Archit Taneja (1):
> > OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
> >
> > Rob Clark (1):
> > OMAPDSS: HDMI: hot plug detect fix
> >
> > drivers/video/omap2/dss/hdmi.c | 24 +++++++++++++++++++++++-
> > drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 9 +--------
> > 2 files changed, 24 insertions(+), 9 deletions(-)
> >
>
> --
> 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] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Jingoo Han @ 2012-02-29 1:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1329983601-25335-1-git-send-email-olivier@sobrie.be>
Hi.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-owner@vger.kernel.org] On Behalf Of Florian
> Tobias Schandinat
> Sent: Wednesday, February 29, 2012 1:14 AM
> To: Olivier Sobrie
> Cc: linux-fbdev@vger.kernel.org; Bernie Thompson
> Subject: Re: [PATCH] udlfb: Fix invalid return codes in edid sysfs entry store function
>
> [Cc'ing Bernie Thompson, the udlfb maintainer]
> @Bernie: Why don't you add an entry for it in MAINTAINERS?
I think so, too. :)
Bernie, it would be good to add you to MAINTAINERS as udlfb maintainer.
>
> On 02/23/2012 07:53 AM, Olivier Sobrie wrote:
> > Return a negative errno instead of zero in the write function of
> > the sysfs entry in case of error.
> > Also add a check on the return value of dlfb_setup_modes().
> >
> > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
> > ---
> > drivers/video/udlfb.c | 9 ++++++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> > index a197731..abbc3fe 100644
> > --- a/drivers/video/udlfb.c
> > +++ b/drivers/video/udlfb.c
> > @@ -1427,19 +1427,22 @@ static ssize_t edid_store(
> > struct device *fbdev = container_of(kobj, struct device, kobj);
> > struct fb_info *fb_info = dev_get_drvdata(fbdev);
> > struct dlfb_data *dev = fb_info->par;
> > + int ret;
> >
> > /* We only support write of entire EDID at once, no offset*/
> > if ((src_size != EDID_LENGTH) || (src_off != 0))
> > - return 0;
> > + return -EINVAL;
> >
> > - dlfb_setup_modes(dev, fb_info, src, src_size);
> > + ret = dlfb_setup_modes(dev, fb_info, src, src_size);
> > + if (ret)
> > + return ret;
> >
> > if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
> > pr_info("sysfs written EDID is new default\n");
> > dlfb_ops_set_par(fb_info);
> > return src_size;
> > } else
> > - return 0;
> > + return -EINVAL;
How about this? According to the coding style, it is more desirable to use braces.
Sorry for nitpicking. :)
- } else
- return 0;
+ } else {
+ return -EINVAL;
+ }
> > }
> >
> > static ssize_t metrics_reset_store(struct device *fbdev,
>
> --
> 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: [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Jingoo Han @ 2012-02-29 1:42 UTC (permalink / raw)
To: 'Tomi Valkeinen', 'Florian Tobias Schandinat'
Cc: linux-fbdev, 'linux-omap mailing list'
In-Reply-To: <1330445287.2123.236.camel@deskari>
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-owner@vger.kernel.org] On Behalf Of Tomi
> Valkeinen
> Sent: Wednesday, February 29, 2012 1:08 AM
> To: Florian Tobias Schandinat
> Cc: linux-fbdev@vger.kernel.org; linux-omap mailing list
> Subject: Re: [GIT PULL] OMAP DSS fixes for 3.3-rc
>
> On Tue, 2012-02-28 at 16:03 +0000, Florian Tobias Schandinat wrote:
> > On 02/23/2012 09:22 AM, Tomi Valkeinen wrote:
> > > Hi Florian,
> > >
> > > Two fixes for OMAP DSS for 3.3:
> > >
> > > First one gets the HDMI output working again. Managing the clocks for
> > > OMAP4 is not very simple, and this patch circumvents the problems we
> > > have in the clock framework. It's a clean but rather hacky fix, but it
> > > shouldn't cause any side-effects. The issue will hopefully be fixed
> > > properly with DT when we'll get proper parent-child hierarchy for DSS HW
> > > submodules.
> > >
> > > The second one is a simple fix for HDMI hotplug detection, which I
> > > missed when I wrote the HDMI PHY fix
> > > (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd).
> >
> > Merged. You would add
> > Cc: stable@vger.kernel.org
> > to patches if appropriate?
>
> Thanks. Yes, I have sent a separate mail to stable list, as the patches
> needed some tuning to apply.
Tomi, sorry.
You have already sent a mail to stable@vger.kernel.org.
Good luck.
Best regards,
Jingoo Han
>
> Tomi
^ permalink raw reply
* [PATCH v2] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Olivier Sobrie @ 2012-02-29 7:06 UTC (permalink / raw)
To: linux-fbdev
Return a negative errno instead of zero in the write function of
the sysfs entry in case of error.
Also add a check on the return value of dlfb_setup_modes().
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
---
drivers/video/udlfb.c | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index a197731..bfd2a56 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1427,19 +1427,22 @@ static ssize_t edid_store(
struct device *fbdev = container_of(kobj, struct device, kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dev = fb_info->par;
+ int ret;
/* We only support write of entire EDID at once, no offset*/
if ((src_size != EDID_LENGTH) || (src_off != 0))
- return 0;
+ return -EINVAL;
- dlfb_setup_modes(dev, fb_info, src, src_size);
+ ret = dlfb_setup_modes(dev, fb_info, src, src_size);
+ if (ret)
+ return ret;
- if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
- pr_info("sysfs written EDID is new default\n");
- dlfb_ops_set_par(fb_info);
- return src_size;
- } else
- return 0;
+ if (!dev->edid || memcmp(src, dev->edid, src_size))
+ return -EINVAL;
+
+ pr_info("sysfs written EDID is new default\n");
+ dlfb_ops_set_par(fb_info);
+ return src_size;
}
static ssize_t metrics_reset_store(struct device *fbdev,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
Hi,
Two small fixes for omapdss.
Florian, if the patches are ok, I guess it's easier if you just apply these
patches from email, instead of me sending a pull request?
Tomi
Tomi Valkeinen (2):
OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
OMAPDSS: APPLY: make ovl_enable/disable synchronous
drivers/video/omap2/displays/Kconfig | 2 +-
drivers/video/omap2/dss/apply.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
index 74d29b5..408a992 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
config PANEL_DVI
tristate "DVI output"
- depends on OMAP2_DSS_DPI
+ depends on OMAP2_DSS_DPI && I2C
help
Driver for external monitors, connected via DVI. The driver uses i2c
to read EDID information from the monitor.
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Tomi Valkeinen @ 2012-02-29 8:48 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-omap; +Cc: Tomi Valkeinen
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
ovl->enable/disable are meant to be synchronous so that they can handle
the configuration of fifo sizes. The current kernel doesn't configure
fifo sizes yet, and so the code doesn't need to block to function (from
omapdss driver's perspective).
However, for the users of omapdss a non-blocking ovl->disable is
confusing, because they don't know when the memory area is not used
any more.
Furthermore, when the fifo size configuration is added in the next merge
window, the change from non-blocking to blocking could cause side
effects to the users of omapdss. So by making the functions block
already will keep them behaving in the same manner.
And, while not the main purpose of this patch, this will also remove the
compile warning:
drivers/video/omap2/dss/apply.c:350: warning:
'wait_pending_extra_info_updates' defined but not used
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/apply.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 052dc87..87b3e25 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1276,6 +1276,9 @@ int dss_ovl_enable(struct omap_overlay *ovl)
spin_unlock_irqrestore(&data_lock, flags);
+ /* wait for overlay to be enabled */
+ wait_pending_extra_info_updates();
+
mutex_unlock(&apply_lock);
return 0;
@@ -1313,6 +1316,9 @@ int dss_ovl_disable(struct omap_overlay *ovl)
spin_unlock_irqrestore(&data_lock, flags);
+ /* wait for the overlay to be disabled */
+ wait_pending_extra_info_updates();
+
mutex_unlock(&apply_lock);
return 0;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc
From: Florian Tobias Schandinat @ 2012-02-29 9:56 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> Hi,
>
> Two small fixes for omapdss.
>
> Florian, if the patches are ok, I guess it's easier if you just apply these
> patches from email, instead of me sending a pull request?
Yes, that's correct as those are only a few patches and as we are already in
late -rc's (and therefore I guess, I should take a better look at what I apply).
I'll add some comments to your patches in separate mails.
Best regards,
Florian Tobias Schandinat
>
> Tomi
>
> Tomi Valkeinen (2):
> OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
> OMAPDSS: APPLY: make ovl_enable/disable synchronous
>
> drivers/video/omap2/displays/Kconfig | 2 +-
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Florian Tobias Schandinat @ 2012-02-29 10:03 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-2-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
> it.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/displays/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
> index 74d29b5..408a992 100644
> --- a/drivers/video/omap2/displays/Kconfig
> +++ b/drivers/video/omap2/displays/Kconfig
> @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
>
> config PANEL_DVI
> tristate "DVI output"
> - depends on OMAP2_DSS_DPI
> + depends on OMAP2_DSS_DPI && I2C
It's just a matter of taste, but are you sure you want to "depend" on it and not
"select" it? Other drivers tend to use select for I2C, for me it doesn't really
matter.
Best regards,
Florian Tobias Schandinat
> help
> Driver for external monitors, connected via DVI. The driver uses i2c
> to read EDID information from the monitor.
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Florian Tobias Schandinat @ 2012-02-29 10:13 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-3-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> ovl->enable/disable are meant to be synchronous so that they can handle
> the configuration of fifo sizes. The current kernel doesn't configure
> fifo sizes yet, and so the code doesn't need to block to function (from
> omapdss driver's perspective).
>
> However, for the users of omapdss a non-blocking ovl->disable is
> confusing, because they don't know when the memory area is not used
> any more.
>
> Furthermore, when the fifo size configuration is added in the next merge
> window, the change from non-blocking to blocking could cause side
> effects to the users of omapdss. So by making the functions block
> already will keep them behaving in the same manner.
Is there any difference to doing it now?
I agree that this should be fixed but if we can't avoid breaking users I'd
prefer to break them in a merge window not in late rc stage. Or did we introduce
these functions just in the last merge window?
Best regards,
Florian Tobias Schandinat
>
> And, while not the main purpose of this patch, this will also remove the
> compile warning:
>
> drivers/video/omap2/dss/apply.c:350: warning:
> 'wait_pending_extra_info_updates' defined but not used
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 052dc87..87b3e25 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1276,6 +1276,9 @@ int dss_ovl_enable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for overlay to be enabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
> @@ -1313,6 +1316,9 @@ int dss_ovl_disable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for the overlay to be disabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Tomi Valkeinen @ 2012-02-29 10:21 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-omap
In-Reply-To: <4F4DF801.3000905@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On Wed, 2012-02-29 at 10:03 +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> > panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
> > it.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> > drivers/video/omap2/displays/Kconfig | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
> > index 74d29b5..408a992 100644
> > --- a/drivers/video/omap2/displays/Kconfig
> > +++ b/drivers/video/omap2/displays/Kconfig
> > @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
> >
> > config PANEL_DVI
> > tristate "DVI output"
> > - depends on OMAP2_DSS_DPI
> > + depends on OMAP2_DSS_DPI && I2C
>
> It's just a matter of taste, but are you sure you want to "depend" on it and not
> "select" it? Other drivers tend to use select for I2C, for me it doesn't really
> matter.
Well, I'd like to "select", but I don't think that's correct. From
Documentation/kbuild/kconfig-language.txt:
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
But I do see quite many selects for I2C, so I'm not sure if all those
are wrong, or has it just been decided that I2C is a valid target for
select.
Using depend is in line with the other panel drivers in the same
directory. I've been thinking about the same thing from time to time,
and I'd rather select I2C, SPI and BACKLIGHT_CLASS_DEVICE than use
depend.
But, for example, using select to BACKLIGHT_CLASS_DEVICE is broken: if I
change a panel driver to select BACKLIGHT_CLASS_DEVICE, but then I
manually disable CONFIG_BACKLIGHT_LCD_SUPPORT (which the
BACKLIGHT_CLASS_DEVICE depends on) from the kernel config, this leads to
BACKLIGHT_CLASS_DEVICE being enabled, but CONFIG_BACKLIGHT_LCD_SUPPORT
being disabled, which is clearly broken.
So... As I see it, depending is a bit awkward, but it's correct.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Tomi Valkeinen @ 2012-02-29 10:30 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-omap, Rob Clark
In-Reply-To: <4F4DFA30.2040503@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> > ovl->enable/disable are meant to be synchronous so that they can handle
> > the configuration of fifo sizes. The current kernel doesn't configure
> > fifo sizes yet, and so the code doesn't need to block to function (from
> > omapdss driver's perspective).
> >
> > However, for the users of omapdss a non-blocking ovl->disable is
> > confusing, because they don't know when the memory area is not used
> > any more.
> >
> > Furthermore, when the fifo size configuration is added in the next merge
> > window, the change from non-blocking to blocking could cause side
> > effects to the users of omapdss. So by making the functions block
> > already will keep them behaving in the same manner.
>
> Is there any difference to doing it now?
> I agree that this should be fixed but if we can't avoid breaking users I'd
> prefer to break them in a merge window not in late rc stage. Or did we introduce
> these functions just in the last merge window?
Yes, these were introduced in the merge window. And I explicitly said
the functions are blocking so that they can perform their job. And just
to clarify, the functions already use a mutex, so in that sense they are
blocking. They just don't currently wait until the HW has finished with
the overlay.
The problem was raised by Rob Clark, who's writing the omapdrm driver,
as he doesn't have a way to ensure that the overlay has been truly
disabled and the memory is is no longer in use.
(I forgot to cc him for the patch, adding him now).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Florian Tobias Schandinat @ 2012-02-29 10:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, Rob Clark
In-Reply-To: <1330511438.1934.95.camel@deskari>
Hi Tomi,
On 02/29/2012 10:30 AM, Tomi Valkeinen wrote:
> On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>> ovl->enable/disable are meant to be synchronous so that they can handle
>>> the configuration of fifo sizes. The current kernel doesn't configure
>>> fifo sizes yet, and so the code doesn't need to block to function (from
>>> omapdss driver's perspective).
>>>
>>> However, for the users of omapdss a non-blocking ovl->disable is
>>> confusing, because they don't know when the memory area is not used
>>> any more.
>>>
>>> Furthermore, when the fifo size configuration is added in the next merge
>>> window, the change from non-blocking to blocking could cause side
>>> effects to the users of omapdss. So by making the functions block
>>> already will keep them behaving in the same manner.
>>
>> Is there any difference to doing it now?
>> I agree that this should be fixed but if we can't avoid breaking users I'd
>> prefer to break them in a merge window not in late rc stage. Or did we introduce
>> these functions just in the last merge window?
>
> Yes, these were introduced in the merge window. And I explicitly said
> the functions are blocking so that they can perform their job. And just
> to clarify, the functions already use a mutex, so in that sense they are
> blocking. They just don't currently wait until the HW has finished with
> the overlay.
okay, than I'll apply this patch as is. I was just worried about asking Linus to
pull something that is labled as "Breaks existing users" now, but that doesn't
look like an issue here.
Best regards,
Florian Tobias Schandinat
>
> The problem was raised by Rob Clark, who's writing the omapdrm driver,
> as he doesn't have a way to ensure that the overlay has been truly
> disabled and the memory is is no longer in use.
>
> (I forgot to cc him for the patch, adding him now).
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
From: Florian Tobias Schandinat @ 2012-02-29 11:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330510902.1934.76.camel@deskari>
Hi Tomi,
On 02/29/2012 10:21 AM, Tomi Valkeinen wrote:
> On Wed, 2012-02-29 at 10:03 +0000, Florian Tobias Schandinat wrote:
>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>> panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
>>> it.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/displays/Kconfig | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig
>>> index 74d29b5..408a992 100644
>>> --- a/drivers/video/omap2/displays/Kconfig
>>> +++ b/drivers/video/omap2/displays/Kconfig
>>> @@ -12,7 +12,7 @@ config PANEL_GENERIC_DPI
>>>
>>> config PANEL_DVI
>>> tristate "DVI output"
>>> - depends on OMAP2_DSS_DPI
>>> + depends on OMAP2_DSS_DPI && I2C
>>
>> It's just a matter of taste, but are you sure you want to "depend" on it and not
>> "select" it? Other drivers tend to use select for I2C, for me it doesn't really
>> matter.
>
> Well, I'd like to "select", but I don't think that's correct. From
> Documentation/kbuild/kconfig-language.txt:
>
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
>
> But I do see quite many selects for I2C, so I'm not sure if all those
> are wrong, or has it just been decided that I2C is a valid target for
> select.
I'd say that the above is only a guideline but not absolute rule. For I2C I'd
argue that I probably wouldn't even know that my hardware has it if I weren't
the one writing the driver using it.
But it's true that select should be used with care as it is much easier to get
the config messed up by using it.
> Using depend is in line with the other panel drivers in the same
> directory. I've been thinking about the same thing from time to time,
> and I'd rather select I2C, SPI and BACKLIGHT_CLASS_DEVICE than use
> depend.
>
> But, for example, using select to BACKLIGHT_CLASS_DEVICE is broken: if I
> change a panel driver to select BACKLIGHT_CLASS_DEVICE, but then I
> manually disable CONFIG_BACKLIGHT_LCD_SUPPORT (which the
> BACKLIGHT_CLASS_DEVICE depends on) from the kernel config, this leads to
> BACKLIGHT_CLASS_DEVICE being enabled, but CONFIG_BACKLIGHT_LCD_SUPPORT
> being disabled, which is clearly broken.
Yes, as far as I understand the problem here is that we don't have any mechanism
to handle transitive dependencies (probably because we don't want it). So if one
wants to do select something I think the right way to do it would be to inherit
all its select/depend statements in the option.
> So... As I see it, depending is a bit awkward, but it's correct.
Yes, it certainly is correct.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
From: Rob Clark @ 2012-02-29 14:52 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Tomi Valkeinen, linux-fbdev, linux-omap
In-Reply-To: <4F4E0294.6000406@gmx.de>
On Wed, Feb 29, 2012 at 4:48 AM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi Tomi,
>
> On 02/29/2012 10:30 AM, Tomi Valkeinen wrote:
>> On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
>>> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
>>>> ovl->enable/disable are meant to be synchronous so that they can handle
>>>> the configuration of fifo sizes. The current kernel doesn't configure
>>>> fifo sizes yet, and so the code doesn't need to block to function (from
>>>> omapdss driver's perspective).
>>>>
>>>> However, for the users of omapdss a non-blocking ovl->disable is
>>>> confusing, because they don't know when the memory area is not used
>>>> any more.
>>>>
>>>> Furthermore, when the fifo size configuration is added in the next merge
>>>> window, the change from non-blocking to blocking could cause side
>>>> effects to the users of omapdss. So by making the functions block
>>>> already will keep them behaving in the same manner.
>>>
>>> Is there any difference to doing it now?
>>> I agree that this should be fixed but if we can't avoid breaking users I'd
>>> prefer to break them in a merge window not in late rc stage. Or did we introduce
>>> these functions just in the last merge window?
>>
>> Yes, these were introduced in the merge window. And I explicitly said
>> the functions are blocking so that they can perform their job. And just
>> to clarify, the functions already use a mutex, so in that sense they are
>> blocking. They just don't currently wait until the HW has finished with
>> the overlay.
>
> okay, than I'll apply this patch as is. I was just worried about asking Linus to
> pull something that is labled as "Breaks existing users" now, but that doesn't
> look like an issue here.
>
I don't expect this change should break any existing users.. I think
it is safe to call this a bug fix
BR,
-R
> Best regards,
>
> Florian Tobias Schandinat
>
>>
>> The problem was raised by Rob Clark, who's writing the omapdrm driver,
>> as he doesn't have a way to ensure that the overlay has been truly
>> disabled and the memory is is no longer in use.
>>
>> (I forgot to cc him for the patch, adding him now).
>>
>> Tomi
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc
From: Florian Tobias Schandinat @ 2012-03-01 5:38 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1330505302-8258-1-git-send-email-tomi.valkeinen@ti.com>
On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> Hi,
>
> Two small fixes for omapdss.
Applied both.
Thanks,
Florian Tobias Schandinat
>
> Florian, if the patches are ok, I guess it's easier if you just apply these
> patches from email, instead of me sending a pull request?
>
> Tomi
>
> Tomi Valkeinen (2):
> OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
> OMAPDSS: APPLY: make ovl_enable/disable synchronous
>
> drivers/video/omap2/displays/Kconfig | 2 +-
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
^ permalink raw reply
* [PATCH 0/7] OMAPDSS: HDMI PHY burnout fix for 3.2 stable
From: Tomi Valkeinen @ 2012-03-01 12:26 UTC (permalink / raw)
To: stable; +Cc: linux-fbdev, linux-omap, Tomi Valkeinen
The main patch in this set is the "PHY burnout fix", which implements a fix for
a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The
possible damage breaks HDMI output hardware, otherwise the board is unaffected.
The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix
can be implemented. And the fix introduced a small bug with hot plug detect,
which is fixed by the patch from Rob. Rob's patch is not yet in upstream, but
has been accepted by fbdev maintainer.
Tomi
Rob Clark (1):
OMAPDSS: HDMI: hot plug detect fix
Tomi Valkeinen (6):
OMAP: 4430SDP/Panda: use gpio_free_array to free HDMI gpios
OMAP: 4430SDP/Panda: rename HPD GPIO to CT_CP_HPD
OMAPDSS: remove wrong HDMI HPD muxing
OMAP: 4430SDP/Panda: setup HDMI GPIO muxes
OMAP: 4430SDP/Panda: add HDMI HPD gpio
OMAPDSS: HDMI: PHY burnout fix
arch/arm/mach-omap2/board-4430sdp.c | 22 +++++---
arch/arm/mach-omap2/board-omap4panda.c | 22 +++++---
drivers/video/omap2/dss/hdmi.c | 3 +
drivers/video/omap2/dss/ti_hdmi.h | 4 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 77 ++++++++++++++++++++++++-----
include/video/omapdss.h | 5 ++
6 files changed, 105 insertions(+), 28 deletions(-)
--
1.7.4.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox