From: Arnd Bergmann arnd@arndb.de
The sh_mobile_lcdcfb driver calls interfaces provided by the corresponding "meram" helper. This fails if meram is a module but lcdcfb is built-in.
To work around it, this uses special Kconfig magic to only allow lcdcfb to be built if a) both are modules, b) meram is built-in, or c) meram is disabled and the helpers stubbed out
Changing meram from 'y' to 'm' now forces clcd to be a module as well, which seems to be the desired behavior.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Simon Horman horms+renesas@verge.net.au Cc: Magnus Damm magnus.damm@gmail.com Cc: linux-sh@vger.kernel.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/fbdev/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index e1f4727..a4116bf 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1971,6 +1971,7 @@ config FB_W100 config FB_SH_MOBILE_LCDC tristate "SuperH Mobile LCDC framebuffer support" depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK + depends on FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM select FB_SYS_FILLRECT select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT
From: Arnd Bergmann arnd@arndb.de
If LPAE is enabled, dma_addr_t is 64 bit, so we have to change a few type for everything in this driver to match again.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Cc: linux-omap@vger.kernel.org --- drivers/video/fbdev/omap2/dss/dispc.c | 4 ++-- include/video/omapdss.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index f18397c..461457d 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2577,9 +2577,9 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
channel = dispc_ovl_get_channel_out(plane);
- DSSDBG("dispc_ovl_setup %d, pa %x, pa_uv %x, sw %d, %d,%d, %dx%d -> " + DSSDBG("dispc_ovl_setup %d, pa %pad, pa_uv %pad, sw %d, %d,%d, %dx%d -> " "%dx%d, cmode %x, rot %d, mir %d, chan %d repl %d\n", - plane, oi->paddr, oi->p_uv_addr, oi->screen_width, oi->pos_x, + plane, &oi->paddr, &oi->p_uv_addr, oi->screen_width, oi->pos_x, oi->pos_y, oi->width, oi->height, oi->out_width, oi->out_height, oi->color_mode, oi->rotation, oi->mirror, channel, replication);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h index 6adb445..ded61a9 100644 --- a/include/video/omapdss.h +++ b/include/video/omapdss.h @@ -388,8 +388,8 @@ struct omap_dss_cpr_coefs { };
struct omap_overlay_info { - u32 paddr; - u32 p_uv_addr; /* for NV12 format */ + dma_addr_t paddr; + dma_addr_t p_uv_addr; /* for NV12 format */ u16 screen_width; u16 width; u16 height;
From: Arnd Bergmann arnd@arndb.de
We can only use I2C support in frame buffer drivers if Either I2C is built-in, or both I2C and the driver itself are loadable modules.
Fix this dependency for MB862XX and CyberPro frame buffers.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/fbdev/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index a4116bf..5577a94 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -360,6 +360,7 @@ config FB_CYBER2000_DDC config FB_CYBER2000_I2C bool "CyberPro 2000/2010/5000 I2C support" depends on FB_CYBER2000 && I2C && ARCH_NETWINDER + depends on I2C=y || FB_CYBER2000=m select I2C_ALGOBIT help Enable support for the I2C video decoder interface on the @@ -2296,6 +2297,7 @@ endchoice config FB_MB862XX_I2C bool "Support I2C bus on MB862XX GDC" depends on FB_MB862XX && I2C + depends on FB_MB862XX=m || I2C=y default y help Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
On Wednesday 23 April 2014 18:28:37 Peter Griffin wrote:
From: Arnd Bergmann arnd@arndb.de
We can only use I2C support in frame buffer drivers if Either I2C is built-in, or both I2C and the driver itself are loadable modules.
Fix this dependency for MB862XX and CyberPro frame buffers.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org
It makes sense to Cc the maintainers for the two drivers here. Unfortunately scripts/get_maintainer.pl seems to fail because the files recently moved. If you use git log --follow, you will find that Russell King and Anatolij Gustschin, respectively, maintain these drivers.
Arnd
From: Arnd Bergmann arnd@arndb.de
The framebuffer layer can be a loadable module, which forces omapfb to be a module as well. However, this breaks the lcd drivers, which are linked into the omapfb driver but each have their own module_init() function. To solve this, we split out the lcd drivers into separate modules and export omapfb_register_panel, which is the only interface required between the main omapfb driver and the lcd panel drivers.
We also have to introduce a new Kconfig symbol for H3, since that lcd driver has a dependency on TPS65010, which we can express better in Kconfig than Makefile syntax.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Cc: linux-omap@vger.kernel.org --- drivers/video/fbdev/omap/Kconfig | 9 +++++++++ drivers/video/fbdev/omap/Makefile | 23 ++++++++++++----------- drivers/video/fbdev/omap/omapfb_main.c | 1 + include/linux/omap-dma.h | 2 +- 4 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig index 0bc3a93..18c4cb0 100644 --- a/drivers/video/fbdev/omap/Kconfig +++ b/drivers/video/fbdev/omap/Kconfig @@ -39,6 +39,15 @@ config FB_OMAP_LCD_MIPID the Mobile Industry Processor Interface DBI-C/DCS specification. (Supported LCDs: Philips LPH8923, Sharp LS041Y3)
+config FB_OMAP_LCD_H3 + bool "TPS65010 LCD controller on OMAP-H3" + depends on MACH_OMAP_H3 + depends on TPS65010 + default y + help + Say Y here if you want to have support for the LCD on the + H3 board. + config FB_OMAP_DMA_TUNE bool "Set DMA SDRAM access priority high" depends on FB_OMAP diff --git a/drivers/video/fbdev/omap/Makefile b/drivers/video/fbdev/omap/Makefile index 1927faf..732e071 100644 --- a/drivers/video/fbdev/omap/Makefile +++ b/drivers/video/fbdev/omap/Makefile @@ -10,17 +10,18 @@ objs-y$(CONFIG_FB_OMAP_LCDC_EXTERNAL) += sossi.o
objs-y$(CONFIG_FB_OMAP_LCDC_HWA742) += hwa742.o
-objs-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o -objs-y$(CONFIG_MACH_OMAP_H3) += lcd_h3.o -objs-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o -objs-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o -objs-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o -objs-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o -objs-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o -objs-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o - -objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o -objs-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o +lcds-y$(CONFIG_MACH_AMS_DELTA) += lcd_ams_delta.o +lcds-y$(CONFIG_FB_OMAP_LCD_H3) += lcd_h3.o +lcds-y$(CONFIG_MACH_OMAP_PALMTE) += lcd_palmte.o +lcds-y$(CONFIG_MACH_OMAP_PALMTT) += lcd_palmtt.o +lcds-y$(CONFIG_MACH_OMAP_PALMZ71) += lcd_palmz71.o +lcds-$(CONFIG_ARCH_OMAP16XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1610.o +lcds-$(CONFIG_ARCH_OMAP15XX)$(CONFIG_MACH_OMAP_INNOVATOR) += lcd_inn1510.o +lcds-y$(CONFIG_MACH_OMAP_OSK) += lcd_osk.o + +lcds-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o +lcds-y$(CONFIG_MACH_HERALD) += lcd_htcherald.o
omapfb-objs := $(objs-yy)
+obj-$(CONFIG_FB_OMAP) += $(lcds-yy) diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c index e4fc6d9..d8d028d 100644 --- a/drivers/video/fbdev/omap/omapfb_main.c +++ b/drivers/video/fbdev/omap/omapfb_main.c @@ -1823,6 +1823,7 @@ void omapfb_register_panel(struct lcd_panel *panel) if (fbdev_pdev != NULL) omapfb_do_probe(fbdev_pdev, fbdev_panel); } +EXPORT_SYMBOL_GPL(omapfb_register_panel);
/* Called when the device is being detached from the driver */ static int omapfb_remove(struct platform_device *pdev) diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h index 41a13e7..0a1a2e2 100644 --- a/include/linux/omap-dma.h +++ b/include/linux/omap-dma.h @@ -393,7 +393,7 @@ extern int omap_modify_dma_chain_params(int chain_id, extern int omap_dma_chain_status(int chain_id); #endif
-#if defined(CONFIG_ARCH_OMAP1) && defined(CONFIG_FB_OMAP) +#if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP) #include <mach/lcd_dma.h> #else static inline int omap_lcd_dma_running(void)
From: Arnd Bergmann arnd@arndb.de
The mbx framebuffer debugfs support apparently hasn't been able to build for a long time, at least since 2006 when the u.generic_ip field in the inode was removed. This fixes the obvious bug, and also makes it possible to build the driver as a module when debugfs support is enabled, by simply including the C file. It's ugly, but it won't make the driver any worse than it already is, and doesn't require a more invasive change that might break it further.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Cc: Raphael Assenat <raph@8d.com Cc: Mike Rapoport <mike@compulab.co.il --- drivers/video/fbdev/mbx/Makefile | 3 +-- drivers/video/fbdev/mbx/mbxdebugfs.c | 2 +- drivers/video/fbdev/mbx/mbxfb.c | 2 ++ 3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/mbx/Makefile b/drivers/video/fbdev/mbx/Makefile index 16c1165..d7ae5a9 100644 --- a/drivers/video/fbdev/mbx/Makefile +++ b/drivers/video/fbdev/mbx/Makefile @@ -1,4 +1,3 @@ # Makefile for the 2700G controller driver.
-obj-$(CONFIG_FB_MBX) += mbxfb.o -obj-$(CONFIG_FB_MBX_DEBUG) += mbxfbdebugfs.o +obj-y += mbxfb.o diff --git a/drivers/video/fbdev/mbx/mbxdebugfs.c b/drivers/video/fbdev/mbx/mbxdebugfs.c index 4449f24..e3bc00a 100644 --- a/drivers/video/fbdev/mbx/mbxdebugfs.c +++ b/drivers/video/fbdev/mbx/mbxdebugfs.c @@ -17,7 +17,7 @@ struct mbxfb_debugfs_data {
static int open_file_generic(struct inode *inode, struct file *file) { - file->private_data = inode->u.generic_ip; + file->private_data = inode->i_private; return 0; }
diff --git a/drivers/video/fbdev/mbx/mbxfb.c b/drivers/video/fbdev/mbx/mbxfb.c index f0a5392..2bd52ed 100644 --- a/drivers/video/fbdev/mbx/mbxfb.c +++ b/drivers/video/fbdev/mbx/mbxfb.c @@ -877,6 +877,8 @@ static int mbxfb_resume(struct platform_device *dev) #ifndef CONFIG_FB_MBX_DEBUG #define mbxfb_debugfs_init(x) do {} while(0) #define mbxfb_debugfs_remove(x) do {} while(0) +#else +#include "mbxdebugfs.c" #endif
#define res_size(_r) (((_r)->end - (_r)->start) + 1)
From: Arnd Bergmann arnd@arndb.de
Some drivers that may be loadable modules use the fb_prepare_logo function, so we have to export it. Found during randconfig builds with mmpfb.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/fbdev/core/fbmem.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index b6d5008..479fe2a 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -674,6 +674,7 @@ int fb_show_logo(struct fb_info *info, int rotate) int fb_prepare_logo(struct fb_info *info, int rotate) { return 0; } int fb_show_logo(struct fb_info *info, int rotate) { return 0; } #endif /* CONFIG_LOGO */ +EXPORT_SYMBOL(fb_prepare_logo); EXPORT_SYMBOL(fb_show_logo);
static void *fb_seq_start(struct seq_file *m, loff_t *pos)
From: Arnd Bergmann arnd@arndb.de
The atmel frame buffer driver doesn't build if FB_BACKLIGHT is disabled, so select it here as we do for lots of other drivers.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/fbdev/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 5577a94..e593365 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -967,6 +967,7 @@ config FB_S1D13XXX config FB_ATMEL tristate "AT91/AT32 LCD Controller support" depends on FB && HAVE_FB_ATMEL + select FB_BACKLIGHT select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT
From: Arnd Bergmann arnd@arndb.de
The LM3630A and LP8788 backlight drivers both use the PWM subsystem, so we have to add an explicit dependency to avoid build errors.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jingoo Han jg1.han@samsung.com Cc: Bryan Wu cooloney@gmail.com Cc: Lee Jones lee.jones@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/backlight/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index 5a3eb2e..ac6bc28 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -370,7 +370,7 @@ config BACKLIGHT_AAT2870
config BACKLIGHT_LM3630A tristate "Backlight Driver for LM3630A" - depends on BACKLIGHT_CLASS_DEVICE && I2C + depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM select REGMAP_I2C help This supports TI LM3630A Backlight Driver @@ -393,7 +393,7 @@ config BACKLIGHT_LP855X
config BACKLIGHT_LP8788 tristate "Backlight driver for TI LP8788 MFD" - depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788 + depends on BACKLIGHT_CLASS_DEVICE && MFD_LP8788 && PWM help This supports TI LP8788 backlight driver.
From: Arnd Bergmann arnd@arndb.de
This driver depends on LCD_CLASS_DEVICE, which can be a loadable module, but S6E8AX0 can only be built-in at the moment, which can lead to link errors when the class device code is not built-in.
Changing this to allow the driver as a module also requires exporting the exynos_mipi_dsi_register_lcd_driver symbol.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: Kukjin Kim kgene.kim@samsung.com Cc: linux-fbdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- drivers/video/fbdev/exynos/Kconfig | 4 ++-- drivers/video/fbdev/exynos/exynos_mipi_dsi.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig index fcf2d48..bf776dd 100644 --- a/drivers/video/fbdev/exynos/Kconfig +++ b/drivers/video/fbdev/exynos/Kconfig @@ -21,9 +21,9 @@ config EXYNOS_MIPI_DSI This enables support for MIPI-DSI device.
config EXYNOS_LCD_S6E8AX0 - bool "S6E8AX0 MIPI AMOLED LCD Driver" + tristate "S6E8AX0 MIPI AMOLED LCD Driver" depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE - depends on (LCD_CLASS_DEVICE = y) + depends on LCD_CLASS_DEVICE default n help If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c index cee9602..cf1390e 100644 --- a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c +++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c @@ -263,6 +263,7 @@ int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv) return 0;
} +EXPORT_SYMBOL_GPL(exynos_mipi_dsi_register_lcd_driver);
static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi( struct mipi_dsim_device *dsim,
On Wednesday 23 April 2014 18:28:43 Peter Griffin wrote:
diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig index fcf2d48..bf776dd 100644 --- a/drivers/video/fbdev/exynos/Kconfig +++ b/drivers/video/fbdev/exynos/Kconfig @@ -21,9 +21,9 @@ config EXYNOS_MIPI_DSI This enables support for MIPI-DSI device. config EXYNOS_LCD_S6E8AX0
bool "S6E8AX0 MIPI AMOLED LCD Driver"
tristate "S6E8AX0 MIPI AMOLED LCD Driver" depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
depends on (LCD_CLASS_DEVICE = y)
depends on LCD_CLASS_DEVICE default n help If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its
Looking at the patch description and the actual changes now, it becomes clear that the bug was already addressed by Sachin Kamat in 31d6af29066bf "video: exynos: Fix S6E8AX0 LCD driver build error". You can probably just drop this patch. I would still prefer my solution, but the change that he did seems good enough.
Arnd
From: Arnd Bergmann arnd@arndb.de
This fixes a randconfig build error when BACKLIGHT_CLASS_DEVICE is disabled, by describing the dependency in Kconfig, as we do for the other drivers in this directory.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jingoo Han jg1.han@samsung.com Cc: Bryan Wu cooloney@gmail.com Cc: Lee Jones lee.jones@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/backlight/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index ac6bc28..5675511 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -29,7 +29,7 @@ if LCD_CLASS_DEVICE
config LCD_CORGI tristate "LCD Panel support for SHARP corgi/spitz model" - depends on SPI_MASTER && PXA_SHARPSL + depends on SPI_MASTER && PXA_SHARPSL && BACKLIGHT_CLASS_DEVICE help Say y here to support the LCD panels usually found on SHARP corgi (C7x0) and spitz (Cxx00) models.
From: Arnd Bergmann arnd@arndb.de
The frame buffer core may be a loadable module, and in this case, the nuc900 driver cannot be built-in. Turning it into a tristate option lets Kconfig work out the dependency and avoid broken builds.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/fbdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index e593365..95396de 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2065,7 +2065,7 @@ config FB_S3C2410_DEBUG through sysfs
config FB_NUC900 - bool "NUC900 LCD framebuffer support" + tristate "NUC900 LCD framebuffer support" depends on FB && ARCH_W90X900 select FB_CFB_FILLRECT select FB_CFB_COPYAREA
On Wednesday 23 April 2014 18:28:45 Peter Griffin wrote:
From: Arnd Bergmann arnd@arndb.de
The frame buffer core may be a loadable module, and in this case, the nuc900 driver cannot be built-in. Turning it into a tristate option lets Kconfig work out the dependency and avoid broken builds.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org
You should take Wan ZongShun, the nuc900 maintainer on Cc. Again, this is slightly non-obvious because get_maintainer.pl doesn't find him because of the move, and because the platform is called w90x900 in the MAINTAINERS file.
On a side-node, someone should do a patch that fixes up the MAINTAINERS file to reflect the move of all the drivers/video/* files to drivers/video/fbdev/*.
Arnd
From: Arnd Bergmann arnd@arndb.de
The LP855X driver cannot be successfully built if we don't enable the PWM subsystem. This patch makes that dependency explicit in Kconfig and prevents broken randconfig builds.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jingoo Han jg1.han@samsung.com Cc: Bryan Wu cooloney@gmail.com Cc: Lee Jones lee.jones@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org --- drivers/video/backlight/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig index 5675511..5d44905 100644 --- a/drivers/video/backlight/Kconfig +++ b/drivers/video/backlight/Kconfig @@ -386,7 +386,7 @@ config BACKLIGHT_LM3639
config BACKLIGHT_LP855X tristate "Backlight driver for TI LP855X" - depends on BACKLIGHT_CLASS_DEVICE && I2C + depends on BACKLIGHT_CLASS_DEVICE && I2C && PWM help This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and LP8557 backlight driver.
On Wednesday 23 April 2014 18:28:46 Peter Griffin wrote:
From: Arnd Bergmann arnd@arndb.de
The LP855X driver cannot be successfully built if we don't enable the PWM subsystem. This patch makes that dependency explicit in Kconfig and prevents broken randconfig builds.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jingoo Han jg1.han@samsung.com Cc: Bryan Wu cooloney@gmail.com Cc: Lee Jones lee.jones@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org
This patch is actually the same as patch 8, just for a different driver. I hadn't noticed that earlier, but now I think it should either be merged into one patch, or split up into three separate patches.
Arnd
From: Arnd Bergmann arnd@arndb.de
The omap lcdc driver has an elaborate mmap_kern function to map the frame buffer into kernel address space as write-combined. This uses functions that are only available on MMU-enabled builds.
It does seem equivalent to ioremap_wc though, so we should be able to just use that instead.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Cc: linux-omap@vger.kernel.org --- drivers/video/fbdev/omap/lcdc.c | 28 +++++----------------------- 1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c index b52f625..40e8200 100644 --- a/drivers/video/fbdev/omap/lcdc.c +++ b/drivers/video/fbdev/omap/lcdc.c @@ -613,29 +613,11 @@ static void lcdc_dma_handler(u16 status, void *data)
static int mmap_kern(void) { - struct vm_struct *kvma; - struct vm_area_struct vma; - pgprot_t pgprot; - unsigned long vaddr; - - kvma = get_vm_area(lcdc.vram_size, VM_IOREMAP); - if (kvma == NULL) { - dev_err(lcdc.fbdev->dev, "can't get kernel vm area\n"); + void __iomem *vaddr; + + vaddr = ioremap_wc(lcdc.vram_phys, lcdc.vram_size); + if (!vaddr) return -ENOMEM; - } - vma.vm_mm = &init_mm; - - vaddr = (unsigned long)kvma->addr; - vma.vm_start = vaddr; - vma.vm_end = vaddr + lcdc.vram_size; - - pgprot = pgprot_writecombine(pgprot_kernel); - if (io_remap_pfn_range(&vma, vaddr, - lcdc.vram_phys >> PAGE_SHIFT, - lcdc.vram_size, pgprot) < 0) { - dev_err(lcdc.fbdev->dev, "kernel mmap for FB memory failed\n"); - return -EAGAIN; - }
lcdc.vram_virt = (void *)vaddr;
@@ -644,7 +626,7 @@ static int mmap_kern(void)
static void unmap_kern(void) { - vunmap(lcdc.vram_virt); + iounmap(lcdc.vram_virt); }
static int alloc_palette_ram(void)
On Wednesday 23 April 2014 18:28:47 Peter Griffin wrote:
From: Arnd Bergmann arnd@arndb.de
The omap lcdc driver has an elaborate mmap_kern function to map the frame buffer into kernel address space as write-combined. This uses functions that are only available on MMU-enabled builds.
It does seem equivalent to ioremap_wc though, so we should be able to just use that instead.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org Cc: linux-omap@vger.kernel.org
You couldn't have guessed this, but the description should probably be extended with this sentence:
| This patch is build-tested only, it needs to be run on real | hardware before applying.
Tomi is also the maintainer of the omap driver, so hopefully he will be able to test it.
Arnd
On Wednesday 23 April 2014 18:28:35 Peter Griffin wrote:
From: Arnd Bergmann arnd@arndb.de
The sh_mobile_lcdcfb driver calls interfaces provided by the corresponding "meram" helper. This fails if meram is a module but lcdcfb is built-in.
To work around it, this uses special Kconfig magic to only allow lcdcfb to be built if a) both are modules, b) meram is built-in, or c) meram is disabled and the helpers stubbed out
Changing meram from 'y' to 'm' now forces clcd to be a module as well, which seems to be the desired behavior.
Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Peter Griffin peter.griffin@linaro.org Cc: Simon Horman horms+renesas@verge.net.au Cc: Magnus Damm magnus.damm@gmail.com Cc: linux-sh@vger.kernel.org Cc: Jean-Christophe Plagniol-Villard plagnioj@jcrosoft.com Cc: Tomi Valkeinen tomi.valkeinen@ti.com Cc: linux-fbdev@vger.kernel.org
This was quick!
I think you got almost everything right with the series, but one important addition would be a cover letter in the sense that 'git format-patch --cover-letter' generates, filling that out with an explanation about the purpose of the patch series, what your involvement is in this, and what you expect to happen with the patches. I'll go through the patches individually and comment on anything that sticks out. I guess once you have addressed those, you can send the patches for real.
Arnd
Hay Arnd,
This was quick!
I think you got almost everything right with the series, but one important addition would be a cover letter in the sense that 'git format-patch --cover-letter' generates, filling that out with an explanation about the purpose of the patch series, what your involvement is in this, and what you expect to happen with the patches. I'll go through the patches individually and comment on anything that sticks out. I guess once you have addressed those, you can send the patches for real.
Thanks for taking a look :-) I'll address your comments and then resend the patchset for real with a cover letter.
Peter.
linaro-kernel@lists.linaro.org
-
Arnd Bergmann -
Peter Griffin