* [PATCH 3/9] ARM: S3C24XX: Remove include/mach/regs-lcd.h header file
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Move remaining s3c2410 LCD controller register bit field definitions
to the platform data header. Now the regs-lcd.h header can be removed
and inclusion of the mach specific header dropped from the driver.
Next step could be to redefine platform data structure, so register
specific definitions are private to the driver. Another possibility
is to add DT support, however these platforms will likely use ATAGS
for some time yet.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
arch/arm/mach-s3c24xx/dma-s3c2410.c | 1 -
arch/arm/mach-s3c24xx/dma-s3c2412.c | 1 -
arch/arm/mach-s3c24xx/dma-s3c2440.c | 1 -
arch/arm/mach-s3c24xx/dma-s3c2443.c | 1 -
arch/arm/mach-s3c24xx/include/mach/regs-lcd.h | 52 -------------------------
arch/arm/mach-s3c24xx/mach-anubis.c | 1 -
arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 -
arch/arm/mach-s3c24xx/mach-bast.c | 1 -
arch/arm/mach-s3c24xx/mach-h1940.c | 1 -
arch/arm/mach-s3c24xx/mach-jive.c | 1 -
arch/arm/mach-s3c24xx/mach-mini2440.c | 1 -
arch/arm/mach-s3c24xx/mach-n30.c | 1 -
arch/arm/mach-s3c24xx/mach-osiris.c | 1 -
arch/arm/mach-s3c24xx/mach-qt2410.c | 1 -
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2413.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2416.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2440.c | 1 -
arch/arm/mach-s3c24xx/mach-smdk2443.c | 1 -
arch/arm/mach-s3c24xx/mach-vstms.c | 1 -
drivers/video/s3c2410fb.c | 1 -
include/linux/platform_data/fb-s3c2410.h | 34 ++++++++++++++++
22 files changed, 34 insertions(+), 72 deletions(-)
delete mode 100644 arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2410.c b/arch/arm/mach-s3c24xx/dma-s3c2410.c
index a6c94b8..764556a 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2410.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2410.c
@@ -27,7 +27,6 @@
#include <mach/regs-gpio.h>
#include <plat/regs-ac97.h>
#include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
#include <plat/regs-iis.h>
#include <plat/regs-spi.h>
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2412.c b/arch/arm/mach-s3c24xx/dma-s3c2412.c
index c0e8c3f..f02fc3c 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2412.c
@@ -27,7 +27,6 @@
#include <mach/regs-gpio.h>
#include <plat/regs-ac97.h>
#include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
#include <plat/regs-iis.h>
#include <plat/regs-spi.h>
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2440.c b/arch/arm/mach-s3c24xx/dma-s3c2440.c
index 1c08eccd..b621563 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2440.c
@@ -27,7 +27,6 @@
#include <mach/regs-gpio.h>
#include <plat/regs-ac97.h>
#include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
#include <plat/regs-iis.h>
#include <plat/regs-spi.h>
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index 000e4c6..095e841 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -27,7 +27,6 @@
#include <mach/regs-gpio.h>
#include <plat/regs-ac97.h>
#include <plat/regs-dma.h>
-#include <mach/regs-lcd.h>
#include <plat/regs-iis.h>
#include <plat/regs-spi.h>
diff --git a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h b/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
deleted file mode 100644
index 369511f..0000000
--- a/arch/arm/mach-s3c24xx/include/mach/regs-lcd.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/* arch/arm/mach-s3c2410/include/mach/regs-lcd.h
- *
- * Copyright (c) 2003 Simtec Electronics <linux@simtec.co.uk>
- * http://www.simtec.co.uk/products/SWLINUX/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-
-#ifndef ___ASM_ARCH_REGS_LCD_H
-#define ___ASM_ARCH_REGS_LCD_H
-
-#define S3C2410_LCDCON1_MMODE (1<<7)
-#define S3C2410_LCDCON1_DSCAN4 (0<<5)
-#define S3C2410_LCDCON1_STN4 (1<<5)
-#define S3C2410_LCDCON1_STN8 (2<<5)
-#define S3C2410_LCDCON1_TFT (3<<5)
-
-#define S3C2410_LCDCON1_STN1BPP (0<<1)
-#define S3C2410_LCDCON1_STN2GREY (1<<1)
-#define S3C2410_LCDCON1_STN4GREY (2<<1)
-#define S3C2410_LCDCON1_STN8BPP (3<<1)
-#define S3C2410_LCDCON1_STN12BPP (4<<1)
-
-#define S3C2410_LCDCON1_TFT1BPP (8<<1)
-#define S3C2410_LCDCON1_TFT2BPP (9<<1)
-#define S3C2410_LCDCON1_TFT4BPP (10<<1)
-#define S3C2410_LCDCON1_TFT8BPP (11<<1)
-#define S3C2410_LCDCON1_TFT16BPP (12<<1)
-#define S3C2410_LCDCON1_TFT24BPP (13<<1)
-
-#define S3C2410_LCDCON1_ENVID (1)
-
-#define S3C2410_LCDCON1_MODEMASK 0x1E
-
-#define S3C2410_LCDCON5_BPP24BL (1<<12)
-#define S3C2410_LCDCON5_FRM565 (1<<11)
-#define S3C2410_LCDCON5_INVVCLK (1<<10)
-#define S3C2410_LCDCON5_INVVLINE (1<<9)
-#define S3C2410_LCDCON5_INVVFRAME (1<<8)
-#define S3C2410_LCDCON5_INVVD (1<<7)
-#define S3C2410_LCDCON5_INVVDEN (1<<6)
-#define S3C2410_LCDCON5_INVPWREN (1<<5)
-#define S3C2410_LCDCON5_INVLEND (1<<4)
-#define S3C2410_LCDCON5_PWREN (1<<3)
-#define S3C2410_LCDCON5_ENLEND (1<<2)
-#define S3C2410_LCDCON5_BSWP (1<<1)
-#define S3C2410_LCDCON5_HWSWP (1<<0)
-
-#endif /* ___ASM_ARCH_REGS_LCD_H */
diff --git a/arch/arm/mach-s3c24xx/mach-anubis.c b/arch/arm/mach-s3c24xx/mach-anubis.c
index c1fb6c3..d5e8cad 100644
--- a/arch/arm/mach-s3c24xx/mach-anubis.c
+++ b/arch/arm/mach-s3c24xx/mach-anubis.c
@@ -34,7 +34,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-at2440evb.c b/arch/arm/mach-s3c24xx/mach-at2440evb.c
index e4d71d5..f151bf7 100644
--- a/arch/arm/mach-s3c24xx/mach-at2440evb.c
+++ b/arch/arm/mach-s3c24xx/mach-at2440evb.c
@@ -35,7 +35,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-bast.c b/arch/arm/mach-s3c24xx/mach-bast.c
index 4402741..a500b21 100644
--- a/arch/arm/mach-s3c24xx/mach-bast.c
+++ b/arch/arm/mach-s3c24xx/mach-bast.c
@@ -47,7 +47,6 @@
#include <linux/platform_data/fb-s3c2410.h>
#include <mach/hardware.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <plat/clock.h>
#include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c b/arch/arm/mach-s3c24xx/mach-h1940.c
index 39ce53a..0236201 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -53,7 +53,6 @@
#include <mach/hardware.h>
#include <mach/regs-clock.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <plat/clock.h>
#include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-jive.c b/arch/arm/mach-s3c24xx/mach-jive.c
index 81e8e8c..d1347ec 100644
--- a/arch/arm/mach-s3c24xx/mach-jive.c
+++ b/arch/arm/mach-s3c24xx/mach-jive.c
@@ -36,7 +36,6 @@
#include <linux/platform_data/i2c-s3c2410.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/fb-s3c2410.h>
#include <asm/mach-types.h>
diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c b/arch/arm/mach-s3c24xx/mach-mini2440.c
index aa59f48..d0f25a4 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -40,7 +40,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
#include <linux/platform_data/leds-s3c24xx.h>
-#include <mach/regs-lcd.h>
#include <mach/irqs.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-n30.c b/arch/arm/mach-s3c24xx/mach-n30.c
index 3a32a75..8b956b7 100644
--- a/arch/arm/mach-s3c24xx/mach-n30.c
+++ b/arch/arm/mach-s3c24xx/mach-n30.c
@@ -35,7 +35,6 @@
#include <linux/platform_data/fb-s3c2410.h>
#include <linux/platform_data/leds-s3c24xx.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <asm/mach/arch.h>
#include <asm/mach/irq.h>
diff --git a/arch/arm/mach-s3c24xx/mach-osiris.c b/arch/arm/mach-s3c24xx/mach-osiris.c
index 58d6fbe..eeca631 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris.c
@@ -49,7 +49,6 @@
#include <mach/hardware.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include "common.h"
#include "osiris.h"
diff --git a/arch/arm/mach-s3c24xx/mach-qt2410.c b/arch/arm/mach-s3c24xx/mach-qt2410.c
index 65be582..7e11373 100644
--- a/arch/arm/mach-s3c24xx/mach-qt2410.c
+++ b/arch/arm/mach-s3c24xx/mach-qt2410.c
@@ -48,7 +48,6 @@
#include <asm/mach-types.h>
#include <linux/platform_data/leds-s3c24xx.h>
-#include <mach/regs-lcd.h>
#include <plat/regs-serial.h>
#include <linux/platform_data/fb-s3c2410.h>
#include <linux/platform_data/mtd-nand-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c
index 17fad4b..1ea1ce8 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -50,7 +50,6 @@
#include <linux/platform_data/fb-s3c2410.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <plat/clock.h>
#include <plat/cpu.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2413.c b/arch/arm/mach-s3c24xx/mach-smdk2413.c
index d504272..9b473cb 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2413.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2413.c
@@ -35,7 +35,6 @@
//#include <asm/debug-ll.h>
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/usb-s3c2410_udc.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c
index cb46847..5630d51 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
@@ -36,7 +36,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <mach/regs-s3c2443-clock.h>
#include <linux/platform_data/leds-s3c24xx.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2440.c b/arch/arm/mach-s3c24xx/mach-smdk2440.c
index 8546941..040e39b 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2440.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2440.c
@@ -33,7 +33,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/fb-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2443.c b/arch/arm/mach-s3c24xx/mach-smdk2443.c
index 5baa2e2..99a5c34 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2443.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2443.c
@@ -33,7 +33,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/fb-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/arch/arm/mach-s3c24xx/mach-vstms.c b/arch/arm/mach-s3c24xx/mach-vstms.c
index 86c9199..92cd9ec 100644
--- a/arch/arm/mach-s3c24xx/mach-vstms.c
+++ b/arch/arm/mach-s3c24xx/mach-vstms.c
@@ -34,7 +34,6 @@
#include <plat/regs-serial.h>
#include <mach/regs-gpio.h>
-#include <mach/regs-lcd.h>
#include <linux/platform_data/fb-s3c2410.h>
#include <linux/platform_data/i2c-s3c2410.h>
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index dc10dbe..12ac94e 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -34,7 +34,6 @@
#include <linux/platform_data/fb-s3c2410.h>
#include <asm/mach/map.h>
-#include <mach/regs-lcd.h>
#include <mach/regs-gpio.h>
#ifdef CONFIG_PM
diff --git a/include/linux/platform_data/fb-s3c2410.h b/include/linux/platform_data/fb-s3c2410.h
index dbebc62..8e04d49 100644
--- a/include/linux/platform_data/fb-s3c2410.h
+++ b/include/linux/platform_data/fb-s3c2410.h
@@ -12,6 +12,40 @@
#ifndef __FB_S3C2410_H
#define __FB_S3C2410_H __FILE__
+#define S3C2410_LCDCON1_DSCAN4 (0 << 5)
+#define S3C2410_LCDCON1_STN4 (1 << 5)
+#define S3C2410_LCDCON1_STN8 (2 << 5)
+#define S3C2410_LCDCON1_TFT (3 << 5)
+
+#define S3C2410_LCDCON1_STN1BPP (0 << 1)
+#define S3C2410_LCDCON1_STN2GREY (1 << 1)
+#define S3C2410_LCDCON1_STN4GREY (2 << 1)
+#define S3C2410_LCDCON1_STN8BPP (3 << 1)
+#define S3C2410_LCDCON1_STN12BPP (4 << 1)
+
+#define S3C2410_LCDCON1_TFT1BPP (8 << 1)
+#define S3C2410_LCDCON1_TFT2BPP (9 << 1)
+#define S3C2410_LCDCON1_TFT4BPP (10 << 1)
+#define S3C2410_LCDCON1_TFT8BPP (11 << 1)
+#define S3C2410_LCDCON1_TFT16BPP (12 << 1)
+#define S3C2410_LCDCON1_TFT24BPP (13 << 1)
+
+
+#define S3C2410_LCDCON5_BPP24BL (1 << 12)
+#define S3C2410_LCDCON5_FRM565 (1 << 11)
+#define S3C2410_LCDCON5_INVVCLK (1 << 10)
+#define S3C2410_LCDCON5_INVVLINE (1 << 9)
+#define S3C2410_LCDCON5_INVVFRAME (1 << 8)
+#define S3C2410_LCDCON5_INVVD (1 << 7)
+#define S3C2410_LCDCON5_INVVDEN (1 << 6)
+#define S3C2410_LCDCON5_INVPWREN (1 << 5)
+#define S3C2410_LCDCON5_INVLEND (1 << 4)
+#define S3C2410_LCDCON5_PWREN (1 << 3)
+#define S3C2410_LCDCON5_ENLEND (1 << 2)
+#define S3C2410_LCDCON5_BSWP (1 << 1)
+#define S3C2410_LCDCON5_HWSWP (1 << 0)
+
+
struct s3c2410fb_hw {
unsigned long lcdcon1;
unsigned long lcdcon2;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/9] s3c2410fb: Register single platform driver
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Use the id_table instead of registering two separate platform drivers.
This allows then to declare the driver with module_platform_driver().
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 59 +++++++++++---------------------------------
1 files changed, 15 insertions(+), 44 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 12ac94e..d6706f7 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -818,8 +818,7 @@ static inline void s3c2410fb_cpufreq_deregister(struct s3c2410fb_info *info)
static const char driver_name[] = "s3c2410fb";
-static int s3c24xxfb_probe(struct platform_device *pdev,
- enum s3c_drv_type drv_type)
+static int s3c2410fb_probe(struct platform_device *pdev)
{
struct s3c2410fb_info *info;
struct s3c2410fb_display *display;
@@ -861,7 +860,7 @@ static int s3c24xxfb_probe(struct platform_device *pdev,
info = fbinfo->par;
info->dev = &pdev->dev;
- info->drv_type = drv_type;
+ info->drv_type = platform_get_device_id(pdev)->driver_data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res = NULL) {
@@ -885,7 +884,7 @@ static int s3c24xxfb_probe(struct platform_device *pdev,
goto release_mem;
}
- if (drv_type = DRV_S3C2412)
+ if (info->drv_type = DRV_S3C2412)
info->irq_base = info->io + S3C2412_LCDINTBASE;
else
info->irq_base = info->io + S3C2410_LCDINTBASE;
@@ -1009,17 +1008,6 @@ dealloc_fb:
return ret;
}
-static int s3c2410fb_probe(struct platform_device *pdev)
-{
- return s3c24xxfb_probe(pdev, DRV_S3C2410);
-}
-
-static int s3c2412fb_probe(struct platform_device *pdev)
-{
- return s3c24xxfb_probe(pdev, DRV_S3C2412);
-}
-
-
/*
* Cleanup
*/
@@ -1098,46 +1086,29 @@ static int s3c2410fb_resume(struct platform_device *dev)
#define s3c2410fb_resume NULL
#endif
-static struct platform_driver s3c2410fb_driver = {
- .probe = s3c2410fb_probe,
- .remove = s3c2410fb_remove,
- .suspend = s3c2410fb_suspend,
- .resume = s3c2410fb_resume,
- .driver = {
- .name = "s3c2410-lcd",
- .owner = THIS_MODULE,
+static struct platform_device_id s3c2410fb_driver_ids[] = {
+ {
+ .name = "s3c2410-lcd",
+ .driver_data = (unsigned long)DRV_S3C2410,
+ }, {
+ .name = "s3c2412-lcd",
+ .driver_data = (unsigned long)DRV_S3C2412,
},
};
-static struct platform_driver s3c2412fb_driver = {
- .probe = s3c2412fb_probe,
+static struct platform_driver s3c2410fb_driver = {
+ .probe = s3c2410fb_probe,
.remove = s3c2410fb_remove,
.suspend = s3c2410fb_suspend,
.resume = s3c2410fb_resume,
+ .id_table = s3c2410fb_driver_ids,
.driver = {
- .name = "s3c2412-lcd",
+ .name = "s3c2410-lcd",
.owner = THIS_MODULE,
},
};
-int __init s3c2410fb_init(void)
-{
- int ret = platform_driver_register(&s3c2410fb_driver);
-
- if (ret = 0)
- ret = platform_driver_register(&s3c2412fb_driver);
-
- return ret;
-}
-
-static void __exit s3c2410fb_cleanup(void)
-{
- platform_driver_unregister(&s3c2410fb_driver);
- platform_driver_unregister(&s3c2412fb_driver);
-}
-
-module_init(s3c2410fb_init);
-module_exit(s3c2410fb_cleanup);
+module_platform_driver(s3c2410fb_driver);
MODULE_AUTHOR("Arnaud Patard <arnaud.patard@rtp-net.org>");
MODULE_AUTHOR("Ben Dooks <ben-linux@fluff.org>");
--
1.7.4.1
^ permalink raw reply related
* [PATCH 5/9] s3c2410fb: Use dev_pm_ops
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Use the driver PM ops rather than legacy suspend/resume callbacks.
Also use CONFIG_PM_SLEEP switch to compile in the system sleep
code instead of CONFIG_PM.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index d6706f7..479ab45 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -26,6 +26,7 @@
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/pm.h>
#include <linux/clk.h>
#include <linux/cpufreq.h>
#include <linux/io.h>
@@ -36,10 +37,6 @@
#include <asm/mach/map.h>
#include <mach/regs-gpio.h>
-#ifdef CONFIG_PM
-#include <linux/pm.h>
-#endif
-
#include "s3c2410fb.h"
/* Debugging stuff */
@@ -1044,8 +1041,7 @@ static int s3c2410fb_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
-
+#ifdef CONFIG_PM_SLEEP
/* suspend and resume support for the lcd controller */
static int s3c2410fb_suspend(struct platform_device *dev, pm_message_t state)
{
@@ -1081,9 +1077,14 @@ static int s3c2410fb_resume(struct platform_device *dev)
return 0;
}
+static const struct dev_pm_ops s3c2410fb_pm_ops = {
+ .resume = s3c2410fb_resume,
+ .suspend = s3c2410fb_suspend,
+};
+
+#define S3C2410FB_PM_OPS (&s3c2410fb_pm_ops)
#else
-#define s3c2410fb_suspend NULL
-#define s3c2410fb_resume NULL
+#define S3C2410FB_PM_OPS (NULL)
#endif
static struct platform_device_id s3c2410fb_driver_ids[] = {
@@ -1099,12 +1100,11 @@ static struct platform_device_id s3c2410fb_driver_ids[] = {
static struct platform_driver s3c2410fb_driver = {
.probe = s3c2410fb_probe,
.remove = s3c2410fb_remove,
- .suspend = s3c2410fb_suspend,
- .resume = s3c2410fb_resume,
.id_table = s3c2410fb_driver_ids,
.driver = {
.name = "s3c2410-lcd",
.owner = THIS_MODULE,
+ .pm = S3C2410FB_PM_OPS,
},
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 6/9] s3c2410fb: Enable display by default
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Enable the display with default configuration at system start up.
This ensures the display is activated also when FRAMBUFFER_CONSOLE
is not set.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 479ab45..da8b6c2 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -969,6 +969,8 @@ static int s3c2410fb_probe(struct platform_device *pdev)
goto free_video_memory;
}
+ s3c2410fb_set_par(fbinfo);
+
ret = register_framebuffer(fbinfo);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to register framebuffer device: %d\n",
--
1.7.4.1
^ permalink raw reply related
* [PATCH 7/9] s3c2410fb: Use devm_ioremap_resource()
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Use devm_ioremap_resource instead of reques_mem_region()/ioremap().
This ensures more consistent error values and simplifies error paths.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 32 ++++----------------------------
1 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index da8b6c2..11f98ca 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -825,7 +825,6 @@ static int s3c2410fb_probe(struct platform_device *pdev)
int ret;
int irq;
int i;
- int size;
u32 lcdcon1;
mach_info = pdev->dev.platform_data;
@@ -860,27 +859,12 @@ static int s3c2410fb_probe(struct platform_device *pdev)
info->drv_type = platform_get_device_id(pdev)->driver_data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res = NULL) {
- dev_err(&pdev->dev, "failed to get memory registers\n");
- ret = -ENXIO;
+ info->io = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(info->io)) {
+ ret = PTR_ERR(info->io);
goto dealloc_fb;
}
- size = resource_size(res);
- info->mem = request_mem_region(res->start, size, pdev->name);
- if (info->mem = NULL) {
- dev_err(&pdev->dev, "failed to get memory region\n");
- ret = -ENOENT;
- goto dealloc_fb;
- }
-
- info->io = ioremap(res->start, size);
- if (info->io = NULL) {
- dev_err(&pdev->dev, "ioremap() of registers failed\n");
- ret = -ENXIO;
- goto release_mem;
- }
-
if (info->drv_type = DRV_S3C2412)
info->irq_base = info->io + S3C2412_LCDINTBASE;
else
@@ -917,7 +901,7 @@ static int s3c2410fb_probe(struct platform_device *pdev)
if (ret) {
dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
ret = -EBUSY;
- goto release_regs;
+ goto dealloc_fb;
}
info->clk = clk_get(NULL, "lcd");
@@ -997,10 +981,6 @@ release_clock:
clk_put(info->clk);
release_irq:
free_irq(irq, info);
-release_regs:
- iounmap(info->io);
-release_mem:
- release_mem_region(res->start, size);
dealloc_fb:
platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
@@ -1033,10 +1013,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
free_irq(irq, info);
- iounmap(info->io);
-
- release_mem_region(info->mem->start, resource_size(info->mem));
-
platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 8/9] s3c2410fb: Remove redundant platform_set_drvdata()
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
driver_data field is being cleared by the driver core since
commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
device-core: Ensure drvdata = NULL when no driver is bound
hence there is no need to do it in the driver's remove() callback.
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 11f98ca..0439ed0 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -1013,7 +1013,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
free_irq(irq, info);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return 0;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 9/9] s3c2410fb: Use module parameter instead of a sysfs entry
From: Sylwester Nawrocki @ 2013-04-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-1-git-send-email-sylvester.nawrocki@gmail.com>
Use module parameter to set debug level instead of a sysfs
entry. Replace pr_debug() with pr_info() so we can actually
control the debug traces without DYNAMIC_PRINTK. This fixes
a sort of regression introduced in commit 81c1655811e941af2
video: s3c2410: Use pr_* and dev_* instead of printk
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
---
drivers/video/s3c2410fb.c | 48 +++++++-------------------------------------
1 files changed, 8 insertions(+), 40 deletions(-)
diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
index 0439ed0..c2ee75a 100644
--- a/drivers/video/s3c2410fb.c
+++ b/drivers/video/s3c2410fb.c
@@ -46,10 +46,13 @@ static int debug = 1;
static int debug;
#endif
-#define dprintk(msg...) \
-do { \
- if (debug) \
- pr_debug(msg); \
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-1)");
+
+#define dprintk(msg...) \
+do { \
+ if (debug) \
+ pr_info(msg); \
} while (0)
/* useful functions */
@@ -584,36 +587,6 @@ static int s3c2410fb_blank(int blank_mode, struct fb_info *info)
return 0;
}
-static int s3c2410fb_debug_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- return snprintf(buf, PAGE_SIZE, "%s\n", debug ? "on" : "off");
-}
-
-static int s3c2410fb_debug_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
-{
- if (len < 1)
- return -EINVAL;
-
- if (strnicmp(buf, "on", 2) = 0 ||
- strnicmp(buf, "1", 1) = 0) {
- debug = 1;
- dev_dbg(dev, "s3c2410fb: Debug On");
- } else if (strnicmp(buf, "off", 3) = 0 ||
- strnicmp(buf, "0", 1) = 0) {
- debug = 0;
- dev_dbg(dev, "s3c2410fb: Debug Off");
- } else {
- return -EINVAL;
- }
-
- return len;
-}
-
-static DEVICE_ATTR(debug, 0666, s3c2410fb_debug_show, s3c2410fb_debug_store);
-
static struct fb_ops s3c2410fb_ops = {
.owner = THIS_MODULE,
.fb_check_var = s3c2410fb_check_var,
@@ -962,17 +935,12 @@ static int s3c2410fb_probe(struct platform_device *pdev)
goto free_cpufreq;
}
- /* create device files */
- ret = device_create_file(&pdev->dev, &dev_attr_debug);
- if (ret)
- dev_err(&pdev->dev, "failed to add debug attribute\n");
-
dev_info(&pdev->dev, "fb%d: %s frame buffer device\n",
fbinfo->node, fbinfo->fix.id);
return 0;
- free_cpufreq:
+free_cpufreq:
s3c2410fb_cpufreq_deregister(info);
free_video_memory:
s3c2410fb_unmap_video_memory(fbinfo);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v8 0/3] Runtime Interpreted Power Sequences
From: Alexandre Courbot @ 2013-04-27 15:36 UTC (permalink / raw)
To: Simon Glass
Cc: Alexandre Courbot, Anton Vorontsov, Stephen Warren,
Thierry Reding, Mark Zhang, Grant Likely, Rob Herring, Mark Brown,
David Woodhouse, Arnd Bergmann, Leela Krishna Amudala,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lk,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree Discuss,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAPnjgZ1P6dmRB0sO2qBUtd=WBiNcY339NAit2faaotAfEqQDeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Simon,
On Sat, Apr 27, 2013 at 3:55 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On Thu, Nov 15, 2012 at 10:38 PM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> Hopefully the final series before the feature gets merged. Anton Vorontsov
>> kindly accepted to take it into his tree, so this series is mostly a call for
>> acks, tests and reviews notices before the merge window for 3.8 opens. If you
>> are interested in seeing this feature, please add your name.
>>
>> This series also adds an entry for the subsystem into MAINTAINERS, setting me as
>> the person in charge.
>>
>> Changes from v7:
>> - fix bug reported by Tony Prisk
>> - add MAINTAINERS entry
>>
>> Alexandre Courbot (3):
>> Runtime Interpreted Power Sequences
>> pwm_backlight: use power sequences
>> Take maintainership of power sequences
>
> Did this actually land? I can't see it in linux-next.
It has not landed yet, and will not land in the form that I proposed
initially. There were some obvious issues with describing the
sequences in the device tree, and I decided to rethink the whole
thing, study the state of the art some more (especially ACPI) and
start again from a blank page.
The v2 idea is almost ready to be shared, but it needs a cleaner way
to manage GPIOs, which itself requires gpiolib to be refactored and
the GENERIC_GPIO option to be removed. These last two items will land
in 3.10, so I hope to have both the gpiod interface *and* the new
power seqs ready and approved for 3.11. Then my $@?*^! panel backlight
will maybe finally switch on (no kidding - that's really what this
whole thing is about).
The new power seqs will fundamentally work in a similar fashion to v1
(a simple bytecode that controls power-related items), but will not be
encoded through the DT. Instead, I'd like to have small power control
objects that can be referenced by the platform data of pseq-enabled
drivers, or fetched and associated to the driver through the
compatible property of the DT. These objects will have, as before,
power resources they need to request, and power methods that the
driver can call as needed.
I hate to give dates, but my wish is to come with a first version of
the code by the time the merge window closes. And yes, I still plan to
use Anton as a trojan horse to get this in. ;)
Thanks,
Alex.
^ permalink raw reply
* Re: [PATCH v5 2/2] video: imxfb: Add DT support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-04-28 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1366810751-26860-3-git-send-email-mpa@pengutronix.de>
On 15:39 Wed 24 Apr , Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
> ---
>
> Notes:
> Changed in v5:
> - Fix compatible property of the example
> - Rename property fsl,bpp to bits-per-pixel
> - Add selects for FB_MODE_HELPERS and VIDEOMODE_HELPERS to Kconfig FB_IMX
>
> Changes in v4:
> - Remove eukrea specific dmacr property.
> - Add optional dmacr property. If not present, the dmacr reset value is not
> changed.
>
> Changes in v3:
> - Fix returncodes of of_read_mode function and print error messages
> - Introduce a lower bound check for bits per pixel
> - Calculate correct bytes per pixel value before using it for the calculation of
> memory size
> - Change DT property names
>
> Changes in v2:
> - Removed pwmr register property
> - Cleanup of devicetree binding documentation
> - Use default values for pwmr and lscr1
>
> .../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++++++
> drivers/video/Kconfig | 2 +
> drivers/video/imxfb.c | 194 +++++++++++++++++----
> 3 files changed, 212 insertions(+), 35 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> new file mode 100644
> index 0000000..46da08d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> @@ -0,0 +1,51 @@
> +Freescale imx21 Framebuffer
> +
> +This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
> +
> +Required properties:
> +- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : One interrupt of the fb dev
> +
> +Required nodes:
> +- display: Phandle to a display node as described in
> + Documentation/devicetree/bindings/video/display-timing.txt
> + Additional, the display node has to define properties:
> + - bits-per-pixel: Bits per pixel
> + - fsl,pcr: LCDC PCR value
> +
> +Optional properties:
> +- fsl,dmacr: DMA Control Register value. This is optional. By default, the
> + register is not modified as recommended by the datasheet.
> +- fsl,lscr1: LCDC Sharp Configuration Register value.
> +
> +Example:
> +
> + imxfb: fb@10021000 {
> + compatible = "fsl,imx21-fb";
> + interrupts = <61>;
> + reg = <0x10021000 0x1000>;
> + display = <&display0>;
> + };
> +
> + ...
> +
> + display0: display0 {
> + model = "Primeview-PD050VL1";
> + native-mode = <&timing_disp0>;
> + bits-per-pixel = <16>;
> + fsl,pcr = <0xf0c88080>; /* non-standard but required */
> + display-timings {
> + timing_disp0: 640x480 {
> + hactive = <640>;
> + vactive = <480>;
> + hback-porch = <112>;
> + hfront-porch = <36>;
> + hsync-len = <32>;
> + vback-porch = <33>;
> + vfront-porch = <33>;
> + vsync-len = <2>;
> + clock-frequency = <25000000>;
> + };
> + };
> + };
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4c1546f..44b1af4 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -391,6 +391,8 @@ config FB_IMX
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select FB_MODE_HELPERS
> + select VIDEOMODE_HELPERS
>
> config FB_CYBER2000
> tristate "CyberPro 2000/2010/5000 support"
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index ef2b587..7bb3728 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -32,6 +32,12 @@
> #include <linux/io.h>
> #include <linux/math64.h>
> #include <linux/uaccess.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +
> +#include <video/of_display_timing.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
>
> #include <linux/platform_data/video-imxfb.h>
>
> @@ -117,10 +123,11 @@
> #define LGWCR_GWAV(alpha) (((alpha) & 0xff) << 24)
> #define LGWCR_GWE (1 << 22)
>
> +#define IMXFB_LSCR1_DEFAULT 0x00120300
> +
> /* Used fb-mode. Can be set on kernel command line, therefore file-static. */
> static const char *fb_mode;
>
> -
> /*
> * These are the bitfields for each
> * display depth that we support.
> @@ -192,6 +199,19 @@ static struct platform_device_id imxfb_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>
> +static struct of_device_id imxfb_of_dev_id[] = {
> + {
> + .compatible = "fsl,imx1-fb",
> + .data = &imxfb_devtype[IMX1_FB],
> + }, {
> + .compatible = "fsl,imx21-fb",
> + .data = &imxfb_devtype[IMX21_FB],
> + }, {
> + /* sentinel */
> + }
> +};
> +MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
> +
> static inline int is_imx1_fb(struct imxfb_info *fbi)
> {
> return fbi->devtype = IMX1_FB;
> @@ -324,6 +344,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
> struct imx_fb_videomode *m;
> int i;
>
> + if (!fb_mode)
> + return &fbi->mode[0];
> +
> for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
> if (!strcmp(m->mode.name, fb_mode))
> return m;
> @@ -479,6 +502,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
> struct imxfb_info *fbi = bl_get_data(bl);
> int brightness = bl->props.brightness;
>
> + if (!fbi->pwmr)
> + return 0;
> +
> if (bl->props.power != FB_BLANK_UNBLANK)
> brightness = 0;
> if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> @@ -719,10 +745,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
>
> writel(fbi->pcr, fbi->regs + LCDC_PCR);
> #ifndef PWMR_BACKLIGHT_AVAILABLE
> - writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> + if (fbi->pwmr)
> + writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
> #endif
> writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
> - writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
> +
> + /* dmacr = 0 is no valid value, as we need DMA control marks. */
> + if (fbi->dmacr)
> + writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
>
> return 0;
> }
> @@ -758,13 +788,12 @@ static int imxfb_resume(struct platform_device *dev)
> #define imxfb_resume NULL
> #endif
>
> -static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> +static int imxfb_init_fbinfo(struct platform_device *pdev)
> {
> struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
> struct fb_info *info = dev_get_drvdata(&pdev->dev);
> struct imxfb_info *fbi = info->par;
> - struct imx_fb_videomode *m;
> - int i;
> + struct device_node *np;
>
> pr_debug("%s\n",__func__);
>
> @@ -795,41 +824,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
> info->fbops = &imxfb_ops;
> info->flags = FBINFO_FLAG_DEFAULT |
> FBINFO_READS_FAST;
> - info->var.grayscale = pdata->cmap_greyscale;
> - fbi->cmap_inverse = pdata->cmap_inverse;
> - fbi->cmap_static = pdata->cmap_static;
> - fbi->lscr1 = pdata->lscr1;
> - fbi->dmacr = pdata->dmacr;
> - fbi->pwmr = pdata->pwmr;
> - fbi->lcd_power = pdata->lcd_power;
> - fbi->backlight_power = pdata->backlight_power;
> -
> - for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
> - info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> - m->mode.xres * m->mode.yres * m->bpp / 8);
> + if (pdata) {
> + info->var.grayscale = pdata->cmap_greyscale;
> + fbi->cmap_inverse = pdata->cmap_inverse;
> + fbi->cmap_static = pdata->cmap_static;
> + fbi->lscr1 = pdata->lscr1;
> + fbi->dmacr = pdata->dmacr;
> + fbi->pwmr = pdata->pwmr;
> + fbi->lcd_power = pdata->lcd_power;
> + fbi->backlight_power = pdata->backlight_power;
> + } else {
> + np = pdev->dev.of_node;
> + info->var.grayscale = of_property_read_bool(np,
> + "cmap-greyscale");
> + fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
> + fbi->cmap_static = of_property_read_bool(np, "cmap-static");
> +
> + fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> + of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> +
> + of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> +
> + /* These two function pointers could be used by some specific
> + * platforms. */
> + fbi->lcd_power = NULL;
> + fbi->backlight_power = NULL;
> + }
> +
> + return 0;
> +}
> +
> +static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
> + struct imx_fb_videomode *imxfb_mode)
> +{
> + int ret;
> + struct fb_videomode *of_mode = &imxfb_mode->mode;
> + u32 bpp;
> + u32 pcr;
> +
> + ret = of_property_read_string(np, "model", &of_mode->name);
> + if (ret)
> + of_mode->name = NULL;
> +
> + ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
> + if (ret) {
> + dev_err(dev, "Failed to get videomode from DT\n");
> + return ret;
> + }
> +
> + ret = of_property_read_u32(np, "bits-per-pixel", &bpp);
> + ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
> +
> + if (ret) {
> + dev_err(dev, "Failed to read bpp and pcr from DT\n");
> + return -EINVAL;
> + }
> +
> + if (bpp < 1 || bpp > 255) {
> + dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
> + return -EINVAL;
> + }
> +
> + imxfb_mode->bpp = bpp;
> + imxfb_mode->pcr = pcr;
>
> return 0;
> }
>
> -static int __init imxfb_probe(struct platform_device *pdev)
> +static int imxfb_probe(struct platform_device *pdev)
> {
> struct imxfb_info *fbi;
> struct fb_info *info;
> struct imx_fb_platform_data *pdata;
> struct resource *res;
> + struct imx_fb_videomode *m;
> + const struct of_device_id *of_id;
> int ret, i;
> + int bytes_per_pixel;
>
> dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
>
> + of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
> + if (of_id)
> + pdev->id_entry = of_id->data;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res)
> return -ENODEV;
>
> pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(&pdev->dev,"No platform_data available\n");
> - return -ENOMEM;
> - }
>
> info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
> if (!info)
> @@ -837,15 +920,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
>
> fbi = info->par;
>
> - if (!fb_mode)
> - fb_mode = pdata->mode[0].mode.name;
> -
> platform_set_drvdata(pdev, info);
>
> ret = imxfb_init_fbinfo(pdev);
> if (ret < 0)
> goto failed_init;
>
> + if (pdata) {
> + if (!fb_mode)
> + fb_mode = pdata->mode[0].mode.name;
> +
> + fbi->mode = pdata->mode;
> + fbi->num_modes = pdata->num_modes;
> + } else {
> + struct device_node *display_np;
> + fb_mode = NULL;
> +
> + display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
> + if (!display_np) {
> + dev_err(&pdev->dev, "No display defined in devicetree\n");
> + ret = -EINVAL;
> + goto failed_of_parse;
> + }
> +
> + /*
> + * imxfb does not support more modes, we choose only the native
> + * mode.
> + */
> + fbi->num_modes = 1;
> +
> + fbi->mode = devm_kzalloc(&pdev->dev,
> + sizeof(struct imx_fb_videomode), GFP_KERNEL);
> + if (!fbi->mode) {
> + ret = -ENOMEM;
> + goto failed_of_parse;
> + }
> +
> + ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
> + if (ret)
> + goto failed_of_parse;
> + }
> +
> + /* Calculate maximum bytes used per pixel. In most cases this should
> + * be the same as m->bpp/8 */
> + m = &fbi->mode[0];
> + bytes_per_pixel = (m->bpp + 7) / 8;
> + for (i = 0; i < fbi->num_modes; i++, m++)
> + info->fix.smem_len = max_t(size_t, info->fix.smem_len,
> + m->mode.xres * m->mode.yres * bytes_per_pixel);
> +
> res = request_mem_region(res->start, resource_size(res),
> DRIVER_NAME);
> if (!res) {
> @@ -878,7 +1001,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
> goto failed_ioremap;
> }
>
> - if (!pdata->fixed_screen_cpu) {
> + /* Seems not being used by anyone, so no support for oftree */
> + if (!pdata || !pdata->fixed_screen_cpu) {
> fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
> fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
> fbi->map_size, &fbi->map_dma, GFP_KERNEL);
> @@ -903,18 +1027,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
> info->fix.smem_start = fbi->screen_dma;
> }
>
> - if (pdata->init) {
> + if (pdata && pdata->init) {
> ret = pdata->init(fbi->pdev);
> if (ret)
> goto failed_platform_init;
> }
>
> - fbi->mode = pdata->mode;
> - fbi->num_modes = pdata->num_modes;
>
> INIT_LIST_HEAD(&info->modelist);
> - for (i = 0; i < pdata->num_modes; i++)
> - fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
> + for (i = 0; i < fbi->num_modes; i++)
> + fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
>
> /*
> * This makes sure that our colour bitfield
> @@ -944,10 +1066,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
> failed_register:
> fb_dealloc_cmap(&info->cmap);
> failed_cmap:
> - if (pdata->exit)
> + if (pdata && pdata->exit)
> pdata->exit(fbi->pdev);
> failed_platform_init:
> - if (!pdata->fixed_screen_cpu)
> + if (pdata && !pdata->fixed_screen_cpu)
> dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
> fbi->map_dma);
> failed_map:
> @@ -956,6 +1078,7 @@ failed_ioremap:
> failed_getclock:
> release_mem_region(res->start, resource_size(res));
> failed_req:
> +failed_of_parse:
> kfree(info->pseudo_palette);
> failed_init:
> platform_set_drvdata(pdev, NULL);
> @@ -980,7 +1103,7 @@ static int imxfb_remove(struct platform_device *pdev)
> unregister_framebuffer(info);
>
> pdata = pdev->dev.platform_data;
> - if (pdata->exit)
> + if (pdata && pdata->exit)
> pdata->exit(fbi->pdev);
>
> fb_dealloc_cmap(&info->cmap);
> @@ -1009,6 +1132,7 @@ static struct platform_driver imxfb_driver = {
> .shutdown = imxfb_shutdown,
> .driver = {
> .name = DRIVER_NAME,
> + .of_match_table = imxfb_of_dev_id,
> },
> .id_table = imxfb_devtype,
> };
> --
> 1.8.1.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 00/10] OMAPDSS: Basic deferred probe support
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
Hi,
omapdss, omapfb and the panel drivers do not currently support deferred probe,
which is causing the display drivers fail when booting with DT.
This series adds very basic support for deferred probing, which hopefully fixes
the issues for omap4 panda and sdp boards with the current kernel.
Limitations:
* Deferred probe support for omap_vout and omapdrm is still totally missing.
* If it so happens that at omapfb probe time one panel has been probed, but
another has been deferred, only the probed one will be used.
* Only DPI, DSI and HDMI outputs have been fixed.
* Some panel drivers may need modifications to support EPROBE_DEFER
Patches based on linux-next, i.e. the latest omapdss stuff.
Tomi
Tomi Valkeinen (10):
OMAPDSS: Makefile: move omapfb after panels
OMAPFB: use module_platform_driver()
OMAPFB: defer probe if no displays
OMAPDSS: DSI: use platform_driver_register()
OMAPDSS: DSI: Add error handling for dsi_probe_pdata
OMAPDSS: DPI: use platform_driver_register()
OMAPDSS: DPI: Add error handling for dpi_probe_pdata
OMAPDSS: HDMI: use platform_driver_register()
OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata
OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
drivers/video/omap2/Makefile | 2 +-
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
drivers/video/omap2/dss/dpi.c | 35 +++++++++++++++++----------
drivers/video/omap2/dss/dsi.c | 35 +++++++++++++++++----------
drivers/video/omap2/dss/hdmi.c | 33 ++++++++++++++++---------
drivers/video/omap2/omapfb/omapfb-main.c | 30 +++--------------------
6 files changed, 71 insertions(+), 66 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 01/10] OMAPDSS: Makefile: move omapfb after panels
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
omapfb requires the panels to have been probed before omapfb's probe. We
currently manage that by having omapfb in late initcall level. However,
a much simpler way is to just change the makefile so that omapfb is
after the panel drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 5ea7cb9..296e5c5 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
obj-$(CONFIG_OMAP2_DSS) += dss/
-obj-$(CONFIG_FB_OMAP2) += omapfb/
obj-y += displays/
+obj-$(CONFIG_FB_OMAP2) += omapfb/
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/10] OMAPFB: use module_platform_driver()
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Instead of using platform_driver_probe(), use module_platform_driver()
so that we can support deferred probing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 28 +++-------------------------
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index f38348e..808f6af 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2422,7 +2422,7 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
return 0;
}
-static int __init omapfb_probe(struct platform_device *pdev)
+static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
int r = 0;
@@ -2595,6 +2595,7 @@ static int __exit omapfb_remove(struct platform_device *pdev)
}
static struct platform_driver omapfb_driver = {
+ .probe = omapfb_probe,
.remove = __exit_p(omapfb_remove),
.driver = {
.name = "omapfb",
@@ -2602,36 +2603,13 @@ static struct platform_driver omapfb_driver = {
},
};
-static int __init omapfb_init(void)
-{
- DBG("omapfb_init\n");
-
- if (platform_driver_probe(&omapfb_driver, omapfb_probe)) {
- printk(KERN_ERR "failed to register omapfb driver\n");
- return -ENODEV;
- }
-
- return 0;
-}
-
-static void __exit omapfb_exit(void)
-{
- DBG("omapfb_exit\n");
- platform_driver_unregister(&omapfb_driver);
-}
-
module_param_named(mode, def_mode, charp, 0);
module_param_named(vram, def_vram, charp, 0);
module_param_named(rotate, def_rotate, int, 0);
module_param_named(vrfb, def_vrfb, bool, 0);
module_param_named(mirror, def_mirror, bool, 0);
-/* late_initcall to let panel/ctrl drivers loaded first.
- * I guess better option would be a more dynamic approach,
- * so that omapfb reacts to new panels when they are loaded */
-late_initcall(omapfb_init);
-/*module_init(omapfb_init);*/
-module_exit(omapfb_exit);
+module_platform_driver(omapfb_driver);
MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@nokia.com>");
MODULE_DESCRIPTION("OMAP2/3 Framebuffer");
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/10] OMAPFB: defer probe if no displays
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
omapfb requires the panel drivers to have been probed when omapfb is
initialized. omapfb does not support insertion of new panels after its
probe. This causes a problem in case omapdss or the panel probes have
been deferred due to EPROBE_DEFER error, as omapfb won't find any
displays.
As a quick fix, this patch changes the omapfb probe so that if omapfb
does not find any displays, it'll return EPROBE_DEFER. This is not
perfect, as with a board with no displays, omapfb will get deferred
forever. Also, if the board has multiple displays, but only some of them
have been probed, omapfb will start and leave the unprobed displays out.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 808f6af..ff00d1d 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2484,7 +2484,7 @@ static int omapfb_probe(struct platform_device *pdev)
if (fbdev->num_displays = 0) {
dev_err(&pdev->dev, "no displays\n");
- r = -EINVAL;
+ r = -EPROBE_DEFER;
goto cleanup;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/10] OMAPDSS: DSI: use platform_driver_register()
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9b1c5ec..55fc0d4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5225,7 +5225,7 @@ static enum omap_channel dsi_get_channel(int module_id)
}
}
-static int __init dsi_init_display(struct omap_dss_device *dssdev)
+static int dsi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev dsi_get_dsidev_from_id(dssdev->phy.dsi.module);
@@ -5366,7 +5366,7 @@ static int dsi_get_clocks(struct platform_device *dsidev)
return 0;
}
-static struct omap_dss_device * __init dsi_find_dssdev(struct platform_device *pdev)
+static struct omap_dss_device *dsi_find_dssdev(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
struct dsi_data *dsi = dsi_get_dsidrv_data(pdev);
@@ -5398,7 +5398,7 @@ static struct omap_dss_device * __init dsi_find_dssdev(struct platform_device *p
return def_dssdev;
}
-static void __init dsi_probe_pdata(struct platform_device *dsidev)
+static void dsi_probe_pdata(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_dss_device *plat_dssdev;
@@ -5436,11 +5436,13 @@ static void __init dsi_probe_pdata(struct platform_device *dsidev)
DSSERR("device %s register failed: %d\n", dssdev->name, r);
omapdss_output_unset_device(&dsi->output);
dss_put_device(dssdev);
- return;
+ return r;
}
+
+ return 0;
}
-static void __init dsi_init_output(struct platform_device *dsidev)
+static void dsi_init_output(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_dss_output *out = &dsi->output;
@@ -5465,7 +5467,7 @@ static void __exit dsi_uninit_output(struct platform_device *dsidev)
}
/* DSI1 HW IP initialisation */
-static int __init omap_dsihw_probe(struct platform_device *dsidev)
+static int omap_dsihw_probe(struct platform_device *dsidev)
{
u32 rev;
int r, i;
@@ -5632,6 +5634,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
};
static struct platform_driver omap_dsihw_driver = {
+ .probe = omap_dsihw_probe,
.remove = __exit_p(omap_dsihw_remove),
.driver = {
.name = "omapdss_dsi",
@@ -5642,7 +5645,7 @@ static struct platform_driver omap_dsihw_driver = {
int __init dsi_init_platform_driver(void)
{
- return platform_driver_probe(&omap_dsihw_driver, omap_dsihw_probe);
+ return platform_driver_register(&omap_dsihw_driver);
}
void __exit dsi_uninit_platform_driver(void)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/10] OMAPDSS: DSI: Add error handling for dsi_probe_pdata
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Add proper error handling for dsi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DSI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 55fc0d4..a73dedc 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5398,7 +5398,7 @@ static struct omap_dss_device *dsi_find_dssdev(struct platform_device *pdev)
return def_dssdev;
}
-static void dsi_probe_pdata(struct platform_device *dsidev)
+static int dsi_probe_pdata(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_dss_device *plat_dssdev;
@@ -5408,11 +5408,11 @@ static void dsi_probe_pdata(struct platform_device *dsidev)
plat_dssdev = dsi_find_dssdev(dsidev);
if (!plat_dssdev)
- return;
+ return 0;
dssdev = dss_alloc_and_init_device(&dsidev->dev);
if (!dssdev)
- return;
+ return -ENOMEM;
dss_copy_device_pdata(dssdev, plat_dssdev);
@@ -5420,7 +5420,7 @@ static void dsi_probe_pdata(struct platform_device *dsidev)
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
dss_put_device(dssdev);
- return;
+ return r;
}
r = omapdss_output_set_device(&dsi->output, dssdev);
@@ -5428,7 +5428,7 @@ static void dsi_probe_pdata(struct platform_device *dsidev)
DSSERR("failed to connect output to new device: %s\n",
dssdev->name);
dss_put_device(dssdev);
- return;
+ return r;
}
r = dss_add_device(dssdev);
@@ -5458,7 +5458,7 @@ static void dsi_init_output(struct platform_device *dsidev)
dss_register_output(out);
}
-static void __exit dsi_uninit_output(struct platform_device *dsidev)
+static void dsi_uninit_output(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_dss_output *out = &dsi->output;
@@ -5563,7 +5563,13 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
dsi_init_output(dsidev);
- dsi_probe_pdata(dsidev);
+ r = dsi_probe_pdata(dsidev);
+ if (r) {
+ dsi_runtime_put(dsidev);
+ dsi_uninit_output(dsidev);
+ pm_runtime_disable(&dsidev->dev);
+ return r;
+ }
dsi_runtime_put(dsidev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/10] OMAPDSS: DPI: use platform_driver_register()
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e93c4de..2024787 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -520,7 +520,7 @@ void omapdss_dpi_set_data_lines(struct omap_dss_device *dssdev, int data_lines)
}
EXPORT_SYMBOL(omapdss_dpi_set_data_lines);
-static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
+static int dpi_verify_dsi_pll(struct platform_device *dsidev)
{
int r;
@@ -572,7 +572,7 @@ static enum omap_channel dpi_get_channel(void)
}
}
-static int __init dpi_init_display(struct omap_dss_device *dssdev)
+static int dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
@@ -607,7 +607,7 @@ static int __init dpi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static struct omap_dss_device * __init dpi_find_dssdev(struct platform_device *pdev)
+static struct omap_dss_device *dpi_find_dssdev(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
const char *def_disp_name = omapdss_get_default_display_name();
@@ -635,7 +635,7 @@ static struct omap_dss_device * __init dpi_find_dssdev(struct platform_device *p
return def_dssdev;
}
-static void __init dpi_probe_pdata(struct platform_device *dpidev)
+static void dpi_probe_pdata(struct platform_device *dpidev)
{
struct omap_dss_device *plat_dssdev;
struct omap_dss_device *dssdev;
@@ -676,7 +676,7 @@ static void __init dpi_probe_pdata(struct platform_device *dpidev)
}
}
-static void __init dpi_init_output(struct platform_device *pdev)
+static void dpi_init_output(struct platform_device *pdev)
{
struct omap_dss_output *out = &dpi.output;
@@ -696,7 +696,7 @@ static void __exit dpi_uninit_output(struct platform_device *pdev)
dss_unregister_output(out);
}
-static int __init omap_dpi_probe(struct platform_device *pdev)
+static int omap_dpi_probe(struct platform_device *pdev)
{
mutex_init(&dpi.lock);
@@ -717,6 +717,7 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
}
static struct platform_driver omap_dpi_driver = {
+ .probe = omap_dpi_probe,
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = "omapdss_dpi",
@@ -726,7 +727,7 @@ static struct platform_driver omap_dpi_driver = {
int __init dpi_init_platform_driver(void)
{
- return platform_driver_probe(&omap_dpi_driver, omap_dpi_probe);
+ return platform_driver_register(&omap_dpi_driver);
}
void __exit dpi_uninit_platform_driver(void)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/10] OMAPDSS: DPI: Add error handling for dpi_probe_pdata
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Add proper error handling for dpi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DPI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dpi.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 2024787..757b57f 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -635,7 +635,7 @@ static struct omap_dss_device *dpi_find_dssdev(struct platform_device *pdev)
return def_dssdev;
}
-static void dpi_probe_pdata(struct platform_device *dpidev)
+static int dpi_probe_pdata(struct platform_device *dpidev)
{
struct omap_dss_device *plat_dssdev;
struct omap_dss_device *dssdev;
@@ -644,11 +644,11 @@ static void dpi_probe_pdata(struct platform_device *dpidev)
plat_dssdev = dpi_find_dssdev(dpidev);
if (!plat_dssdev)
- return;
+ return 0;
dssdev = dss_alloc_and_init_device(&dpidev->dev);
if (!dssdev)
- return;
+ return -ENOMEM;
dss_copy_device_pdata(dssdev, plat_dssdev);
@@ -656,7 +656,7 @@ static void dpi_probe_pdata(struct platform_device *dpidev)
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
dss_put_device(dssdev);
- return;
+ return r;
}
r = omapdss_output_set_device(&dpi.output, dssdev);
@@ -664,7 +664,7 @@ static void dpi_probe_pdata(struct platform_device *dpidev)
DSSERR("failed to connect output to new device: %s\n",
dssdev->name);
dss_put_device(dssdev);
- return;
+ return r;
}
r = dss_add_device(dssdev);
@@ -672,8 +672,10 @@ static void dpi_probe_pdata(struct platform_device *dpidev)
DSSERR("device %s register failed: %d\n", dssdev->name, r);
omapdss_output_unset_device(&dpi.output);
dss_put_device(dssdev);
- return;
+ return r;
}
+
+ return 0;
}
static void dpi_init_output(struct platform_device *pdev)
@@ -698,11 +700,17 @@ static void __exit dpi_uninit_output(struct platform_device *pdev)
static int omap_dpi_probe(struct platform_device *pdev)
{
+ int r;
+
mutex_init(&dpi.lock);
dpi_init_output(pdev);
- dpi_probe_pdata(pdev);
+ r = dpi_probe_pdata(pdev);
+ if (r) {
+ dpi_uninit_output(pdev);
+ return r;
+ }
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/10] OMAPDSS: HDMI: use platform_driver_register()
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 7939309..9aefe60 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -328,7 +328,7 @@ static void hdmi_runtime_put(void)
WARN_ON(r < 0 && r != -ENOSYS);
}
-static int __init hdmi_init_display(struct omap_dss_device *dssdev)
+static int hdmi_init_display(struct omap_dss_device *dssdev)
{
int r;
@@ -954,7 +954,7 @@ int hdmi_audio_config(struct omap_dss_audio *audio)
#endif
-static struct omap_dss_device * __init hdmi_find_dssdev(struct platform_device *pdev)
+static struct omap_dss_device *hdmi_find_dssdev(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
const char *def_disp_name = omapdss_get_default_display_name();
@@ -982,7 +982,7 @@ static struct omap_dss_device * __init hdmi_find_dssdev(struct platform_device *
return def_dssdev;
}
-static void __init hdmi_probe_pdata(struct platform_device *pdev)
+static void hdmi_probe_pdata(struct platform_device *pdev)
{
struct omap_dss_device *plat_dssdev;
struct omap_dss_device *dssdev;
@@ -1031,7 +1031,7 @@ static void __init hdmi_probe_pdata(struct platform_device *pdev)
}
}
-static void __init hdmi_init_output(struct platform_device *pdev)
+static void hdmi_init_output(struct platform_device *pdev)
{
struct omap_dss_output *out = &hdmi.output;
@@ -1052,7 +1052,7 @@ static void __exit hdmi_uninit_output(struct platform_device *pdev)
}
/* HDMI HW IP initialisation */
-static int __init omapdss_hdmihw_probe(struct platform_device *pdev)
+static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
struct resource *res;
int r;
@@ -1151,6 +1151,7 @@ static const struct dev_pm_ops hdmi_pm_ops = {
};
static struct platform_driver omapdss_hdmihw_driver = {
+ .probe = omapdss_hdmihw_probe,
.remove = __exit_p(omapdss_hdmihw_remove),
.driver = {
.name = "omapdss_hdmi",
@@ -1161,7 +1162,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
int __init hdmi_init_platform_driver(void)
{
- return platform_driver_probe(&omapdss_hdmihw_driver, omapdss_hdmihw_probe);
+ return platform_driver_register(&omapdss_hdmihw_driver);
}
void __exit hdmi_uninit_platform_driver(void)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/10] OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
Add proper error handling for hdmi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the HDMI driver to be
probed again later if a resource was missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 9aefe60..17f4d55 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -982,7 +982,7 @@ static struct omap_dss_device *hdmi_find_dssdev(struct platform_device *pdev)
return def_dssdev;
}
-static void hdmi_probe_pdata(struct platform_device *pdev)
+static int hdmi_probe_pdata(struct platform_device *pdev)
{
struct omap_dss_device *plat_dssdev;
struct omap_dss_device *dssdev;
@@ -992,11 +992,11 @@ static void hdmi_probe_pdata(struct platform_device *pdev)
plat_dssdev = hdmi_find_dssdev(pdev);
if (!plat_dssdev)
- return;
+ return 0;
dssdev = dss_alloc_and_init_device(&pdev->dev);
if (!dssdev)
- return;
+ return -ENOMEM;
dss_copy_device_pdata(dssdev, plat_dssdev);
@@ -1010,7 +1010,7 @@ static void hdmi_probe_pdata(struct platform_device *pdev)
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
dss_put_device(dssdev);
- return;
+ return r;
}
r = omapdss_output_set_device(&hdmi.output, dssdev);
@@ -1018,7 +1018,7 @@ static void hdmi_probe_pdata(struct platform_device *pdev)
DSSERR("failed to connect output to new device: %s\n",
dssdev->name);
dss_put_device(dssdev);
- return;
+ return r;
}
r = dss_add_device(dssdev);
@@ -1027,8 +1027,10 @@ static void hdmi_probe_pdata(struct platform_device *pdev)
omapdss_output_unset_device(&hdmi.output);
hdmi_uninit_display(dssdev);
dss_put_device(dssdev);
- return;
+ return r;
}
+
+ return 0;
}
static void hdmi_init_output(struct platform_device *pdev)
@@ -1096,7 +1098,13 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
- hdmi_probe_pdata(pdev);
+ r = hdmi_probe_pdata(pdev);
+ if (r) {
+ hdmi_panel_exit();
+ hdmi_uninit_output(pdev);
+ pm_runtime_disable(&pdev->dev);
+ return r;
+ }
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/10] OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
From: Tomi Valkeinen @ 2013-04-29 10:22 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Tony Lindgren, grygorii.strashko, chf.fritz, Archit Taneja,
Tomi Valkeinen
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
If the I2C adapter needed by the TFP410 device is not available yet,
return EPROBE_DEFER so that the device will get probed again.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays/panel-tfp410.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index a1dba868..46039c4 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -135,7 +135,7 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
if (!adapter) {
dev_err(&dssdev->dev, "Failed to get I2C adapter, bus %d\n",
i2c_bus_num);
- return -EINVAL;
+ return -EPROBE_DEFER;
}
ddata->i2c_adapter = adapter;
--
1.7.10.4
^ permalink raw reply related
* [GIT PULL] fbdev changes for 3.10
From: Tomi Valkeinen @ 2013-04-29 11:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6642 bytes --]
Hi Linus,
The following changes since commit 60d509fa6a9c4653a86ad830e4c4b30360b23f0e:
Linux 3.9-rc8 (2013-04-21 14:38:45 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-for-3.10
for you to fetch changes up to 9bf9d47a29afbf7a43eae74a988a4aefe88ccbfd:
Merge branch '3.10/fb-mmap' into for-next (2013-04-26 09:14:47 +0300)
----------------------------------------------------------------
fbdev for 3.10
* use vm_iomap_memory() in various fb drivers to map the fb memory to userspace
* Cleanups for the videomode and display_timing features
* Updates to vt8500, wm8505 and auo-k190x fb drivers
----------------------------------------------------------------
Arnd Bergmann (2):
video/exynos: remove unnecessary header inclusions
video/s3c: move platform_data out of arch/arm
Fabio Porcedda (1):
drivers: video: use module_platform_driver_probe()
Heiko Stübner (9):
AUO-K190x: Use correct line length
AUO-K190x: add runtime-pm calls to controller init functions
AUO-K190x: set the correct runtime-pm state in recover
AUO-K190x: make memory check in check_var more flexible
AUO-K190x: move var resolution-handling into check_var
AUO-K190x: make color handling more flexible
AUO-K190x: add a 16bit truecolor mode
AUO-K190x: add framebuffer rotation support
AUO-K190x: Add resolutions for portrait displays
Julia Lawall (1):
drivers/video/wm8505fb.c: use devm_ functions
Paul Bolle (1):
ARM: OMAP: remove "config FB_OMAP_CONSISTENT_DMA_SIZE"
Sachin Kamat (1):
video: wm8505fb: Convert to devm_ioremap_resource()
Timur Tabi (1):
drivers/video: fsl-diu-fb: add hardware cursor support
Tomi Valkeinen (17):
videomode: simplify videomode Kconfig and Makefile
videomode: combine videomode dmt_flags and data_flags
videomode: create enum for videomode's display flags
videomode: remove timing_entry_index
videomode: videomode_from_timing work
fbdev: Merge fbdev topic branches
video: vt8500: fix Kconfig for videomode
fbdev/omapfb: use vm_iomap_memory()
fbdev/controlfb: use vm_iomap_memory()
fbdev/fb-puv3: use vm_iomap_memory()
fbdev/sa1100fb: use vm_iomap_memory()
fbdev/vermillion: use vm_iomap_memory()
fbdev/sgivwfb: use vm_iomap_memory()
fbdev/ps3fb: use vm_iomap_memory()
fbdev: improve fb_mmap bounds checks
fbdev: fix check for fb_mmap's mmio availability
Merge branch '3.10/fb-mmap' into for-next
Tony Prisk (5):
video: vt8500: Make wmt_ge_rops optional
video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
video: vt8500: Correct descriptions in video/Kconfig
video: vt8500: Adjust contrast in wm8505 framebuffer driver.
video: fb: vt8500: Convert framebuffer drivers to standardized binding
.../devicetree/bindings/video/via,vt8500-fb.txt | 48 +---
.../devicetree/bindings/video/wm,wm8505-fb.txt | 32 ++-
arch/arm/boot/dts/vt8500-bv07.dts | 34 ++-
arch/arm/boot/dts/vt8500.dtsi | 4 +-
arch/arm/boot/dts/wm8505-ref.dts | 34 ++-
arch/arm/boot/dts/wm8505.dtsi | 4 +-
arch/arm/boot/dts/wm8650-mid.dts | 36 ++-
arch/arm/boot/dts/wm8650.dtsi | 4 +-
arch/arm/boot/dts/wm8850-w70v2.dts | 40 ++--
arch/arm/boot/dts/wm8850.dtsi | 4 +-
arch/arm/plat-samsung/include/plat/fb.h | 50 +----
drivers/gpu/drm/drm_modes.c | 20 +-
drivers/gpu/drm/tilcdc/Kconfig | 3 +-
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
drivers/video/Kconfig | 57 ++---
drivers/video/Makefile | 8 +-
drivers/video/amifb.c | 14 +-
drivers/video/atmel_lcdfb.c | 13 +-
drivers/video/auo_k1900fb.c | 11 +-
drivers/video/auo_k1901fb.c | 11 +-
drivers/video/auo_k190x.c | 235 ++++++++++++++++----
drivers/video/controlfb.c | 50 ++---
drivers/video/exynos/exynos_mipi_dsi.c | 2 -
drivers/video/exynos/exynos_mipi_dsi_common.c | 2 -
drivers/video/exynos/exynos_mipi_dsi_lowlevel.c | 2 -
drivers/video/fb-puv3.c | 14 +-
drivers/video/fbmem.c | 5 +
drivers/video/fbmon.c | 16 +-
drivers/video/fsl-diu-fb.c | 157 ++++++++++++-
drivers/video/gbefb.c | 4 +-
drivers/video/of_display_timing.c | 19 +-
drivers/video/of_videomode.c | 2 +-
drivers/video/omap/Kconfig | 11 -
drivers/video/omap2/omapfb/omapfb-main.c | 30 +--
drivers/video/omap2/vrfb.c | 13 +-
drivers/video/ps3fb.c | 18 +-
drivers/video/s3c-fb.c | 3 +-
drivers/video/sa1100fb.c | 16 +-
drivers/video/sgivwfb.c | 20 +-
drivers/video/sh_mipi_dsi.c | 12 +-
drivers/video/sh_mobile_hdmi.c | 12 +-
drivers/video/smscufx.c | 6 +-
drivers/video/udlfb.c | 6 +-
drivers/video/vermilion/vermilion.c | 14 +-
drivers/video/vfb.c | 7 +-
drivers/video/videomode.c | 36 +--
drivers/video/vt8500lcdfb.c | 55 ++---
drivers/video/wm8505fb.c | 145 ++++--------
drivers/video/wmt_ge_rops.h | 23 ++
include/linux/platform_data/video-vt8500lcdfb.h | 31 ---
include/linux/platform_data/video_s3c.h | 54 +++++
include/video/auo_k190xfb.h | 3 +-
include/video/display_timing.h | 57 ++---
include/video/videomode.h | 18 +-
54 files changed, 799 insertions(+), 728 deletions(-)
delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
create mode 100644 include/linux/platform_data/video_s3c.h
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-04-29 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51671F3D.5040501@wwwdotorg.org>
Hi Stephen,
Sorry for the late reply.
On Thursday 11 April 2013 14:38:21 Stephen Warren wrote:
> On 04/11/2013 02:06 PM, Laurent Pinchart wrote:
> > On Thursday 11 April 2013 10:06:49 Stephen Warren wrote:
> >> On 04/11/2013 03:56 AM, Laurent Pinchart wrote:
> >>> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> >>>> On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> >>>>> A simple frame-buffer describes a raw memory region that may be
> >>>>> rendered to, with the assumption that the display hardware has already
> >>>>> been set up to scan out from that buffer.
> >>>>>
> >>>>> This is useful in cases where a bootloader exists and has set up the
> >>>>> display hardware, but a Linux driver doesn't yet exist for the display
> >>>>> hardware.
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> +config FB_SIMPLE
> >>>>> + bool "Simple framebuffer support"
> >>>>> + depends on (FB = y) && OF
> >>>>
> >>>> It's sad that this simple little thing requires Open Firmware. Could
> >>>> it be generalised in some way so that the small amount of setup info
> >>>> could be provided by other means (eg, module_param) or does the
> >>>> dependency go deeper than that?
> >>>
> >>> I second that request. I like the idea of a simple framebuffer driver if
> >>> it helps deprecating fbdev in the long term, but I don't want it to
> >>> offer an excuse not to implement a DRM/KMS driver. In particular adding
> >>> DT bindings would force us to keep supporting the ABI for a (too) long
> >>> time.
> >>
> >> The platforms I intend to use this with only support device tree. Adding
> >> support for platform data right now would just be dead code. If somebody
> >> wants to use this driver with a board file based system rather than a DT
> >> based system, it would be trivial do modify the driver to add a platform
> >> data structure at that time.
> >
> > What about using module parameters instead of DT bindings and platform
> > data ? As this is a hack designed to work around the lack of a proper
> > display driver the frame buffer address and size could just be passed by
> > the boot loader through the kernel command line, and the device would
> > then be instantiated by the driver.
>
> I'm afraid I strongly dislike the idea of using module parameters. One
> of the things that I dislike the most about NVIDIA's downstream Android
> kernels is the huge number of random parameters that are required on the
> kernel command-line just to get it to boot.
>
> I'd specifically prefer the configuration for this driver to be a device
> tree binding so that it /is/ an ABI. That way, arbitrary software that
> boots the Linux kernel will be able to target a common standard for how
> to pass this information to the kernel. If we move to module parameters
> instead, especially with the specific intent that the format of those
> parameters is no longer an ABI, we run in to issues where a new kernel
> requires a bootloader update in order to generate the new set of module
> parameters that are required by the driver. If we say the module
> parameters will never change except in a backwards-compatible fashion,
> and hence that issue won't arise, then why not just make it a DT binding?
>
> Do module parameters handle the case of multiple device instances?
Not well. It can be handled manually by using parameter arrays, but that's a
bit hackish.
> Also, I really don't see this driver as a hack. It's a perfectly reasonable
> situation to have some other SW set up the frame-buffer, and Linux simply
> continue to use it. Perhaps that other SW even ran on a difference CPU, or
> the parameters are hard-coded in HW design, and so there's no HW that Linux
> ever could drive, so it just isn't possible to create any more advanced
> driver.
I totally agree that this driver would be very useful during board bring-up.
My concern is that it would also give an incentive to vendors not to develop a
proper KMS driver (or rather remove an incentive to develop one).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomasz Figa @ 2013-04-29 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2569832.XQDrhUGNaI@avalon>
Hi Laurent,
On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > A simple frame-buffer describes a raw memory region that may be
> > > rendered to, with the assumption that the display hardware has
> > > already been set up to scan out from that buffer.
> > >
> > > This is useful in cases where a bootloader exists and has set up the
> > > display hardware, but a Linux driver doesn't yet exist for the
> > > display
> > > hardware.
> > >
> > > ...
> > >
> > > +config FB_SIMPLE
> > > + bool "Simple framebuffer support"
> > > + depends on (FB = y) && OF
> >
> > It's sad that this simple little thing requires Open Firmware. Could
> > it be generalised in some way so that the small amount of setup info
> > could be provided by other means (eg, module_param) or does the
> > dependency go deeper than that?
>
> I second that request. I like the idea of a simple framebuffer driver if
> it helps deprecating fbdev in the long term, but I don't want it to
> offer an excuse not to implement a DRM/KMS driver. In particular adding
> DT bindings would force us to keep supporting the ABI for a (too) long
> time.
Well, there is also at least one legitimate use case for this driver.
I believe there exist embedded devices on which there is no need to
dynamically control the framebuffer. It needs one time initialization,
usually in bootloader, and then it is used as is, using constant
parameters as long as the system is running.
I doubt there is a need for any KMS (or any other control) driver for such
devices - dumb framebuffer driver would be everything needed in such case.
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-04-29 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2863648.BDvrAG5uPk@flatron>
Hi Tomasz,
On Monday 29 April 2013 23:15:13 Tomasz Figa wrote:
> On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > > On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > > A simple frame-buffer describes a raw memory region that may be
> > > > rendered to, with the assumption that the display hardware has
> > > > already been set up to scan out from that buffer.
> > > >
> > > > This is useful in cases where a bootloader exists and has set up the
> > > > display hardware, but a Linux driver doesn't yet exist for the
> > > > display hardware.
> > > >
> > > > ...
> > > >
> > > > +config FB_SIMPLE
> > > > + bool "Simple framebuffer support"
> > > > + depends on (FB = y) && OF
> > >
> > > It's sad that this simple little thing requires Open Firmware. Could
> > > it be generalised in some way so that the small amount of setup info
> > > could be provided by other means (eg, module_param) or does the
> > > dependency go deeper than that?
> >
> > I second that request. I like the idea of a simple framebuffer driver if
> > it helps deprecating fbdev in the long term, but I don't want it to
> > offer an excuse not to implement a DRM/KMS driver. In particular adding
> > DT bindings would force us to keep supporting the ABI for a (too) long
> > time.
>
> Well, there is also at least one legitimate use case for this driver.
>
> I believe there exist embedded devices on which there is no need to
> dynamically control the framebuffer. It needs one time initialization,
> usually in bootloader, and then it is used as is, using constant
> parameters as long as the system is running.
>
> I doubt there is a need for any KMS (or any other control) driver for such
> devices - dumb framebuffer driver would be everything needed in such case.
As we want to deprecate the fbdev API we would need to move to KMS at some
point anyway, even if the device can't be controlled. I don't think writting
such a KMS driver would be that difficult.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomasz Figa @ 2013-04-29 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1461633.kfcPFxva7x@avalon>
On Monday 29 of April 2013 23:20:43 Laurent Pinchart wrote:
> Hi Tomasz,
>
> On Monday 29 April 2013 23:15:13 Tomasz Figa wrote:
> > On Thursday 11 of April 2013 11:56:31 Laurent Pinchart wrote:
> > > On Monday 08 April 2013 17:16:37 Andrew Morton wrote:
> > > > On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren wrote:
> > > > > A simple frame-buffer describes a raw memory region that may be
> > > > > rendered to, with the assumption that the display hardware has
> > > > > already been set up to scan out from that buffer.
> > > > >
> > > > > This is useful in cases where a bootloader exists and has set up
> > > > > the
> > > > > display hardware, but a Linux driver doesn't yet exist for the
> > > > > display hardware.
> > > > >
> > > > > ...
> > > > >
> > > > > +config FB_SIMPLE
> > > > > + bool "Simple framebuffer support"
> > > > > + depends on (FB = y) && OF
> > > >
> > > > It's sad that this simple little thing requires Open Firmware.
> > > > Could
> > > > it be generalised in some way so that the small amount of setup
> > > > info
> > > > could be provided by other means (eg, module_param) or does the
> > > > dependency go deeper than that?
> > >
> > > I second that request. I like the idea of a simple framebuffer
> > > driver if it helps deprecating fbdev in the long term, but I don't
> > > want it to offer an excuse not to implement a DRM/KMS driver. In
> > > particular adding DT bindings would force us to keep supporting the
> > > ABI for a (too) long time.
> >
> > Well, there is also at least one legitimate use case for this driver.
> >
> > I believe there exist embedded devices on which there is no need to
> > dynamically control the framebuffer. It needs one time initialization,
> > usually in bootloader, and then it is used as is, using constant
> > parameters as long as the system is running.
> >
> > I doubt there is a need for any KMS (or any other control) driver for
> > such devices - dumb framebuffer driver would be everything needed in
> > such case.
> As we want to deprecate the fbdev API we would need to move to KMS at
> some point anyway, even if the device can't be controlled. I don't
> think writting such a KMS driver would be that difficult.
Good point. Stephen, would it be a problem to make this a KMS driver
instead? Old fbdev API could be emulated on top of it, until it goes out
of use, couldn't it?
Best regards,
Tomasz
^ 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