* [PATCH 0/3] sh_mobile_lcdcfb overlays support
From: Laurent Pinchart @ 2012-05-31 17:21 UTC (permalink / raw)
To: linux-fbdev
Hello,
These three patches implement overlays support for the sh_mobile_lcdcfb driver.
Compared to the previous version (posted as part of a larger patch set), the
sysfs entries are documented in Documentation/ABI and the DMA coherent memory
allocated for the planes is now freed at cleanup time.
Laurent Pinchart (3):
fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common
prefix
fbdev: sh_mobile_lcdc: Implement overlays support
.../sysfs-devices-platform-sh_mobile_lcdc_fb | 59 ++
drivers/video/sh_mobile_lcdcfb.c | 1011 ++++++++++++++++++--
include/video/sh_mobile_lcdc.h | 7 +
3 files changed, 981 insertions(+), 96 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/3] fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
From: Laurent Pinchart @ 2012-05-31 17:21 UTC (permalink / raw)
To: linux-fbdev
The structure is only read, make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 7a0b301..b6fb8a4 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1002,7 +1002,7 @@ static int sh_mobile_lcdc_setcolreg(u_int regno,
return 0;
}
-static struct fb_fix_screeninfo sh_mobile_lcdc_fix = {
+static const struct fb_fix_screeninfo sh_mobile_lcdc_fix = {
.id = "SH Mobile LCDC",
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_TRUECOLOR,
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/3] fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
From: Laurent Pinchart @ 2012-05-31 17:21 UTC (permalink / raw)
To: linux-fbdev
Make all fb operation handlers start with sh_mobile_lcdc_ in preparation
for the multi-plane support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 48 +++++++++++++++++++------------------
1 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index b6fb8a4..36dad2f 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -384,8 +384,8 @@ sh_mobile_lcdc_must_reconfigure(struct sh_mobile_lcdc_chan *ch,
return true;
}
-static int sh_mobile_check_var(struct fb_var_screeninfo *var,
- struct fb_info *info);
+static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info);
static int sh_mobile_lcdc_display_notify(struct sh_mobile_lcdc_chan *ch,
enum sh_mobile_lcdc_entity_event event,
@@ -439,7 +439,7 @@ static int sh_mobile_lcdc_display_notify(struct sh_mobile_lcdc_chan *ch,
fb_videomode_to_var(&var, mode);
var.bits_per_pixel = info->var.bits_per_pixel;
var.grayscale = info->var.grayscale;
- ret = sh_mobile_check_var(&var, info);
+ ret = sh_mobile_lcdc_check_var(&var, info);
break;
}
@@ -585,7 +585,7 @@ static irqreturn_t sh_mobile_lcdc_irq(int irq, void *data)
return IRQ_HANDLED;
}
-static int sh_mobile_wait_for_vsync(struct sh_mobile_lcdc_chan *ch)
+static int sh_mobile_lcdc_wait_for_vsync(struct sh_mobile_lcdc_chan *ch)
{
unsigned long ldintr;
int ret;
@@ -686,7 +686,7 @@ static void sh_mobile_lcdc_geometry(struct sh_mobile_lcdc_chan *ch)
}
/*
- * __sh_mobile_lcdc_start - Configure and tart the LCDC
+ * __sh_mobile_lcdc_start - Configure and start the LCDC
* @priv: LCDC device
*
* Configure all enabled channels and start the LCDC device. All external
@@ -1034,8 +1034,8 @@ static void sh_mobile_lcdc_imageblit(struct fb_info *info,
sh_mobile_lcdc_deferred_io_touch(info);
}
-static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
- struct fb_info *info)
+static int sh_mobile_lcdc_pan(struct fb_var_screeninfo *var,
+ struct fb_info *info)
{
struct sh_mobile_lcdc_chan *ch = info->par;
struct sh_mobile_lcdc_priv *priv = ch->lcdc;
@@ -1098,14 +1098,15 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
return 0;
}
-static int sh_mobile_ioctl(struct fb_info *info, unsigned int cmd,
- unsigned long arg)
+static int sh_mobile_lcdc_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
{
+ struct sh_mobile_lcdc_chan *ch = info->par;
int retval;
switch (cmd) {
case FBIO_WAITFORVSYNC:
- retval = sh_mobile_wait_for_vsync(info->par);
+ retval = sh_mobile_lcdc_wait_for_vsync(ch);
break;
default:
@@ -1157,7 +1158,7 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
* Locking: both .fb_release() and .fb_open() are called with info->lock held if
* user = 1, or with console sem held, if user = 0.
*/
-static int sh_mobile_release(struct fb_info *info, int user)
+static int sh_mobile_lcdc_release(struct fb_info *info, int user)
{
struct sh_mobile_lcdc_chan *ch = info->par;
@@ -1178,7 +1179,7 @@ static int sh_mobile_release(struct fb_info *info, int user)
return 0;
}
-static int sh_mobile_open(struct fb_info *info, int user)
+static int sh_mobile_lcdc_open(struct fb_info *info, int user)
{
struct sh_mobile_lcdc_chan *ch = info->par;
@@ -1191,7 +1192,8 @@ static int sh_mobile_open(struct fb_info *info, int user)
return 0;
}
-static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
{
struct sh_mobile_lcdc_chan *ch = info->par;
struct sh_mobile_lcdc_priv *p = ch->lcdc;
@@ -1312,7 +1314,7 @@ static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *in
return 0;
}
-static int sh_mobile_set_par(struct fb_info *info)
+static int sh_mobile_lcdc_set_par(struct fb_info *info)
{
struct sh_mobile_lcdc_chan *ch = info->par;
int ret;
@@ -1382,8 +1384,8 @@ static int sh_mobile_lcdc_blank(int blank, struct fb_info *info)
* mode will reenable the clocks and update the screen in time,
* so it does not need this. */
if (!info->fbdefio) {
- sh_mobile_wait_for_vsync(ch);
- sh_mobile_wait_for_vsync(ch);
+ sh_mobile_lcdc_wait_for_vsync(ch);
+ sh_mobile_lcdc_wait_for_vsync(ch);
}
sh_mobile_lcdc_clk_off(p);
}
@@ -1401,12 +1403,12 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_copyarea = sh_mobile_lcdc_copyarea,
.fb_imageblit = sh_mobile_lcdc_imageblit,
.fb_blank = sh_mobile_lcdc_blank,
- .fb_pan_display = sh_mobile_fb_pan_display,
- .fb_ioctl = sh_mobile_ioctl,
- .fb_open = sh_mobile_open,
- .fb_release = sh_mobile_release,
- .fb_check_var = sh_mobile_check_var,
- .fb_set_par = sh_mobile_set_par,
+ .fb_pan_display = sh_mobile_lcdc_pan,
+ .fb_ioctl = sh_mobile_lcdc_ioctl,
+ .fb_open = sh_mobile_lcdc_open,
+ .fb_release = sh_mobile_lcdc_release,
+ .fb_check_var = sh_mobile_lcdc_check_var,
+ .fb_set_par = sh_mobile_lcdc_set_par,
};
static void
@@ -1536,7 +1538,7 @@ sh_mobile_lcdc_channel_fb_init(struct sh_mobile_lcdc_chan *ch,
else
var->grayscale = ch->format->fourcc;
- ret = sh_mobile_check_var(var, info);
+ ret = sh_mobile_lcdc_check_var(var, info);
if (ret)
return ret;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 3/3] fbdev: sh_mobile_lcdc: Implement overlays support
From: Laurent Pinchart @ 2012-05-31 17:21 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../sysfs-devices-platform-sh_mobile_lcdc_fb | 59 ++
drivers/video/sh_mobile_lcdcfb.c | 961 ++++++++++++++++++--
include/video/sh_mobile_lcdc.h | 7 +
3 files changed, 955 insertions(+), 72 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb b/Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb
new file mode 100644
index 0000000..30269d8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb
@@ -0,0 +1,59 @@
+What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_alpha
+Date: May 2012
+Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Description:
+ This file is only available on fb[0-9] devices corresponding
+ to overlay planes.
+
+ Stores the alpha blending value for the overlay. Values range
+ from 0 (transparent) to 255 (opaque). The value is ignored if
+ the mode is not set to Alpha Blending.
+
+What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_enabled
+Date: May 2012
+Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Description:
+ This file is only available on fb[0-9] devices corresponding
+ to overlay planes.
+
+ Indicates whether the overlay is enabled or disabled. Possible
+ values are
+
+ 0 - Disabled
+ 1 - Enabled
+
+ Disabled overlays are not displayed by the LCDC.
+
+What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_mode
+Date: May 2012
+Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Description:
+ This file is only available on fb[0-9] devices corresponding
+ to overlay planes.
+
+ Selects the composition mode for the overlay. Possible values
+ are
+
+ 0 - Alpha Blending
+ 1 - ROP3
+
+What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_position
+Date: May 2012
+Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Description:
+ This file is only available on fb[0-9] devices corresponding
+ to overlay planes.
+
+ Stores the x,y overlay position on the display in pixels. The
+ position format is `[0-9]+,[0-9]+'.
+
+What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_rop3
+Date: May 2012
+Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Description:
+ This file is only available on fb[0-9] devices corresponding
+ to overlay planes.
+
+ Stores the raster operation (ROP3) for the overlay. Values
+ range from 0 to 255. The value is ignored if the mode is not
+ set to ROP3.
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 36dad2f..0394d95 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -12,6 +12,7 @@
#include <linux/backlight.h>
#include <linux/clk.h>
#include <linux/console.h>
+#include <linux/ctype.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
#include <linux/gpio.h>
@@ -32,12 +33,176 @@
#include "sh_mobile_lcdcfb.h"
+/* ----------------------------------------------------------------------------
+ * Overlay register definitions
+ */
+
+#define LDBCR 0xb00
+#define LDBCR_UPC(n) (1 << ((n) + 16))
+#define LDBCR_UPF(n) (1 << ((n) + 8))
+#define LDBCR_UPD(n) (1 << ((n) + 0))
+#define LDBnBSIFR(n) (0xb20 + (n) * 0x20 + 0x00)
+#define LDBBSIFR_EN (1 << 31)
+#define LDBBSIFR_VS (1 << 29)
+#define LDBBSIFR_BRSEL (1 << 28)
+#define LDBBSIFR_MX (1 << 27)
+#define LDBBSIFR_MY (1 << 26)
+#define LDBBSIFR_CV3 (3 << 24)
+#define LDBBSIFR_CV2 (2 << 24)
+#define LDBBSIFR_CV1 (1 << 24)
+#define LDBBSIFR_CV0 (0 << 24)
+#define LDBBSIFR_CV_MASK (3 << 24)
+#define LDBBSIFR_LAY_MASK (0xff << 16)
+#define LDBBSIFR_LAY_SHIFT 16
+#define LDBBSIFR_ROP3_MASK (0xff << 16)
+#define LDBBSIFR_ROP3_SHIFT 16
+#define LDBBSIFR_AL_PL8 (3 << 14)
+#define LDBBSIFR_AL_PL1 (2 << 14)
+#define LDBBSIFR_AL_PK (1 << 14)
+#define LDBBSIFR_AL_1 (0 << 14)
+#define LDBBSIFR_AL_MASK (3 << 14)
+#define LDBBSIFR_SWPL (1 << 10)
+#define LDBBSIFR_SWPW (1 << 9)
+#define LDBBSIFR_SWPB (1 << 8)
+#define LDBBSIFR_RY (1 << 7)
+#define LDBBSIFR_CHRR_420 (2 << 0)
+#define LDBBSIFR_CHRR_422 (1 << 0)
+#define LDBBSIFR_CHRR_444 (0 << 0)
+#define LDBBSIFR_RPKF_ARGB32 (0x00 << 0)
+#define LDBBSIFR_RPKF_RGB16 (0x03 << 0)
+#define LDBBSIFR_RPKF_RGB24 (0x0b << 0)
+#define LDBBSIFR_RPKF_MASK (0x1f << 0)
+#define LDBnBSSZR(n) (0xb20 + (n) * 0x20 + 0x04)
+#define LDBBSSZR_BVSS_MASK (0xfff << 16)
+#define LDBBSSZR_BVSS_SHIFT 16
+#define LDBBSSZR_BHSS_MASK (0xfff << 0)
+#define LDBBSSZR_BHSS_SHIFT 0
+#define LDBnBLOCR(n) (0xb20 + (n) * 0x20 + 0x08)
+#define LDBBLOCR_CVLC_MASK (0xfff << 16)
+#define LDBBLOCR_CVLC_SHIFT 16
+#define LDBBLOCR_CHLC_MASK (0xfff << 0)
+#define LDBBLOCR_CHLC_SHIFT 0
+#define LDBnBSMWR(n) (0xb20 + (n) * 0x20 + 0x0c)
+#define LDBBSMWR_BSMWA_MASK (0xffff << 16)
+#define LDBBSMWR_BSMWA_SHIFT 16
+#define LDBBSMWR_BSMW_MASK (0xffff << 0)
+#define LDBBSMWR_BSMW_SHIFT 0
+#define LDBnBSAYR(n) (0xb20 + (n) * 0x20 + 0x10)
+#define LDBBSAYR_FG1A_MASK (0xff << 24)
+#define LDBBSAYR_FG1A_SHIFT 24
+#define LDBBSAYR_FG1R_MASK (0xff << 16)
+#define LDBBSAYR_FG1R_SHIFT 16
+#define LDBBSAYR_FG1G_MASK (0xff << 8)
+#define LDBBSAYR_FG1G_SHIFT 8
+#define LDBBSAYR_FG1B_MASK (0xff << 0)
+#define LDBBSAYR_FG1B_SHIFT 0
+#define LDBnBSACR(n) (0xb20 + (n) * 0x20 + 0x14)
+#define LDBBSACR_FG2A_MASK (0xff << 24)
+#define LDBBSACR_FG2A_SHIFT 24
+#define LDBBSACR_FG2R_MASK (0xff << 16)
+#define LDBBSACR_FG2R_SHIFT 16
+#define LDBBSACR_FG2G_MASK (0xff << 8)
+#define LDBBSACR_FG2G_SHIFT 8
+#define LDBBSACR_FG2B_MASK (0xff << 0)
+#define LDBBSACR_FG2B_SHIFT 0
+#define LDBnBSAAR(n) (0xb20 + (n) * 0x20 + 0x18)
+#define LDBBSAAR_AP_MASK (0xff << 24)
+#define LDBBSAAR_AP_SHIFT 24
+#define LDBBSAAR_R_MASK (0xff << 16)
+#define LDBBSAAR_R_SHIFT 16
+#define LDBBSAAR_GY_MASK (0xff << 8)
+#define LDBBSAAR_GY_SHIFT 8
+#define LDBBSAAR_B_MASK (0xff << 0)
+#define LDBBSAAR_B_SHIFT 0
+#define LDBnBPPCR(n) (0xb20 + (n) * 0x20 + 0x1c)
+#define LDBBPPCR_AP_MASK (0xff << 24)
+#define LDBBPPCR_AP_SHIFT 24
+#define LDBBPPCR_R_MASK (0xff << 16)
+#define LDBBPPCR_R_SHIFT 16
+#define LDBBPPCR_GY_MASK (0xff << 8)
+#define LDBBPPCR_GY_SHIFT 8
+#define LDBBPPCR_B_MASK (0xff << 0)
+#define LDBBPPCR_B_SHIFT 0
+#define LDBnBBGCL(n) (0xb10 + (n) * 0x04)
+#define LDBBBGCL_BGA_MASK (0xff << 24)
+#define LDBBBGCL_BGA_SHIFT 24
+#define LDBBBGCL_BGR_MASK (0xff << 16)
+#define LDBBBGCL_BGR_SHIFT 16
+#define LDBBBGCL_BGG_MASK (0xff << 8)
+#define LDBBBGCL_BGG_SHIFT 8
+#define LDBBBGCL_BGB_MASK (0xff << 0)
+#define LDBBBGCL_BGB_SHIFT 0
+
#define SIDE_B_OFFSET 0x1000
#define MIRROR_OFFSET 0x2000
#define MAX_XRES 1920
#define MAX_YRES 1080
+enum sh_mobile_lcdc_overlay_mode {
+ LCDC_OVERLAY_BLEND,
+ LCDC_OVERLAY_ROP3,
+};
+
+/*
+ * struct sh_mobile_lcdc_overlay - LCDC display overlay
+ *
+ * @channel: LCDC channel this overlay belongs to
+ * @cfg: Overlay configuration
+ * @info: Frame buffer device
+ * @index: Overlay index (0-3)
+ * @base: Overlay registers base address
+ * @enabled: True if the overlay is enabled
+ * @mode: Overlay blending mode (alpha blend or ROP3)
+ * @alpha: Global alpha blending value (0-255, for alpha blending mode)
+ * @rop3: Raster operation (for ROP3 mode)
+ * @fb_mem: Frame buffer virtual memory address
+ * @fb_size: Frame buffer size in bytes
+ * @dma_handle: Frame buffer DMA address
+ * @base_addr_y: Overlay base address (RGB or luma component)
+ * @base_addr_c: Overlay base address (chroma component)
+ * @pan_offset: Current pan offset in bytes
+ * @format: Current pixelf format
+ * @xres: Horizontal visible resolution
+ * @xres_virtual: Horizontal total resolution
+ * @yres: Vertical visible resolution
+ * @yres_virtual: Vertical total resolution
+ * @pitch: Overlay line pitch
+ * @pos_x: Horizontal overlay position
+ * @pos_y: Vertical overlay position
+ */
+struct sh_mobile_lcdc_overlay {
+ struct sh_mobile_lcdc_chan *channel;
+
+ const struct sh_mobile_lcdc_overlay_cfg *cfg;
+ struct fb_info *info;
+
+ unsigned int index;
+ unsigned long base;
+
+ bool enabled;
+ enum sh_mobile_lcdc_overlay_mode mode;
+ unsigned int alpha;
+ unsigned int rop3;
+
+ void *fb_mem;
+ unsigned long fb_size;
+
+ dma_addr_t dma_handle;
+ unsigned long base_addr_y;
+ unsigned long base_addr_c;
+ unsigned long pan_offset;
+
+ const struct sh_mobile_lcdc_format_info *format;
+ unsigned int xres;
+ unsigned int xres_virtual;
+ unsigned int yres;
+ unsigned int yres_virtual;
+ unsigned int pitch;
+ int pos_x;
+ int pos_y;
+};
+
struct sh_mobile_lcdc_priv {
void __iomem *base;
int irq;
@@ -45,7 +210,10 @@ struct sh_mobile_lcdc_priv {
struct device *dev;
struct clk *dot_clk;
unsigned long lddckr;
+
struct sh_mobile_lcdc_chan ch[2];
+ struct sh_mobile_lcdc_overlay overlays[4];
+
struct notifier_block notifier;
int started;
int forced_fourcc; /* 2 channel LCDC must share fourcc setting */
@@ -141,6 +309,13 @@ static unsigned long lcdc_read_chan(struct sh_mobile_lcdc_chan *chan,
return ioread32(chan->lcdc->base + chan->reg_offs[reg_nr]);
}
+static void lcdc_write_overlay(struct sh_mobile_lcdc_overlay *ovl,
+ int reg, unsigned long data)
+{
+ iowrite32(data, ovl->channel->lcdc->base + reg);
+ iowrite32(data, ovl->channel->lcdc->base + reg + SIDE_B_OFFSET);
+}
+
static void lcdc_write(struct sh_mobile_lcdc_priv *priv,
unsigned long reg_offs, unsigned long data)
{
@@ -685,6 +860,93 @@ static void sh_mobile_lcdc_geometry(struct sh_mobile_lcdc_chan *ch)
lcdc_write_chan(ch, LDHAJR, tmp);
}
+static void sh_mobile_lcdc_overlay_setup(struct sh_mobile_lcdc_overlay *ovl)
+{
+ u32 format = 0;
+
+ if (!ovl->enabled) {
+ lcdc_write_overlay(ovl, LDBnBSIFR(ovl->index), 0);
+ return;
+ }
+
+ ovl->base_addr_y = ovl->dma_handle;
+ ovl->base_addr_c = ovl->base_addr_y + ovl->xres
+ * ovl->yres_virtual;
+
+ switch (ovl->mode) {
+ case LCDC_OVERLAY_BLEND:
+ format = LDBBSIFR_EN | (ovl->alpha << LDBBSIFR_LAY_SHIFT);
+ break;
+
+ case LCDC_OVERLAY_ROP3:
+ format = LDBBSIFR_EN | LDBBSIFR_BRSEL
+ | (ovl->rop3 << LDBBSIFR_ROP3_SHIFT);
+ break;
+ }
+
+ switch (ovl->format->fourcc) {
+ case V4L2_PIX_FMT_RGB565:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_NV61:
+ case V4L2_PIX_FMT_NV42:
+ format |= LDBBSIFR_SWPL | LDBBSIFR_SWPW;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV24:
+ format |= LDBBSIFR_SWPL | LDBBSIFR_SWPW | LDBBSIFR_SWPB;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ default:
+ format |= LDBBSIFR_SWPL;
+ break;
+ }
+
+ switch (ovl->format->fourcc) {
+ case V4L2_PIX_FMT_RGB565:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_RY | LDBBSIFR_RPKF_RGB16;
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_RY | LDBBSIFR_RPKF_RGB24;
+ break;
+ case V4L2_PIX_FMT_BGR32:
+ format |= LDBBSIFR_AL_PK | LDBBSIFR_RY | LDDFR_PKF_ARGB32;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_CHRR_420;
+ break;
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_CHRR_422;
+ break;
+ case V4L2_PIX_FMT_NV24:
+ case V4L2_PIX_FMT_NV42:
+ format |= LDBBSIFR_AL_1 | LDBBSIFR_CHRR_444;
+ break;
+ }
+
+ lcdc_write(ovl->channel->lcdc, LDBCR, LDBCR_UPC(ovl->index));
+
+ lcdc_write_overlay(ovl, LDBnBSIFR(ovl->index), format);
+
+ lcdc_write_overlay(ovl, LDBnBSSZR(ovl->index),
+ (ovl->yres << LDBBSSZR_BVSS_SHIFT) |
+ (ovl->xres << LDBBSSZR_BHSS_SHIFT));
+ lcdc_write_overlay(ovl, LDBnBLOCR(ovl->index),
+ (ovl->pos_y << LDBBLOCR_CVLC_SHIFT) |
+ (ovl->pos_x << LDBBLOCR_CHLC_SHIFT));
+ lcdc_write_overlay(ovl, LDBnBSMWR(ovl->index),
+ ovl->pitch << LDBBSMWR_BSMW_SHIFT);
+
+ lcdc_write_overlay(ovl, LDBnBSAYR(ovl->index), ovl->base_addr_y);
+ lcdc_write_overlay(ovl, LDBnBSACR(ovl->index), ovl->base_addr_c);
+
+ lcdc_write(ovl->channel->lcdc, LDBCR,
+ LDBCR_UPF(ovl->index) | LDBCR_UPD(ovl->index));
+}
+
/*
* __sh_mobile_lcdc_start - Configure and start the LCDC
* @priv: LCDC device
@@ -891,6 +1153,11 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
}
}
+ for (k = 0; k < ARRAY_SIZE(priv->overlays); ++k) {
+ struct sh_mobile_lcdc_overlay *ovl = &priv->overlays[k];
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
/* Start the LCDC. */
__sh_mobile_lcdc_start(priv);
@@ -974,8 +1241,538 @@ static void sh_mobile_lcdc_stop(struct sh_mobile_lcdc_priv *priv)
sh_mobile_lcdc_clk_off(priv);
}
+static int __sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ if (var->xres > MAX_XRES || var->yres > MAX_YRES)
+ return -EINVAL;
+
+ /* Make sure the virtual resolution is at least as big as the visible
+ * resolution.
+ */
+ if (var->xres_virtual < var->xres)
+ var->xres_virtual = var->xres;
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
+ if (sh_mobile_format_is_fourcc(var)) {
+ const struct sh_mobile_lcdc_format_info *format;
+
+ format = sh_mobile_format_info(var->grayscale);
+ if (format = NULL)
+ return -EINVAL;
+ var->bits_per_pixel = format->bpp;
+
+ /* Default to RGB and JPEG color-spaces for RGB and YUV formats
+ * respectively.
+ */
+ if (!format->yuv)
+ var->colorspace = V4L2_COLORSPACE_SRGB;
+ else if (var->colorspace != V4L2_COLORSPACE_REC709)
+ var->colorspace = V4L2_COLORSPACE_JPEG;
+ } else {
+ if (var->bits_per_pixel <= 16) { /* RGB 565 */
+ var->bits_per_pixel = 16;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->blue.offset = 0;
+ var->blue.length = 5;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 24) { /* RGB 888 */
+ var->bits_per_pixel = 24;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 32) { /* RGBA 888 */
+ var->bits_per_pixel = 32;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ } else
+ return -EINVAL;
+
+ var->red.msb_right = 0;
+ var->green.msb_right = 0;
+ var->blue.msb_right = 0;
+ var->transp.msb_right = 0;
+ }
+
+ /* Make sure we don't exceed our allocated memory. */
+ if (var->xres_virtual * var->yres_virtual * var->bits_per_pixel / 8 >
+ info->fix.smem_len)
+ return -EINVAL;
+
+ return 0;
+}
+
/* -----------------------------------------------------------------------------
- * Frame buffer operations
+ * Frame buffer operations - Overlays
+ */
+
+static ssize_t
+overlay_alpha_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->alpha);
+}
+
+static ssize_t
+overlay_alpha_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ unsigned int alpha;
+ char *endp;
+
+ alpha = simple_strtoul(buf, &endp, 10);
+ if (isspace(*endp))
+ endp++;
+
+ if (endp - buf != count)
+ return -EINVAL;
+
+ if (alpha > 255)
+ return -EINVAL;
+
+ if (ovl->alpha != alpha) {
+ ovl->alpha = alpha;
+
+ if (ovl->mode = LCDC_OVERLAY_BLEND && ovl->enabled)
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
+ return count;
+}
+
+static ssize_t
+overlay_enabled_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->enabled);
+}
+
+static ssize_t
+overlay_enabled_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ bool enabled;
+ char *endp;
+
+ enabled = !!simple_strtoul(buf, &endp, 10);
+ if (isspace(*endp))
+ endp++;
+
+ if (endp - buf != count)
+ return -EINVAL;
+
+ if (ovl->enabled != enabled) {
+ ovl->enabled = enabled;
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
+ return count;
+}
+
+static ssize_t
+overlay_mode_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->mode);
+}
+
+static ssize_t
+overlay_mode_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ unsigned int mode;
+ char *endp;
+
+ mode = simple_strtoul(buf, &endp, 10);
+ if (isspace(*endp))
+ endp++;
+
+ if (endp - buf != count)
+ return -EINVAL;
+
+ if (mode != LCDC_OVERLAY_BLEND && mode != LCDC_OVERLAY_ROP3)
+ return -EINVAL;
+
+ if (ovl->mode != mode) {
+ ovl->mode = mode;
+
+ if (ovl->enabled)
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
+ return count;
+}
+
+static ssize_t
+overlay_position_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return scnprintf(buf, PAGE_SIZE, "%d,%d\n", ovl->pos_x, ovl->pos_y);
+}
+
+static ssize_t
+overlay_position_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ char *endp;
+ int pos_x;
+ int pos_y;
+
+ pos_x = simple_strtol(buf, &endp, 10);
+ if (*endp != ',')
+ return -EINVAL;
+
+ pos_y = simple_strtol(endp + 1, &endp, 10);
+ if (isspace(*endp))
+ endp++;
+
+ if (endp - buf != count)
+ return -EINVAL;
+
+ if (ovl->pos_x != pos_x || ovl->pos_y != pos_y) {
+ ovl->pos_x = pos_x;
+ ovl->pos_y = pos_y;
+
+ if (ovl->enabled)
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
+ return count;
+}
+
+static ssize_t
+overlay_rop3_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->rop3);
+}
+
+static ssize_t
+overlay_rop3_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(dev);
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ unsigned int rop3;
+ char *endp;
+
+ rop3 = !!simple_strtoul(buf, &endp, 10);
+ if (isspace(*endp))
+ endp++;
+
+ if (endp - buf != count)
+ return -EINVAL;
+
+ if (rop3 > 255)
+ return -EINVAL;
+
+ if (ovl->rop3 != rop3) {
+ ovl->rop3 = rop3;
+
+ if (ovl->mode = LCDC_OVERLAY_ROP3 && ovl->enabled)
+ sh_mobile_lcdc_overlay_setup(ovl);
+ }
+
+ return count;
+}
+
+static const struct device_attribute overlay_sysfs_attrs[] = {
+ __ATTR(ovl_alpha, S_IRUGO|S_IWUSR,
+ overlay_alpha_show, overlay_alpha_store),
+ __ATTR(ovl_enabled, S_IRUGO|S_IWUSR,
+ overlay_enabled_show, overlay_enabled_store),
+ __ATTR(ovl_mode, S_IRUGO|S_IWUSR,
+ overlay_mode_show, overlay_mode_store),
+ __ATTR(ovl_position, S_IRUGO|S_IWUSR,
+ overlay_position_show, overlay_position_store),
+ __ATTR(ovl_rop3, S_IRUGO|S_IWUSR,
+ overlay_rop3_show, overlay_rop3_store),
+};
+
+static const struct fb_fix_screeninfo sh_mobile_lcdc_overlay_fix = {
+ .id = "SH Mobile LCDC",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .accel = FB_ACCEL_NONE,
+ .xpanstep = 0,
+ .ypanstep = 1,
+ .ywrapstep = 0,
+ .capabilities = FB_CAP_FOURCC,
+};
+
+static int sh_mobile_lcdc_overlay_pan(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+ unsigned long base_addr_y;
+ unsigned long base_addr_c;
+ unsigned long pan_offset;
+ unsigned long c_offset;
+
+ if (!ovl->format->yuv)
+ pan_offset = var->yoffset * ovl->pitch
+ + var->xoffset * (ovl->format->bpp / 8);
+ else
+ pan_offset = var->yoffset * ovl->pitch + var->xoffset;
+
+ if (pan_offset = ovl->pan_offset)
+ return 0; /* No change, do nothing */
+
+ /* Set the source address for the next refresh */
+ base_addr_y = ovl->dma_handle + pan_offset;
+
+ ovl->base_addr_y = base_addr_y;
+ ovl->base_addr_c = base_addr_y;
+
+ if (ovl->format->yuv) {
+ /* Set Y offset */
+ c_offset = var->yoffset * ovl->pitch
+ * (ovl->format->bpp - 8) / 8;
+ base_addr_c = ovl->dma_handle
+ + ovl->xres * ovl->yres_virtual
+ + c_offset;
+ /* Set X offset */
+ if (ovl->format->fourcc = V4L2_PIX_FMT_NV24)
+ base_addr_c += 2 * var->xoffset;
+ else
+ base_addr_c += var->xoffset;
+
+ ovl->base_addr_c = base_addr_c;
+ }
+
+ lcdc_write_overlay(ovl, LDBnBSAYR(ovl->index), ovl->base_addr_y);
+ lcdc_write_overlay(ovl, LDBnBSACR(ovl->index), ovl->base_addr_c);
+
+ ovl->pan_offset = pan_offset;
+
+ return 0;
+}
+
+static int sh_mobile_lcdc_overlay_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:
+ return sh_mobile_lcdc_wait_for_vsync(ovl->channel);
+
+ default:
+ return -ENOIOCTLCMD;
+ }
+}
+
+static int sh_mobile_lcdc_overlay_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return __sh_mobile_lcdc_check_var(var, info);
+}
+
+static int sh_mobile_lcdc_overlay_set_par(struct fb_info *info)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ ovl->format + sh_mobile_format_info(sh_mobile_format_fourcc(&info->var));
+
+ ovl->xres = info->var.xres;
+ ovl->xres_virtual = info->var.xres_virtual;
+ ovl->yres = info->var.yres;
+ ovl->yres_virtual = info->var.yres_virtual;
+
+ if (ovl->format->yuv)
+ ovl->pitch = info->var.xres;
+ else
+ ovl->pitch = info->var.xres * ovl->format->bpp / 8;
+
+ sh_mobile_lcdc_overlay_setup(ovl);
+
+ info->fix.line_length = ovl->pitch;
+
+ if (sh_mobile_format_is_fourcc(&info->var)) {
+ info->fix.type = FB_TYPE_FOURCC;
+ info->fix.visual = FB_VISUAL_FOURCC;
+ } else {
+ info->fix.type = FB_TYPE_PACKED_PIXELS;
+ info->fix.visual = FB_VISUAL_TRUECOLOR;
+ }
+
+ return 0;
+}
+
+/* Overlay blanking. Disable the overlay when blanked. */
+static int sh_mobile_lcdc_overlay_blank(int blank, struct fb_info *info)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ ovl->enabled = !blank;
+
+ return 0;
+}
+
+static struct fb_ops sh_mobile_lcdc_overlay_ops = {
+ .owner = THIS_MODULE,
+ .fb_read = fb_sys_read,
+ .fb_write = fb_sys_write,
+ .fb_fillrect = sys_fillrect,
+ .fb_copyarea = sys_copyarea,
+ .fb_imageblit = sys_imageblit,
+ .fb_blank = sh_mobile_lcdc_overlay_blank,
+ .fb_pan_display = sh_mobile_lcdc_overlay_pan,
+ .fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
+ .fb_check_var = sh_mobile_lcdc_overlay_check_var,
+ .fb_set_par = sh_mobile_lcdc_overlay_set_par,
+};
+
+static void
+sh_mobile_lcdc_overlay_fb_unregister(struct sh_mobile_lcdc_overlay *ovl)
+{
+ struct fb_info *info = ovl->info;
+
+ if (info = NULL || info->dev = NULL)
+ return;
+
+ unregister_framebuffer(ovl->info);
+}
+
+static int __devinit
+sh_mobile_lcdc_overlay_fb_register(struct sh_mobile_lcdc_overlay *ovl)
+{
+ struct sh_mobile_lcdc_priv *lcdc = ovl->channel->lcdc;
+ struct fb_info *info = ovl->info;
+ unsigned int i;
+ int ret;
+
+ if (info = NULL)
+ return 0;
+
+ ret = register_framebuffer(info);
+ if (ret < 0)
+ return ret;
+
+ dev_info(lcdc->dev, "registered %s/overlay %u as %dx%d %dbpp.\n",
+ dev_name(lcdc->dev), ovl->index, info->var.xres,
+ info->var.yres, info->var.bits_per_pixel);
+
+ for (i = 0; i < ARRAY_SIZE(overlay_sysfs_attrs); ++i) {
+ ret = device_create_file(info->dev, &overlay_sysfs_attrs[i]);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void
+sh_mobile_lcdc_overlay_fb_cleanup(struct sh_mobile_lcdc_overlay *ovl)
+{
+ struct fb_info *info = ovl->info;
+
+ if (info = NULL || info->device = NULL)
+ return;
+
+ framebuffer_release(info);
+}
+
+static int __devinit
+sh_mobile_lcdc_overlay_fb_init(struct sh_mobile_lcdc_overlay *ovl)
+{
+ struct sh_mobile_lcdc_priv *priv = ovl->channel->lcdc;
+ struct fb_var_screeninfo *var;
+ struct fb_info *info;
+
+ /* Allocate and initialize the frame buffer device. */
+ info = framebuffer_alloc(0, priv->dev);
+ if (info = NULL) {
+ dev_err(priv->dev, "unable to allocate fb_info\n");
+ return -ENOMEM;
+ }
+
+ ovl->info = info;
+
+ info->flags = FBINFO_FLAG_DEFAULT;
+ info->fbops = &sh_mobile_lcdc_overlay_ops;
+ info->device = priv->dev;
+ info->screen_base = ovl->fb_mem;
+ info->par = ovl;
+
+ /* Initialize fixed screen information. Restrict pan to 2 lines steps
+ * for NV12 and NV21.
+ */
+ info->fix = sh_mobile_lcdc_overlay_fix;
+ snprintf(info->fix.id, sizeof(info->fix.id),
+ "SH Mobile LCDC Overlay %u", ovl->index);
+ info->fix.smem_start = ovl->dma_handle;
+ info->fix.smem_len = ovl->fb_size;
+ info->fix.line_length = ovl->pitch;
+
+ if (ovl->format->yuv)
+ info->fix.visual = FB_VISUAL_FOURCC;
+ else
+ info->fix.visual = FB_VISUAL_TRUECOLOR;
+
+ if (ovl->format->fourcc = V4L2_PIX_FMT_NV12 ||
+ ovl->format->fourcc = V4L2_PIX_FMT_NV21)
+ info->fix.ypanstep = 2;
+
+ /* Initialize variable screen information. */
+ var = &info->var;
+ memset(var, 0, sizeof(*var));
+ var->xres = ovl->xres;
+ var->yres = ovl->yres;
+ var->xres_virtual = ovl->xres_virtual;
+ var->yres_virtual = ovl->yres_virtual;
+ var->activate = FB_ACTIVATE_NOW;
+
+ /* Use the legacy API by default for RGB formats, and the FOURCC API
+ * for YUV formats.
+ */
+ if (!ovl->format->yuv)
+ var->bits_per_pixel = ovl->format->bpp;
+ else
+ var->grayscale = ovl->format->fourcc;
+
+ return sh_mobile_lcdc_overlay_check_var(var, info);
+}
+
+/* -----------------------------------------------------------------------------
+ * Frame buffer operations - main frame buffer
*/
static int sh_mobile_lcdc_setcolreg(u_int regno,
@@ -1201,9 +1998,7 @@ static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
unsigned int best_xres = 0;
unsigned int best_yres = 0;
unsigned int i;
-
- if (var->xres > MAX_XRES || var->yres > MAX_YRES)
- return -EINVAL;
+ int ret;
/* If board code provides us with a list of available modes, make sure
* we use one of them. Find the mode closest to the requested one. The
@@ -1238,73 +2033,9 @@ static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
var->yres = best_yres;
}
- /* Make sure the virtual resolution is at least as big as the visible
- * resolution.
- */
- if (var->xres_virtual < var->xres)
- var->xres_virtual = var->xres;
- if (var->yres_virtual < var->yres)
- var->yres_virtual = var->yres;
-
- if (sh_mobile_format_is_fourcc(var)) {
- const struct sh_mobile_lcdc_format_info *format;
-
- format = sh_mobile_format_info(var->grayscale);
- if (format = NULL)
- return -EINVAL;
- var->bits_per_pixel = format->bpp;
-
- /* Default to RGB and JPEG color-spaces for RGB and YUV formats
- * respectively.
- */
- if (!format->yuv)
- var->colorspace = V4L2_COLORSPACE_SRGB;
- else if (var->colorspace != V4L2_COLORSPACE_REC709)
- var->colorspace = V4L2_COLORSPACE_JPEG;
- } else {
- if (var->bits_per_pixel <= 16) { /* RGB 565 */
- var->bits_per_pixel = 16;
- var->red.offset = 11;
- var->red.length = 5;
- var->green.offset = 5;
- var->green.length = 6;
- var->blue.offset = 0;
- var->blue.length = 5;
- var->transp.offset = 0;
- var->transp.length = 0;
- } else if (var->bits_per_pixel <= 24) { /* RGB 888 */
- var->bits_per_pixel = 24;
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 0;
- var->transp.length = 0;
- } else if (var->bits_per_pixel <= 32) { /* RGBA 888 */
- var->bits_per_pixel = 32;
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 24;
- var->transp.length = 8;
- } else
- return -EINVAL;
-
- var->red.msb_right = 0;
- var->green.msb_right = 0;
- var->blue.msb_right = 0;
- var->transp.msb_right = 0;
- }
-
- /* Make sure we don't exceed our allocated memory. */
- if (var->xres_virtual * var->yres_virtual * var->bits_per_pixel / 8 >
- info->fix.smem_len)
- return -EINVAL;
+ ret = __sh_mobile_lcdc_check_var(var, info);
+ if (ret < 0)
+ return ret;
/* only accept the forced_fourcc for dual channel configurations */
if (p->forced_fourcc &&
@@ -1713,15 +2444,27 @@ static const struct fb_videomode default_720p __devinitconst = {
static int sh_mobile_lcdc_remove(struct platform_device *pdev)
{
struct sh_mobile_lcdc_priv *priv = platform_get_drvdata(pdev);
- int i;
+ unsigned int i;
fb_unregister_client(&priv->notifier);
+ for (i = 0; i < ARRAY_SIZE(priv->overlays); i++)
+ sh_mobile_lcdc_overlay_fb_unregister(&priv->overlays[i]);
for (i = 0; i < ARRAY_SIZE(priv->ch); i++)
sh_mobile_lcdc_channel_fb_unregister(&priv->ch[i]);
sh_mobile_lcdc_stop(priv);
+ for (i = 0; i < ARRAY_SIZE(priv->overlays); i++) {
+ struct sh_mobile_lcdc_overlay *ovl = &priv->overlays[i];
+
+ sh_mobile_lcdc_overlay_fb_cleanup(ovl);
+
+ if (ovl->fb_mem)
+ dma_free_coherent(&pdev->dev, ovl->fb_size,
+ ovl->fb_mem, ovl->dma_handle);
+ }
+
for (i = 0; i < ARRAY_SIZE(priv->ch); i++) {
struct sh_mobile_lcdc_chan *ch = &priv->ch[i];
@@ -1797,6 +2540,61 @@ static int __devinit sh_mobile_lcdc_check_interface(struct sh_mobile_lcdc_chan *
}
static int __devinit
+sh_mobile_lcdc_overlay_init(struct sh_mobile_lcdc_priv *priv,
+ struct sh_mobile_lcdc_overlay *ovl)
+{
+ const struct sh_mobile_lcdc_format_info *format;
+ int ret;
+
+ if (ovl->cfg->fourcc = 0)
+ return 0;
+
+ /* Validate the format. */
+ format = sh_mobile_format_info(ovl->cfg->fourcc);
+ if (format = NULL) {
+ dev_err(priv->dev, "Invalid FOURCC %08x\n", ovl->cfg->fourcc);
+ return -EINVAL;
+ }
+
+ ovl->enabled = false;
+ ovl->mode = LCDC_OVERLAY_BLEND;
+ ovl->alpha = 255;
+ ovl->rop3 = 0;
+ ovl->pos_x = 0;
+ ovl->pos_y = 0;
+
+ /* The default Y virtual resolution is twice the panel size to allow for
+ * double-buffering.
+ */
+ ovl->format = format;
+ ovl->xres = ovl->cfg->max_xres;
+ ovl->xres_virtual = ovl->xres;
+ ovl->yres = ovl->cfg->max_yres;
+ ovl->yres_virtual = ovl->yres * 2;
+
+ if (!format->yuv)
+ ovl->pitch = ovl->xres * format->bpp / 8;
+ else
+ ovl->pitch = ovl->xres;
+
+ /* Allocate frame buffer memory. */
+ ovl->fb_size = ovl->cfg->max_xres * ovl->cfg->max_yres
+ * format->bpp / 8 * 2;
+ ovl->fb_mem = dma_alloc_coherent(priv->dev, ovl->fb_size,
+ &ovl->dma_handle, GFP_KERNEL);
+ if (!ovl->fb_mem) {
+ dev_err(priv->dev, "unable to allocate buffer\n");
+ return -ENOMEM;
+ }
+
+ ret = sh_mobile_lcdc_overlay_fb_init(ovl);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int __devinit
sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_priv *priv,
struct sh_mobile_lcdc_chan *ch)
{
@@ -2004,6 +2802,17 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
goto err1;
}
+ for (i = 0; i < ARRAY_SIZE(pdata->overlays); i++) {
+ struct sh_mobile_lcdc_overlay *ovl = &priv->overlays[i];
+
+ ovl->cfg = &pdata->overlays[i];
+ ovl->channel = &priv->ch[0];
+
+ error = sh_mobile_lcdc_overlay_init(priv, ovl);
+ if (error)
+ goto err1;
+ }
+
error = sh_mobile_lcdc_start(priv);
if (error) {
dev_err(&pdev->dev, "unable to start hardware\n");
@@ -2018,6 +2827,14 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
goto err1;
}
+ for (i = 0; i < ARRAY_SIZE(pdata->overlays); i++) {
+ struct sh_mobile_lcdc_overlay *ovl = &priv->overlays[i];
+
+ error = sh_mobile_lcdc_overlay_fb_register(ovl);
+ if (error)
+ goto err1;
+ }
+
/* Failure ignored */
priv->notifier.notifier_call = sh_mobile_lcdc_notify;
fb_register_client(&priv->notifier);
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index 7571b27..ff43ffc 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -166,6 +166,12 @@ struct sh_mobile_lcdc_bl_info {
int (*get_brightness)(void);
};
+struct sh_mobile_lcdc_overlay_cfg {
+ int fourcc;
+ unsigned int max_xres;
+ unsigned int max_yres;
+};
+
struct sh_mobile_lcdc_chan_cfg {
int chan;
int fourcc;
@@ -186,6 +192,7 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_info {
int clock_source;
struct sh_mobile_lcdc_chan_cfg ch[2];
+ struct sh_mobile_lcdc_overlay_cfg overlays[4];
struct sh_mobile_meram_info *meram_dev;
};
--
1.7.3.4
^ permalink raw reply related
* [GIT PULL] fbdev updates for 3.5
From: Florian Tobias Schandinat @ 2012-06-01 0:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org
Hi Linus,
please pull the changes below.
Thanks,
Florian Tobias Schandinat
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://github.com/schandinat/linux-2.6.git fbdev-updates-for-3.5
for you to fetch changes up to c895305e806b4346006d3cfba2b432d52268ecd3:
video: bfin_adv7393fb: Fix cleanup code (2012-05-29 13:16:45 +0000)
----------------------------------------------------------------
fbdev updates for 3.5
It includes:
- driver for AUO-K1900 and AUO-K1901 epaper controller
- large updates for OMAP (e.g. decouple HDMI audio and video)
- some updates for Exynos and SH Mobile
- various other small fixes and cleanups
----------------------------------------------------------------
Alexander Guy (1):
skeletonfb: fixed module exit function typo.
Archit Taneja (19):
OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size
OMAPDSS: DISPC: Use a common function to set manager timings
OMAPDSS: DISPC: Clean up manager timing/size functions
OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
OMAPDSS: HDMI: define and dump CORE registers in correct order
OMAPDSS: Fix DSI_FCLK clock source selection
OMAPDSS: DISPC: Remove Fake VSYNC support
OMAPDSS: APPLY: Add manager timings as extra_info in private data
OMAPDSS: Apply manager timings instead of direct DISPC writes
OMAPDSS: MANAGER: Create a function to check manager timings
OMAPDSS: APPLY: Don't check manager settings if it is disabled
OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
OMAPDSS: Apply VENC timings even if panel is disabled
Axel Castaneda Gonzalez (1):
OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop
Axel Lin (1):
video: pxa3xx-gcu: Simplify the logic to exit while loop in pxa3xx_gcu_wait_idle
Chandrabhanu Mahapatra (5):
OMAPDSS: DISPC: Enable predecimation
OMAPDSS: DISPC: Handle synclost errors in OMAP3
OMAPDSS: DISPC: Correct DISPC functional clock usage
OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
OMAPDSS: DISPC: Support rotation through TILER
Dan Carpenter (1):
fb: handle NULL pointers in framebuffer release
David Brown (1):
video: msm: Fix section mismatches in mddi.c
Donghwa Lee (3):
video: EXYNOS: enable interrupt again after sw reset
video: EXYNOS: changes mipi dsi regulator name from vdd10 to vdd11
video: exynos mipi dsi: support reverse panel type
Emil Goode (1):
video: bfin_adv7393fb: Fix cleanup code
Florian Tobias Schandinat (2):
Merge branch 'fixes' of git://linuxtv.org/pinchartl/fbdev into fbdev-next
Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-next
Grazvydas Ignotas (5):
OMAPDSS: OMAPFB: check for matching memory size early
OMAPDSS: provide default get_timings function for panels
OMAPDSS: TPO-TD03MTEA1: add set/check timing functions
OMAPDSS: VENC: allow switching venc output type at runtime
OMAPDSS: OMAPFB: always allow to configure overlay
H Hartley Sweeten (4):
video: smscufx.c: local functions should not be exposed globally
video: fb_defio.c: local functions should not be exposed globally
video: mb862xx-i2c: local functions should not be exposed globally
video: mb862xxfbdrv.c: local functions should not be exposed globally
Heiko Stübner (4):
fb_defio: add first_io callback
video: auo_k190x: add code shared by controller drivers
video: auo_k190x: add driver for AUO-K1900 variant
video: auo_k190x: add driver for AUO-K1901 variant
Jan Weitzel (1):
ARM: OMAP2+ Add Primview displays to panel-generic
Jingoo Han (10):
video: s3c-fb: add runtime_get/put to suspend/resume
video: exynos_dp: check DP PLL Lock status
video: exynos_dp: replace char pointer with char array for adjust_request variable
video: exynos_dp: add analog and pll control setting
video: exynos_dp: fix max loop count in EQ sequence of link training
video: exynos_dp: remove unnecessary header includes
video: s3c-fb: use pr_debug instead of printk
video: exynos_dp: use devm_ functions
video: exynos_dp: move sw reset prioir to enabling sw defined function
video: exynos_dp: reduce delay time when configuring video setting
Julia Lawall (3):
drivers/video/ep93xx-fb.c: clean up error-handling code
drivers/video/mbx/mbxfb.c: correct ioremap_nocache test
drivers/video/intelfb/intelfbdrv.c: add missing agp_backend_release
Kuninori Morimoto (4):
fbdev: sh_mobile_hdmi: add hdmi_bit_set() function
fbdev: sh_mobile_hdmi: add interrupt output option
fbdev: sh_mobile_hdmi: 32bit register access support
fbdev: sh_mobile_hdmi: add HDMI Control Register support
Laurent Pinchart (1):
fb: exynos: Fix MIPI/DSI front/back porch settings
Marek Vasut (1):
i.MX28: Shut down the LCD controller to avoid BootROM sampling bug
Mark Brown (5):
OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
OMAPDSS: VENC: Check for errors from regulator_enable()
OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
video: s3c-fb: s3c_fb_missing_pixclock() can't be __devinit
Peter Huewe (3):
video/sis: Remove unused structs SiS_SDRDRAM_TYPE/SiS_DDRDRAM_TYPE/SiS_DRAMType
video/sis: Annotate SiS_DRAMType as __devinitconst
video/via: Convert to kstrtou8_from_user
Peter Meerwald (1):
OMAPFB: remove unused FB_OMAP_BOOTLOADER_INIT config option
Ricardo Neri (15):
OMAPDSS: Provide an interface for audio support
OMAPDSS: HDMI: Split audio_enable into audio_enable/disable
OMAPDSS: HDMI: Split video_enable into video_enable/disable
OMAPDSS: HDMI: Remove ASoC codec
OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
OMAPDSS: HDMI: Decouple HDMI audio from ASoC
OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
OMAPDSS: HDMI: Relocate N/CTS calculation
OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
OMAPDSS: HDMI: Add an audio configuration function
OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
OMAPDSS: HDMI: Implement DSS driver interface for audio
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
Russ Dill (1):
OMAPDSS: TFP410: use gpio_set_value_cansleep
Steven J. Hill (1):
cobalt_lcdfb: LCD panel framebuffer support for SEAD-3 platform.
Sylwester Nawrocki (3):
video: exynos mipi dsi: Do not use deprecated suspend/resume callbacks
video: exynos mipi dsi: Avoid races in probe()
video: exynos mipi dsi: Properly interpret the interrupt source flags
Thomas Abraham (4):
video: s3c-fb: move video interface timing out of window setup data
video: s3c-fb: remove 'default_win' element from platform data
ARM: s3c64xx: Decouple lcd type from display controller window data
ARM: Samsung: Rework platform data of s3c-fb driver
Thomas Weber (2):
OMAPDSS: Add Mitsubishi AA084SB01 display support
OMAPDSS: Add EDT ET0500G0DH6 display support
Timur Tabi (1):
drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
Tomi Valkeinen (38):
OMAPDSS: add set_min_bus_tput pointer to omapdss's platform data
OMAPDSS: Ensure OPP100 when DSS is operational
OMAPDSS: DSI: remove option to use pck for DSI PLL clkin
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
Merge branch 'archit/set-timing-work'
Merge branch 'for-l-o-3.5'
OMAPFB: fix parsing of vram parameter
OMAPDSS: TFP410: pdata rewrite
OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id
OMAPDSS: clean up the omapdss platform data mess
OMAPDSS: remove return from platform_driver_unreg
OMAPDSS: use platform_driver_probe for core/dispc/dss
OMAPDSS: create custom pdevs for DSS omap_devices
OMAPDSS: create DPI & SDI devices
OMAPDSS: create DPI & SDI drivers
OMAPDSS: remove uses of dss_runtime_get/put
OMAPDSS: handle output-driver reg/unreg more dynamically
OMAPDSS: move the creation of debugfs files
OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
OMAPDSS: add __init & __exit
OMAPFB: add __init & __exit
OMAPDSS: change default_device handling
OMAPDSS: interface drivers register their panel devices
OMAPDSS: init omap_dss_devices internally
OMAPDSS: DSI: improve DSI module id handling
OMAPDSS: separate pdata based initialization
Merge branch 'dss-devtree-cleanup'
Merge branch 'omapdss-hdmi-audio'
OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
OMAPDSS: remove compiler warnings when CONFIG_BUG=n
OMAPFB: remove compiler warnings when CONFIG_BUG=n
OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
Documentation/arm/OMAP/DSS | 46 +
arch/arm/mach-exynos/mach-nuri.c | 26 +-
arch/arm/mach-exynos/mach-origen.c | 24 +-
arch/arm/mach-exynos/mach-smdkv310.c | 28 +-
arch/arm/mach-exynos/mach-universal_c210.c | 26 +-
arch/arm/mach-omap2/board-3430sdp.c | 38 +-
arch/arm/mach-omap2/board-4430sdp.c | 37 +-
arch/arm/mach-omap2/board-am3517evm.c | 25 +-
arch/arm/mach-omap2/board-cm-t35.c | 30 +-
arch/arm/mach-omap2/board-devkit8000.c | 30 +-
arch/arm/mach-omap2/board-igep0020.c | 32 +-
arch/arm/mach-omap2/board-omap3beagle.c | 37 +-
arch/arm/mach-omap2/board-omap3evm.c | 29 +-
arch/arm/mach-omap2/board-omap3stalker.c | 29 +-
arch/arm/mach-omap2/board-omap4panda.c | 39 +-
arch/arm/mach-omap2/board-overo.c | 25 +-
arch/arm/mach-omap2/display.c | 196 ++++-
arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 +-
arch/arm/mach-s3c64xx/mach-anw6410.c | 25 +-
arch/arm/mach-s3c64xx/mach-crag6410.c | 25 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 24 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 92 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 90 +-
arch/arm/mach-s3c64xx/mach-smartq5.c | 26 +-
arch/arm/mach-s3c64xx/mach-smartq7.c | 26 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 +-
arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 +-
arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 +-
arch/arm/mach-s5pc100/mach-smdkc100.c | 27 +-
arch/arm/mach-s5pv210/mach-aquila.c | 36 +-
arch/arm/mach-s5pv210/mach-goni.c | 26 +-
arch/arm/mach-s5pv210/mach-smdkv210.c | 24 +-
arch/arm/plat-samsung/include/plat/fb.h | 11 +-
drivers/video/Kconfig | 35 +-
drivers/video/Makefile | 3 +
drivers/video/auo_k1900fb.c | 198 ++++
drivers/video/auo_k1901fb.c | 251 +++++
drivers/video/auo_k190x.c | 1046 ++++++++++++++++++++
drivers/video/auo_k190x.h | 129 +++
drivers/video/bfin_adv7393fb.c | 43 +-
drivers/video/cobalt_lcdfb.c | 45 +-
drivers/video/ep93xx-fb.c | 32 +-
drivers/video/exynos/exynos_dp_core.c | 69 +-
drivers/video/exynos/exynos_dp_core.h | 3 +-
drivers/video/exynos/exynos_dp_reg.c | 45 +-
drivers/video/exynos/exynos_dp_reg.h | 29 +
drivers/video/exynos/exynos_mipi_dsi.c | 49 +-
drivers/video/exynos/exynos_mipi_dsi_common.c | 36 +-
drivers/video/exynos/s6e8ax0.c | 15 +-
drivers/video/fb_defio.c | 6 +-
drivers/video/fbsysfs.c | 2 +
drivers/video/fsl-diu-fb.c | 1 -
drivers/video/intelfb/intelfbdrv.c | 2 +
drivers/video/mb862xx/mb862xx-i2c.c | 2 +-
drivers/video/mb862xx/mb862xxfbdrv.c | 2 +-
drivers/video/mbx/mbxfb.c | 2 +-
drivers/video/mxsfb.c | 13 +
drivers/video/omap/Kconfig | 8 -
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-acx565akm.c | 7 -
drivers/video/omap2/displays/panel-generic-dpi.c | 107 ++-
drivers/video/omap2/displays/panel-n8x0.c | 8 -
drivers/video/omap2/displays/panel-taal.c | 108 +--
.../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 186 ++--
.../video/omap2/displays/panel-tpo-td043mtea1.c | 22 +-
drivers/video/omap2/dss/Kconfig | 13 +-
drivers/video/omap2/dss/apply.c | 134 ++-
drivers/video/omap2/dss/core.c | 255 +++--
drivers/video/omap2/dss/dispc.c | 747 ++++++++++----
drivers/video/omap2/dss/dispc.h | 72 ++
drivers/video/omap2/dss/display.c | 49 +-
drivers/video/omap2/dss/dpi.c | 75 +-
drivers/video/omap2/dss/dsi.c | 537 +++++++----
drivers/video/omap2/dss/dss.c | 65 +-
drivers/video/omap2/dss/dss.h | 151 +--
drivers/video/omap2/dss/dss_features.c | 30 +-
drivers/video/omap2/dss/dss_features.h | 5 +
drivers/video/omap2/dss/hdmi.c | 443 ++++-----
drivers/video/omap2/dss/hdmi_panel.c | 236 ++++-
drivers/video/omap2/dss/manager.c | 19 +-
drivers/video/omap2/dss/overlay.c | 16 +-
drivers/video/omap2/dss/rfbi.c | 84 ++-
drivers/video/omap2/dss/sdi.c | 63 +-
drivers/video/omap2/dss/ti_hdmi.h | 32 +-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 480 ++++++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 161 +---
drivers/video/omap2/dss/venc.c | 133 ++-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 17 +-
drivers/video/omap2/omapfb/omapfb-main.c | 12 +-
drivers/video/omap2/omapfb/omapfb.h | 1 +
drivers/video/omap2/vrfb.c | 4 +-
drivers/video/pxa3xx-gcu.c | 5 +-
drivers/video/s3c-fb.c | 148 ++--
drivers/video/sh_mobile_hdmi.c | 219 ++++-
drivers/video/sis/init.h | 45 -
drivers/video/sis/sis_main.c | 41 +-
drivers/video/skeletonfb.c | 2 +-
drivers/video/smscufx.c | 4 +-
drivers/video/udlfb.c | 2 +-
drivers/video/via/viafbdev.c | 34 +-
include/linux/fb.h | 1 +
include/video/auo_k190xfb.h | 106 ++
include/video/exynos_dp.h | 2 +-
include/video/exynos_mipi_dsim.h | 1 +
include/video/omap-panel-nokia-dsi.h | 3 +
.../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 +-
include/video/omapdss.h | 75 ++-
include/video/sh_mobile_hdmi.h | 12 +-
109 files changed, 5705 insertions(+), 2590 deletions(-)
create mode 100644 drivers/video/auo_k1900fb.c
create mode 100644 drivers/video/auo_k1901fb.c
create mode 100644 drivers/video/auo_k190x.c
create mode 100644 drivers/video/auo_k190x.h
rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (56%)
create mode 100644 include/video/auo_k190xfb.h
rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
^ permalink raw reply
* RE: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
From: Nellutla, Aditya @ 2012-06-04 6:02 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1337753191-14802-1-git-send-email-aditya.n@ti.com>
All,
Did you get chance to review this patch? Request to give your feedback as early as possible.
Regards,
Aditya
-----Original Message-----
From: Nellutla, Aditya
Sent: Wednesday, May 23, 2012 11:37 AM
To: linux-fbdev@vger.kernel.org
Cc: Nellutla, Aditya
Subject: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
In the real time use-case when SGX is used for rendering to FB buffers it has been
observed that, the available memory from framebuffer driver is not sufficient for
SGX under certain cases (like 16-bit WVGA resolution). SGX requires 2 swap buffers
with each of the buffers aligned to lcm(line_length, PAGE_SIZE).
Inorder to satisfy this requirement, we have two options,
- Increase number of FB buffers (LCD_NUM_BUFFERS) to 3. This is not
recommended as we end up wasting huge memory in most of the cases.
- Align FB buffers to lcm(line_length, PAGE_SIZE).This ensures framebuffer
size is increased to satisfy SGX requirements keeping alignment intact.
This patch makes sure that FB allocates buffers aligned to above formula.
Signed-off-by: Aditya Nellutla <aditya.n@ti.com>
---
drivers/video/da8xx-fb.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 47118c7..2f24c19 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -31,6 +31,7 @@
#include <linux/cpufreq.h>
#include <linux/console.h>
#include <linux/slab.h>
+#include <linux/lcm.h>
#include <video/da8xx-fb.h>
#include <asm/div64.h>
@@ -1114,6 +1115,7 @@ static int __devinit fb_probe(struct platform_device *device)
struct da8xx_fb_par *par;
resource_size_t len;
int ret, i;
+ unsigned long ulcm;
if (fb_pdata = NULL) {
dev_err(&device->dev, "Can not get platform data\n");
@@ -1209,7 +1211,8 @@ static int __devinit fb_probe(struct platform_device *device)
/* allocate frame buffer */
par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
- par->vram_size = PAGE_ALIGN(par->vram_size/8);
+ ulcm = lcm((lcdc_info->width * lcd_cfg->bpp)/8, PAGE_SIZE);
+ par->vram_size = roundup(par->vram_size/8, ulcm);
par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
par->vram_virt = dma_alloc_coherent(NULL,
--
1.7.0.4
^ permalink raw reply related
* Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Witold Baryluk @ 2012-06-04 17:37 UTC (permalink / raw)
To: linux-fbdev
Hello,
When watching movie using mplayer -quiet -vo fbdev2 somefile.flv when
being on console, with 6 virtual terminals, and no other program using
fbdev, after pressing key Q (quit), kernel throws this in my face:
[ 3288.708198]
[ 3288.711153] ===========================
[ 3288.712015] [ INFO: possible circular locking dependency detected ]
[ 3288.712015] 3.4.0-t43-devel-smp-10118-g233e562-dirty #12 Tainted: G O
[ 3288.712015] -------------------------------------------------------
[ 3288.712015] mplayer/11769 is trying to acquire lock:
[ 3288.712015] (&fb_info->lock){+.+.+.}, at: [<c137789c>] fb_release+0x1c/0x60
[ 3288.712015]
[ 3288.712015] but task is already holding lock:
[ 3288.712015] (&mm->mmap_sem){++++++}, at: [<c1160a8f>] vm_munmap+0x2f/0x60
[ 3288.712015]
[ 3288.712015] which lock already depends on the new lock.
[ 3288.712015]
[ 3288.712015]
[ 3288.712015] the existing dependency chain (in reverse order) is:
[ 3288.712015]
[ 3288.712015] -> #2 (&mm->mmap_sem){++++++}:
[ 3288.712015] [<c10b9719>] lock_acquire+0x89/0x1b0
[ 3288.712015] [<c11580c7>] might_fault+0x87/0xb0
[ 3288.712015] [<f8e2c498>] drm_mode_getresources+0x188/0x5b0 [drm]
[ 3288.712015] [<f8e1e582>] drm_ioctl+0x482/0x590 [drm]
[ 3288.712015] [<c119ea2b>] do_vfs_ioctl+0x7b/0x5c0
[ 3288.712015] [<c119efa2>] sys_ioctl+0x32/0x60
[ 3288.712015] [<c17d5158>] sysenter_do_call+0x12/0x38
[ 3288.712015]
[ 3288.712015] -> #1 (&dev->mode_config.mutex){+.+.+.}:
[ 3288.712015] [<c10b9719>] lock_acquire+0x89/0x1b0
[ 3288.712015] [<c17c9a50>] mutex_lock_nested+0x70/0x300
[ 3288.712015] [<f8f2fd9c>] drm_fb_helper_set_par+0x3c/0xd0 [drm_kms_helper]
[ 3288.712015] [<c137757f>] fb_set_var+0x1ef/0x4c0
[ 3288.712015] [<c137866a>] do_fb_ioctl+0x34a/0x510
[ 3288.712015] [<c137887b>] fb_ioctl+0x4b/0x60
[ 3288.712015] [<c119ea2b>] do_vfs_ioctl+0x7b/0x5c0
[ 3288.712015] [<c119efa2>] sys_ioctl+0x32/0x60
[ 3288.712015] [<c17d5158>] sysenter_do_call+0x12/0x38
[ 3288.712015]
[ 3288.712015] -> #0 (&fb_info->lock){+.+.+.}:
[ 3288.712015] [<c10b8be5>] __lock_acquire+0x1265/0x1760
[ 3288.712015] [<c10b9719>] lock_acquire+0x89/0x1b0
[ 3288.712015] [<c17c9a50>] mutex_lock_nested+0x70/0x300
[ 3288.712015] [<c137789c>] fb_release+0x1c/0x60
[ 3288.712015] [<c118e5ec>] fput+0xfc/0x230
[ 3288.712015] [<c115efa3>] remove_vma+0x43/0x70
[ 3288.712015] [<c116097c>] do_munmap+0x23c/0x320
[ 3288.712015] [<c1160a9d>] vm_munmap+0x3d/0x60
[ 3288.712015] [<c116174d>] sys_munmap+0x1d/0x20
[ 3288.712015] [<c17d5158>] sysenter_do_call+0x12/0x38
[ 3288.712015]
[ 3288.712015] other info that might help us debug this:
[ 3288.712015]
[ 3288.712015] Chain exists of:
[ 3288.712015] &fb_info->lock --> &dev->mode_config.mutex --> &mm->mmap_sem
[ 3288.712015]
[ 3288.712015] Possible unsafe locking scenario:
[ 3288.712015]
[ 3288.712015] CPU0 CPU1
[ 3288.712015] ---- ----
[ 3288.712015] lock(&mm->mmap_sem);
[ 3288.712015] lock(&dev->mode_config.mutex);
[ 3288.712015] lock(&mm->mmap_sem);
[ 3288.712015] lock(&fb_info->lock);
[ 3288.712015]
[ 3288.712015] *** DEADLOCK ***
[ 3288.712015]
[ 3288.712015] 1 lock held by mplayer/11769:
[ 3288.712015] #0: (&mm->mmap_sem){++++++}, at: [<c1160a8f>] vm_munmap+0x2f/0x60
[ 3288.712015]
[ 3288.712015] stack backtrace:
[ 3288.712015] Pid: 11769, comm: mplayer Tainted: G O 3.4.0-t43-devel-smp-10118-g233e562-dirty #12
[ 3288.712015] Call Trace:
[ 3288.712015] [<c17c0c53>] print_circular_bug+0x1af/0x1b9
[ 3288.712015] [<c10b8be5>] __lock_acquire+0x1265/0x1760
[ 3288.712015] [<c10b604d>] ? mark_held_locks+0x8d/0xf0
[ 3288.712015] [<c113c895>] ? free_hot_cold_page+0xe5/0x180
[ 3288.712015] [<c116b512>] ? free_page_and_swap_cache+0x22/0x50
[ 3288.712015] [<c10b9719>] lock_acquire+0x89/0x1b0
[ 3288.712015] [<c137789c>] ? fb_release+0x1c/0x60
[ 3288.712015] [<c17c9a50>] mutex_lock_nested+0x70/0x300
[ 3288.712015] [<c137789c>] ? fb_release+0x1c/0x60
[ 3288.712015] [<c137789c>] ? fb_release+0x1c/0x60
[ 3288.712015] [<c137789c>] fb_release+0x1c/0x60
[ 3288.712015] [<c118e5ec>] fput+0xfc/0x230
[ 3288.712015] [<c115efa3>] remove_vma+0x43/0x70
[ 3288.712015] [<c116097c>] do_munmap+0x23c/0x320
[ 3288.712015] [<c1160a9d>] vm_munmap+0x3d/0x60
[ 3288.712015] [<c116174d>] sys_munmap+0x1d/0x20
[ 3288.712015] [<c17d5158>] sysenter_do_call+0x12/0x38
There was Xorg server running on tty7 (but nobody logged in), and it is
using open source radeon driver.
I sometimes use fbterm on console (to have full UTF-8, better speed, or
just larger fonts changed dynamically), and it works without any similar problems.
This possible deadlock message shows up only on first mplayer start/stop
cycle. Next ones doesn't trigger displaying this warning, but I belive
this is only due lockdep disabling checking, not solving any problem.
I reproduced it on two kernel builds already.
Machine is single CPU, but kernel is SMP. (Compiling and running kernel without SMP
support gives exactly same dmesg INFO about deadlock when quiting
mplayer).
$ egrep 'SMP|LOCK|RCU' /boot/config-`uname -r`
CONFIG_LOCKDEP_SUPPORT=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_X86_32_SMP=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
# RCU Subsystem
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT2
CONFIG_RCU_FANOUT_LEAF\x16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_UNINLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
CONFIG_SMP=y
# CONFIG_X86_BIGSMP is not set
# CONFIG_KVM_CLOCK is not set
CONFIG_PARAVIRT_SPINLOCKS=y
CONFIG_PARAVIRT_CLOCK=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_SPLIT_PTLOCK_CPUS™9999
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_WAKELOCKS=y
CONFIG_PM_WAKELOCKS_LIMIT\x100
CONFIG_PM_WAKELOCKS_GC=y
# CONFIG_X86_P4_CLOCKMOD is not set
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_DM_DEBUG_BLOCK_STACK_TRACING=y
CONFIG_TCM_IBLOCK=m
# CONFIG_TELCLOCK is not set
CONFIG_I8253_LOCK=y
CONFIG_FILE_LOCKING=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_PROVE_RCU=y
CONFIG_PROVE_RCU_REPEATEDLY=y
CONFIG_SPARSE_RCU_POINTER=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_RCU_TORTURE_TEST=m
CONFIG_RCU_CPU_STALL_TIMEOUT`
CONFIG_RCU_CPU_STALL_INFO=y
CONFIG_RCU_TRACE=y
CONFIG_DEBUG_BLOCK_EXT_DEVT=y
CONFIG_XOR_BLOCKS=m
Commit g233e562 (a kernel which I was running - Linus' main tree) is
after
commit 804ce9866d56130032c9c8afc90a1297b7deed56
Merge: f5e7e84 c895305
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Jun 1 16:57:51 2012 -0700
Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linu
Pull fbdev updates from Florian Tobias Schandinat:
- driver for AUO-K1900 and AUO-K1901 epaper controller
- large updates for OMAP (e.g. decouple HDMI audio and video)
- some updates for Exynos and SH Mobile
- various other small fixes and cleanups
* tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.
...
fb: handle NULL pointers in framebuffer release
...
....
commit cc4401142c1cbc63b01d6024cbc7a9f804cb3143
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon May 14 23:58:37 2012 +0300
fb: handle NULL pointers in framebuffer release
This function is called with a potential NULL pointer in
picolcd_init_framebuffer() and it causes a static checker warning. T
used to handle NULL pointers when the picolcd code was written, but a
couple months later we added the "info->apertures" dereference.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
so this may be a regression, should I try bissecting, or at least
reverting commit cc4401142c1c ?
Regards,
Witek
--
Witold Baryluk
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.5
From: Jean Pihet @ 2012-06-05 12:17 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev, Tony Lindgren
In-Reply-To: <1337681363.4125.10.camel@deskari>
Hi Tomi,
On Tue, May 22, 2012 at 12:09 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Florian,
>
> Here are the OMAP DSS changes for 3.5.
>
> I really tried this time to send the pull request early, but here I am
> again, sending it when the merge window has already opened... A few
> late-found bugs caused some unnecessary delays.
>
> I'm using github this time instead of gitorious, as gitorious seems to
> be down. This is my first pull request with a signed tag, I hope
> everything is correct.
>
> Note that there's a merge for small branch with omap board file changes
> (e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07) that is also pulled by Tony
> for the linux-omap tree. This is meant to help avoid conflicts in the
> board files.
>
> Tomi
>
>
> The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
>
> Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
>
> are available in the git repository at:
>
> git://github.com/tomba/linux.git tags/omapdss-for-3.5
>
> for you to fetch changes up to e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
>
> OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
>
> ----------------------------------------------------------------
> Omapdss driver changes for 3.5 merge window.
>
> Lots of normal development commits, but perhaps most notable changes are:
>
> * HDMI rework to properly decouple the HDMI audio part from the HDMI video part.
> * Restructure omapdss core driver so that it's possible to implement device
> tree support. This included changing how platform data is passed to the
> drivers, changing display device registration and improving the panel driver's
> ability to configure the underlying video output interface.
> * Basic support for DSI packet interleaving
>
I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
I have an issue with suspend/resume on OMAP3 Beagleboard, where the
system hangs at resume time.
Here below is a log with the option no_console_suspend set and a few
added messages in case of null pointer in _od_resume_noirq.
It looks like there is no omap_device associated to the "omapdss_dpi" pdev.
What do you think? How to fix this?
Sorry I know there have been some discussions on the lists but I am
not aware of all the details in the devices creation for DSS.
/ # echo mem > /sys/power/state
[ 23.262298] PM: Syncing filesystems ... done.
[ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don
e.
[ 23.502197] PM: suspend of devices complete after 163.766 msecs
[ 23.511932] PM: late suspend of devices complete after 3.418 msecs
[ 23.524444] PM: noirq suspend of devices complete after 5.860 msecs
[ 23.531249] Disabling non-boot CPUs ...
[ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1
[ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1
[ 24.489166] Could not enter target state in pm_suspend
[ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08
[ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00
[ 24.506805] *** _od_resume_noirq: od=NULL, pdev->name:omapdss_dpi
[ 24.513336] Unable to handle kernel NULL pointer dereference at virtual addre
ss 00000018
[ 24.521942] pgd = c62f0000
[ 24.524841] [00000018] *pgd†2c1831, *pte\0000000, *ppte\0000000
[ 24.531524] Internal error: Oops: 17 [#1] SMP ARM
[ 24.536529] Modules linked in:
[ 24.539764] CPU: 0 Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131)
[ 24.546844] PC is at _od_resume_noirq+0x1c/0xac
[ 24.551635] LR is at _od_resume_noirq+0x94/0xac
...
Regards,
Jean
> ----------------------------------------------------------------
> Archit Taneja (19):
> OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size
> OMAPDSS: DISPC: Use a common function to set manager timings
> OMAPDSS: DISPC: Clean up manager timing/size functions
> OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
> OMAPDSS: HDMI: define and dump CORE registers in correct order
> OMAPDSS: Fix DSI_FCLK clock source selection
> OMAPDSS: DISPC: Remove Fake VSYNC support
> OMAPDSS: APPLY: Add manager timings as extra_info in private data
> OMAPDSS: Apply manager timings instead of direct DISPC writes
> OMAPDSS: MANAGER: Create a function to check manager timings
> OMAPDSS: APPLY: Don't check manager settings if it is disabled
> OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
> OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
> OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
> OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
> OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
> OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
> OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
> OMAPDSS: Apply VENC timings even if panel is disabled
>
> Axel Castaneda Gonzalez (1):
> OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop
>
> Chandrabhanu Mahapatra (5):
> OMAPDSS: DISPC: Enable predecimation
> OMAPDSS: DISPC: Handle synclost errors in OMAP3
> OMAPDSS: DISPC: Correct DISPC functional clock usage
> OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
> OMAPDSS: DISPC: Support rotation through TILER
>
> Grazvydas Ignotas (5):
> OMAPDSS: OMAPFB: check for matching memory size early
> OMAPDSS: provide default get_timings function for panels
> OMAPDSS: TPO-TD03MTEA1: add set/check timing functions
> OMAPDSS: VENC: allow switching venc output type at runtime
> OMAPDSS: OMAPFB: always allow to configure overlay
>
> Jan Weitzel (1):
> ARM: OMAP2+ Add Primview displays to panel-generic
>
> Mark Brown (4):
> OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
> OMAPDSS: VENC: Check for errors from regulator_enable()
> OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
> OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
>
> Peter Meerwald (1):
> OMAPFB: remove unused FB_OMAP_BOOTLOADER_INIT config option
>
> Ricardo Neri (15):
> OMAPDSS: Provide an interface for audio support
> OMAPDSS: HDMI: Split audio_enable into audio_enable/disable
> OMAPDSS: HDMI: Split video_enable into video_enable/disable
> OMAPDSS: HDMI: Remove ASoC codec
> OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
> OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
> OMAPDSS: HDMI: Decouple HDMI audio from ASoC
> OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
> OMAPDSS: HDMI: Relocate N/CTS calculation
> OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
> OMAPDSS: HDMI: Add an audio configuration function
> OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
> OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
> OMAPDSS: HDMI: Implement DSS driver interface for audio
> OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
>
> Russ Dill (1):
> OMAPDSS: TFP410: use gpio_set_value_cansleep
>
> Thomas Weber (2):
> OMAPDSS: Add Mitsubishi AA084SB01 display support
> OMAPDSS: Add EDT ET0500G0DH6 display support
>
> Tomi Valkeinen (38):
> OMAPDSS: add set_min_bus_tput pointer to omapdss's platform data
> OMAPDSS: Ensure OPP100 when DSS is operational
> OMAPDSS: DSI: remove option to use pck for DSI PLL clkin
> OMAPDSS: panel-dvi: add PD gpio handling
> OMAP: board-files: remove custom PD GPIO handling for DVI output
> OMAPDSS: TFP410: rename dvi -> tfp410
> OMAPDSS: TFP410: rename dvi files to tfp410
> OMAPDSS: Taal: move reset gpio handling to taal driver
> OMAPDSS: DSI: implement generic DSI pin config
> Merge branch 'archit/set-timing-work'
> Merge branch 'for-l-o-3.5'
> OMAPFB: fix parsing of vram parameter
> OMAPDSS: TFP410: pdata rewrite
> OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id
> OMAPDSS: clean up the omapdss platform data mess
> OMAPDSS: remove return from platform_driver_unreg
> OMAPDSS: use platform_driver_probe for core/dispc/dss
> OMAPDSS: create custom pdevs for DSS omap_devices
> OMAPDSS: create DPI & SDI devices
> OMAPDSS: create DPI & SDI drivers
> OMAPDSS: remove uses of dss_runtime_get/put
> OMAPDSS: handle output-driver reg/unreg more dynamically
> OMAPDSS: move the creation of debugfs files
> OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
> OMAPDSS: add __init & __exit
> OMAPFB: add __init & __exit
> OMAPDSS: change default_device handling
> OMAPDSS: interface drivers register their panel devices
> OMAPDSS: init omap_dss_devices internally
> OMAPDSS: DSI: improve DSI module id handling
> OMAPDSS: separate pdata based initialization
> Merge branch 'dss-devtree-cleanup'
> Merge branch 'omapdss-hdmi-audio'
> OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
> OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
> OMAPDSS: remove compiler warnings when CONFIG_BUG=n
> OMAPFB: remove compiler warnings when CONFIG_BUG=n
> OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
>
> Documentation/arm/OMAP/DSS | 46 ++
> arch/arm/mach-omap2/board-3430sdp.c | 38 +-
> arch/arm/mach-omap2/board-4430sdp.c | 37 +-
> arch/arm/mach-omap2/board-am3517evm.c | 25 +-
> arch/arm/mach-omap2/board-cm-t35.c | 30 +-
> arch/arm/mach-omap2/board-devkit8000.c | 30 +-
> arch/arm/mach-omap2/board-igep0020.c | 32 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 37 +-
> arch/arm/mach-omap2/board-omap3evm.c | 29 +-
> arch/arm/mach-omap2/board-omap3stalker.c | 29 +-
> arch/arm/mach-omap2/board-omap4panda.c | 39 +-
> arch/arm/mach-omap2/board-overo.c | 25 +-
> arch/arm/mach-omap2/display.c | 196 ++++-
> drivers/video/omap/Kconfig | 8 -
> drivers/video/omap2/displays/Kconfig | 8 +-
> drivers/video/omap2/displays/Makefile | 2 +-
> drivers/video/omap2/displays/panel-acx565akm.c | 7 -
> drivers/video/omap2/displays/panel-generic-dpi.c | 107 ++-
> drivers/video/omap2/displays/panel-n8x0.c | 8 -
> drivers/video/omap2/displays/panel-taal.c | 108 +--
> .../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 186 ++---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 22 +-
> drivers/video/omap2/dss/Kconfig | 13 +-
> drivers/video/omap2/dss/apply.c | 134 +++-
> drivers/video/omap2/dss/core.c | 255 ++++---
> drivers/video/omap2/dss/dispc.c | 747 ++++++++++++++------
> drivers/video/omap2/dss/dispc.h | 72 ++
> drivers/video/omap2/dss/display.c | 49 +-
> drivers/video/omap2/dss/dpi.c | 75 +-
> drivers/video/omap2/dss/dsi.c | 537 ++++++++------
> drivers/video/omap2/dss/dss.c | 65 +-
> drivers/video/omap2/dss/dss.h | 151 ++--
> drivers/video/omap2/dss/dss_features.c | 30 +-
> drivers/video/omap2/dss/dss_features.h | 5 +
> drivers/video/omap2/dss/hdmi.c | 443 +++++-------
> drivers/video/omap2/dss/hdmi_panel.c | 236 ++++++-
> drivers/video/omap2/dss/manager.c | 19 +-
> drivers/video/omap2/dss/overlay.c | 16 +-
> drivers/video/omap2/dss/rfbi.c | 84 ++-
> drivers/video/omap2/dss/sdi.c | 63 +-
> drivers/video/omap2/dss/ti_hdmi.h | 32 +-
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 480 ++++++++-----
> drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 161 +----
> drivers/video/omap2/dss/venc.c | 133 +++-
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 17 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 12 +-
> drivers/video/omap2/omapfb/omapfb.h | 1 +
> drivers/video/omap2/vrfb.c | 4 +-
> include/video/omap-panel-nokia-dsi.h | 3 +
> .../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 +-
> include/video/omapdss.h | 75 +-
> 51 files changed, 2983 insertions(+), 1996 deletions(-)
> rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (56%)
> rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
>
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.5
From: Tomi Valkeinen @ 2012-06-05 12:33 UTC (permalink / raw)
To: Jean Pihet
Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev, Tony Lindgren
In-Reply-To: <CAORVsuXLhGCEHMbZB_8FrzfL-sMH76wMH9rdUjOzOfL06bLH4w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2360 bytes --]
Hi Jean,
On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
> Hi Tomi,
> I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
> I have an issue with suspend/resume on OMAP3 Beagleboard, where the
> system hangs at resume time.
>
> Here below is a log with the option no_console_suspend set and a few
> added messages in case of null pointer in _od_resume_noirq.
> It looks like there is no omap_device associated to the "omapdss_dpi" pdev.
>
> What do you think? How to fix this?
> Sorry I know there have been some discussions on the lists but I am
> not aware of all the details in the devices creation for DSS.
>
> / # echo mem > /sys/power/state
> [ 23.262298] PM: Syncing filesystems ... done.
> [ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don
> e.
> [ 23.502197] PM: suspend of devices complete after 163.766 msecs
> [ 23.511932] PM: late suspend of devices complete after 3.418 msecs
> [ 23.524444] PM: noirq suspend of devices complete after 5.860 msecs
> [ 23.531249] Disabling non-boot CPUs ...
> [ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1
> [ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1
> [ 24.489166] Could not enter target state in pm_suspend
> [ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08
> [ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00
> [ 24.506805] *** _od_resume_noirq: od=NULL, pdev->name:omapdss_dpi
> [ 24.513336] Unable to handle kernel NULL pointer dereference at virtual addre
> ss 00000018
> [ 24.521942] pgd = c62f0000
> [ 24.524841] [00000018] *pgd=862c1831, *pte=00000000, *ppte=00000000
> [ 24.531524] Internal error: Oops: 17 [#1] SMP ARM
> [ 24.536529] Modules linked in:
> [ 24.539764] CPU: 0 Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131)
> [ 24.546844] PC is at _od_resume_noirq+0x1c/0xac
> [ 24.551635] LR is at _od_resume_noirq+0x94/0xac
> ...
I'm on leave currently, so I can't test it right now. But can you try
the attached patch? Or even better, try merging the tag:
git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
which contains the included patch plus a couple other fixes.
Tomi
[-- Attachment #1.2: 0001-OMAPDSS-fix-registration-of-DPI-and-SDI-devices.patch --]
[-- Type: text/x-patch, Size: 2547 bytes --]
From 4ea30e9e0f2956b2ebcf1e81ac08d7c6691cf32d Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Tue, 5 Jun 2012 13:17:32 +0300
Subject: [PATCH] OMAPDSS: fix registration of DPI and SDI devices
The omapdss arch initialization code registers all the output devices as
omap_devices. However, DPI and SDI are not proper omap_devices, as they
do not have any corresponding HWMOD. This leads to crashes or problems
when the platform code tries to use omap_device functions for DPI and
SDI devices.
One such crash was reported by John Stultz <johnstul@us.ibm.com>:
[ 18.756835] Unable to handle kernel NULL pointer dereference at
virtual addr8
[ 18.765319] pgd = ea6b8000
[ 18.768188] [00000018] *pgd=aa942831, *pte=00000000, *ppte=00000000
[ 18.774749] Internal error: Oops: 17 [#1] SMP ARM
[ 18.779663] Modules linked in:
[ 18.782836] CPU: 0 Not tainted (3.5.0-rc1-dirty #456)
[ 18.788482] PC is at _od_resume_noirq+0x1c/0x78
[ 18.793212] LR is at _od_resume_noirq+0x6c/0x78
[ 18.797943] pc : [<c00307ec>] lr : [<c003083c>] psr: 20000113
[ 18.797943] sp : ec3abe80 ip : ec3abdb8 fp : 00000006
[ 18.809936] r10: ec1148b8 r9 : c08a48f0 r8 : c00307d0
[ 18.815368] r7 : 00000000 r6 : 00000000 r5 : ec114800 r4 :
ec114808
[ 18.822174] r3 : 00000000 r2 : 00000000 r1 : ec154fe8 r0 :
00000006
[ 18.829010] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 18.836456] Control: 10c5387d Table: aa6b804a DAC: 00000015
[ 18.842437] Process sh (pid: 1139, stack limit = 0xec3aa2f0)
[ 18.848358] Stack: (0xec3abe80 to 0xec3ac000)
DPI and SDI can be plain platform_devices. This patch changes the
registration from omap_device_register() to platform_device_add().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: John Stultz <johnstul@us.ibm.com>
---
arch/arm/mach-omap2/display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 54d49dd..5fb47a1 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -271,9 +271,9 @@ static struct platform_device *create_simple_dss_pdev(const char *pdev_name,
goto err;
}
- r = omap_device_register(pdev);
+ r = platform_device_add(pdev);
if (r) {
- pr_err("Could not register omap_device for %s\n", pdev_name);
+ pr_err("Could not register platform_device for %s\n", pdev_name);
goto err;
}
--
1.7.9.5
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [GIT PULL] OMAP DSS for v3.5
From: Jean Pihet @ 2012-06-05 13:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev, Tony Lindgren
In-Reply-To: <1338899593.4456.6.camel@deskari>
Hi Tomi,
On Tue, Jun 5, 2012 at 2:33 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Jean,
>
> On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
>> Hi Tomi,
>
>> I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
>> I have an issue with suspend/resume on OMAP3 Beagleboard, where the
>> system hangs at resume time.
>>
>> Here below is a log with the option no_console_suspend set and a few
>> added messages in case of null pointer in _od_resume_noirq.
>> It looks like there is no omap_device associated to the "omapdss_dpi" pdev.
>>
>> What do you think? How to fix this?
>> Sorry I know there have been some discussions on the lists but I am
>> not aware of all the details in the devices creation for DSS.
>>
>> / # echo mem > /sys/power/state
>> [ 23.262298] PM: Syncing filesystems ... done.
>> [ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done.
>> [ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don
>> e.
>> [ 23.502197] PM: suspend of devices complete after 163.766 msecs
>> [ 23.511932] PM: late suspend of devices complete after 3.418 msecs
>> [ 23.524444] PM: noirq suspend of devices complete after 5.860 msecs
>> [ 23.531249] Disabling non-boot CPUs ...
>> [ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1
>> [ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1
>> [ 24.489166] Could not enter target state in pm_suspend
>> [ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08
>> [ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00
>> [ 24.506805] *** _od_resume_noirq: od=NULL, pdev->name:omapdss_dpi
>> [ 24.513336] Unable to handle kernel NULL pointer dereference at virtual addre
>> ss 00000018
>> [ 24.521942] pgd = c62f0000
>> [ 24.524841] [00000018] *pgd†2c1831, *pte\0000000, *ppte\0000000
>> [ 24.531524] Internal error: Oops: 17 [#1] SMP ARM
>> [ 24.536529] Modules linked in:
>> [ 24.539764] CPU: 0 Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131)
>> [ 24.546844] PC is at _od_resume_noirq+0x1c/0xac
>> [ 24.551635] LR is at _od_resume_noirq+0x94/0xac
>> ...
>
> I'm on leave currently, so I can't test it right now. But can you try
Oh sorry about that!
> the attached patch? Or even better, try merging the tag:
That fixes it! I am able to suspend/resume correctly now.
>
> git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
>
> which contains the included patch plus a couple other fixes.
Thanks for the link, that is certainly useful!
Have a nice time on leave ;-p
>
> Tomi
>
Regards,
Jean
^ permalink raw reply
* Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Dan Carpenter @ 2012-06-05 14:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120604173702.GZ16584@smp.if.uj.edu.pl>
My patch can't cause this. I'd be surprised if my patch has any
effect beyond silencing a static checker warning, honestly.
I'm not sure this is a new bug.
The problem is we hold ->mmap_sem when we call fb_release() which
takes the info->lock.
We take the info->lock in do_fb_ioctl() before we call fb_set_var()
which calls drm_fb_helper_set_par() which takes the
mode_config.mutex.
In drm_mode_getresources() we take the mode_config.mutex() and call
put_user() which takes the ->mmap_sem.
So on one CPU we are holding the ->mmap_sem and want the info->lock.
On another CPU we are holding the info->lock and want the
config.mutex. On the other CPU we hold the config.mutex and want
the ->mmap_sem.
Deadlock.
I'm not sure how to make this work with just two CPUs... Or how to
fix it. But I'm going to disclaim all responsibility and hope the
fbdev people can take a look. ;)
regards,
dan carpenter
^ permalink raw reply
* [GIT PULL] OMAP DSS for v3.5-rc2
From: Tomi Valkeinen @ 2012-06-05 15:11 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-omap, linux-fbdev, Archit Taneja
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
Hi Florian,
Here are 5 small fixes for omapdss. The most important is the "fix
registration..." patch, without which omapdss crashes when
suspending/resuming. The compilation bug ("fix build...") is also rather
annoying for those users not interested in debug outputs. The rest are
quite minor small fixes.
It'd be great if these made it in for -rc2, as the crash bug is quite
bad, but -rc3 is good also.
Tomi
The following changes since commit e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
for you to fetch changes up to c3a21fc79b6bc097d8b0e47498903a649a111127:
OMAPDSS: fix registration of DPI and SDI devices (2012-06-05 17:15:24 +0300)
----------------------------------------------------------------
Small fixes for omapdss driver. Most importantly, fixes a build problem when
debugfs or omapdss debug support is turned off, and fixes a suspend related
crash.
----------------------------------------------------------------
Archit Taneja (1):
OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
Tomi Valkeinen (4):
OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
OMAPDSS: Taal: fix compilation warning
OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
OMAPDSS: fix registration of DPI and SDI devices
arch/arm/mach-omap2/display.c | 4 ++--
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/omap2/dss/core.c | 3 +--
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
5 files changed, 6 insertions(+), 7 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Witold Baryluk @ 2012-06-05 17:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120604173702.GZ16584@smp.if.uj.edu.pl>
On 06-05 17:10, Dan Carpenter wrote:
> My patch can't cause this. I'd be surprised if my patch has any
> effect beyond silencing a static checker warning, honestly.
>
Yes, you are right. Your patch cannot be cause of it. Sorry for
confusion.
> I'm not sure this is a new bug.
>
Indeed, last time I used mplayer -vo fbdev2 was years ago, so bug could
appear anywhere in this period, or it is a more a matter of my
configuration.
> The problem is we hold ->mmap_sem when we call fb_release() which
> takes the info->lock.
>
> We take the info->lock in do_fb_ioctl() before we call fb_set_var()
> which calls drm_fb_helper_set_par() which takes the
> mode_config.mutex.
>
> In drm_mode_getresources() we take the mode_config.mutex() and call
> put_user() which takes the ->mmap_sem.
>
> So on one CPU we are holding the ->mmap_sem and want the info->lock.
> On another CPU we are holding the info->lock and want the
> config.mutex. On the other CPU we hold the config.mutex and want
> the ->mmap_sem.
>
> Deadlock.
Temporary solution would be to break a cycle, and for example take
info->lock first on first processor before taking ->mmap_sem and calling
fb_release - it is just fb release, so performance doesn't matter so
much. Other possibility is to protect this code paths by separate common
lock, but it will increase memory and make it slower probably in this
function and other ones. I do not know which subsystems use
drm_mode_getresources, and if this is important performance wise.
There is probably other possibilities, but only fbdev people can tell
which is best.
>
> I'm not sure how to make this work with just two CPUs... Or how to
> fix it. But I'm going to disclaim all responsibility and hope the
> fbdev people can take a look. ;)
>
> regards,
> dan carpenter
>
thanks for analysis,
Regards,
Witek
--
Witold Baryluk
^ permalink raw reply
* Re: Circular locking (and possible deadlock), when exiting from mplayer -vo fbdev2
From: Florian Tobias Schandinat @ 2012-06-05 18:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120604173702.GZ16584@smp.if.uj.edu.pl>
Hi,
On 06/05/2012 05:18 PM, Witold Baryluk wrote:
> On 06-05 17:10, Dan Carpenter wrote:
>> My patch can't cause this. I'd be surprised if my patch has any
>> effect beyond silencing a static checker warning, honestly.
>>
>
> Yes, you are right. Your patch cannot be cause of it. Sorry for
> confusion.
>
>> I'm not sure this is a new bug.
>>
>
> Indeed, last time I used mplayer -vo fbdev2 was years ago, so bug could
> appear anywhere in this period, or it is a more a matter of my
> configuration.
>
>> The problem is we hold ->mmap_sem when we call fb_release() which
>> takes the info->lock.
>>
>> We take the info->lock in do_fb_ioctl() before we call fb_set_var()
>> which calls drm_fb_helper_set_par() which takes the
>> mode_config.mutex.
>>
>> In drm_mode_getresources() we take the mode_config.mutex() and call
>> put_user() which takes the ->mmap_sem.
>>
>> So on one CPU we are holding the ->mmap_sem and want the info->lock.
>> On another CPU we are holding the info->lock and want the
>> config.mutex. On the other CPU we hold the config.mutex and want
>> the ->mmap_sem.
>>
>> Deadlock.
>
> Temporary solution would be to break a cycle, and for example take
> info->lock first on first processor before taking ->mmap_sem and calling
> fb_release - it is just fb release, so performance doesn't matter so
> much. Other possibility is to protect this code paths by separate common
> lock, but it will increase memory and make it slower probably in this
> function and other ones. I do not know which subsystems use
> drm_mode_getresources, and if this is important performance wise.
>
> There is probably other possibilities, but only fbdev people can tell
> which is best.
That's not true. This is the wrong mailing list as this happens only
with DRM-based framebuffers (in drivers/gpu/drm/ not drivers/video/) and
therefore you should resend your initial mail to
dri-devel@lists.freedesktop.org.
Best regards,
Florian Tobias Schandinat
>>
>> I'm not sure how to make this work with just two CPUs... Or how to
>> fix it. But I'm going to disclaim all responsibility and hope the
>> fbdev people can take a look. ;)
>>
>> regards,
>> dan carpenter
>>
>
>
> thanks for analysis,
>
> Regards,
> Witek
>
^ permalink raw reply
* Re: [PATCH] mbxfb: unbreak compilation with CONFIG_FB_MBX_DEBUG
From: Florian Tobias Schandinat @ 2012-06-05 19:15 UTC (permalink / raw)
To: tartler
Cc: Eric Miao, Arnd Bergmann, linux-fbdev, linux-kernel, vamos-dev,
Reinhard Tartler
In-Reply-To: <1337013111-7732-1-git-send-email-tartler@cs.fau.de>
Hi,
On 05/14/2012 04:31 PM, tartler@cs.fau.de wrote:
> From: Reinhard Tartler <siretart@tauware.de>
>
> This patch adds missing function prototypes.
>
> Signed-off-by: Reinhard Tartler <tartler@cs.fau.de>
> ---
> drivers/video/mbx/mbxfb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> This patch was found with tools developed in the VAMOS project:
> http://www4.cs.fau.de/Research/VAMOS/
>
> TBH, I'm not sure if this is the correct solution. However, I'd
> appreciate if someone could confirm that this is a real bug.
>
>
> diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
> index 6ce3416..c2200ec 100644
> --- a/drivers/video/mbx/mbxfb.c
> +++ b/drivers/video/mbx/mbxfb.c
> @@ -878,6 +878,9 @@ 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
> +void mbxfb_debugfs_init(struct fb_info *fbi);
> +void mbxfb_debugfs_remove(struct fb_info *fbi);
I don't agree. checkpatch complains
WARNING: externs should be avoided in .c files
#71: FILE: drivers/video/mbx/mbxfb.c:882:
+void mbxfb_debugfs_init(struct fb_info *fbi);
And in drivers/video/mbx/mbxdebugfs.c
static void __devinit mbxfb_debugfs_init(struct fb_info *fbi)
static void __devexit mbxfb_debugfs_remove(struct fb_info *fbi)
So even if you want to ignore the checkpatch warning (which I could
understand for just 2 includes even if headers are certainly better)
you'd have to remove the static at the implementation and for
consistency include the __devinit/exit in your prototypes.
> #endif
>
> #define res_size(_r) (((_r)->end - (_r)->start) + 1)
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] mbxfb: unbreak compilation with CONFIG_FB_MBX_DEBUG
From: Eric Miao @ 2012-06-05 20:54 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: tartler, Arnd Bergmann, linux-fbdev, linux-kernel, vamos-dev,
Reinhard Tartler
In-Reply-To: <4FCE5AD1.6040705@gmx.de>
On Wed, Jun 6, 2012 at 3:15 AM, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Hi,
>
> On 05/14/2012 04:31 PM, tartler@cs.fau.de wrote:
>> From: Reinhard Tartler <siretart@tauware.de>
>>
>> This patch adds missing function prototypes.
>>
>> Signed-off-by: Reinhard Tartler <tartler@cs.fau.de>
>> ---
>> drivers/video/mbx/mbxfb.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> This patch was found with tools developed in the VAMOS project:
>> http://www4.cs.fau.de/Research/VAMOS/
>>
>> TBH, I'm not sure if this is the correct solution. However, I'd
>> appreciate if someone could confirm that this is a real bug.
>>
>>
>> diff --git a/drivers/video/mbx/mbxfb.c b/drivers/video/mbx/mbxfb.c
>> index 6ce3416..c2200ec 100644
>> --- a/drivers/video/mbx/mbxfb.c
>> +++ b/drivers/video/mbx/mbxfb.c
>> @@ -878,6 +878,9 @@ 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
>> +void mbxfb_debugfs_init(struct fb_info *fbi);
>> +void mbxfb_debugfs_remove(struct fb_info *fbi);
>
> I don't agree. checkpatch complains
> WARNING: externs should be avoided in .c files
> #71: FILE: drivers/video/mbx/mbxfb.c:882:
> +void mbxfb_debugfs_init(struct fb_info *fbi);
>
> And in drivers/video/mbx/mbxdebugfs.c
> static void __devinit mbxfb_debugfs_init(struct fb_info *fbi)
> static void __devexit mbxfb_debugfs_remove(struct fb_info *fbi)
>
> So even if you want to ignore the checkpatch warning (which I could
> understand for just 2 includes even if headers are certainly better)
> you'd have to remove the static at the implementation and for
> consistency include the __devinit/exit in your prototypes.
That actually made a very good point, and I seriously doubt whether the
mbxfb_debugfs_* thing has ever been tested. Instead of making them
public, I see a chance maybe we could remove them completely instead.
>
>> #endif
>>
>> #define res_size(_r) (((_r)->end - (_r)->start) + 1)
>
>
> Best regards,
>
> Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-06 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1338351267-25561-1-git-send-email-Ying.Liu@freescale.com>
2012/5/30, Liu Ying <Ying.Liu@freescale.com>:
> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
> calls custom fb_set_par() method and then calls custom
> fb_pan_display() method. The current implementation of mx3fb
> reinitializes IPU display controller every time the custom
> fb_set_par() method is called, which makes the display flash
> if fb_set_var() is called to do panning frequently. The custom
> fb_pan_display() method checks if the current xoffset and
> yoffset are different from previous ones before doing actual
> panning, which prevents the panning from happening within the
> fb_set_var() context. This patch checks new var info to decide
> whether we really need to reinitialize IPU display controller.
> We ignore xoffset and yoffset update because it doesn't require
> to reinitialize the controller. Users may specify activate field
> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
> reinialize the controller by force. Meanwhile, this patch removes
> the check in custom fb_pan_display() method mentioned before to
> have the panning work within fb_set_var() context. It doesn't
> hurt to do panning again if there is no update for xoffset and
> yoffset.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> drivers/video/mx3fb.c | 31 +++++++++++++++++++++++++++----
> 1 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..86daabe 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -269,6 +269,8 @@ struct mx3fb_info {
> struct scatterlist sg[2];
>
> u32 sync; /* preserve var->sync flags */
> +
> + struct fb_var_screeninfo cur_var; /* current var info */
> };
>
> static void mx3fb_dma_done(void *);
> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
> complete(&mx3_fbi->flip_cmpl);
> }
>
> +static bool fb_need_not_to_set_par(struct fb_info *fbi)
> +{
> + struct mx3fb_info *mx3_fbi = fbi->par;
> + struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
> + struct fb_var_screeninfo new_var = fbi->var;
> +
> + if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
> + (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
> + return false;
> +
> + /*
> + * Ignore xoffset and yoffset update,
> + * because pan display handles this case.
> + */
> + old_var.xoffset = new_var.xoffset;
> + old_var.yoffset = new_var.yoffset;
> +
> + return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
> +}
> +
> static int __set_par(struct fb_info *fbi, bool lock)
> {
> u32 mem_len;
> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
> struct idmac_video_param *video = &ichan->params.video;
> struct scatterlist *sg = mx3_fbi->sg;
>
> + if (fb_need_not_to_set_par(fbi))
> + return 0;
> +
> /* Total cleanup */
> if (mx3_fbi->txd)
> sdc_disable_channel(mx3_fbi);
> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
> if (mx3_fbi->blank = FB_BLANK_UNBLANK)
> sdc_enable_channel(mx3_fbi);
>
> + mx3_fbi->cur_var = fbi->var;
> +
> return 0;
> }
>
> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> - if (fbi->var.xoffset = var->xoffset &&
> - fbi->var.yoffset = var->yoffset)
> - return 0; /* No change, do nothing */
> -
> y_bottom = var->yoffset;
>
> if (!(var->vmode & FB_VMODE_YWRAP))
> --
> 1.7.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
The patch is present here for a period of time.
Can someone help to review this?
Thanks.
--
Best Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Guennadi Liakhovetski @ 2012-06-06 15:54 UTC (permalink / raw)
To: Liu Ying; +Cc: FlorianSchandinat, linux-fbdev, linux-kernel
In-Reply-To: <1338352042-26522-1-git-send-email-Ying.Liu@freescale.com>
On Wed, 30 May 2012, Liu Ying wrote:
> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
> calls custom fb_set_par() method and then calls custom
> fb_pan_display() method. The current implementation of mx3fb
> reinitializes IPU display controller every time the custom
> fb_set_par() method is called, which makes the display flash
> if fb_set_var() is called to do panning frequently. The custom
> fb_pan_display() method checks if the current xoffset and
> yoffset are different from previous ones before doing actual
> panning, which prevents the panning from happening within the
> fb_set_var() context. This patch checks new var info to decide
> whether we really need to reinitialize IPU display controller.
> We ignore xoffset and yoffset update because it doesn't require
> to reinitialize the controller. Users may specify activate field
> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
> reinialize the controller by force. Meanwhile, this patch removes
> the check in custom fb_pan_display() method mentioned before to
> have the panning work within fb_set_var() context. It doesn't
> hurt to do panning again if there is no update for xoffset and
> yoffset.
You are really addressing 2 separate problems here: (1) panning cannot be
set using FBIOPUT_VSCREENINFO and (2) screen flashes every time
fb_set_var() is called, even if only panning is required. The reason for
the first one is, that in fb_set_var() info->var is already updated from
the new *var when fb_pan_display() is called. So, as you correctly
identified, the condition
if (fbi->var.xoffset = var->xoffset &&
fbi->var.yoffset = var->yoffset)
return 0; /* No change, do nothing */
is trivially met and no panning takes place. Instead, you can use your
idea to cache var_info locally and check against that one to see, whether
offsets have changed, instead of removing that check completely.
To solve the second problem you can use your check against the cached copy
of var_info. See below for more details.
>
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
> drivers/video/mx3fb.c | 31 +++++++++++++++++++++++++++----
> 1 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..238b9aa 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -269,6 +269,8 @@ struct mx3fb_info {
> struct scatterlist sg[2];
>
> u32 sync; /* preserve var->sync flags */
An incremental patch could then also remove the above .sync member and
switch to using .cur_var.sync instead.
> +
> + struct fb_var_screeninfo cur_var; /* current var info */
> };
>
> static void mx3fb_dma_done(void *);
> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
> complete(&mx3_fbi->flip_cmpl);
> }
>
> +static bool mx3fb_need_not_to_set_par(struct fb_info *fbi)
How about inverting logic and calling the function
mx3fb_must_update_par()?
> +{
> + struct mx3fb_info *mx3_fbi = fbi->par;
> + struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
> + struct fb_var_screeninfo new_var = fbi->var;
> +
> + if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
> + (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
> + return false;
> +
> + /*
> + * Ignore xoffset and yoffset update,
> + * because pan display handles this case.
> + */
> + old_var.xoffset = new_var.xoffset;
> + old_var.yoffset = new_var.yoffset;
> +
> + return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
> +}
> +
> static int __set_par(struct fb_info *fbi, bool lock)
> {
> u32 mem_len;
> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
> struct idmac_video_param *video = &ichan->params.video;
> struct scatterlist *sg = mx3_fbi->sg;
>
> + if (mx3fb_need_not_to_set_par(fbi))
> + return 0;
> +
__set_par() is called from 2 locations: from mx3fb_set_par() and
init_fb_chan(), called from probing. You don't need to perform the above
check in init_fb_chan() - there you always have to configure. Maybe better
put it in mx3fb_set_par() just before calling __set_par() like
ret = mx3fb_must_set_par() ? __set_par() : 0;
As mentioned above, this solves problem #2 and should go into patch #2.
> /* Total cleanup */
> if (mx3_fbi->txd)
> sdc_disable_channel(mx3_fbi);
> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
> if (mx3_fbi->blank = FB_BLANK_UNBLANK)
> sdc_enable_channel(mx3_fbi);
>
> + mx3_fbi->cur_var = fbi->var;
> +
Yes, but preserve xoffset and yoffset - you don't apply them yet in
__set_par().
> return 0;
> }
>
> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
> return -EINVAL;
> }
>
> - if (fbi->var.xoffset = var->xoffset &&
> - fbi->var.yoffset = var->yoffset)
> - return 0; /* No change, do nothing */
> -
I think, it would be better not to remove these completely, but check
against cached .cur_var, and then update those values too.
> y_bottom = var->yoffset;
>
> if (!(var->vmode & FB_VMODE_YWRAP))
> --
> 1.7.1
Makes sense? Or have I misunderstood something?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Arnd Bergmann @ 2012-06-09 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339194280-27475-1-git-send-email-mathieu.poirier@linaro.org>
On Friday 08 June 2012, mathieu.poirier@linaro.org wrote:
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> These patches fix miscellaneous problems when working
> with make randconfig. They were discovered on kernel
> 3.1-rc4 and sent out during the 3.4 cycle but were not
> ack'ed.
>
> Sending out again for completeness.
Hi Mathieu,
I just realized that most of these are for the same subsystem
(framebuffer), so you should have kept the respective mailing list
and maintainer on Cc (added now).
The mg_disk driver is not listed in the MAINTAINERS file but
has an author email listed in the file itself.
I can take the mg_disk patch into the arm-soc tree as a fix,
but I'd prefer the other patches to go through the framebuffer
tree.
Arnd
> Arnd Bergmann (6):
> drivers/video: use correct __devexit_p annotation
> mg_disk: use readb/writeb instead of inb/outb
> video/ili9320: do not mark exported functions __devexit
> video/console: automatically select a font
> drivers/savagefb: use mdelay instead of udelay
> drivers/tosa: driver needs I2C and SPI to compile
>
> drivers/block/mg_disk.c | 78 ++++++++++++++++----------------
> drivers/video/backlight/Kconfig | 2 +-
> drivers/video/backlight/ili9320.c | 2 +-
> drivers/video/broadsheetfb.c | 2 +-
> drivers/video/console/Kconfig | 14 ++++++
> drivers/video/mbx/mbxfb.c | 2 +-
> drivers/video/savage/savagefb_driver.c | 10 ++--
> 7 files changed, 62 insertions(+), 48 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.5-rc2
From: Florian Tobias Schandinat @ 2012-06-09 12:39 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1338909099.4456.13.camel@deskari>
Hi Tomi,
On 06/05/2012 03:11 PM, Tomi Valkeinen wrote:
> Hi Florian,
>
> Here are 5 small fixes for omapdss. The most important is the "fix
> registration..." patch, without which omapdss crashes when
> suspending/resuming. The compilation bug ("fix build...") is also rather
> annoying for those users not interested in debug outputs. The rest are
> quite minor small fixes.
>
> It'd be great if these made it in for -rc2, as the crash bug is quite
> bad, but -rc3 is good also.
I merged this some days ago. Sorry that I didn't realize that rc2 would
be released early and hence didn't manage to get it in.
Best regards,
Florian Tobias Schandinat
>
> Tomi
>
>
> The following changes since commit e92a5b28f71aea01b281f9c89d97a4bc5b24748f:
>
> OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
>
> for you to fetch changes up to c3a21fc79b6bc097d8b0e47498903a649a111127:
>
> OMAPDSS: fix registration of DPI and SDI devices (2012-06-05 17:15:24 +0300)
>
> ----------------------------------------------------------------
> Small fixes for omapdss driver. Most importantly, fixes a build problem when
> debugfs or omapdss debug support is turned off, and fixes a suspend related
> crash.
>
> ----------------------------------------------------------------
> Archit Taneja (1):
> OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters
>
> Tomi Valkeinen (4):
> OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
> OMAPDSS: Taal: fix compilation warning
> OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
> OMAPDSS: fix registration of DPI and SDI devices
>
> arch/arm/mach-omap2/display.c | 4 ++--
> drivers/video/omap2/displays/panel-taal.c | 2 +-
> drivers/video/omap2/dss/core.c | 3 +--
> drivers/video/omap2/dss/dsi.c | 2 +-
> drivers/video/omap2/dss/dss.c | 2 +-
> 5 files changed, 6 insertions(+), 7 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] video: bfin_adv7393fb: Convert to kstrtouint_from_user
From: Florian Tobias Schandinat @ 2012-06-09 12:41 UTC (permalink / raw)
To: Emil Goode; +Cc: linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <1338310620-6886-1-git-send-email-emilgoode@gmail.com>
On 05/29/2012 04:57 PM, Emil Goode wrote:
> This patch removes a call to the deprecated simple_strtoul function
> and simplifies the code by replacing two function calls with one
> call to kstrtouint_from_user.
>
> -Simplify the adv7393_write_proc function by replacing the
> simple_strtoul and copy_from_user calls with one call
> to kstrtouint_from_user.
>
> -Change the count parameter from unsigned long to size_t as
> this is the type that the kstrtouint_from_user function expects.
> (size_t is what will be passed to the adv7393_write_proc function
> by the proc write handler function proc_file_write anyway)
>
> Signed-off-by: Emil Goode <emilgoode@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/bfin_adv7393fb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c
> index 1a268a2..8c6edfd 100644
> --- a/drivers/video/bfin_adv7393fb.c
> +++ b/drivers/video/bfin_adv7393fb.c
> @@ -353,18 +353,16 @@ adv7393_read_proc(char *page, char **start, off_t off,
>
> static int
> adv7393_write_proc(struct file *file, const char __user * buffer,
> - unsigned long count, void *data)
> + size_t count, void *data)
> {
> struct adv7393fb_device *fbdev = data;
> - char line[8];
> unsigned int val;
> int ret;
>
> - ret = copy_from_user(line, buffer, count);
> + ret = kstrtouint_from_user(buffer, count, 0, &val);
> if (ret)
> return -EFAULT;
>
> - val = simple_strtoul(line, NULL, 0);
> adv7393_write(fbdev->client, val >> 8, val & 0xff);
>
> return count;
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Florian Tobias Schandinat @ 2012-06-09 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201206090013.27149.arnd@arndb.de>
Hi Arnd, Mathieu,
On 06/09/2012 12:13 AM, Arnd Bergmann wrote:
> On Friday 08 June 2012, mathieu.poirier@linaro.org wrote:
>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>> These patches fix miscellaneous problems when working
>> with make randconfig. They were discovered on kernel
>> 3.1-rc4 and sent out during the 3.4 cycle but were not
>> ack'ed.
>>
>> Sending out again for completeness.
>
> Hi Mathieu,
>
> I just realized that most of these are for the same subsystem
> (framebuffer), so you should have kept the respective mailing list
> and maintainer on Cc (added now).
>
> The mg_disk driver is not listed in the MAINTAINERS file but
> has an author email listed in the file itself.
>
> I can take the mg_disk patch into the arm-soc tree as a fix,
> but I'd prefer the other patches to go through the framebuffer
> tree.
Applied all (including the backlight patches which are usually handled
by Andrew Morton) but the mg_disk patch.
Thanks,
Florian Tobias Schandinat
>
> Arnd
>
>> Arnd Bergmann (6):
>> drivers/video: use correct __devexit_p annotation
>> mg_disk: use readb/writeb instead of inb/outb
>> video/ili9320: do not mark exported functions __devexit
>> video/console: automatically select a font
>> drivers/savagefb: use mdelay instead of udelay
>> drivers/tosa: driver needs I2C and SPI to compile
>>
>> drivers/block/mg_disk.c | 78 ++++++++++++++++----------------
>> drivers/video/backlight/Kconfig | 2 +-
>> drivers/video/backlight/ili9320.c | 2 +-
>> drivers/video/broadsheetfb.c | 2 +-
>> drivers/video/console/Kconfig | 14 ++++++
>> drivers/video/mbx/mbxfb.c | 2 +-
>> drivers/video/savage/savagefb_driver.c | 10 ++--
>> 7 files changed, 62 insertions(+), 48 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 0/6] drivers: randconfig patches for kernel 3.5
From: Arnd Bergmann @ 2012-06-09 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FD3482B.5050004@gmx.de>
On Saturday 09 June 2012, Florian Tobias Schandinat wrote:
> >
> > I just realized that most of these are for the same subsystem
> > (framebuffer), so you should have kept the respective mailing list
> > and maintainer on Cc (added now).
> >
> > The mg_disk driver is not listed in the MAINTAINERS file but
> > has an author email listed in the file itself.
> >
> > I can take the mg_disk patch into the arm-soc tree as a fix,
> > but I'd prefer the other patches to go through the framebuffer
> > tree.
>
> Applied all (including the backlight patches which are usually handled
> by Andrew Morton) but the mg_disk patch.
Ok, Thanks a lot!
Arnd
^ permalink raw reply
* [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
This patch checks if framebuffer is unblanked before
we actually trigger panning in custom pan display
function.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/mx3fb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index e3406ab..d53db60 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
dev_dbg(fbi->device, "%s [%c]\n", __func__,
list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
+ if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
+ dev_dbg(fbi->device, "panning with fb blanked not supported\n");
+ return -EFAULT;
+ }
+
if (var->xoffset > 0) {
dev_dbg(fbi->device, "x panning not supported\n");
return -EINVAL;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-11 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>
Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
This ioctrl relies on fb_set_var() to do the job. fb_set_var()
calls the custom fb_set_par() method and then calls the custom
fb_pan_display() method. Before calling the custom fb_pan_display()
method, info->var is already updated from the new *var in fb_set_var().
And, the custom fb_pan_display() method checks if xoffset and yoffset
in info->var and the new *var are different before doing actual panning,
which prevents the panning from happening within fb_set_var() context.
This patch caches the current var info locally in mx3fb driver so that
pan display with fb_set_var is supported.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/mx3fb.c | 33 ++++++++++++++++++++++++++-------
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d53db60..2dd11c4 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -268,7 +268,7 @@ struct mx3fb_info {
dma_cookie_t cookie;
struct scatterlist sg[2];
- u32 sync; /* preserve var->sync flags */
+ struct fb_var_screeninfo cur_var; /* current var info */
};
static void mx3fb_dma_done(void *);
@@ -723,7 +723,7 @@ static void mx3fb_dma_done(void *arg)
static int __set_par(struct fb_info *fbi, bool lock)
{
- u32 mem_len;
+ u32 mem_len, cur_xoffset, cur_yoffset;
struct ipu_di_signal_cfg sig_cfg;
enum ipu_panel mode = IPU_PANEL_TFT;
struct mx3fb_info *mx3_fbi = fbi->par;
@@ -805,8 +805,25 @@ static int __set_par(struct fb_info *fbi, bool lock)
video->out_height = fbi->var.yres;
video->out_stride = fbi->var.xres_virtual;
- if (mx3_fbi->blank = FB_BLANK_UNBLANK)
+ if (mx3_fbi->blank = FB_BLANK_UNBLANK) {
sdc_enable_channel(mx3_fbi);
+ /*
+ * sg[0] points to fb smem_start address
+ * and is actually active in controller.
+ */
+ mx3_fbi->cur_var.xoffset = 0;
+ mx3_fbi->cur_var.yoffset = 0;
+ }
+
+ /*
+ * Preserve xoffset and yoffest in case they are
+ * inactive in controller as fb is blanked.
+ */
+ cur_xoffset = mx3_fbi->cur_var.xoffset;
+ cur_yoffset = mx3_fbi->cur_var.yoffset;
+ mx3_fbi->cur_var = fbi->var;
+ mx3_fbi->cur_var.xoffset = cur_xoffset;
+ mx3_fbi->cur_var.yoffset = cur_yoffset;
return 0;
}
@@ -926,8 +943,8 @@ static int mx3fb_check_var(struct fb_var_screeninfo *var, struct fb_info *fbi)
var->grayscale = 0;
/* Preserve sync flags */
- var->sync |= mx3_fbi->sync;
- mx3_fbi->sync |= var->sync;
+ var->sync |= mx3_fbi->cur_var.sync;
+ mx3_fbi->cur_var.sync |= var->sync;
return 0;
}
@@ -1073,8 +1090,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
return -EINVAL;
}
- if (fbi->var.xoffset = var->xoffset &&
- fbi->var.yoffset = var->yoffset)
+ if (mx3_fbi->cur_var.xoffset = var->xoffset &&
+ mx3_fbi->cur_var.yoffset = var->yoffset)
return 0; /* No change, do nothing */
y_bottom = var->yoffset;
@@ -1157,6 +1174,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
else
fbi->var.vmode &= ~FB_VMODE_YWRAP;
+ mx3_fbi->cur_var = fbi->var;
+
mutex_unlock(&mx3_fbi->mutex);
dev_dbg(fbi->device, "Update complete\n");
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox