* [PATCH v5 6/8] ARM: mmp: added device for display controller
From: Zhou Zhu @ 2013-01-17 8:24 UTC (permalink / raw)
To: linux-fbdev
added device for display controller and fb support
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
arch/arm/mach-mmp/include/mach/pxa910.h | 5 ++++-
arch/arm/mach-mmp/pxa910.c | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/include/mach/pxa910.h b/arch/arm/mach-mmp/include/mach/pxa910.h
index 3b58a3b..b4c94d8 100644
--- a/arch/arm/mach-mmp/include/mach/pxa910.h
+++ b/arch/arm/mach-mmp/include/mach/pxa910.h
@@ -10,6 +10,7 @@ extern void __init pxa910_init_irq(void);
#include <linux/i2c/pxa-i2c.h>
#include <mach/devices.h>
#include <linux/platform_data/mtd-nand-pxa3xx.h>
+#include <video/mmp_disp.h>
extern struct pxa_device_desc pxa910_device_uart1;
extern struct pxa_device_desc pxa910_device_uart2;
@@ -23,7 +24,9 @@ extern struct pxa_device_desc pxa910_device_nand;
extern struct platform_device pxa168_device_u2o;
extern struct platform_device pxa168_device_u2ootg;
extern struct platform_device pxa168_device_u2oehci;
-
+extern struct pxa_device_desc pxa910_device_disp;
+extern struct pxa_device_desc pxa910_device_fb;
+extern struct pxa_device_desc pxa910_device_panel;
extern struct platform_device pxa910_device_gpio;
extern struct platform_device pxa910_device_rtc;
diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c
index 8b1e16f..e49cdd9 100644
--- a/arch/arm/mach-mmp/pxa910.c
+++ b/arch/arm/mach-mmp/pxa910.c
@@ -138,6 +138,9 @@ PXA910_DEVICE(pwm2, "pxa910-pwm", 1, NONE, 0xd401a400, 0x10);
PXA910_DEVICE(pwm3, "pxa910-pwm", 2, NONE, 0xd401a800, 0x10);
PXA910_DEVICE(pwm4, "pxa910-pwm", 3, NONE, 0xd401ac00, 0x10);
PXA910_DEVICE(nand, "pxa3xx-nand", -1, NAND, 0xd4283000, 0x80, 97, 99);
+PXA910_DEVICE(disp, "mmp-disp", 0, LCD, 0xd420b000, 0x1ec);
+PXA910_DEVICE(fb, "mmp-fb", -1, NONE, 0, 0);
+PXA910_DEVICE(panel, "tpo-hvga", -1, NONE, 0, 0);
struct resource pxa910_resource_gpio[] = {
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 7/8] ARM: mmp: enable display in ttc_dkb
From: Zhou Zhu @ 2013-01-17 8:24 UTC (permalink / raw)
To: linux-fbdev
enable display in ttc_dkb
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
arch/arm/mach-mmp/ttc_dkb.c | 92 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index ce55fd8..7c3c3c9 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -19,6 +19,8 @@
#include <linux/gpio.h>
#include <linux/mfd/88pm860x.h>
#include <linux/platform_data/mv_usb.h>
+#include <linux/spi/spi.h>
+#include <linux/delay.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -184,6 +186,92 @@ static struct pxa3xx_nand_platform_data dkb_nand_info = {
};
#endif
+#ifdef CONFIG_MMP_DISP
+/* path config */
+#define CFG_IOPADMODE(iopad) (iopad) /* 0x0 ~ 0xd */
+#define SCLK_SOURCE_SELECT(x) (x << 30) /* 0x0 ~ 0x3 */
+/* link config */
+#define CFG_DUMBMODE(mode) (mode << 28) /* 0x0 ~ 0x6*/
+#define CFG_GRA_SWAPRB(x) (x << 0) /* 1: rbswap enabled */
+static struct mmp_mach_path_config dkb_disp_config[] = {
+ [0] = {
+ .name = "mmp-parallel",
+ .ovly_num = 2,
+ .output_type = PATH_OUT_PARALLEL,
+ .path_config = CFG_IOPADMODE(0x1)
+ | SCLK_SOURCE_SELECT(0x1),
+ .link_config = CFG_DUMBMODE(0x2)
+ | CFG_GRA_SWAPRB(0x1),
+ },
+};
+
+static struct mmp_mach_plat_info dkb_disp_info = {
+ .name = "mmp-disp",
+ .clk_name = "disp0",
+ .path_num = 1,
+ .paths = dkb_disp_config,
+};
+
+static struct mmp_buffer_driver_mach_info dkb_fb_info = {
+ .name = "mmp-fb",
+ .path_name = "mmp-parallel",
+ .ovly_id = 0,
+ .dmafetch_id = 1,
+ .default_pixfmt = PIXFMT_RGB565,
+};
+
+static void dkb_tpo_panel_power(int on)
+{
+ int err;
+ u32 spi_reset = mfp_to_gpio(MFP_PIN_GPIO106);
+
+ if (on) {
+ err = gpio_request(spi_reset, "TPO_LCD_SPI_RESET");
+ if (err) {
+ pr_err("failed to request GPIO for TPO LCD RESET\n");
+ return;
+ }
+ gpio_direction_output(spi_reset, 0);
+ udelay(100);
+ gpio_set_value(spi_reset, 1);
+ gpio_free(spi_reset);
+ } else {
+ err = gpio_request(spi_reset, "TPO_LCD_SPI_RESET");
+ if (err) {
+ pr_err("failed to request LCD RESET gpio\n");
+ return;
+ }
+ gpio_set_value(spi_reset, 0);
+ gpio_free(spi_reset);
+ }
+}
+
+static struct mmp_mach_panel_info dkb_tpo_panel_info = {
+ .name = "tpo-hvga",
+ .plat_path_name = "mmp-parallel",
+ .plat_set_onoff = dkb_tpo_panel_power,
+};
+
+static struct spi_board_info spi_board_info[] __initdata = {
+ {
+ .modalias = "tpo-hvga",
+ .platform_data = &dkb_tpo_panel_info,
+ .bus_num = 5,
+ }
+};
+
+static void __init add_disp(void)
+{
+ pxa_register_device(&pxa910_device_disp,
+ &dkb_disp_info, sizeof(dkb_disp_info));
+ spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
+ pxa_register_device(&pxa910_device_fb,
+ &dkb_fb_info, sizeof(dkb_fb_info));
+ pxa_register_device(&pxa910_device_panel,
+ &dkb_tpo_panel_info, sizeof(dkb_tpo_panel_info));
+}
+#endif
+
static void __init ttc_dkb_init(void)
{
mfp_config(ARRAY_AND_SIZE(ttc_dkb_pin_config));
@@ -212,6 +300,10 @@ static void __init ttc_dkb_init(void)
pxa168_device_u2ootg.dev.platform_data = &ttc_usb_pdata;
platform_device_register(&pxa168_device_u2ootg);
#endif
+
+#ifdef CONFIG_MMP_DISP
+ add_disp();
+#endif
}
MACHINE_START(TTC_DKB, "PXA910-based TTC_DKB Development Platform")
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 8/8] ARM: mmp: add display and fb support in pxa910 defconfig
From: Zhou Zhu @ 2013-01-17 8:24 UTC (permalink / raw)
To: linux-fbdev
added display and fb support in pxa910 defconfig.
added tpohvga panel, spi support.
added logo support.
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
arch/arm/configs/pxa910_defconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/configs/pxa910_defconfig b/arch/arm/configs/pxa910_defconfig
index 191118c..3bb7771 100644
--- a/arch/arm/configs/pxa910_defconfig
+++ b/arch/arm/configs/pxa910_defconfig
@@ -42,6 +42,14 @@ CONFIG_SMC91X=y
# CONFIG_SERIO is not set
CONFIG_SERIAL_PXA=y
CONFIG_SERIAL_PXA_CONSOLE=y
+CONFIG_SPI=y
+CONFIG_FB=y
+CONFIG_MMP_DISP=y
+CONFIG_MMP_DISP_CONTROLLER=y
+CONFIG_MMP_SPI=y
+CONFIG_MMP_PANEL_TPOHVGA=y
+CONFIG_MMP_FB=y
+CONFIG_LOGO=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 0/8] video: mmp display subsystem
From: Haojian Zhuang @ 2013-01-17 8:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358410826-2557-1-git-send-email-zzhu3@marvell.com>
On Thu, Jan 17, 2013 at 4:20 PM, Zhou Zhu <zzhu3@marvell.com> wrote:
> Hi,
>
> This series added support for display controller in
> Marvell "mmp" series processors.
> It also contains patches to enable display panel on
> TTC_DKB board.
>
> v5: rebased to 3.8RC3 and support common clock tree.
> v4: added patches to enable display panel on TTC_DKB
> board.
> v3: registered lcd spi control as a spi master and
> panel driver operations moved to standard spi bus
> interface.
> v2: removed change-id and blank lines.
>
> Thanks,
> -Zhou
>
> Guoqing Li (1):
> video: mmp display controller support
>
> Lisa Du (1):
> video: mmp: add tpo hvga panel supported
>
> Zhou Zhu (6):
> video: mmp display subsystem
> video: mmp fb support
> video: mmpdisp: add spi port in display controller
> ARM: mmp: added device for display controller
> ARM: mmp: enable display in ttc_dkb
> ARM: mmp: add display and fb support in pxa910 defconfig
>
Acked for all patches.
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
^ permalink raw reply
* (no subject)
From: "李真能" @ 2013-01-17 11:34 UTC (permalink / raw)
To: linux-fbdev
Kernel supports RV710 in drivers/gpu/drm/radeon(r600),but I want gpu
acceleration in framebuffer for RV710 to use in directfb, I try to migrate
code from drivers/gpu/drm/radeon to drivers/video/aty/ to support
directfb, but it's very difficulty, because I have not the datasheet for
RV710, I don't konw how to set registers to draw a line, or a rectangle,
if someone has the datasheet for rv710, please sent me, thanks very
much!!!
^ permalink raw reply
* Re: DirectFB on RV710
From: Michel Dänzer @ 2013-01-17 13:37 UTC (permalink / raw)
To: linux-fbdev
On Don, 2013-01-17 at 19:34 +0800, "李真能" wrote:
> Kernel supports RV710 in drivers/gpu/drm/radeon(r600),but I want gpu
> acceleration in framebuffer for RV710 to use in directfb, I try to migrate
> code from drivers/gpu/drm/radeon to drivers/video/aty/ to support
> directfb, but it's very difficulty, because I have not the datasheet for
> RV710, I don't konw how to set registers to draw a line, or a rectangle,
> if someone has the datasheet for rv710, please sent me, thanks very
> much!!!
RV710 doesn't have a 2D engine, so you'd have to use the 3D engine.
There are some links to documentation for this on
http://wiki.x.org/wiki/RadeonFeature .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* [PATCH 1/2] drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
From: Anatolij Gustschin @ 2013-01-17 20:28 UTC (permalink / raw)
To: linux-fbdev
Framebuffer colors for 24 and 16 bpp are currently wrong. The order
of the color component arguments in the MAKE_PF() is not natural
and causes some confusion. The generated pixel format values for 24
and 16 bpp depths do not much the values in the comments.
Fix the macro arguments to be in the natural RGB order and adjust
the arguments for all depths to generate correct pixel format values
(equal to the values mentioned in the comments).
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Timur Tabi <timur@tabi.org>
---
drivers/video/fsl-diu-fb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 19cfd7a..4f8a2e4 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -944,7 +944,7 @@ static u32 fsl_diu_get_pixel_format(unsigned int bits_per_pixel)
#define PF_COMP_0_MASK 0x0000000F
#define PF_COMP_0_SHIFT 0
-#define MAKE_PF(alpha, red, blue, green, size, c0, c1, c2, c3) \
+#define MAKE_PF(alpha, red, green, blue, size, c0, c1, c2, c3) \
cpu_to_le32(PF_BYTE_F | (alpha << PF_ALPHA_C_SHIFT) | \
(blue << PF_BLUE_C_SHIFT) | (green << PF_GREEN_C_SHIFT) | \
(red << PF_RED_C_SHIFT) | (c3 << PF_COMP_3_SHIFT) | \
@@ -954,10 +954,10 @@ static u32 fsl_diu_get_pixel_format(unsigned int bits_per_pixel)
switch (bits_per_pixel) {
case 32:
/* 0x88883316 */
- return MAKE_PF(3, 2, 0, 1, 3, 8, 8, 8, 8);
+ return MAKE_PF(3, 2, 1, 0, 3, 8, 8, 8, 8);
case 24:
/* 0x88082219 */
- return MAKE_PF(4, 0, 1, 2, 2, 0, 8, 8, 8);
+ return MAKE_PF(4, 0, 1, 2, 2, 8, 8, 8, 0);
case 16:
/* 0x65053118 */
return MAKE_PF(4, 2, 1, 0, 1, 5, 6, 5, 0);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-01-17 20:28 UTC (permalink / raw)
To: linux-fbdev
Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
enabling of interrupts" the interrupt handling in the driver
is broken. Enabling diu interrupt causes an interrupt storm and
results in system lockup.
The cookie for the interrupt handler function passed to request_irq()
is wrong (it must be a pointer to the diu struct, and not the address
of the pointer to the diu struct). As a result the interrupt handler
can not read diu registers and acknowledge the interrupt. Fix cookie
arguments for request_irq() and free_irq().
Masking the diu interrupts in probe() must happen before install_fb()
calls since this function registers framebuffer devices and if fbcon
tries to take over framebuffer after registering a framebuffer device,
it will call fb_open of the diu driver and enable the interrupts. But
at this time the diu interrupt handler is not registered yet. Therefore
we must mask the diu interrupts before registering the framebuffers
and enable the interrupts after registering the handler.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Timur Tabi <timur@tabi.org>
---
drivers/video/fsl-diu-fb.c | 58 +++++++++++++++++++++++++++----------------
1 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4f8a2e4..b88cf78 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -378,6 +378,7 @@ struct fsl_diu_data {
u8 cursor[MAX_CURS * MAX_CURS * 2] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
+ bool can_handle_irq;
} __aligned(32);
/* Determine the DMA address of a member of the fsl_diu_data structure */
@@ -1232,6 +1233,19 @@ static int fsl_diu_ioctl(struct fb_info *info, unsigned int cmd,
return 0;
}
+static inline void fsl_diu_enable_interrupts(struct fsl_diu_data *data)
+{
+ u32 int_mask = INT_UNDRUN; /* enable underrun detection */
+
+ if (!data->can_handle_irq)
+ return;
+
+ if (IS_ENABLED(CONFIG_NOT_COHERENT_CACHE))
+ int_mask |= INT_VSYNC; /* enable vertical sync */
+
+ clrbits32(&data->diu_reg->int_mask, int_mask);
+}
+
/* turn on fb if count = 1
*/
static int fsl_diu_open(struct fb_info *info, int user)
@@ -1251,19 +1265,7 @@ static int fsl_diu_open(struct fb_info *info, int user)
if (res < 0)
mfbi->count--;
else {
- struct fsl_diu_data *data = mfbi->parent;
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
- /*
- * Enable underrun detection and vertical sync
- * interrupts.
- */
- clrbits32(&data->diu_reg->int_mask,
- INT_UNDRUN | INT_VSYNC);
-#else
- /* Enable underrun detection */
- clrbits32(&data->diu_reg->int_mask, INT_UNDRUN);
-#endif
+ fsl_diu_enable_interrupts(mfbi->parent);
fsl_diu_enable_panel(info);
}
}
@@ -1614,6 +1616,14 @@ static int fsl_diu_probe(struct platform_device *pdev)
out_be32(&data->diu_reg->desc[1], data->dummy_ad.paddr);
out_be32(&data->diu_reg->desc[2], data->dummy_ad.paddr);
+ /*
+ * Older versions of U-Boot leave interrupts enabled, so disable
+ * all of them and clear the status register.
+ */
+ out_be32(&data->diu_reg->int_mask, 0xffffffff);
+ in_be32(&data->diu_reg->int_status);
+ data->can_handle_irq = false;
+
for (i = 0; i < NUM_AOIS; i++) {
ret = install_fb(&data->fsl_diu_info[i]);
if (ret) {
@@ -1622,20 +1632,24 @@ static int fsl_diu_probe(struct platform_device *pdev)
}
}
- /*
- * Older versions of U-Boot leave interrupts enabled, so disable
- * all of them and clear the status register.
- */
- out_be32(&data->diu_reg->int_mask, 0xffffffff);
- in_be32(&data->diu_reg->int_status);
-
ret = request_irq(data->irq, fsl_diu_isr, 0, "fsl-diu-fb",
- &data->diu_reg);
+ data->diu_reg);
if (ret) {
dev_err(&pdev->dev, "could not claim irq\n");
goto error;
}
+ data->can_handle_irq = true;
+
+ /* if an AOI is opened (i.e. by fbcon), enable the interrupts */
+ for (i = 0; i < NUM_AOIS; i++) {
+ struct fb_info *info = &data->fsl_diu_info[i];
+
+ mfbi = info->par;
+ if (mfbi->count)
+ fsl_diu_enable_interrupts(data);
+ }
+
sysfs_attr_init(&data->dev_attr.attr);
data->dev_attr.attr.name = "monitor";
data->dev_attr.attr.mode = S_IRUGO|S_IWUSR;
@@ -1667,7 +1681,7 @@ static int fsl_diu_remove(struct platform_device *pdev)
data = dev_get_drvdata(&pdev->dev);
disable_lcdc(&data->fsl_diu_info[0]);
- free_irq(data->irq, &data->diu_reg);
+ free_irq(data->irq, data->diu_reg);
for (i = 0; i < NUM_AOIS; i++)
uninstall_fb(&data->fsl_diu_info[i]);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/2] drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
From: Timur Tabi @ 2013-01-17 22:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-1-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> /* 0x88883316 */
> - return MAKE_PF(3, 2, 0, 1, 3, 8, 8, 8, 8);
> + return MAKE_PF(3, 2, 1, 0, 3, 8, 8, 8, 8);
> case 24:
> /* 0x88082219 */
> - return MAKE_PF(4, 0, 1, 2, 2, 0, 8, 8, 8);
> + return MAKE_PF(4, 0, 1, 2, 2, 8, 8, 8, 0);
> case 16:
> /* 0x65053118 */
> return MAKE_PF(4, 2, 1, 0, 1, 5, 6, 5, 0);
You're right that the original values are incorrect, but I think your
patch is changing the wrong lines.
I put this code in the driver:
printk(KERN_INFO "%s:%u 0x88883316 old %08x new %08x\n", __func__,
__LINE__, MAKE_PF(3, 2, 0, 1, 3, 8, 8, 8, 8), MAKE_PF(3, 2, 1, 0, 3, 8, 8,
8, 8));
printk(KERN_INFO "%s:%u 0x88082219 old %08x new %08x\n", __func__,
__LINE__, MAKE_PF(4, 0, 1, 2, 2, 0, 8, 8, 8), MAKE_PF(4, 0, 1, 2, 2, 8, 8,
8, 0));
printk(KERN_INFO "%s:%u 0x65053118 %08x\n", __func__, __LINE__,
MAKE_PF(4, 2, 1, 0, 1, 5, 6, 5, 0));
and it gave me this output:
fsl_diu_get_pixel_format:956 0x88883316 old 88883316 new 88889316
fsl_diu_get_pixel_format:957 0x88082219 old 8088c218 new 8808c218
fsl_diu_get_pixel_format:958 0x65053118 65059118
fsl_diu_get_pixel_format:956 0x88883316 old 88883316 new 88889316
fsl_diu_get_pixel_format:957 0x88082219 old 8088c218 new 8808c218
fsl_diu_get_pixel_format:958 0x65053118 65059118
Console: switching to colour frame buffer device 182x73
So the value for 32-bit is already correct, but your patch breaks it. The
value for 24-bit is wrong, but your patch just gives me another wrong
value. The value for 16-bit is wrong, but you don't change that.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Timur Tabi @ 2013-01-17 22:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-2-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
> enabling of interrupts" the interrupt handling in the driver
> is broken. Enabling diu interrupt causes an interrupt storm and
> results in system lockup.
>
> The cookie for the interrupt handler function passed to request_irq()
> is wrong (it must be a pointer to the diu struct, and not the address
> of the pointer to the diu struct). As a result the interrupt handler
> can not read diu registers and acknowledge the interrupt. Fix cookie
> arguments for request_irq() and free_irq().
Ok, thanks for catching this. I don't know how I missed it.
> Masking the diu interrupts in probe() must happen before install_fb()
> calls since this function registers framebuffer devices and if fbcon
> tries to take over framebuffer after registering a framebuffer device,
> it will call fb_open of the diu driver and enable the interrupts. But
> at this time the diu interrupt handler is not registered yet. Therefore
> we must mask the diu interrupts before registering the framebuffers
> and enable the interrupts after registering the handler.
The root cause of this problem is that the hardware is initialized in the
.probe(), but it should instead be initialized in the .open. This has
been a major design flaw in the DIU driver that I've hoping to fix, but I
never got around to it (and probably never will).
This is why you need hacks like can_handle_irq. So I'm not crazy about
this patch. I think you need to get rid of can_handle_irq and allow the
interrupt handler to be registered before the hardware is initialized.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH 1/2] drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
From: Anatolij Gustschin @ 2013-01-17 22:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-1-git-send-email-agust@denx.de>
On Thu, 17 Jan 2013 16:12:05 -0600
Timur Tabi <timur@tabi.org> wrote:
> Anatolij Gustschin wrote:
> > /* 0x88883316 */
> > - return MAKE_PF(3, 2, 0, 1, 3, 8, 8, 8, 8);
> > + return MAKE_PF(3, 2, 1, 0, 3, 8, 8, 8, 8);
> > case 24:
> > /* 0x88082219 */
> > - return MAKE_PF(4, 0, 1, 2, 2, 0, 8, 8, 8);
> > + return MAKE_PF(4, 0, 1, 2, 2, 8, 8, 8, 0);
> > case 16:
> > /* 0x65053118 */
> > return MAKE_PF(4, 2, 1, 0, 1, 5, 6, 5, 0);
>
> You're right that the original values are incorrect, but I think your
> patch is changing the wrong lines.
No.
> I put this code in the driver:
>
> printk(KERN_INFO "%s:%u 0x88883316 old %08x new %08x\n", __func__,
> __LINE__, MAKE_PF(3, 2, 0, 1, 3, 8, 8, 8, 8), MAKE_PF(3, 2, 1, 0, 3, 8, 8,
> 8, 8));
> printk(KERN_INFO "%s:%u 0x88082219 old %08x new %08x\n", __func__,
> __LINE__, MAKE_PF(4, 0, 1, 2, 2, 0, 8, 8, 8), MAKE_PF(4, 0, 1, 2, 2, 8, 8,
> 8, 0));
> printk(KERN_INFO "%s:%u 0x65053118 %08x\n", __func__, __LINE__,
> MAKE_PF(4, 2, 1, 0, 1, 5, 6, 5, 0));
>
>
> and it gave me this output:
>
> fsl_diu_get_pixel_format:956 0x88883316 old 88883316 new 88889316
>
> fsl_diu_get_pixel_format:957 0x88082219 old 8088c218 new 8808c218
>
> fsl_diu_get_pixel_format:958 0x65053118 65059118
>
> fsl_diu_get_pixel_format:956 0x88883316 old 88883316 new 88889316
>
> fsl_diu_get_pixel_format:957 0x88082219 old 8088c218 new 8808c218
>
> fsl_diu_get_pixel_format:958 0x65053118 65059118
>
> Console: switching to colour frame buffer device 182x73
>
> So the value for 32-bit is already correct, but your patch breaks it.
No, my patch doesn't break it. The patch also modifies the order of
red, blue, green arguments in the MAKE_PF() macro to red, green, blue
order since this is more natural:
-#define MAKE_PF(alpha, red, blue, green, size, c0, c1, c2, c3) \
+#define MAKE_PF(alpha, red, green, blue, size, c0, c1, c2, c3) \
> value for 24-bit is wrong, but your patch just gives me another wrong
> value. The value for 16-bit is wrong, but you don't change that.
No. Please read the whole patch and commit message again.
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH 1/2] drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
From: Timur Tabi @ 2013-01-17 23:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-1-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> No, my patch doesn't break it. The patch also modifies the order of
> red, blue, green arguments in the MAKE_PF() macro to red, green, blue
> order since this is more natural:
I'm sorry, I don't know why I didn't notice that.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH 1/2] drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp
From: Timur Tabi @ 2013-01-17 23:08 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-1-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> Framebuffer colors for 24 and 16 bpp are currently wrong. The order
> of the color component arguments in the MAKE_PF() is not natural
> and causes some confusion. The generated pixel format values for 24
> and 16 bpp depths do not much the values in the comments.
>
> Fix the macro arguments to be in the natural RGB order and adjust
> the arguments for all depths to generate correct pixel format values
> (equal to the values mentioned in the comments).
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Timur Tabi <timur@tabi.org>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-01-17 23:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358454518-14032-2-git-send-email-agust@denx.de>
On Thu, 17 Jan 2013 16:20:04 -0600
Timur Tabi <timur@tabi.org> wrote:
...
> This is why you need hacks like can_handle_irq. So I'm not crazy about
> this patch. I think you need to get rid of can_handle_irq and allow the
> interrupt handler to be registered before the hardware is initialized.
It makes sense. More testing shows that disabling interrupts in
fsl_diu_release() needs to be fixed, too. If the fb0 plane is opened
(i.e. by fbcon) and another app opens an overlay plane i.e. on /dev/fb1
and then closes it, the diu interrupts will be disabled, even though the
first plane is still opened.
Thanks,
Anatolij
^ permalink raw reply
* Re: linux-next: Tree for Jan 18 [ BROKEN suspend: jbd2|acpi|pm? ]
From: Sedat Dilek @ 2013-01-19 2:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Rothwell, linux-next, linux-kernel, Theodore Ts'o,
linux-fsdevel, Linux PM List, Linux ACPI, Greg Kroah-Hartman,
Jiri Slaby, alan, linux-fbdev
In-Reply-To: <CA+icZUVJujqWdXP7tM5CBRT53Mx7ycOJPfQqXs-wbRebcrP9pQ@mail.gmail.com>
On Sat, Jan 19, 2013 at 2:55 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Sat, Jan 19, 2013 at 12:58 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Saturday, January 19, 2013 12:41:11 AM Sedat Dilek wrote:
>>> On Sat, Jan 19, 2013 at 12:39 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> > On Saturday, January 19, 2013 12:28:55 AM Sedat Dilek wrote:
>>> >> On Sat, Jan 19, 2013 at 12:25 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> >> > On Friday, January 18, 2013 11:56:53 PM Sedat Dilek wrote:
>>> >> >> On Fri, Jan 18, 2013 at 11:35 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> >> >> > On Fri, Jan 18, 2013 at 11:20 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> >> >> >> On Friday, January 18, 2013 11:11:07 PM Sedat Dilek wrote:
>>> >> >> >>> On Fri, Jan 18, 2013 at 5:37 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> >> >> >>> > Hi all,
>>> >> >> >>> >
>>> >> >> >>> > Changes since 20130117:
>>> >> >> >>> >
>>> >> >> >>> > Undropped tree: samung
>>> >> >> >>> >
>>> >> >> >>> > The powerpc tree still had a build failure.
>>> >> >> >>> >
>>> >> >> >>> > The driver-core tree gained a build failure for which I applied a merge
>>> >> >> >>> > fix patch.
>>> >> >> >>> >
>>> >> >> >>> > The gpio-lw tree gained a build failure so I used the version from
>>> >> >> >>> > next-20130117.
>>> >> >> >>> >
>>> >> >> >>> > The samsung tree lost the majority of its conflicts but gained more
>>> >> >> >>> > against the arm-soc and slave-dma tree.
>>> >> >> >>> >
>>> >> >> >>> > ----------------------------------------------------------------------------
>>> >> >> >>> >
>>> >> >> >>>
>>> >> >> >>> From my dmesg diff-file:
>>> >> >> >>>
>>> >> >> >>> +[ 288.730849] PM: Syncing filesystems ... done.
>>> >> >> >>> +[ 294.050498] Freezing user space processes ... (elapsed 0.04 seconds) done.
>>> >> >> >>> +[ 294.097024] Freezing remaining freezable tasks ...
>>> >> >> >>> +[ 314.098849] Freezing of tasks failed after 20.01 seconds (1 tasks
>>> >> >> >>> refusing to freeze, wq_busy=0):
>>> >> >> >>> +[ 314.098862] jbd2/loop0-8 D ffffffff8180d780 0 297 2 0x00000000
>>> >> >> >>> +[ 314.098865] ffff880117ec5b68 0000000000000046 ffff880117ec5b08
>>> >> >> >>> ffffffff81044c29
>>> >> >> >>> +[ 314.098868] ffff88011829dc80 ffff880117ec5fd8 ffff880117ec5fd8
>>> >> >> >>> ffff880117ec5fd8
>>> >> >> >>> +[ 314.098871] ffff880119b34560 ffff88011829dc80 ffff880117ec5b68
>>> >> >> >>> ffff88011fad4738
>>> >> >> >>> +[ 314.098873] Call Trace:
>>> >> >> >>> +[ 314.098881] [<ffffffff81044c29>] ? default_spin_lock_flags+0x9/0x10
>>> >> >> >>> +[ 314.098885] [<ffffffff811c63e0>] ? __wait_on_buffer+0x30/0x30
>>> >> >> >>> +[ 314.098888] [<ffffffff816b4b59>] schedule+0x29/0x70
>>> >> >> >>> +[ 314.098890] [<ffffffff816b4c2f>] io_schedule+0x8f/0xd0
>>> >> >> >>> +[ 314.098892] [<ffffffff811c63ee>] sleep_on_buffer+0xe/0x20
>>> >> >> >>> +[ 314.098896] [<ffffffff816b342f>] __wait_on_bit+0x5f/0x90
>>> >> >> >>> +[ 314.098898] [<ffffffff811c5aa1>] ? submit_bh+0x121/0x1e0
>>> >> >> >>> +[ 314.098900] [<ffffffff811c63e0>] ? __wait_on_buffer+0x30/0x30
>>> >> >> >>> +[ 314.098903] [<ffffffff816b34dc>] out_of_line_wait_on_bit+0x7c/0x90
>>> >> >> >>> +[ 314.098906] [<ffffffff8107eb00>] ? autoremove_wake_function+0x40/0x40
>>> >> >> >>> +[ 314.098909] [<ffffffff811c63de>] __wait_on_buffer+0x2e/0x30
>>> >> >> >>> +[ 314.098913] [<ffffffff8128a6a1>]
>>> >> >> >>> jbd2_journal_commit_transaction+0x1791/0x1960
>>> >> >> >>> +[ 314.098917] [<ffffffff8109269d>] ? sched_clock_cpu+0xbd/0x110
>>> >> >> >>> +[ 314.098920] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
>>> >> >> >>> +[ 314.098923] [<ffffffff81069fbf>] ? try_to_del_timer_sync+0x4f/0x70
>>> >> >> >>> +[ 314.098925] [<ffffffff8128e4e8>] kjournald2+0xb8/0x240
>>> >> >> >>> +[ 314.098927] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
>>> >> >> >>> +[ 314.098929] [<ffffffff8128e430>] ? commit_timeout+0x10/0x10
>>> >> >> >>> +[ 314.098931] [<ffffffff8107ded0>] kthread+0xc0/0xd0
>>> >> >> >>> +[ 314.098933] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>>> >> >> >>> +[ 314.098936] [<ffffffff816be52c>] ret_from_fork+0x7c/0xb0
>>> >> >> >>> +[ 314.098938] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
>>> >> >> >>> +[ 314.098969]
>>> >> >> >>> +[ 314.098970] Restarting kernel threads ... done.
>>> >> >> >>> +[ 314.099052] Restarting tasks ... done.
>>> >> >> >>>
>>> >> >> >>> Please, have a lot at it.
>>> >> >> >>
>>> >> >> >> This is a freezer failure while freezing kernel threads, so I don't think it's
>>> >> >> >> related to ACPI or PM directly.
>>> >> >> >>
>>> >> >> >> Does it happen on every suspend?
>>> >> >> >>
>>> >> >> >
>>> >> >> > No, I only did one S/R.
>>> >> >> >
>>> >> >> > I have built a 2nd new kernel where I pulled-in latest pm.git#linux-next.
>>> >> >> > With this kernel two S/Rs were fine - but that says not much.
>>> >> >> >
>>> >> >>
>>> >> >> After several S/Rs on the "buggy" -1 kernel I know see in my syslogs:
>>> >> >>
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.853828] Disabling non-boot CPUs ...
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.956943] smpboot: CPU 1 is now offline
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.957438] NOHZ: local_softirq_pending 02
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 141.957454] NOHZ: local_softirq_pending 02
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 142.060830] smpboot: CPU 2 is now offline
>>> >> >> Jan 18 23:50:02 fambox kernel: [ 142.164639] smpboot: CPU 3 is now offline
>>> >> >
>>> >> > Are you worried about the "local_softirq_pending" messages?
>>> >> >
>>> >>
>>> >> That's the only new messages I have seen after several S/Rs.
>>> >
>>> > They are kind of unusual.
>>> >
>>> > Anyway, they seem to be related to CPU hotplug (CPU offline), so you can try
>>> > if you can trigger them through the sysfs CPU offline/online interface.
>>> >
>>>
>>> Can you explain that a bit clearer or give some sample lines for testing?
>>
>> There is a sysfs file
>>
>> /sys/devices/system/cpu/cpuX/online
>>
>> (where X=0,1,2,3,...) for each CPU core in the system. The value read from it
>> indicates whether or not the given core is online (1 means online). Writing 0
>> to it means that the given core should be put offline. Writing 1 means to put
>> it back online. You can simply write first 0s and than 1s to those files
>> for CPUs > 0 multiple times in a row and see if that triggers messages like the
>> above. If it does, that may mean there's been a change in kernel/cpu.c, for
>> example, that causes it to appear. The change may have been made somewhere in
>> arch/x86 too, though.
>>
>>> >> If you have a testcase for me to reproduce it here, I would be happy.
>>> >
>>> > Do you mean the freezer-related issue?
>>> >
>>>
>>> Any one as I am still stepping in the dark.
>>> I checked my disc-space as I built a lot of software today and run
>>> once out of space.
>>> But 1.7GiB should be enough on / for testing.
>>> I wanted to run the new LTP version I built the last days.
>>> Let's see what I get...
>>
>> Stress-testing the freezer is rather easy and doesn't require disk space.
>> All it takes is to echo "freezer" to /sys/power/pm_test and then do
>> "echo mem > /sys/power/state && sleep 1" in a loop. This is described in
>> Documentation/power/basic-pm-debugging.txt IIRC.
>>
>
> [ CCing TTY and FBDEV folks ]
>
> [ TESTCASE ]
>
> kernel-config: CONFIG_PM_DEBUG=y
>
> root# echo "freezer" > /sys/power/pm_test
>
> root# echo mem > /sys/power/state && sleep 1
>
> This produces several TTY call-traces...
>
> +[ 810.417180] ------------[ cut here ]------------
> +[ 810.417203] WARNING: at drivers/tty/tty_buffer.c:475
> flush_to_ldisc+0x12f/0x1f0()
> +[ 810.417207] Hardware name: 530U3BI/530U4BI/530U4BH
> +[ 810.417210] tty is NULL
> +[ 791.200932] Freezing remaining freezable tasks ...
> +[ 810.417213] Modules linked in: bnep rfcomm parport_pc ppdev
> snd_hda_codec_hdmi snd_hda_codec_realtek coretemp kvm_intel kvm arc4
> iwldvm ghash_clmulni_intel aesni_intel snd_hda_intel mac80211 xts
> uvcvideo snd_hda_codec aes_x86_64 lrw snd_hwdep gf128mul
> videobuf2_vmalloc joydev ablk_helper snd_pcm i915 videobuf2_memops
> cryptd videobuf2_core snd_page_alloc videodev snd_seq_midi
> snd_seq_midi_event iwlwifi snd_rawmidi snd_seq i2c_algo_bit snd_timer
> drm_kms_helper psmouse snd_seq_device drm btusb microcode cfg80211 snd
> bluetooth serio_raw soundcore lpc_ich samsung_laptop wmi mei mac_hid
> video lp parport hid_generic r8169 usbhid hid
> +[ 810.417307] Pid: 37, comm: kworker/0:1 Not tainted
> 3.8.0-rc4-next20130118-3-iniza-generic #1
> +[ 810.417310] Call Trace:
> +[ 810.417325] [<ffffffff81058acf>] warn_slowpath_common+0x7f/0xc0
> +[ 810.417332] [<ffffffff81058bc6>] warn_slowpath_fmt+0x46/0x50
> +[ 810.417340] [<ffffffff8141b03f>] flush_to_ldisc+0x12f/0x1f0
> +[ 810.417349] [<ffffffff81077d95>] process_one_work+0x155/0x460
> +[ 810.417357] [<ffffffff81078a38>] worker_thread+0x168/0x410
> +[ 810.417364] [<ffffffff810788d0>] ? manage_workers+0x2c0/0x2c0
> +[ 810.417371] [<ffffffff8107ded0>] kthread+0xc0/0xd0
> +[ 810.417377] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
> +[ 810.417385] [<ffffffff816beaec>] ret_from_fork+0x7c/0xb0
> +[ 810.417427] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
> +[ 810.417438] ---[ end trace a302c76f044b14c2 ]---
>
> ...and my first reported call-trace is also seen afterwards...
>
> +[ 811.192835] Freezing of tasks failed after 20.01 seconds (1 tasks
> refusing to freeze, wq_busy=0):
> +[ 811.192957] jbd2/loop0-8 D ffffffff8180d780 0 289 2 0x00000000
> +[ 811.192966] ffff880118115b68 0000000000000046 ffff880118761720
> 0000000000000001
> +[ 811.192974] ffff880118761720 ffff880118115fd8 ffff880118115fd8
> ffff880118115fd8
> +[ 811.192981] ffffffff81c15440 ffff880118761720 ffff880118115b68
> ffff88011fa14738
> +[ 811.192988] Call Trace:
> +[ 811.193006] [<ffffffff811c6830>] ? __wait_on_buffer+0x30/0x30
> +[ 811.193015] [<ffffffff816b5149>] schedule+0x29/0x70
> +[ 811.193021] [<ffffffff816b521f>] io_schedule+0x8f/0xd0
> +[ 811.193028] [<ffffffff811c683e>] sleep_on_buffer+0xe/0x20
> +[ 811.193037] [<ffffffff816b3a1f>] __wait_on_bit+0x5f/0x90
> +[ 811.193044] [<ffffffff811c5ef1>] ? submit_bh+0x121/0x1e0
> +[ 811.193051] [<ffffffff811c6830>] ? __wait_on_buffer+0x30/0x30
> +[ 811.193058] [<ffffffff816b3acc>] out_of_line_wait_on_bit+0x7c/0x90
> +[ 811.193067] [<ffffffff8107eb00>] ? autoremove_wake_function+0x40/0x40
> +[ 811.193073] [<ffffffff811c682e>] __wait_on_buffer+0x2e/0x30
> +[ 811.193085] [<ffffffff8128aaf1>]
> jbd2_journal_commit_transaction+0x1791/0x1960
> +[ 811.193093] [<ffffffff816b62de>] ? _raw_spin_lock_irqsave+0x2e/0x40
> +[ 811.193102] [<ffffffff81069fbf>] ? try_to_del_timer_sync+0x4f/0x70
> +[ 811.193109] [<ffffffff8128e938>] kjournald2+0xb8/0x240
> +[ 811.193115] [<ffffffff8107eac0>] ? add_wait_queue+0x60/0x60
> +[ 811.193120] [<ffffffff8128e880>] ? commit_timeout+0x10/0x10
> +[ 811.193126] [<ffffffff8107ded0>] kthread+0xc0/0xd0
> +[ 811.193132] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
> +[ 811.193139] [<ffffffff816beaec>] ret_from_fork+0x7c/0xb0
> +[ 811.193144] [<ffffffff8107de10>] ? flush_kthread_worker+0xb0/0xb0
> +[ 811.193228]
> +[ 811.193231] Restarting kernel threads ... done.
> +[ 811.193403] Restarting tasks ... done.
>
> Thanks Rafael for the hints and your patience!
>
> Hope TTY/FBDEV folks can help.
>
> IMPORTANT NOTE:
> I have tested with some patches on top of Linux-Next (next-20130118),
> see attached patches file!
>
This looks like a typo to me...
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -471,7 +471,7 @@ static void flush_to_ldisc(struct work_struct *work)
unsigned long flags;
struct tty_ldisc *disc;
- tty = port->itty;
+ tty = port->tty;
if (WARN_RATELIMIT(tty = NULL, "tty is NULL\n"))
return;
- Sedat -
> - Sedat -
>
>> Thanks,
>> Rafael
>>
>>
>> --
>> I speak only for myself.
>> Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [GIT PULL] video: vt8500: Cleanup for 3.9
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Florian,
This is a series of patches for the vt8500 framebuffer driver. Mostly
cleanup stuff.
Non-cleanup:
video: vt8500: Make wmt_ge_rops optional - This patch makes hardware accelerated
raster ops optional as it doesn't work on the newly added WM8850 (yet).
Regards
Tony Prisk
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://server.prisktech.co.nz/git/linuxwmt.git tags/vt8500/video-3.9
for you to fetch changes up to 9167fe967de331a9457e1b4d4fc211857ba3b6ab:
video: vt8500: Update descriptions in video/Kconfig (2013-01-19 18:52:28 +1300)
----------------------------------------------------------------
video: vt8500: Cleanup for 3.9
----------------------------------------------------------------
Julia Lawall (1):
drivers/video/wm8505fb.c: use devm_ functions
Tony Prisk (3):
video: vt8500: Make wmt_ge_rops optional
video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
video: vt8500: Update descriptions in video/Kconfig
drivers/video/Kconfig | 32 ++++----
drivers/video/vt8500lcdfb.c | 17 +++-
drivers/video/wm8505fb.c | 95 ++++++++---------------
include/linux/platform_data/video-vt8500lcdfb.h | 31 --------
4 files changed, 67 insertions(+), 108 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
^ permalink raw reply
* [PATCH 1/4] drivers/video/wm8505fb.c: use devm_ functions
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-1-git-send-email-linux@prisktech.co.nz>
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 4dd0580..ddf78fc 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -274,15 +274,11 @@ static int 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 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 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 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 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 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 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 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
* [PATCH 2/4] video: vt8500: Make wmt_ge_rops optional
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-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 aa2579c..d8cc1f6 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 ddf78fc..dd28c26 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 3/4] video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-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 d8cc1f6..1c34821 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 dd28c26..8c8c129 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 4/4] video: vt8500: Update descriptions in video/Kconfig
From: Tony Prisk @ 2013-01-19 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358575377-26364-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 v2 2/2] drivers/video: fsl-diu-fb: fix bugs in interrupt handling
From: Anatolij Gustschin @ 2013-01-19 9:59 UTC (permalink / raw)
To: linux-fbdev
Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
enabling of interrupts" the interrupt handling in the driver
is broken. Enabling diu interrupt causes an interrupt storm and
results in system lockup.
The cookie for the interrupt handler function passed to request_irq()
is wrong (it must be a pointer to the diu struct, and not the address
of the pointer to the diu struct). As a result the interrupt handler
can not read diu registers and acknowledge the interrupt. Fix cookie
arguments for request_irq() and free_irq().
Registering the diu interrupt handler in probe() must happen before
install_fb() calls since this function registers framebuffer devices
and if fbcon tries to take over framebuffer after registering a frame
buffer device, it will call fb_open of the diu driver and enable the
interrupts. At this time the diu interrupt handler must be registered
already.
Disabling the interrupts in fsl_diu_release() must happen only if all
other AOIs are closed. Otherwise closing an overlay plane will disable
the interrupts even if the primary frame buffer plane is opened. Add
an appropriate check in the release function.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Timur Tabi <timur@tabi.org>
---
v2:
- don't add can_handle_irq flag and do the interrupt registration
before registering frame buffers instead.
drivers/video/fsl-diu-fb.c | 58 +++++++++++++++++++++++++-------------------
1 files changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4f8a2e4..41fbd94 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1232,6 +1232,16 @@ static int fsl_diu_ioctl(struct fb_info *info, unsigned int cmd,
return 0;
}
+static inline void fsl_diu_enable_interrupts(struct fsl_diu_data *data)
+{
+ u32 int_mask = INT_UNDRUN; /* enable underrun detection */
+
+ if (IS_ENABLED(CONFIG_NOT_COHERENT_CACHE))
+ int_mask |= INT_VSYNC; /* enable vertical sync */
+
+ clrbits32(&data->diu_reg->int_mask, int_mask);
+}
+
/* turn on fb if count = 1
*/
static int fsl_diu_open(struct fb_info *info, int user)
@@ -1251,19 +1261,7 @@ static int fsl_diu_open(struct fb_info *info, int user)
if (res < 0)
mfbi->count--;
else {
- struct fsl_diu_data *data = mfbi->parent;
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
- /*
- * Enable underrun detection and vertical sync
- * interrupts.
- */
- clrbits32(&data->diu_reg->int_mask,
- INT_UNDRUN | INT_VSYNC);
-#else
- /* Enable underrun detection */
- clrbits32(&data->diu_reg->int_mask, INT_UNDRUN);
-#endif
+ fsl_diu_enable_interrupts(mfbi->parent);
fsl_diu_enable_panel(info);
}
}
@@ -1283,9 +1281,18 @@ static int fsl_diu_release(struct fb_info *info, int user)
mfbi->count--;
if (mfbi->count = 0) {
struct fsl_diu_data *data = mfbi->parent;
+ bool disable = true;
+ int i;
- /* Disable interrupts */
- out_be32(&data->diu_reg->int_mask, 0xffffffff);
+ /* Disable interrupts only if all AOIs are closed */
+ for (i = 0; i < NUM_AOIS; i++) {
+ struct mfb_info *mi = data->fsl_diu_info[i].par;
+
+ if (mi->count)
+ disable = false;
+ }
+ if (disable)
+ out_be32(&data->diu_reg->int_mask, 0xffffffff);
fsl_diu_disable_panel(info);
}
@@ -1614,14 +1621,6 @@ static int fsl_diu_probe(struct platform_device *pdev)
out_be32(&data->diu_reg->desc[1], data->dummy_ad.paddr);
out_be32(&data->diu_reg->desc[2], data->dummy_ad.paddr);
- for (i = 0; i < NUM_AOIS; i++) {
- ret = install_fb(&data->fsl_diu_info[i]);
- if (ret) {
- dev_err(&pdev->dev, "could not register fb %d\n", i);
- goto error;
- }
- }
-
/*
* Older versions of U-Boot leave interrupts enabled, so disable
* all of them and clear the status register.
@@ -1630,12 +1629,21 @@ static int fsl_diu_probe(struct platform_device *pdev)
in_be32(&data->diu_reg->int_status);
ret = request_irq(data->irq, fsl_diu_isr, 0, "fsl-diu-fb",
- &data->diu_reg);
+ data->diu_reg);
if (ret) {
dev_err(&pdev->dev, "could not claim irq\n");
goto error;
}
+ for (i = 0; i < NUM_AOIS; i++) {
+ ret = install_fb(&data->fsl_diu_info[i]);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register fb %d\n", i);
+ free_irq(data->irq, data->diu_reg);
+ goto error;
+ }
+ }
+
sysfs_attr_init(&data->dev_attr.attr);
data->dev_attr.attr.name = "monitor";
data->dev_attr.attr.mode = S_IRUGO|S_IWUSR;
@@ -1667,7 +1675,7 @@ static int fsl_diu_remove(struct platform_device *pdev)
data = dev_get_drvdata(&pdev->dev);
disable_lcdc(&data->fsl_diu_info[0]);
- free_irq(data->irq, &data->diu_reg);
+ free_irq(data->irq, data->diu_reg);
for (i = 0; i < NUM_AOIS; i++)
uninstall_fb(&data->fsl_diu_info[i]);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/3] pwm-backlight: add subdrivers & Tegra support
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
This series introduces a way to use pwm-backlight hooks with platforms
that use the device tree through a subdriver system. It also adds support
for the Tegra-based Ventana board, adding the last missing block to enable
its panel. Support for other Tegra board can thus be easily added.
I have something else in mind to properly support this (power
sequences), but this work relies on the GPIO subsystem redesign which will
take some time. The pwm-backlight subdrivers can do the job by the meantime.
There are a few design points that might need to be discussed:
1) Link order is important: subdrivers register themselves in their
module_init function, which must be called before pwm-backlight's probe.
This forbids linking subdrivers as separate modules from pwm-backlight.
2) The subdriver's data is temporarily passed through the backlight
device's driver data. This should not hurt, but maybe there is a better way
to do this.
3) Subdrivers must add themselves into pwm-backlight's own of_device_id
table. It would be cleaner to not have to list subdrivers into
pwm-backlight's main file, but I cannot think of a way to do otherwise.
Suggestions for the 3 points listed above are very welcome - in any case,
I hope to make this converge into something mergeable quickly.
Note that these patches are the last missing block to get a functional
panel on Tegra boards. Using 3.8rc4 and these patches, the internal panel
on Ventana is usable out-of-the-box. Yay.
Alexandre Courbot (3):
pwm-backlight: add subdriver mechanism
tegra: pwm-backlight: add tegra pwm-bl driver
tegra: ventana: of: add host1x device to DT
arch/arm/boot/dts/tegra20-ventana.dts | 29 +++++-
arch/arm/configs/tegra_defconfig | 1 +
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 4 +
drivers/video/backlight/pwm_bl.c | 70 ++++++++++++++-
drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
include/linux/pwm_backlight.h | 15 ++++
7 files changed, 281 insertions(+), 4 deletions(-)
create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/3] pwm-backlight: add subdriver mechanism
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot@nvidia.com>
PWM-controlled backlights often need additional power control prior
to activating the PWM, typically switching regulators or GPIOs. This has
been done so far through hooks defined in board files, but this
mechanism cannot be used on platforms that rely on the device tree.
This patch introduces a "subdriver" mechanism to the pwm-backlight
driver that allows such hooks to be defined in optionally-compiled
sub-drivers. Every subdriver has its own device tree properties, which
sets the correct hooks to the pwm-backlight driver.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
drivers/video/backlight/Makefile | 4 +++
drivers/video/backlight/pwm_bl.c | 67 +++++++++++++++++++++++++++++++++++++++-
include/linux/pwm_backlight.h | 15 +++++++++
3 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..df97ab1 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -29,6 +29,10 @@ obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
obj-$(CONFIG_BACKLIGHT_CARILLO_RANCH) += cr_bllcd.o
+# pwm-backlight subdrivers must be listed *before* pwm_bl.o.
+# Link order is important as subdrivers must register themselves
+# before pwm-backlight's probe function can be called.
+obj-$(CONFIG_BACKLIGHT_PWM_TEGRA) += pwm_bl_tegra.o
obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
obj-$(CONFIG_BACKLIGHT_DA903X) += da903x_bl.o
obj-$(CONFIG_BACKLIGHT_DA9052) += da9052_bl.o
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 069983c..b65a797 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -22,6 +22,7 @@
#include <linux/slab.h>
struct pwm_bl_data {
+ void *subdriver_data;
struct pwm_device *pwm;
struct device *dev;
unsigned int period;
@@ -35,6 +36,54 @@ struct pwm_bl_data {
void (*exit)(struct device *);
};
+static DEFINE_MUTEX(pwm_backlight_subdrivers_mutex);
+static LIST_HEAD(pwm_backlight_subdrivers);
+
+void pwm_backlight_add_subdriver(struct pwm_backlight_subdriver *driver)
+{
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_add(&driver->list, &pwm_backlight_subdrivers);
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
+}
+EXPORT_SYMBOL(pwm_backlight_add_subdriver);
+
+void pwm_backlight_remove_subdriver(struct pwm_backlight_subdriver *driver)
+{
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_del(&driver->list);
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
+}
+EXPORT_SYMBOL(pwm_backlight_remove_subdriver);
+
+/**
+ * pwm_backlight_set_subdriver_data - set subdriver data
+ * @dev: backlight device which data is to be set
+ * @data: subdriver data
+ *
+ * This function can be called *only* in the init() hook of the subdriver. The
+ * data will be temporarily set as driver data before being retrieved by
+ * the probe() function and moved to its final place.
+ */
+void pwm_backlight_set_subdriver_data(struct device *dev, void *data)
+{
+ dev_set_drvdata(dev, data);
+}
+EXPORT_SYMBOL(pwm_backlight_set_subdriver_data);
+
+/**
+ * pwm_backlight_get_subdriver_data - retrieve subdriver data
+ * @dev: backlight device to get subdriver data of
+ *
+ * This function can be called in any subdriver hook, excepted init().
+ */
+void *pwm_backlight_get_subdriver_data(struct device *dev)
+{
+ struct backlight_device *bl = dev_get_drvdata(dev);
+ struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+ return pb->subdriver_data;
+}
+EXPORT_SYMBOL(pwm_backlight_get_subdriver_data);
+
static int pwm_backlight_update_status(struct backlight_device *bl)
{
struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
@@ -98,6 +147,7 @@ static const struct backlight_ops pwm_backlight_ops = {
static int pwm_backlight_parse_dt(struct device *dev,
struct platform_pwm_backlight_data *data)
{
+ struct pwm_backlight_subdriver *subdriver;
struct device_node *node = dev->of_node;
struct property *prop;
int length;
@@ -150,6 +200,17 @@ static int pwm_backlight_parse_dt(struct device *dev,
* backlight power. Support for specifying these needs to be
* added.
*/
+ mutex_lock(&pwm_backlight_subdrivers_mutex);
+ list_for_each_entry(subdriver, &pwm_backlight_subdrivers, list)
+ if (of_device_is_compatible(node, subdriver->name)) {
+ data->init = subdriver->init;
+ data->exit = subdriver->exit;
+ data->notify = subdriver->notify;
+ data->notify_after = subdriver->notify_after;
+ data->check_fb = subdriver->check_fb;
+ break;
+ }
+ mutex_unlock(&pwm_backlight_subdrivers_mutex);
return 0;
}
@@ -201,6 +262,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ /* if the init function set subdriver data, move it to correct place */
+ pb->subdriver_data = dev_get_drvdata(&pdev->dev);
+
if (data->levels) {
max = data->levels[data->max_brightness];
pb->levels = data->levels;
@@ -249,10 +313,11 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ platform_set_drvdata(pdev, bl);
+
bl->props.brightness = data->dft_brightness;
backlight_update_status(bl);
- platform_set_drvdata(pdev, bl);
return 0;
err_alloc:
diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
index 56f4a86..6abe1ef 100644
--- a/include/linux/pwm_backlight.h
+++ b/include/linux/pwm_backlight.h
@@ -20,4 +20,19 @@ struct platform_pwm_backlight_data {
int (*check_fb)(struct device *dev, struct fb_info *info);
};
+struct pwm_backlight_subdriver {
+ struct list_head list;
+ const char *name;
+ int (*init)(struct device *dev);
+ int (*notify)(struct device *dev, int brightness);
+ void (*notify_after)(struct device *dev, int brightness);
+ void (*exit)(struct device *dev);
+ int (*check_fb)(struct device *dev, struct fb_info *info);
+};
+
+void pwm_backlight_add_subdriver(struct pwm_backlight_subdriver *driver);
+void pwm_backlight_remove_subdriver(struct pwm_backlight_subdriver *driver);
+
+void pwm_backlight_set_subdriver_data(struct device *dev, void *data);
+void *pwm_backlight_get_subdriver_data(struct device *dev);
#endif
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/3] tegra: pwm-backlight: add tegra pwm-bl driver
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev, linux-kernel, linux-tegra, Mark Zhang, gnurou,
Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot@nvidia.com>
Add a PWM-backlight subdriver for Tegra boards, with support for
Ventana.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/boot/dts/tegra20-ventana.dts | 18 +++-
arch/arm/configs/tegra_defconfig | 1 +
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/pwm_bl.c | 3 +
drivers/video/backlight/pwm_bl_tegra.c | 159 +++++++++++++++++++++++++++++++++
5 files changed, 186 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/backlight/pwm_bl_tegra.c
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index adc4754..a77b529 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -516,6 +516,20 @@
bus-width = <8>;
};
+ backlight {
+ compatible = "pwm-backlight-ventana";
+ brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
+ default-brightness-level = <12>;
+
+ pwms = <&pwm 2 5000000>;
+ pwm-names = "backlight";
+
+ power-supply = <&vdd_bl_reg>;
+ panel-supply = <&vdd_pnl_reg>;
+ bl-gpio = <&gpio 28 0>;
+ bl-panel = <&gpio 10 0>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -549,7 +563,7 @@
enable-active-high;
};
- regulator@3 {
+ vdd_pnl_reg: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "vdd_pnl";
@@ -559,7 +573,7 @@
enable-active-high;
};
- regulator@4 {
+ vdd_bl_reg: regulator@4 {
compatible = "regulator-fixed";
reg = <4>;
regulator-name = "vdd_bl";
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index a7827fd..1c46602 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -150,6 +150,7 @@ CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_PWM_TEGRA=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_SOUND=y
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..377a409 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -244,6 +244,13 @@ config BACKLIGHT_PWM
If you have a LCD backlight adjustable by PWM, say Y to enable
this driver.
+config BACKLIGHT_PWM_TEGRA
+ bool "PWM Backlight Driver for Tegra boards"
+ depends on BACKLIGHT_PWM && ARCH_TEGRA
+ help
+ Support backlight power sequencing for Tegra boards.
+ Supported boards: Ventana.
+
config BACKLIGHT_DA903X
tristate "Backlight Driver for DA9030/DA9034 using WLED"
depends on PMIC_DA903X
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b65a797..1a4a9a3 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -217,6 +217,9 @@ static int pwm_backlight_parse_dt(struct device *dev,
static struct of_device_id pwm_backlight_of_match[] = {
{ .compatible = "pwm-backlight" },
+#ifdef CONFIG_BACKLIGHT_PWM_TEGRA
+ { .compatible = "pwm-backlight-ventana" },
+#endif
{ }
};
diff --git a/drivers/video/backlight/pwm_bl_tegra.c b/drivers/video/backlight/pwm_bl_tegra.c
new file mode 100644
index 0000000..8f2195b
--- /dev/null
+++ b/drivers/video/backlight/pwm_bl_tegra.c
@@ -0,0 +1,159 @@
+/*
+ * pwm-backlight subdriver for Tegra.
+ *
+ * Copyright (c) 2013 NVIDIA CORPORATION. All rights reserved.
+ *
+ * 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.
+ *
+ */
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/pwm_backlight.h>
+#include <linux/regulator/consumer.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/list.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+
+struct ventana_bl_data {
+ struct regulator *vdd_power;
+ struct regulator *vdd_panel;
+ int bl_gpio;
+ int panel_gpio;
+ bool is_on;
+};
+
+static int init_ventana(struct device *dev)
+{
+ struct ventana_bl_data *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(struct ventana_bl_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->vdd_power = devm_regulator_get(dev, "power");
+ if (IS_ERR(data->vdd_power)) {
+ dev_err(dev, "cannot get power regulator!\n");
+ return PTR_ERR(data->vdd_power);
+ }
+
+ data->vdd_panel = devm_regulator_get(dev, "panel");
+ if (IS_ERR(data->vdd_panel)) {
+ dev_err(dev, "cannot get panel regulator!\n");
+ return PTR_ERR(data->vdd_panel);
+ }
+
+ ret = of_get_named_gpio(dev->of_node, "bl-gpio", 0);
+ if (ret < 0) {
+ dev_err(dev, "cannot find backlight GPIO!\n");
+ return ret;
+ }
+ data->bl_gpio = ret;
+
+ ret = of_get_named_gpio(dev->of_node, "bl-panel", 0);
+ if (ret < 0) {
+ dev_err(dev, "cannot find panel GPIO!\n");
+ return ret;
+ }
+ data->panel_gpio = ret;
+
+ ret = devm_gpio_request_one(dev, data->bl_gpio,
+ GPIOF_DIR_OUT | GPIOF_OUT_INIT_LOW,
+ "backlight");
+ if (ret < 0) {
+ dev_err(dev, "cannot request backlight GPIO!\n");
+ return ret;
+ }
+
+ ret = devm_gpio_request_one(dev, data->panel_gpio,
+ GPIOF_DIR_OUT | GPIOF_OUT_INIT_LOW,
+ "panel");
+ if (ret < 0) {
+ dev_err(dev, "cannot request panel GPIO!\n");
+ return ret;
+ }
+
+ pwm_backlight_set_subdriver_data(dev, data);
+
+ return 0;
+}
+
+static void exit_ventana(struct device *dev)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+
+ devm_gpio_free(dev, data->panel_gpio);
+ devm_gpio_free(dev, data->bl_gpio);
+ devm_regulator_put(data->vdd_panel);
+ devm_regulator_put(data->vdd_power);
+ devm_kfree(dev, data);
+}
+
+static int notify_ventana(struct device *dev, int brightness)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+ if (brightness && !data->is_on) {
+ regulator_enable(data->vdd_panel);
+ gpio_set_value(data->panel_gpio, 1);
+ usleep_range(200000, 200000);
+ regulator_enable(data->vdd_power);
+ usleep_range(10000, 10000);
+ } else if (!brightness && data->is_on) {
+ gpio_set_value(data->bl_gpio, 0);
+ }
+
+ return brightness;
+}
+
+static void notify_after_ventana(struct device *dev, int brightness)
+{
+ struct ventana_bl_data *data = pwm_backlight_get_subdriver_data(dev);
+ if (brightness && !data->is_on) {
+ gpio_set_value(data->bl_gpio, 1);
+ data->is_on = true;
+ } else if (!brightness && data->is_on) {
+ usleep_range(10000, 10000);
+ regulator_disable(data->vdd_power);
+ usleep_range(200000, 200000);
+ gpio_set_value(data->panel_gpio, 0);
+ regulator_disable(data->vdd_panel);
+ data->is_on = false;
+ }
+}
+
+static struct pwm_backlight_subdriver pwm_backlight_ventana_subdriver = {
+ .name = "pwm-backlight-ventana",
+ .init = init_ventana,
+ .exit = exit_ventana,
+ .notify = notify_ventana,
+ .notify_after = notify_after_ventana,
+};
+
+static int __init pwm_backlight_tegra_init(void)
+{
+ pwm_backlight_add_subdriver(&pwm_backlight_ventana_subdriver);
+ return 0;
+}
+
+static void __exit pwm_backlight_tegra_exit(void)
+{
+ pwm_backlight_remove_subdriver(&pwm_backlight_ventana_subdriver);
+}
+
+module_init(pwm_backlight_tegra_init);
+module_exit(pwm_backlight_tegra_exit);
+
+MODULE_DESCRIPTION("Backlight Driver for Tegra boards");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pwm-tegra-backlight");
+
+
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/3] tegra: ventana: of: add host1x device to DT
From: Alexandre Courbot @ 2013-01-19 10:30 UTC (permalink / raw)
To: Thierry Reding, Stephen Warren
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, Mark Zhang,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, Alexandre Courbot
In-Reply-To: <1358591420-7790-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Add the host1x device and DDC i2c bus to enable internal panel on
Ventana.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/boot/dts/tegra20-ventana.dts | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index a77b529..4477e9c 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -10,6 +10,15 @@
reg = <0x00000000 0x40000000>;
};
+ host1x {
+ dc@54200000 {
+ rgb {
+ status = "okay";
+ nvidia,ddc-i2c-bus = <&lcd_ddc>;
+ };
+ };
+ };
+
pinmux {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -341,7 +350,7 @@
#size-cells = <0>;
};
- i2c@1 {
+ lcd_ddc: i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
--
1.8.1.1
^ 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