* [PATCH 1/2] fbdev: shmobile-lcdcfb: Use NULL instead of 0 as NULL pointer
From: Laurent Pinchart @ 2014-01-21 11:59 UTC (permalink / raw)
To: linux-fbdev
Setting a pointer to NULL shouldn't use 0.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index ab85ad6..2bcc84a 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1227,7 +1227,7 @@ static void sh_mobile_lcdc_stop(struct sh_mobile_lcdc_priv *priv)
/* Free the MERAM cache. */
if (ch->cache) {
sh_mobile_meram_cache_free(priv->meram_dev, ch->cache);
- ch->cache = 0;
+ ch->cache = NULL;
}
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/2] fbdev: shmobile-lcdcfb: Fix sparse address space cast warning
From: Laurent Pinchart @ 2014-01-21 11:59 UTC (permalink / raw)
To: linux-fbdev
The fbdev screen_base field stores the frame buffer base address.
Depending on the drivers this is either an I/O memory pointer or a
kernel virtual pointer.
The field is marked with the __iomem address space type, cast the kernel
pointer to __iomem to make sparse happy.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 2bcc84a..5805044 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1710,7 +1710,7 @@ sh_mobile_lcdc_overlay_fb_init(struct sh_mobile_lcdc_overlay *ovl)
info->flags = FBINFO_FLAG_DEFAULT;
info->fbops = &sh_mobile_lcdc_overlay_ops;
info->device = priv->dev;
- info->screen_base = ovl->fb_mem;
+ info->screen_base = (char __force __iomem *)ovl->fb_mem;
info->par = ovl;
/* Initialize fixed screen information. Restrict pan to 2 lines steps
@@ -2212,7 +2212,7 @@ sh_mobile_lcdc_channel_fb_init(struct sh_mobile_lcdc_chan *ch,
info->flags = FBINFO_FLAG_DEFAULT;
info->fbops = &sh_mobile_lcdc_ops;
info->device = priv->dev;
- info->screen_base = ch->fb_mem;
+ info->screen_base = (char __force __iomem *)ch->fb_mem;
info->pseudo_palette = &ch->pseudo_palette;
info->par = ch;
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCHv3 30/41] ARM: omap3-n900.dts: add display information
From: Sebastian Reichel @ 2014-01-21 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-31-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
> Add DT data for OMAP3 N900 board. The board has the following
> displays:
>
> lcd: LCD panel connected to OMAP's SDI output
> tv: analog svideo
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Your dss-dt-review-3 branch boots on my N900 with working display.
Tested-by: Sebastian Reichel <sre@debian.org>
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv3 39/41] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Sebastian Reichel @ 2014-01-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-40-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
On Tue, Jan 21, 2014 at 12:57:11PM +0200, Tomi Valkeinen wrote:
> Add DT binding documentation for Sony acx565akm panel
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2014-01-21 15:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki, linux-fbdev, linux-kernel, shuahkhan,
Shuah Khan
In-Reply-To: <15798389.lgk83XnI1i@vostro.rjw.lan>
On 01/19/2014 08:37 AM, Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2040 04:27:17 AM Shuah Khan wrote:
>> Convert drivers/video/backlight/class to use dev_pm_ops for power
>> management and remove Legacy PM ops hooks. With this change, rtc class
>> registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
>> Legacy class->suspend/resume. When __device_suspend() runs call-backs,
>> it will find class->pm ops for the backlight class.
>>
>> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
>> Cc: Shuah Khan <shuahkhan@gmail.com>
>
> Can you please resend the patches that nobody took with CCs to
> linux-pm@vger.kernel.org? If the original maintainers don't care, I'll be
> able to pick those patches up then (if they look good).
>
Rafael,
Thanks. I have a few legacy pm patches that didn't get pulled into
trees. I will rebase to the latest and resend.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply
* [PATCH 32/73] logo: emit "#include <linux/init.h> in autogenerated C file
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-arch, Paul Gortmaker, linux-fbdev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
The header linux_logo.h itself does not use any __init type
directives, but the autogenerated C file itself does. Hence
move the include directive into the autogenerated file.
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
include/linux/linux_logo.h | 3 ---
scripts/pnmtologo.c | 1 +
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/linux_logo.h b/include/linux/linux_logo.h
index ca5bd91..aea584c 100644
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -14,9 +14,6 @@
* but should contain %s to display the version
*/
-#include <linux/init.h>
-
-
#define LINUX_LOGO_MONO 1 /* monochrome black/white */
#define LINUX_LOGO_VGA16 2 /* 16 colors VGA text palette */
#define LINUX_LOGO_CLUT224 3 /* 224 colors */
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 68bb4ef..06a4b4e 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -243,6 +243,7 @@ static void write_header(void)
fputs(" *\n", out);
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
+ fputs("#include <linux/init.h>\n", out);
fputs("#include <linux/linux_logo.h>\n\n", out);
fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
logoname);
--
1.8.4.1
^ permalink raw reply related
* [PATCH 41/73] video: delete non-required instances of include <linux/init.h>
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, Paul Gortmaker, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/video/aty/aty128fb.c | 1 -
drivers/video/aty/mach64_cursor.c | 1 -
drivers/video/auo_k1900fb.c | 1 -
drivers/video/auo_k1901fb.c | 1 -
drivers/video/backlight/88pm860x_bl.c | 1 -
drivers/video/backlight/adp5520_bl.c | 1 -
drivers/video/backlight/adp8860_bl.c | 1 -
drivers/video/backlight/adp8870_bl.c | 1 -
drivers/video/backlight/corgi_lcd.c | 1 -
drivers/video/backlight/da903x_bl.c | 1 -
drivers/video/backlight/generic_bl.c | 1 -
drivers/video/backlight/ili922x.c | 1 -
drivers/video/backlight/ili9320.c | 1 -
drivers/video/backlight/lm3533_bl.c | 1 -
drivers/video/backlight/ltv350qv.c | 1 -
drivers/video/backlight/max8925_bl.c | 1 -
drivers/video/backlight/omap1_bl.c | 1 -
drivers/video/backlight/pwm_bl.c | 1 -
drivers/video/backlight/tdo24m.c | 1 -
drivers/video/backlight/vgg2432a4.c | 1 -
drivers/video/backlight/wm831x_bl.c | 1 -
drivers/video/bfin-lq035q1-fb.c | 1 -
drivers/video/clps711xfb.c | 1 -
drivers/video/console/dummycon.c | 1 -
drivers/video/console/sticore.c | 1 -
drivers/video/goldfishfb.c | 1 -
drivers/video/i810/i810_main.c | 1 -
drivers/video/intelfb/intelfbhw.c | 1 -
drivers/video/matrox/matroxfb_base.h | 1 -
drivers/video/mb862xx/mb862xxfb_accel.c | 1 -
drivers/video/mb862xx/mb862xxfbdrv.c | 1 -
drivers/video/mbx/mbxfb.c | 1 -
drivers/video/nuc900fb.c | 1 -
drivers/video/nvidia/nvidia.c | 1 -
drivers/video/pxa168fb.c | 1 -
drivers/video/riva/fbdev.c | 1 -
drivers/video/s3c-fb.c | 1 -
drivers/video/sh_mobile_lcdcfb.c | 1 -
drivers/video/sm501fb.c | 1 -
drivers/video/smscufx.c | 1 -
drivers/video/sstfb.c | 1 -
drivers/video/tgafb.c | 1 -
drivers/video/udlfb.c | 1 -
drivers/video/uvesafb.c | 1 -
drivers/video/via/global.h | 1 -
drivers/video/vt8500lcdfb.c | 1 -
drivers/video/w100fb.c | 1 -
drivers/video/wm8505fb.c | 1 -
drivers/video/xilinxfb.c | 1 -
49 files changed, 49 deletions(-)
diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index 52108be..f572384 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -57,7 +57,6 @@
#include <linux/interrupt.h>
#include <linux/uaccess.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/ioport.h>
#include <linux/console.h>
diff --git a/drivers/video/aty/mach64_cursor.c b/drivers/video/aty/mach64_cursor.c
index 95ec042..af16ef6 100644
--- a/drivers/video/aty/mach64_cursor.c
+++ b/drivers/video/aty/mach64_cursor.c
@@ -3,7 +3,6 @@
*/
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/string.h>
#include <asm/io.h>
diff --git a/drivers/video/auo_k1900fb.c b/drivers/video/auo_k1900fb.c
index f5b668e..e81f4c5 100644
--- a/drivers/video/auo_k1900fb.c
+++ b/drivers/video/auo_k1900fb.c
@@ -35,7 +35,6 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/list.h>
#include <linux/firmware.h>
diff --git a/drivers/video/auo_k1901fb.c b/drivers/video/auo_k1901fb.c
index 12b9adc..3ccb91c 100644
--- a/drivers/video/auo_k1901fb.c
+++ b/drivers/video/auo_k1901fb.c
@@ -39,7 +39,6 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/list.h>
#include <linux/firmware.h>
diff --git a/drivers/video/backlight/88pm860x_bl.c b/drivers/video/backlight/88pm860x_bl.c
index 7db5234..955632e 100644
--- a/drivers/video/backlight/88pm860x_bl.c
+++ b/drivers/video/backlight/88pm860x_bl.c
@@ -9,7 +9,6 @@
* published by the Free Software Foundation.
*/
-#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/backlight/adp5520_bl.c b/drivers/video/backlight/adp5520_bl.c
index f37097a..bb7ab3c 100644
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
#include <linux/backlight.h>
diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
index 9d65671..0a23509 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
index 6370720..2b3c91c 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -7,7 +7,6 @@
*/
#include <linux/module.h>
-#include <linux/init.h>
#include <linux/errno.h>
#include <linux/pm.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
index db8db5f..db4c094 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -17,7 +17,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/fb.h>
diff --git a/drivers/video/backlight/da903x_bl.c b/drivers/video/backlight/da903x_bl.c
index 12c5d84..7a48447 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -13,7 +13,6 @@
*/
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
#include <linux/backlight.h>
diff --git a/drivers/video/backlight/generic_bl.c b/drivers/video/backlight/generic_bl.c
index 5d8d652..06dca66 100644
--- a/drivers/video/backlight/generic_bl.c
+++ b/drivers/video/backlight/generic_bl.c
@@ -11,7 +11,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/fb.h>
diff --git a/drivers/video/backlight/ili922x.c b/drivers/video/backlight/ili922x.c
index 73464e4..877426e 100644
--- a/drivers/video/backlight/ili922x.c
+++ b/drivers/video/backlight/ili922x.c
@@ -15,7 +15,6 @@
#include <linux/fb.h>
#include <linux/delay.h>
#include <linux/errno.h>
-#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/lcd.h>
#include <linux/module.h>
diff --git a/drivers/video/backlight/ili9320.c b/drivers/video/backlight/ili9320.c
index e2b8b40..42175d1 100644
--- a/drivers/video/backlight/ili9320.c
+++ b/drivers/video/backlight/ili9320.c
@@ -14,7 +14,6 @@
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/lcd.h>
#include <linux/module.h>
#include <linux/slab.h>
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index 187d1c2..b6c642d 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -12,7 +12,6 @@
*/
#include <linux/module.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/backlight.h>
#include <linux/fb.h>
diff --git a/drivers/video/backlight/ltv350qv.c b/drivers/video/backlight/ltv350qv.c
index 383f550..77c509d 100644
--- a/drivers/video/backlight/ltv350qv.c
+++ b/drivers/video/backlight/ltv350qv.c
@@ -10,7 +10,6 @@
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/lcd.h>
#include <linux/module.h>
#include <linux/slab.h>
diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c
index 66fa08c..75f5b7b 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -9,7 +9,6 @@
* published by the Free Software Foundation.
*/
-#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
diff --git a/drivers/video/backlight/omap1_bl.c b/drivers/video/backlight/omap1_bl.c
index a0dcd88..dbd863c 100644
--- a/drivers/video/backlight/omap1_bl.c
+++ b/drivers/video/backlight/omap1_bl.c
@@ -20,7 +20,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
#include <linux/backlight.h>
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index b75201f..15ada9f 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -14,7 +14,6 @@
#include <linux/of_gpio.h>
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
#include <linux/backlight.h>
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index 908016f..b5ab1da 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -11,7 +11,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/device.h>
#include <linux/spi/spi.h>
#include <linux/spi/tdo24m.h>
diff --git a/drivers/video/backlight/vgg2432a4.c b/drivers/video/backlight/vgg2432a4.c
index d538947..fac8577 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -14,7 +14,6 @@
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/lcd.h>
#include <linux/module.h>
diff --git a/drivers/video/backlight/wm831x_bl.c b/drivers/video/backlight/wm831x_bl.c
index 8b9455e..16ebb3e 100644
--- a/drivers/video/backlight/wm831x_bl.c
+++ b/drivers/video/backlight/wm831x_bl.c
@@ -9,7 +9,6 @@
*/
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/module.h>
#include <linux/fb.h>
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index b594a58..f2dce09 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -15,7 +15,6 @@
#include <linux/fb.h>
#include <linux/gpio.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/types.h>
#include <linux/interrupt.h>
#include <linux/device.h>
diff --git a/drivers/video/clps711xfb.c b/drivers/video/clps711xfb.c
index f009806..bec42d5 100644
--- a/drivers/video/clps711xfb.c
+++ b/drivers/video/clps711xfb.c
@@ -24,7 +24,6 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f..b734028 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -10,7 +10,6 @@
#include <linux/console.h>
#include <linux/vt_kern.h>
#include <linux/screen_info.h>
-#include <linux/init.h>
#include <linux/module.h>
/*
diff --git a/drivers/video/console/sticore.c b/drivers/video/console/sticore.c
index 4ad24f2..a077504 100644
--- a/drivers/video/console/sticore.c
+++ b/drivers/video/console/sticore.c
@@ -17,7 +17,6 @@
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/font.h>
diff --git a/drivers/video/goldfishfb.c b/drivers/video/goldfishfb.c
index 7f6c9e6..7bdb1ba 100644
--- a/drivers/video/goldfishfb.c
+++ b/drivers/video/goldfishfb.c
@@ -22,7 +22,6 @@
#include <linux/delay.h>
#include <linux/mm.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/i810/i810_main.c b/drivers/video/i810/i810_main.c
index bb674e4..d5df169 100644
--- a/drivers/video/i810/i810_main.c
+++ b/drivers/video/i810/i810_main.c
@@ -35,7 +35,6 @@
#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/resource.h>
diff --git a/drivers/video/intelfb/intelfbhw.c b/drivers/video/intelfb/intelfbhw.c
index fbad61d..f3374c9 100644
--- a/drivers/video/intelfb/intelfbhw.c
+++ b/drivers/video/intelfb/intelfbhw.c
@@ -27,7 +27,6 @@
#include <linux/delay.h>
#include <linux/fb.h>
#include <linux/ioport.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/vmalloc.h>
#include <linux/pagemap.h>
diff --git a/drivers/video/matrox/matroxfb_base.h b/drivers/video/matrox/matroxfb_base.h
index 11ed57b..e8d4ac5 100644
--- a/drivers/video/matrox/matroxfb_base.h
+++ b/drivers/video/matrox/matroxfb_base.h
@@ -36,7 +36,6 @@
#include <linux/console.h>
#include <linux/selection.h>
#include <linux/ioport.h>
-#include <linux/init.h>
#include <linux/timer.h>
#include <linux/pci.h>
#include <linux/spinlock.h>
diff --git a/drivers/video/mb862xx/mb862xxfb_accel.c b/drivers/video/mb862xx/mb862xxfb_accel.c
index fe92eed..a24a482 100644
--- a/drivers/video/mb862xx/mb862xxfb_accel.c
+++ b/drivers/video/mb862xx/mb862xxfb_accel.c
@@ -14,7 +14,6 @@
*/
#include <linux/fb.h>
#include <linux/delay.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/pci.h>
diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
index 0cd4c33..c2bfed4 100644
--- a/drivers/video/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/mb862xx/mb862xxfbdrv.c
@@ -18,7 +18,6 @@
#include <linux/delay.h>
#include <linux/uaccess.h>
#include <linux/module.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/pci.h>
#if defined(CONFIG_OF)
diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
index f0a5392..30a0511 100644
--- a/drivers/video/mbx/mbxfb.c
+++ b/drivers/video/mbx/mbxfb.c
@@ -22,7 +22,6 @@
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/uaccess.h>
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 478f980..9cdf9b6 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -23,7 +23,6 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/workqueue.h>
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index def0412..da7cb5e 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -17,7 +17,6 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/console.h>
#include <linux/backlight.h>
diff --git a/drivers/video/pxa168fb.c b/drivers/video/pxa168fb.c
index c95b9e4..727db73 100644
--- a/drivers/video/pxa168fb.c
+++ b/drivers/video/pxa168fb.c
@@ -20,7 +20,6 @@
#include <linux/slab.h>
#include <linux/fb.h>
#include <linux/delay.h>
-#include <linux/init.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
index 8a8d7f0..3ba0bb0 100644
--- a/drivers/video/riva/fbdev.c
+++ b/drivers/video/riva/fbdev.c
@@ -37,7 +37,6 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/pci.h>
#include <linux/backlight.h>
#include <linux/bitrev.h>
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 62acae2..4dc781e 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -17,7 +17,6 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/slab.h>
-#include <linux/init.h>
#include <linux/clk.h>
#include <linux/fb.h>
#include <linux/io.h>
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 2bcc84a..fec86d6 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -16,7 +16,6 @@
#include <linux/dma-mapping.h>
#include <linux/delay.h>
#include <linux/gpio.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/ioctl.h>
#include <linux/kernel.h>
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 1501979..3d84279 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -20,7 +20,6 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/vmalloc.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
index d513ed6..694033c 100644
--- a/drivers/video/smscufx.c
+++ b/drivers/video/smscufx.c
@@ -24,7 +24,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/usb.h>
#include <linux/uaccess.h>
#include <linux/mm.h>
diff --git a/drivers/video/sstfb.c b/drivers/video/sstfb.c
index f0cb279..f10ca57 100644
--- a/drivers/video/sstfb.c
+++ b/drivers/video/sstfb.c
@@ -85,7 +85,6 @@
#include <linux/fb.h>
#include <linux/pci.h>
#include <linux/delay.h>
-#include <linux/init.h>
#include <asm/io.h>
#include <linux/uaccess.h>
#include <video/sstfb.h>
diff --git a/drivers/video/tgafb.c b/drivers/video/tgafb.c
index 07c7df9..90e2583 100644
--- a/drivers/video/tgafb.c
+++ b/drivers/video/tgafb.c
@@ -18,7 +18,6 @@
#include <linux/device.h>
#include <linux/errno.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/mm.h>
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 77b890e..c00aec3 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -20,7 +20,6 @@
#include <linux/module.h>
#include <linux/kernel.h>
-#include <linux/init.h>
#include <linux/usb.h>
#include <linux/uaccess.h>
#include <linux/mm.h>
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 256fba7..9b2c7b5 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -5,7 +5,6 @@
* Loosely based upon the vesafb driver.
*
*/
-#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/skbuff.h>
diff --git a/drivers/video/via/global.h b/drivers/video/via/global.h
index 275dbbb..d356dec 100644
--- a/drivers/video/via/global.h
+++ b/drivers/video/via/global.h
@@ -28,7 +28,6 @@
#include <linux/pci.h>
#include <linux/io.h>
#include <linux/uaccess.h>
-#include <linux/init.h>
#include <linux/proc_fs.h>
#include <linux/console.h>
#include <linux/timer.h>
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index a8f2b28..dc55ef4 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -19,7 +19,6 @@
#include <linux/dma-mapping.h>
#include <linux/errno.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
diff --git a/drivers/video/w100fb.c b/drivers/video/w100fb.c
index 10951c8..1c55014 100644
--- a/drivers/video/w100fb.c
+++ b/drivers/video/w100fb.c
@@ -26,7 +26,6 @@
#include <linux/delay.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/platform_device.h>
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 537d199..fc8e0d7 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -19,7 +19,6 @@
#include <linux/fb.h>
#include <linux/errno.h>
#include <linux/err.h>
-#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 6ff1a91..4506252 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -27,7 +27,6 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/fb.h>
-#include <linux/init.h>
#include <linux/dma-mapping.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Nishanth Menon @ 2014-01-21 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Tomi,
On 01/21/2014 04:56 AM, Tomi Valkeinen wrote:
> Hi,
>
> Here's version 3 of the DSS DT series.
>
> The previous version can be found from:
>
> v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
> v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
>
> The main changes to v2 are:
>
> - DT Binding documentation
> - OMAP2 DSS support
> - Split DSI register space
> - DSS nodes disabled by default
> - Hack to have generic DT bindings but OMAP specific drivers (for now)
>
> This series can also be found from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
>
http://slexy.org/view/s20JhteOFR is my quick build test report -> few
checkpatch and build bisect issues would probably need fixing.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re:[PATCH v2] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-22 5:03 UTC (permalink / raw)
To: jg1.han
Cc: linux-fbdev, linux-kernel, DRI mailing list, plagnioj,
tomi.valkeinen
In-Reply-To: <CA+8Hj810rwNCaiF8vEp9QXGufLp3=AdgF60gcTNfkd7C7pawgw@mail.gmail.com>
Ping...
Regards,
Liu Ying
On 01/20/2014 12:52 PM, Liu Ying wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight should be turned on or off. To be more specific,
> only one unblank operation on a certain blanked framebuffer
> may increase the backlight device's use count by one, while
> one blank operation on a certain unblanked framebuffer may
> decrease the use count by one, because the userspace is
> likely to unblank a unblanked framebuffer or blank a blanked
> framebuffer.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>
> v1->v2:
> * Make the commit message be more specific about the condition
> in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
>
> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> include/linux/backlight.h | 6 ++++++
> 2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 5d05555..42044be 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> /* This callback gets called when something important happens inside a
> * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is, we're switching backlight power as well ...
> + * and if it is and necessary, we're switching backlight power as well ...
> */
> static int fb_notifier_callback(struct notifier_block *self,
> unsigned long event, void *data)
> {
> struct backlight_device *bd;
> struct fb_event *evdata = data;
> + int node = evdata->info->node;
> + int fb_blank = 0;
>
> /* If we aren't interested in this event, skip it immediately ... */
> if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
> if (bd->ops)
> if (!bd->ops->check_fb ||
> bd->ops->check_fb(bd, evdata->info)) {
> - bd->props.fb_blank = *(int *)evdata->data;
> - if (bd->props.fb_blank = FB_BLANK_UNBLANK)
> - bd->props.state &= ~BL_CORE_FBBLANK;
> - else
> - bd->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(bd);
> + fb_blank = *(int *)evdata->data;
> + if (fb_blank = FB_BLANK_UNBLANK &&
> + !bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = true;
> + if (!bd->use_count++) {
> + bd->props.state &= ~BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + backlight_update_status(bd);
> + }
> + } else if (fb_blank != FB_BLANK_UNBLANK &&
> + bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = false;
> + if (!(--bd->use_count)) {
> + bd->props.state |= BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + backlight_update_status(bd);
> + }
> + }
> }
> mutex_unlock(&bd->ops_lock);
> return 0;
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 5f9cd96..7264742 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -9,6 +9,7 @@
> #define _LINUX_BACKLIGHT_H
>
> #include <linux/device.h>
> +#include <linux/fb.h>
> #include <linux/mutex.h>
> #include <linux/notifier.h>
>
> @@ -104,6 +105,11 @@ struct backlight_device {
> struct list_head entry;
>
> struct device dev;
> +
> + /* Multiple framebuffers may share one backlight device */
> + bool fb_bl_on[FB_MAX];
> +
> + int use_count;
> };
>
> static inline void backlight_update_status(struct backlight_device *bd)
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Jingoo Han @ 2014-01-22 5:09 UTC (permalink / raw)
To: 'Liu Ying'
Cc: linux-fbdev, 'linux-kernel', 'DRI mailing list',
plagnioj, tomi.valkeinen, 'Jingoo Han'
In-Reply-To: <52DF5125.3040909@freescale.com>
On Wednesday, January 22, 2014 2:04 PM, Liu Ying wrote:
>
> Ping...
>
> Regards,
> Liu Ying
Please, don't send the ping within 2 days.
It is not a good practice. You sent the v1 patch 6 months ago.
However, why I should review the patch within 2 days?
Please wait.
Best regards,
Jingoo Han
>
> On 01/20/2014 12:52 PM, Liu Ying wrote:
> > We don't have to turn backlight on/off everytime a blanking
> > or unblanking event comes because the backlight status may
> > have already been what we want. Another thought is that one
> > backlight device may be shared by multiple framebuffers. We
> > don't hope blanking one of the framebuffers may turn the
> > backlight off for all the other framebuffers, since they are
> > likely being active to display something. This patch adds
> > some logics to record each framebuffer's backlight usage to
> > determine the backlight device use count and whether the
> > backlight should be turned on or off. To be more specific,
> > only one unblank operation on a certain blanked framebuffer
> > may increase the backlight device's use count by one, while
> > one blank operation on a certain unblanked framebuffer may
> > decrease the use count by one, because the userspace is
> > likely to unblank a unblanked framebuffer or blank a blanked
> > framebuffer.
> >
> > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> > ---
> > v1 can be found at https://lkml.org/lkml/2013/5/30/139
> >
> > v1->v2:
> > * Make the commit message be more specific about the condition
> > in which backlight device use count can be increased/decreased.
> > * Correct the setting for bd->props.fb_blank.
> >
> > drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> > include/linux/backlight.h | 6 ++++++
> > 2 files changed, 27 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> > index 5d05555..42044be 100644
> > --- a/drivers/video/backlight/backlight.c
> > +++ b/drivers/video/backlight/backlight.c
> > @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
> > defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> > /* This callback gets called when something important happens inside a
> > * framebuffer driver. We're looking if that important event is blanking,
> > - * and if it is, we're switching backlight power as well ...
> > + * and if it is and necessary, we're switching backlight power as well ...
> > */
> > static int fb_notifier_callback(struct notifier_block *self,
> > unsigned long event, void *data)
> > {
> > struct backlight_device *bd;
> > struct fb_event *evdata = data;
> > + int node = evdata->info->node;
> > + int fb_blank = 0;
> >
> > /* If we aren't interested in this event, skip it immediately ... */
> > if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> > @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
> > if (bd->ops)
> > if (!bd->ops->check_fb ||
> > bd->ops->check_fb(bd, evdata->info)) {
> > - bd->props.fb_blank = *(int *)evdata->data;
> > - if (bd->props.fb_blank = FB_BLANK_UNBLANK)
> > - bd->props.state &= ~BL_CORE_FBBLANK;
> > - else
> > - bd->props.state |= BL_CORE_FBBLANK;
> > - backlight_update_status(bd);
> > + fb_blank = *(int *)evdata->data;
> > + if (fb_blank = FB_BLANK_UNBLANK &&
> > + !bd->fb_bl_on[node]) {
> > + bd->fb_bl_on[node] = true;
> > + if (!bd->use_count++) {
> > + bd->props.state &= ~BL_CORE_FBBLANK;
> > + bd->props.fb_blank = FB_BLANK_UNBLANK;
> > + backlight_update_status(bd);
> > + }
> > + } else if (fb_blank != FB_BLANK_UNBLANK &&
> > + bd->fb_bl_on[node]) {
> > + bd->fb_bl_on[node] = false;
> > + if (!(--bd->use_count)) {
> > + bd->props.state |= BL_CORE_FBBLANK;
> > + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> > + backlight_update_status(bd);
> > + }
> > + }
> > }
> > mutex_unlock(&bd->ops_lock);
> > return 0;
> > diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> > index 5f9cd96..7264742 100644
> > --- a/include/linux/backlight.h
> > +++ b/include/linux/backlight.h
> > @@ -9,6 +9,7 @@
> > #define _LINUX_BACKLIGHT_H
> >
> > #include <linux/device.h>
> > +#include <linux/fb.h>
> > #include <linux/mutex.h>
> > #include <linux/notifier.h>
> >
> > @@ -104,6 +105,11 @@ struct backlight_device {
> > struct list_head entry;
> >
> > struct device dev;
> > +
> > + /* Multiple framebuffers may share one backlight device */
> > + bool fb_bl_on[FB_MAX];
> > +
> > + int use_count;
> > };
> >
> > static inline void backlight_update_status(struct backlight_device *bd)
> > --
> > 1.7.9.5
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tomi Valkeinen @ 2014-01-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEE6B0.20106@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
On 2014-01-21 23:29, Nishanth Menon wrote:
> Tomi,
>
> On 01/21/2014 04:56 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's version 3 of the DSS DT series.
>>
>> The previous version can be found from:
>>
>> v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
>> v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
>>
>> The main changes to v2 are:
>>
>> - DT Binding documentation
>> - OMAP2 DSS support
>> - Split DSI register space
>> - DSS nodes disabled by default
>> - Hack to have generic DT bindings but OMAP specific drivers (for now)
>>
>> This series can also be found from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
>>
> http://slexy.org/view/s20JhteOFR is my quick build test report -> few
> checkpatch and build bisect issues would probably need fixing.
Thanks. Shouldn't make trivial changes, and then not run a full
commit-by-commit compile test...
I fixed the issues and pushed the branch again to work/dss-dt-review-3.
The fixes are minor, so the already posted series can be reviewed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Jani Nikula @ 2014-01-22 9:35 UTC (permalink / raw)
To: Liu Ying, jg1.han
Cc: linux-fbdev, tomi.valkeinen, plagnioj, linux-kernel, dri-devel
In-Reply-To: <1390196846-15304-1-git-send-email-Ying.Liu@freescale.com>
On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight should be turned on or off. To be more specific,
> only one unblank operation on a certain blanked framebuffer
> may increase the backlight device's use count by one, while
> one blank operation on a certain unblanked framebuffer may
> decrease the use count by one, because the userspace is
> likely to unblank a unblanked framebuffer or blank a blanked
> framebuffer.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>
> v1->v2:
> * Make the commit message be more specific about the condition
> in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
>
> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> include/linux/backlight.h | 6 ++++++
> 2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index 5d05555..42044be 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> /* This callback gets called when something important happens inside a
> * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is, we're switching backlight power as well ...
> + * and if it is and necessary, we're switching backlight power as well ...
> */
> static int fb_notifier_callback(struct notifier_block *self,
> unsigned long event, void *data)
> {
> struct backlight_device *bd;
> struct fb_event *evdata = data;
> + int node = evdata->info->node;
> + int fb_blank = 0;
>
> /* If we aren't interested in this event, skip it immediately ... */
> if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
> if (bd->ops)
> if (!bd->ops->check_fb ||
> bd->ops->check_fb(bd, evdata->info)) {
> - bd->props.fb_blank = *(int *)evdata->data;
> - if (bd->props.fb_blank = FB_BLANK_UNBLANK)
> - bd->props.state &= ~BL_CORE_FBBLANK;
> - else
> - bd->props.state |= BL_CORE_FBBLANK;
> - backlight_update_status(bd);
> + fb_blank = *(int *)evdata->data;
> + if (fb_blank = FB_BLANK_UNBLANK &&
> + !bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = true;
> + if (!bd->use_count++) {
> + bd->props.state &= ~BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + backlight_update_status(bd);
> + }
> + } else if (fb_blank != FB_BLANK_UNBLANK &&
> + bd->fb_bl_on[node]) {
> + bd->fb_bl_on[node] = false;
> + if (!(--bd->use_count)) {
> + bd->props.state |= BL_CORE_FBBLANK;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + backlight_update_status(bd);
> + }
> + }
Anything backlight worries me a little, and there are actually three
changes bundled into one patch here:
1. Changing bd->props.state and bd->props.fb_blank only when use_count
changes from 0->1 or 1->0.
2. Calling backlight_update_status() only with the above change, and not
on all notifier callbacks.
3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
The rationale in the commit message seems plausible, and AFAICT the code
does what it says on the box, so for that (and for that alone) you can
have my
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
*BUT* it would be laborous to figure out whether this change in
behaviour might regress some drivers. I'm just punting on that. And that
brings us back to the three changes above - in a bisect POV it might be
helpful to split the patch up. Up to the maintainers.
HTH,
Jani.
> }
> mutex_unlock(&bd->ops_lock);
> return 0;
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 5f9cd96..7264742 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -9,6 +9,7 @@
> #define _LINUX_BACKLIGHT_H
>
> #include <linux/device.h>
> +#include <linux/fb.h>
> #include <linux/mutex.h>
> #include <linux/notifier.h>
>
> @@ -104,6 +105,11 @@ struct backlight_device {
> struct list_head entry;
>
> struct device dev;
> +
> + /* Multiple framebuffers may share one backlight device */
> + bool fb_bl_on[FB_MAX];
> +
> + int use_count;
> };
>
> static inline void backlight_update_status(struct backlight_device *bd)
> --
> 1.7.9.5
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-22 10:47 UTC (permalink / raw)
To: Jani Nikula
Cc: jg1.han, linux-fbdev, tomi.valkeinen, plagnioj, linux-kernel,
dri-devel
In-Reply-To: <87sisg5pfo.fsf@intel.com>
On 01/22/2014 05:35 PM, Jani Nikula wrote:
> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
>> We don't have to turn backlight on/off everytime a blanking
>> or unblanking event comes because the backlight status may
>> have already been what we want. Another thought is that one
>> backlight device may be shared by multiple framebuffers. We
>> don't hope blanking one of the framebuffers may turn the
>> backlight off for all the other framebuffers, since they are
>> likely being active to display something. This patch adds
>> some logics to record each framebuffer's backlight usage to
>> determine the backlight device use count and whether the
>> backlight should be turned on or off. To be more specific,
>> only one unblank operation on a certain blanked framebuffer
>> may increase the backlight device's use count by one, while
>> one blank operation on a certain unblanked framebuffer may
>> decrease the use count by one, because the userspace is
>> likely to unblank a unblanked framebuffer or blank a blanked
>> framebuffer.
>>
>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> ---
>> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>>
>> v1->v2:
>> * Make the commit message be more specific about the condition
>> in which backlight device use count can be increased/decreased.
>> * Correct the setting for bd->props.fb_blank.
>>
>> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
>> include/linux/backlight.h | 6 ++++++
>> 2 files changed, 27 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
>> index 5d05555..42044be 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
>> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
>> /* This callback gets called when something important happens inside a
>> * framebuffer driver. We're looking if that important event is blanking,
>> - * and if it is, we're switching backlight power as well ...
>> + * and if it is and necessary, we're switching backlight power as well ...
>> */
>> static int fb_notifier_callback(struct notifier_block *self,
>> unsigned long event, void *data)
>> {
>> struct backlight_device *bd;
>> struct fb_event *evdata = data;
>> + int node = evdata->info->node;
>> + int fb_blank = 0;
>>
>> /* If we aren't interested in this event, skip it immediately ... */
>> if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
>> @@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
>> if (bd->ops)
>> if (!bd->ops->check_fb ||
>> bd->ops->check_fb(bd, evdata->info)) {
>> - bd->props.fb_blank = *(int *)evdata->data;
>> - if (bd->props.fb_blank = FB_BLANK_UNBLANK)
>> - bd->props.state &= ~BL_CORE_FBBLANK;
>> - else
>> - bd->props.state |= BL_CORE_FBBLANK;
>> - backlight_update_status(bd);
>> + fb_blank = *(int *)evdata->data;
>> + if (fb_blank = FB_BLANK_UNBLANK &&
>> + !bd->fb_bl_on[node]) {
>> + bd->fb_bl_on[node] = true;
>> + if (!bd->use_count++) {
>> + bd->props.state &= ~BL_CORE_FBBLANK;
>> + bd->props.fb_blank = FB_BLANK_UNBLANK;
>> + backlight_update_status(bd);
>> + }
>> + } else if (fb_blank != FB_BLANK_UNBLANK &&
>> + bd->fb_bl_on[node]) {
>> + bd->fb_bl_on[node] = false;
>> + if (!(--bd->use_count)) {
>> + bd->props.state |= BL_CORE_FBBLANK;
>> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
Looking at the patch again, I think we should set fb_blank to bd->props.fb_blank here to minimize the logic change.
I'll do more test for this and provide v3 if necessary.
>> + backlight_update_status(bd);
>> + }
>> + }
>
> Anything backlight worries me a little, and there are actually three
> changes bundled into one patch here:
>
> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
> changes from 0->1 or 1->0.
>
> 2. Calling backlight_update_status() only with the above change, and not
> on all notifier callbacks.
>
> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
>
> The rationale in the commit message seems plausible, and AFAICT the code
> does what it says on the box, so for that (and for that alone) you can
> have my
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Thanks for your review.
The backlight on my board is driving two separate display interfaces.
Instead of applying this patch to my kernel tree every time I upgrade it, I chose to send it to folks for review.
As the essential idea of this patch looks reasonable to me, I hope change could be done in other drivers in case this patch regresses them.
Liu Ying
>
> *BUT* it would be laborous to figure out whether this change in
> behaviour might regress some drivers. I'm just punting on that. And that
> brings us back to the three changes above - in a bisect POV it might be
> helpful to split the patch up. Up to the maintainers.
>
> HTH,
> Jani.
>
>
>> }
>> mutex_unlock(&bd->ops_lock);
>> return 0;
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index 5f9cd96..7264742 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -9,6 +9,7 @@
>> #define _LINUX_BACKLIGHT_H
>>
>> #include <linux/device.h>
>> +#include <linux/fb.h>
>> #include <linux/mutex.h>
>> #include <linux/notifier.h>
>>
>> @@ -104,6 +105,11 @@ struct backlight_device {
>> struct list_head entry;
>>
>> struct device dev;
>> +
>> + /* Multiple framebuffers may share one backlight device */
>> + bool fb_bl_on[FB_MAX];
>> +
>> + int use_count;
>> };
>>
>> static inline void backlight_update_status(struct backlight_device *bd)
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* [PATCH v3] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-22 11:24 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
We don't have to turn backlight on/off every time a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight should be turned on or off. To be more specific,
only one unblank operation on a certain blanked framebuffer
may increase the backlight device's use count by one, while
one blank operation on a certain unblanked framebuffer may
decrease the use count by one, because the userspace is
likely to unblank an unblanked framebuffer or blank a blanked
framebuffer.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
v1 can be found at https://lkml.org/lkml/2013/5/30/139
v2->v3:
* Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
when we turn off a blacklight.
* Correct some trivial typos in the commit message.
v1->v2:
* Make the commit message be more specific about the condition
in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.
drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
include/linux/backlight.h | 6 ++++++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 5d05555..27d3cf2 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
* framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
{
struct backlight_device *bd;
struct fb_event *evdata = data;
+ int node = evdata->info->node;
+ int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
- bd->props.fb_blank = *(int *)evdata->data;
- if (bd->props.fb_blank = FB_BLANK_UNBLANK)
- bd->props.state &= ~BL_CORE_FBBLANK;
- else
- bd->props.state |= BL_CORE_FBBLANK;
- backlight_update_status(bd);
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank = FB_BLANK_UNBLANK &&
+ !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK &&
+ bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = fb_blank;
+ backlight_update_status(bd);
+ }
+ }
}
mutex_unlock(&bd->ops_lock);
return 0;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
#define _LINUX_BACKLIGHT_H
#include <linux/device.h>
+#include <linux/fb.h>
#include <linux/mutex.h>
#include <linux/notifier.h>
@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;
struct device dev;
+
+ /* Multiple framebuffers may share one backlight device */
+ bool fb_bl_on[FB_MAX];
+
+ int use_count;
};
static inline void backlight_update_status(struct backlight_device *bd)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv14][ 1/4] video: imxfb: Introduce regulator support.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
This commit is based on the following commit by Fabio Estevam:
4344429 video: mxsfb: Introduce regulator support
Cc: Eric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v13->v14:
- Remove people not concerned by this patch from the Cc list.
- Simplified the regulator handling: The regulator-core now supplies
a dummy regulator if one hasn't been hooked up explicitely.
So we don't need to handle that case in the driver.
The code has been updated to do that, and the error messages
were updated accordingly.
ChangeLog v9->v10:
- Added a return 0; at the end of imxfb_disable_controller.
ChangeLog v8->v9:
- return an error if regulator_{enable,disable} fails in
imxfb_{enable,disable}_controller, and use it.
---
drivers/video/imxfb.c | 38 +++++++++++++++++++++++++-------------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 44ee678..dd8a35d 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -28,6 +28,7 @@
#include <linux/cpufreq.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/math64.h>
@@ -145,6 +146,7 @@ struct imxfb_info {
struct clk *clk_ipg;
struct clk *clk_ahb;
struct clk *clk_per;
+ struct regulator *reg_lcd;
enum imxfb_type devtype;
bool enabled;
@@ -561,14 +563,16 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
}
#endif
-static void imxfb_enable_controller(struct imxfb_info *fbi)
+static int imxfb_enable_controller(struct imxfb_info *fbi)
{
-
if (fbi->enabled)
- return;
+ return 0;
pr_debug("Enabling LCD controller\n");
+ if (regulator_enable(fbi->reg_lcd))
+ dev_err(&fbi->pdev->dev, "Failed to enable regulator.\n");
+
writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
/* panning offset 0 (0 pixel offset) */
@@ -593,12 +597,14 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
fbi->backlight_power(1);
if (fbi->lcd_power)
fbi->lcd_power(1);
+
+ return 0;
}
-static void imxfb_disable_controller(struct imxfb_info *fbi)
+static int imxfb_disable_controller(struct imxfb_info *fbi)
{
if (!fbi->enabled)
- return;
+ return 0;
pr_debug("Disabling LCD controller\n");
@@ -613,6 +619,11 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
fbi->enabled = false;
writel(0, fbi->regs + LCDC_RMCR);
+
+ if(regulator_disable(fbi->reg_lcd))
+ dev_err(&fbi->pdev->dev, "Failed to disable regulator.\n");
+
+ return 0;
}
static int imxfb_blank(int blank, struct fb_info *info)
@@ -626,13 +637,12 @@ static int imxfb_blank(int blank, struct fb_info *info)
case FB_BLANK_VSYNC_SUSPEND:
case FB_BLANK_HSYNC_SUSPEND:
case FB_BLANK_NORMAL:
- imxfb_disable_controller(fbi);
- break;
+ return imxfb_disable_controller(fbi);
case FB_BLANK_UNBLANK:
- imxfb_enable_controller(fbi);
- break;
+ return imxfb_enable_controller(fbi);
}
+
return 0;
}
@@ -734,8 +744,7 @@ static int imxfb_suspend(struct platform_device *dev, pm_message_t state)
pr_debug("%s\n", __func__);
- imxfb_disable_controller(fbi);
- return 0;
+ return imxfb_disable_controller(fbi);
}
static int imxfb_resume(struct platform_device *dev)
@@ -745,8 +754,7 @@ static int imxfb_resume(struct platform_device *dev)
pr_debug("%s\n", __func__);
- imxfb_enable_controller(fbi);
- return 0;
+ return imxfb_enable_controller(fbi);
}
#else
#define imxfb_suspend NULL
@@ -1020,6 +1028,10 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_register;
}
+ fbi->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
+ if (IS_ERR(fbi->reg_lcd))
+ return PTR_ERR(fbi->reg_lcd);
+
imxfb_enable_controller(fbi);
fbi->pdev = pdev;
#ifdef PWMR_BACKLIGHT_AVAILABLE
--
1.7.9.5
^ permalink raw reply related
* [PATCHv14][ 2/4] video: imxfb: Add DT default contrast control register property.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-fbdev
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Eric Bénard <eric@eukrea.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
---
ChangeLog v5->v14:
- Remove people not concerned by this patch from the Cc list.
- Changed the property name to match the register name and function.
- Updated the documentation, code and commit message accordingly.
---
.../devicetree/bindings/video/fsl,imx-fb.txt | 3 +++
drivers/video/imxfb.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
index 46da08d..a2a19cb 100644
--- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -17,6 +17,9 @@ Required nodes:
Optional properties:
- fsl,dmacr: DMA Control Register value. This is optional. By default, the
register is not modified as recommended by the datasheet.
+- fsl,lpccr: Contrast Control Register value. This property provides the
+ default value for the contrast control register.
+ If that property is ommited, the register is zeroed.
- fsl,lscr1: LCDC Sharp Configuration Register value.
Example:
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index dd8a35d..c55991a 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -818,6 +818,8 @@ static int imxfb_init_fbinfo(struct platform_device *pdev)
of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+ of_property_read_u32(np, "fsl,lpccr", &fbi->pwmr);
+
/* These two function pointers could be used by some specific
* platforms. */
fbi->lcd_power = NULL;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv14][ 3/4] video: Kconfig: Allow more broad selection of the imxfb framebuffer driver.
From: Denis Carikli @ 2014-01-22 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390410577-22073-1-git-send-email-denis@eukrea.com>
Without that patch, a user can't select the imxfb driver when the i.MX25 and/or
the i.MX27 device tree board are selected and that no boards that selects
IMX_HAVE_PLATFORM_IMX_FB are compiled in.
Cc: Eric Bénard <eric@eukrea.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
ChangeLog v11->v14:
- Remove people not concerned by this patch from the Cc list.
ChangeLog v10->v11:
- moved my signed-off-by.
ChangeLog v8->v9:
- Added Jean-Christophe PLAGNIOL-VILLARD's ACK.
---
drivers/video/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 22262a3..dade5b7 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -364,7 +364,7 @@ config FB_SA1100
config FB_IMX
tristate "Freescale i.MX1/21/25/27 LCD support"
- depends on FB && IMX_HAVE_PLATFORM_IMX_FB
+ depends on FB && ARCH_MXC
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Ivaylo Dimitrov @ 2014-01-22 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D146E8.4090105@gmail.com>
Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
Ivo
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Jingoo Han @ 2014-01-23 5:44 UTC (permalink / raw)
To: 'Liu Ying'
Cc: 'Jani Nikula', linux-fbdev, tomi.valkeinen, plagnioj,
linux-kernel, dri-devel, 'Jingoo Han'
In-Reply-To: <87sisg5pfo.fsf@intel.com>
On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
> > We don't have to turn backlight on/off everytime a blanking
> > or unblanking event comes because the backlight status may
> > have already been what we want. Another thought is that one
> > backlight device may be shared by multiple framebuffers. We
> > don't hope blanking one of the framebuffers may turn the
> > backlight off for all the other framebuffers, since they are
> > likely being active to display something. This patch adds
> > some logics to record each framebuffer's backlight usage to
> > determine the backlight device use count and whether the
> > backlight should be turned on or off. To be more specific,
> > only one unblank operation on a certain blanked framebuffer
> > may increase the backlight device's use count by one, while
> > one blank operation on a certain unblanked framebuffer may
> > decrease the use count by one, because the userspace is
> > likely to unblank a unblanked framebuffer or blank a blanked
> > framebuffer.
> >
> > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> > ---
> > v1 can be found at https://lkml.org/lkml/2013/5/30/139
> >
> > v1->v2:
> > * Make the commit message be more specific about the condition
> > in which backlight device use count can be increased/decreased.
> > * Correct the setting for bd->props.fb_blank.
> >
> > drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> > include/linux/backlight.h | 6 ++++++
> > 2 files changed, 27 insertions(+), 7 deletions(-)
> >
[.....]
>
> Anything backlight worries me a little, and there are actually three
> changes bundled into one patch here:
>
> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
> changes from 0->1 or 1->0.
>
> 2. Calling backlight_update_status() only with the above change, and not
> on all notifier callbacks.
>
> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
>
> The rationale in the commit message seems plausible, and AFAICT the code
> does what it says on the box, so for that (and for that alone) you can
> have my
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
> *BUT* it would be laborous to figure out whether this change in
> behaviour might regress some drivers. I'm just punting on that. And that
> brings us back to the three changes above - in a bisect POV it might be
> helpful to split the patch up. Up to the maintainers.
I agree with Jani Nikula's opinion.
Please split this patch into three patches as above mentioned.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-23 9:27 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-fbdev, linux-kernel, dri-devel, tomi.valkeinen, plagnioj
In-Reply-To: <000101cf17fe$20ac79a0$62056ce0$%han@samsung.com>
On 01/23/2014 01:44 PM, Jingoo Han wrote:
> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
>>> We don't have to turn backlight on/off everytime a blanking
>>> or unblanking event comes because the backlight status may
>>> have already been what we want. Another thought is that one
>>> backlight device may be shared by multiple framebuffers. We
>>> don't hope blanking one of the framebuffers may turn the
>>> backlight off for all the other framebuffers, since they are
>>> likely being active to display something. This patch adds
>>> some logics to record each framebuffer's backlight usage to
>>> determine the backlight device use count and whether the
>>> backlight should be turned on or off. To be more specific,
>>> only one unblank operation on a certain blanked framebuffer
>>> may increase the backlight device's use count by one, while
>>> one blank operation on a certain unblanked framebuffer may
>>> decrease the use count by one, because the userspace is
>>> likely to unblank a unblanked framebuffer or blank a blanked
>>> framebuffer.
>>>
>>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>>> ---
>>> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>>>
>>> v1->v2:
>>> * Make the commit message be more specific about the condition
>>> in which backlight device use count can be increased/decreased.
>>> * Correct the setting for bd->props.fb_blank.
>>>
>>> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
>>> include/linux/backlight.h | 6 ++++++
>>> 2 files changed, 27 insertions(+), 7 deletions(-)
>>>
>
> [.....]
>>
>> Anything backlight worries me a little, and there are actually three
>> changes bundled into one patch here:
>>
>> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
>> changes from 0->1 or 1->0.
>>
>> 2. Calling backlight_update_status() only with the above change, and not
>> on all notifier callbacks.
>>
>> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
>> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
Since I have already post v3(https://lkml.org/lkml/2014/1/22/126) to change the setting for bd->props.fb_blank, the idea of the 3rd point is not very appropriate any more.
>>
>> The rationale in the commit message seems plausible, and AFAICT the code
>> does what it says on the box, so for that (and for that alone) you can
>> have my
>>
>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>>
>> *BUT* it would be laborous to figure out whether this change in
>> behaviour might regress some drivers. I'm just punting on that. And that
>> brings us back to the three changes above - in a bisect POV it might be
>> helpful to split the patch up. Up to the maintainers.
>
> I agree with Jani Nikula's opinion.
> Please split this patch into three patches as above mentioned.
>
I am open to split the patch up.
However, IMHO, this patch is somewhat self-contained.
For example, if we try to create 2 patches for the 1st point and the 2nd point Jani mentioned, one patch would invent the use_count and call backlight_update_status() on all notifier callbacks(just
ignore the use_count).
Do you think this is a good patch?
It also doesn't look straightforward for me to create 2 patches for the 1st point and the 2nd point.
Please advice.
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-23 9:55 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-fbdev, linux-kernel, dri-devel, tomi.valkeinen, plagnioj
In-Reply-To: <52E0E093.1070803@freescale.com>
On 01/23/2014 05:27 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
>> On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
>>> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
>>>> We don't have to turn backlight on/off everytime a blanking
>>>> or unblanking event comes because the backlight status may
>>>> have already been what we want. Another thought is that one
>>>> backlight device may be shared by multiple framebuffers. We
>>>> don't hope blanking one of the framebuffers may turn the
>>>> backlight off for all the other framebuffers, since they are
>>>> likely being active to display something. This patch adds
>>>> some logics to record each framebuffer's backlight usage to
>>>> determine the backlight device use count and whether the
>>>> backlight should be turned on or off. To be more specific,
>>>> only one unblank operation on a certain blanked framebuffer
>>>> may increase the backlight device's use count by one, while
>>>> one blank operation on a certain unblanked framebuffer may
>>>> decrease the use count by one, because the userspace is
>>>> likely to unblank a unblanked framebuffer or blank a blanked
>>>> framebuffer.
>>>>
>>>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>>>> ---
>>>> v1 can be found at https://lkml.org/lkml/2013/5/30/139
>>>>
>>>> v1->v2:
>>>> * Make the commit message be more specific about the condition
>>>> in which backlight device use count can be increased/decreased.
>>>> * Correct the setting for bd->props.fb_blank.
>>>>
>>>> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
>>>> include/linux/backlight.h | 6 ++++++
>>>> 2 files changed, 27 insertions(+), 7 deletions(-)
>>>>
>>
>> [.....]
>>>
>>> Anything backlight worries me a little, and there are actually three
>>> changes bundled into one patch here:
>>>
>>> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
>>> changes from 0->1 or 1->0.
>>>
>>> 2. Calling backlight_update_status() only with the above change, and not
>>> on all notifier callbacks.
>>>
>>> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
>>> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
>
> Since I have already post v3(https://lkml.org/lkml/2014/1/22/126) to change the setting for bd->props.fb_blank, the idea of the 3rd point is not very appropriate any more.
>
>>>
>>> The rationale in the commit message seems plausible, and AFAICT the code
>>> does what it says on the box, so for that (and for that alone) you can
>>> have my
>>>
>>> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>>>
>>> *BUT* it would be laborous to figure out whether this change in
>>> behaviour might regress some drivers. I'm just punting on that. And that
>>> brings us back to the three changes above - in a bisect POV it might be
>>> helpful to split the patch up. Up to the maintainers.
>>
>> I agree with Jani Nikula's opinion.
>> Please split this patch into three patches as above mentioned.
>>
>
> I am open to split the patch up.
> However, IMHO, this patch is somewhat self-contained.
> For example, if we try to create 2 patches for the 1st point and the 2nd point Jani mentioned, one patch would invent the use_count and call backlight_update_status() on all notifier callbacks(just
> ignore the use_count).
> Do you think this is a good patch?
>
> It also doesn't look straightforward for me to create 2 patches for the 1st point and the 3rd point.
^ Sorry, fix typo(2nd -> 3rd).
>
> Please advice.
>
^ permalink raw reply
* [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-01-23 14:14 UTC (permalink / raw)
To: dri-devel
Cc: linux-fbdev, Daniel Vetter, linux-kernel, Tomi Valkeinen,
Ingo Molnar
Hi
Another round of SimpleDRM patches. I somehow lost track of the last ones and as
this is a major rewrite, I'll just start at v1 again.
Some comments up-front:
- @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I
included them in this series as the other patches depend on them. Could you
pick them up for the x86 tree? The other 9 patches won't make it in 3.14 so
no reason to put them through the DRM tree.
All mentioned issues should be addressed. If there's still sth missing,
please let me know.
- The DRM patches depend on my "DRM Anonymous Inode" patches. But it should be
trivial to apply them on drm-next (I think only one line needs to be changed:
i_mapping => dev_mapping).
- I tested the SimpleDRM fbdev fallback with linux-console+Xorg and it works
fine. The DRM backend is only tested with some DRM tests I have locally. I
have no idea how to make Xorg pick up a specific /dev/dri/card0 card. It
always tells me "no screens found" (as the underlying device is not marked as
boot_vga..). If someone knows how to tell Xorg to use card0, I'd gladly test
this. But I'm no longer used to writing xorg.confs..
This series introduces two new concepts: sysfb and SimpleDRM
Sysfb is just a generalization of the x86-sysfb concept. It allows to register
firmware-framebuffers with the system as platform-devices. This way, drivers can
properly bind to these devices and we prevent multiple drivers from accessing
the same firmware-framebuffer.
Sysfb also provides hooks to get a safe handover to real hw-drivers (like i915).
Please see the "video: sysfb: add generic firmware-fb interface" patch for a
thorough description of the API. This patch also adds a rather verbose
documentation of all known firmware-fb facilities.
As second part, this series introduces SimpleDRM. It's a very basic DRM driver
that can replace efifb, vesafb, simplefb and friends. It's 100% compatible to
the "udl" DRM driver, so user-space like xf86-video-modesetting can pick them up
just fine. User-space that cannot deal with drmModeDirtyFB() (like weston and
friends) currently cannot use SimpleDRM. However, that's also true for all other
DRM drivers which provide shadow framebuffers. We could provide something like
FB-DEFIO, but that's just useless overhead to paper of lazy user-space.
I have tested this with all hardware that I have at home, with a lot hand-over
combinations (with/without SYSFB, with efifb/vesafb/simplefb, with SimpleDRM,
...) and all worked great so far.
Comments welcome!
David
David Herrmann (11):
x86: sysfb: fool-proof CONFIG_X86_SYSFB
x86: sysfb: remove sysfb when probing real hw
fbdev: efifb: add dev->remove() callback
fbdev: vesafb: add dev->remove() callback
x86: sysfb: store apertures in simplefb platform-data
video: sysfb: add generic firmware-fb interface
drm: mgag200: remove redundant fbdev removal
drm/i915: remove sysfbs early
drm: add SimpleDRM driver
drm: simpledrm: add fbdev fallback support
x86/sysfb: allow sysfb+simpledrm combination
Documentation/firmware-fbs.txt | 236 +++++++++++++++++
MAINTAINERS | 8 +
arch/x86/Kconfig | 2 +
arch/x86/include/asm/sysfb.h | 6 +-
arch/x86/kernel/sysfb.c | 3 +-
arch/x86/kernel/sysfb_simplefb.c | 97 ++++---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 6 +
drivers/gpu/drm/mgag200/mgag200_main.c | 9 -
drivers/gpu/drm/simpledrm/Kconfig | 29 +++
drivers/gpu/drm/simpledrm/Makefile | 4 +
drivers/gpu/drm/simpledrm/simpledrm.c | 263 +++++++++++++++++++
drivers/gpu/drm/simpledrm/simpledrm.h | 122 +++++++++
drivers/gpu/drm/simpledrm/simpledrm_damage.c | 306 ++++++++++++++++++++++
drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 148 +++++++++++
drivers/gpu/drm/simpledrm/simpledrm_gem.c | 282 +++++++++++++++++++++
drivers/gpu/drm/simpledrm/simpledrm_kms.c | 365 +++++++++++++++++++++++++++
drivers/video/Kconfig | 3 +
drivers/video/Makefile | 1 +
drivers/video/efifb.c | 13 +-
drivers/video/fbmem.c | 17 +-
drivers/video/simplefb.c | 8 -
drivers/video/sysfb.c | 348 +++++++++++++++++++++++++
drivers/video/vesafb.c | 13 +-
include/linux/fb.h | 9 +-
include/linux/platform_data/simplefb.h | 2 +
include/linux/sysfb.h | 62 +++++
28 files changed, 2299 insertions(+), 66 deletions(-)
create mode 100644 Documentation/firmware-fbs.txt
create mode 100644 drivers/gpu/drm/simpledrm/Kconfig
create mode 100644 drivers/gpu/drm/simpledrm/Makefile
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c
create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c
create mode 100644 drivers/video/sysfb.c
create mode 100644 include/linux/sysfb.h
--
1.8.5.3
^ permalink raw reply
* [PATCH 01/11] x86: sysfb: fool-proof CONFIG_X86_SYSFB
From: David Herrmann @ 2014-01-23 14:14 UTC (permalink / raw)
To: dri-devel
Cc: linux-fbdev, Daniel Vetter, linux-kernel, Tomi Valkeinen,
Ingo Molnar
In-Reply-To: <1390486503-1504-1-git-send-email-dh.herrmann@gmail.com>
Turns out, people do not read help-texts of new config-options and enable
them nonetheless. So several reports came in with X86_SYSFB=y and
FB_SIMPLE=n, which in almost all situations prevents firmware-fbs from
being probed.
X86_SYSFB clearly states that it turns legacy vesa/efi framebuffers into a
format compatible to simplefb (and does nothing else..). So to avoid
further complaints about missing gfx-support during boot, simply depend on
FB_SIMPLE now.
As FB_SIMPLE is disabled by default and usually only enabled on selected
ARM architectures, x86 users should thus never see the X86_SYSFB
config-option. And if they do, everything is fine as simplefb will be
available.
Note that most of the sysfb code is enabled independently of X86_SYSFB.
The config option only selects a compatibility mode for simplefb. It was
introduced to ease the transition to SimpleDRM and disabling fbdev. As
this is still ongoing, there's no need for non-developers to care for
X86_SYSFB so we can safely hide it behind FB_SIMPLE.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0952ecd..098228e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2299,6 +2299,7 @@ source "drivers/rapidio/Kconfig"
config X86_SYSFB
bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
+ depends on FB_SIMPLE
help
Firmwares often provide initial graphics framebuffers so the BIOS,
bootloader or kernel can show basic video-output during boot for
--
1.8.5.3
^ permalink raw reply related
* [PATCH 02/11] x86: sysfb: remove sysfb when probing real hw
From: David Herrmann @ 2014-01-23 14:14 UTC (permalink / raw)
To: dri-devel
Cc: linux-fbdev, Daniel Vetter, linux-kernel, Tomi Valkeinen,
Ingo Molnar
In-Reply-To: <1390486503-1504-1-git-send-email-dh.herrmann@gmail.com>
With CONFIG_X86_SYSFB=y, probing real hw-drivers may result in
resource-conflicts and drivers will refuse to load. A call to
request_mem_region() will fail, if the region overlaps with the mem-region
used by simplefb. The common desktop DRM drivers (intel, nouveau, radeon)
are not affected as they don't reserve their resources, but some others
do, including (nvidiafb, cirrus, ..).
The problem is that we add an IORESOURCE_MEM to the simple-framebuffer
platform-device during bootup but never release it. Probing simplefb on
this platform-device is fine, but the handover to real-hw via
remove_conflicting_framebuffers() will only unload the fbdev driver, but
keep the platform-device around. Thus, if the real hw-driver calls
request_mem_region() and friends on the same PCI region, we will get a
resource conflict and most drivers refuse to load. Users will see
errors like:
"nvidiafb: cannot reserve video memory at <xyz>"
vesafb and efifb don't store any resources, so disabling CONFIG_X86_SYSFB
and falling back to those drivers will avoid the bug. With sysfb enabled,
we need to properly unload the simple-framebuffer devices before probing
real hw-drivers.
This patch adds sysfb_unregister() for that purpose. It can be called from
any context (except from the platform-device ->probe and ->remove callback
path), synchronously unloads any global sysfb and prevents new sysfbs from
getting registered. Thus, you can call it even before any sysfb has been
loaded. Note that for now we only do that for simple-framebuffer devices,
as efi/vesa-framebuffer platform-drivers lack ->remove() callbacks.
They're not affected by the resource-conflicts, so we can fix those later.
This also changes remove_conflicting_framebuffer() to call this helper
*before* trying its heuristic to remove conflicting drivers. This way, we
unload sysfbs properly on any conflict. But to avoid dead-locks in
register_framebuffer(), we must not call sysfb_unregister() for
framebuffers probing on sysfb devices. Hence, we simply remove any
aperture from simplefb and we're good to go. simplefb is unregistered by
sysfb_unregister() now, so no reason to keep the apertures (on non-x86,
there currently is no handover from simplefb, so we're fine. If it's
added, they need to provide something like sysfb_unregister() too)
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Takashi Iwai <tiwai@suse.de>
---
arch/x86/include/asm/sysfb.h | 5 ++++
arch/x86/kernel/sysfb.c | 65 ++++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/sysfb_simplefb.c | 9 ++----
drivers/video/fbmem.c | 11 +++++++
drivers/video/simplefb.c | 8 -----
5 files changed, 83 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/sysfb.h b/arch/x86/include/asm/sysfb.h
index 2aeb3e2..6f95b8d 100644
--- a/arch/x86/include/asm/sysfb.h
+++ b/arch/x86/include/asm/sysfb.h
@@ -59,6 +59,11 @@ struct efifb_dmi_info {
int flags;
};
+int __init sysfb_register(const char *name, int id,
+ const struct resource *res, unsigned int res_num,
+ const void *data, size_t data_size);
+void sysfb_unregister(const struct apertures_struct *apert, bool primary);
+
#ifdef CONFIG_EFI
extern struct efifb_dmi_info efifb_dmi_list[];
diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c
index 193ec2c..ba9ff26 100644
--- a/arch/x86/kernel/sysfb.c
+++ b/arch/x86/kernel/sysfb.c
@@ -33,11 +33,76 @@
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/mm.h>
+#include <linux/mutex.h>
#include <linux/platform_data/simplefb.h>
#include <linux/platform_device.h>
#include <linux/screen_info.h>
#include <asm/sysfb.h>
+static DEFINE_MUTEX(sysfb_lock);
+static struct platform_device *sysfb_dev;
+
+int __init sysfb_register(const char *name, int id,
+ const struct resource *res, unsigned int res_num,
+ const void *data, size_t data_size)
+{
+ struct platform_device *pd;
+ int ret = 0;
+
+ mutex_lock(&sysfb_lock);
+ if (!sysfb_dev) {
+ pd = platform_device_register_resndata(NULL, name, id,
+ res, res_num,
+ data, data_size);
+ if (IS_ERR(pd))
+ ret = PTR_ERR(pd);
+ else
+ sysfb_dev = pd;
+ }
+ mutex_unlock(&sysfb_lock);
+
+ return ret;
+}
+
+static bool sysfb_match(const struct apertures_struct *apert)
+{
+ struct screen_info *si = &screen_info;
+ unsigned int i;
+ const struct aperture *a;
+
+ for (i = 0; i < apert->count; ++i) {
+ a = &apert->ranges[i];
+ if (a->base >= si->lfb_base &&
+ a->base < si->lfb_base + ((u64)si->lfb_size << 16))
+ return true;
+ if (si->lfb_base >= a->base &&
+ si->lfb_base < a->base + a->size)
+ return true;
+ }
+
+ return false;
+}
+
+/* Remove sysfb and disallow new sysfbs from now on. Can be called from any
+ * context except recursively (see also remove_conflicting_framebuffers()). */
+void sysfb_unregister(const struct apertures_struct *apert, bool primary)
+{
+ if (!apert)
+ return;
+
+ mutex_lock(&sysfb_lock);
+ if (!IS_ERR(sysfb_dev) && sysfb_dev) {
+ if (primary || sysfb_match(apert)) {
+ platform_device_unregister(sysfb_dev);
+ sysfb_dev = ERR_PTR(-EALREADY);
+ }
+ } else {
+ /* set/overwrite error so no new sysfb is probed later */
+ sysfb_dev = ERR_PTR(-EALREADY);
+ }
+ mutex_unlock(&sysfb_lock);
+}
+
static __init int sysfb_init(void)
{
struct screen_info *si = &screen_info;
diff --git a/arch/x86/kernel/sysfb_simplefb.c b/arch/x86/kernel/sysfb_simplefb.c
index 86179d4..a760d47 100644
--- a/arch/x86/kernel/sysfb_simplefb.c
+++ b/arch/x86/kernel/sysfb_simplefb.c
@@ -64,7 +64,6 @@ __init bool parse_mode(const struct screen_info *si,
__init int create_simplefb(const struct screen_info *si,
const struct simplefb_platform_data *mode)
{
- struct platform_device *pd;
struct resource res;
unsigned long len;
@@ -86,10 +85,6 @@ __init int create_simplefb(const struct screen_info *si,
if (res.end <= res.start)
return -EINVAL;
- pd = platform_device_register_resndata(NULL, "simple-framebuffer", 0,
- &res, 1, mode, sizeof(*mode));
- if (IS_ERR(pd))
- return PTR_ERR(pd);
-
- return 0;
+ return sysfb_register("simple-framebuffer", 0, &res, 1, mode,
+ sizeof(*mode));
}
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index e296967..79a47ff 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -35,6 +35,9 @@
#include <asm/fb.h>
+#ifdef CONFIG_X86_SYSFB
+# include <asm/sysfb.h>
+#endif
/*
* Frame buffer device initialization and setup routines
@@ -1751,6 +1754,10 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
{
int ret;
+#ifdef CONFIG_X86_SYSFB
+ sysfb_unregister(a, primary);
+#endif
+
mutex_lock(®istration_lock);
ret = do_remove_conflicting_framebuffers(a, name, primary);
mutex_unlock(®istration_lock);
@@ -1773,6 +1780,10 @@ register_framebuffer(struct fb_info *fb_info)
{
int ret;
+#ifdef CONFIG_X86_SYSFB
+ sysfb_unregister(fb_info->apertures, fb_is_primary_device(fb_info));
+#endif
+
mutex_lock(®istration_lock);
ret = do_register_framebuffer(fb_info);
mutex_unlock(®istration_lock);
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 210f3a0..9f4a0cf 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -209,14 +209,6 @@ static int simplefb_probe(struct platform_device *pdev)
info->var.blue = params.format->blue;
info->var.transp = params.format->transp;
- info->apertures = alloc_apertures(1);
- if (!info->apertures) {
- framebuffer_release(info);
- return -ENOMEM;
- }
- info->apertures->ranges[0].base = info->fix.smem_start;
- info->apertures->ranges[0].size = info->fix.smem_len;
-
info->fbops = &simplefb_ops;
info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
info->screen_base = ioremap_wc(info->fix.smem_start,
--
1.8.5.3
^ permalink raw reply related
* [PATCH 03/11] fbdev: efifb: add dev->remove() callback
From: David Herrmann @ 2014-01-23 14:14 UTC (permalink / raw)
To: dri-devel
Cc: linux-fbdev, Daniel Vetter, linux-kernel, Tomi Valkeinen,
Ingo Molnar
In-Reply-To: <1390486503-1504-1-git-send-email-dh.herrmann@gmail.com>
If x86-sysfb platform-devices are removed from a system, we should
properly unload efifb. Otherwise, we end up releasing the parent while our
efi framebuffer is still running. This currently works just fine, but will
cause problems on handover to real hw. So add the ->remove() callback and
unregister efifb.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
drivers/video/efifb.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
index cd7c0df..ae9618f 100644
--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -73,7 +73,6 @@ static void efifb_destroy(struct fb_info *info)
release_mem_region(info->apertures->ranges[0].base,
info->apertures->ranges[0].size);
fb_dealloc_cmap(&info->cmap);
- framebuffer_release(info);
}
static struct fb_ops efifb_ops = {
@@ -244,6 +243,7 @@ static int efifb_probe(struct platform_device *dev)
err = -ENOMEM;
goto err_release_mem;
}
+ platform_set_drvdata(dev, info);
info->pseudo_palette = info->par;
info->par = NULL;
@@ -337,12 +337,23 @@ err_release_mem:
return err;
}
+static int efifb_remove(struct platform_device *pdev)
+{
+ struct fb_info *info = platform_get_drvdata(pdev);
+
+ unregister_framebuffer(info);
+ framebuffer_release(info);
+
+ return 0;
+}
+
static struct platform_driver efifb_driver = {
.driver = {
.name = "efi-framebuffer",
.owner = THIS_MODULE,
},
.probe = efifb_probe,
+ .remove = efifb_remove,
};
module_platform_driver(efifb_driver);
--
1.8.5.3
^ 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