* [PATCH 2/2] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tomi Valkeinen @ 2012-10-08 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev
Cc: Archit Taneja, Tony Lindgren, Tomi Valkeinen, Vaibhav Hiremath
In-Reply-To: <1349699429-12736-1-git-send-email-tomi.valkeinen@ti.com>
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/plat-omap/include/plat/vrfb.h | 66 -----------------------------
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
drivers/media/video/omap/omap_voutdef.h | 2 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 2 +-
drivers/video/omap2/vrfb.c | 2 +-
include/video/omapvrfb.h | 66 +++++++++++++++++++++++++++++
9 files changed, 73 insertions(+), 73 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
deleted file mode 100644
index 3792bde..0000000
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * VRFB Rotation Engine
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRFB_H__
-#define __OMAP_VRFB_H__
-
-#define OMAP_VRFB_LINE_LEN 2048
-
-struct vrfb {
- u8 context;
- void __iomem *vaddr[4];
- unsigned long paddr[4];
- u16 xres;
- u16 yres;
- u16 xoffset;
- u16 yoffset;
- u8 bytespp;
- bool yuv_mode;
-};
-
-#ifdef CONFIG_OMAP2_VRFB
-extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp);
-extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
-extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
-extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height,
- unsigned bytespp, bool yuv_mode);
-extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
-extern void omap_vrfb_restore_context(void);
-
-#else
-static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
-static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
-static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp) {}
-static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
- { return 0; }
-static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
- { return 0; }
-static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
-static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
- { return 0; }
-static inline void omap_vrfb_restore_context(void) {}
-#endif
-#endif /* __VRFB_H */
diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
index f721fd2..940f39f 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -45,7 +45,7 @@
#include <media/v4l2-ioctl.h>
#include <plat/dma.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include <video/omapdss.h>
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -17,7 +17,7 @@
#include <media/v4l2-device.h>
#include <plat/dma.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omap_voutdef.h"
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_voutdef.h b/drivers/media/video/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/omap/omap_voutdef.h
@@ -12,7 +12,7 @@
#define OMAP_VOUTDEF_H
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#define YUYV_BPP 2
#define RGB565_BPP 2
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..55a39be 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -30,7 +30,7 @@
#include <linux/export.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include <plat/vram.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index b103793..742a66b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,7 @@
#include <video/omapdss.h>
#include <plat/vram.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c b/drivers/video/omap2/omapfb/omapfb-sysfs.c
index e8d8cc7..17aa174 100644
--- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
@@ -30,7 +30,7 @@
#include <linux/omapfb.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index c072e37..1bf0253 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -28,7 +28,7 @@
#include <linux/mutex.h>
#include <linux/platform_device.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
new file mode 100644
index 0000000..3792bde
--- /dev/null
+++ b/include/video/omapvrfb.h
@@ -0,0 +1,66 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xres;
+ u16 yres;
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+ bool yuv_mode;
+};
+
+#ifdef CONFIG_OMAP2_VRFB
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
+extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
+extern void omap_vrfb_restore_context(void);
+
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
+#endif /* __VRFB_H */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2 v6] of: add generic videomode description
From: Steffen Trumtrar @ 2012-10-08 12:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
linux-media, Tomi Valkeinen
In-Reply-To: <12272414.930KpWciBg@avalon>
On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
>
> Thanks for the patch.
>
> On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
> > Get videomode from devicetree in a format appropriate for the
> > backend. drm_display_mode and fb_videomode are supported atm.
> > Uses the display signal timings from of_display_timings
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > drivers/of/Kconfig | 5 +
> > drivers/of/Makefile | 1 +
> > drivers/of/of_videomode.c | 212 +++++++++++++++++++++++++++++++++++++++
> > include/linux/of_videomode.h | 41 ++++++++
> > 4 files changed, 259 insertions(+)
> > create mode 100644 drivers/of/of_videomode.c
> > create mode 100644 include/linux/of_videomode.h
> >
> > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > index 646deb0..74282e2 100644
> > --- a/drivers/of/Kconfig
> > +++ b/drivers/of/Kconfig
> > @@ -88,4 +88,9 @@ config OF_DISPLAY_TIMINGS
> > help
> > helper to parse display timings from the devicetree
> >
> > +config OF_VIDEOMODE
> > + def_bool y
> > + help
> > + helper to get videomodes from the devicetree
> > +
> > endmenu # OF
> > diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> > index c8e9603..09d556f 100644
> > --- a/drivers/of/Makefile
> > +++ b/drivers/of/Makefile
> > @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
> > obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> > obj-$(CONFIG_OF_MTD) += of_mtd.o
> > obj-$(CONFIG_OF_DISPLAY_TIMINGS) += of_display_timings.o
> > +obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
> > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> > new file mode 100644
> > index 0000000..76ac16e
> > --- /dev/null
> > +++ b/drivers/of/of_videomode.c
> > @@ -0,0 +1,212 @@
> > +/*
> > + * generic videomode helper
> > + *
> > + * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>,
> > Pengutronix
> > + *
> > + * This file is released under the GPLv2
> > + */
> > +#include <linux/of.h>
> > +#include <linux/fb.h>
> > +#include <linux/slab.h>
> > +#include <drm/drm_mode.h>
> > +#include <linux/of_display_timings.h>
> > +#include <linux/of_videomode.h>
> > +
> > +void dump_fb_videomode(struct fb_videomode *m)
> > +{
> > + pr_debug("fb_videomode = %d %d %d %d %d %d %d %d %d %d %d %d %d\n",
>
> That's going to be pretty difficult to read :-) Would it make sense to group
> several attributes logically (for instance using %ux%u for m->xres, m->yres) ?
>
No problem. That can be changed.
> > + m->refresh, m->xres, m->yres, m->pixclock, m->left_margin,
> > + m->right_margin, m->upper_margin, m->lower_margin, +
> > m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
> > +}
>
> Shouldn't this (and the other non exported functions below) be static ?
>
Yes.
> > +void dump_drm_displaymode(struct drm_display_mode *m)
> > +{
> > + pr_debug("drm_displaymode = %d %d %d %d %d %d %d %d %d\n",
> > + m->hdisplay, m->hsync_start, m->hsync_end, m->htotal,
> > + m->vdisplay, m->vsync_start, m->vsync_end, m->vtotal,
> > + m->clock);
> > +}
> > +
> > +int videomode_from_timing(struct display_timings *disp, struct videomode
> > *vm,
> > + int index)
> > +{
> > + struct signal_timing *st = NULL;
> > +
> > + if (!vm)
> > + return -EINVAL;
> > +
>
> What about making vm a mandatory argument ? It looks to me like a caller bug
> if vm is NULL.
>
The caller must provide the struct videomode, yes. Wouldn't the kernel hang itself
with a NULL pointer exception, if I just work with it ?
> > + st = display_timings_get(disp, index);
> > +
>
> You can remove the blank line.
>
> > + if (!st) {
> > + pr_err("%s: no signal timings found\n", __func__);
> > + return -EINVAL;
> > + }
> > +
> > + vm->pixelclock = signal_timing_get_value(&st->pixelclock, 0);
> > + vm->hactive = signal_timing_get_value(&st->hactive, 0);
> > + vm->hfront_porch = signal_timing_get_value(&st->hfront_porch, 0);
> > + vm->hback_porch = signal_timing_get_value(&st->hback_porch, 0);
> > + vm->hsync_len = signal_timing_get_value(&st->hsync_len, 0);
> > +
> > + vm->vactive = signal_timing_get_value(&st->vactive, 0);
> > + vm->vfront_porch = signal_timing_get_value(&st->vfront_porch, 0);
> > + vm->vback_porch = signal_timing_get_value(&st->vback_porch, 0);
> > + vm->vsync_len = signal_timing_get_value(&st->vsync_len, 0);
> > +
> > + vm->vah = st->vsync_pol_active_high;
> > + vm->hah = st->hsync_pol_active_high;
> > + vm->interlaced = st->interlaced;
> > + vm->doublescan = st->doublescan;
> > +
> > + return 0;
> > +}
> > +
> > +int of_get_videomode(struct device_node *np, struct videomode *vm, int
> > index)
>
> I wonder how to avoid abuse of this functions. It's a useful helper for
> drivers that need to get a video mode once only, but would result in lower
> performances if a driver calls it for every mode. Drivers must call
> of_get_display_timing_list instead in that case and case the display timings.
> I'm wondering whether we should really expose of_get_videomode.
>
The intent was to let the driver decide. That way all the other overhead may
be skipped.
> > +{
> > + struct display_timings *disp;
> > + int ret = 0;
>
> No need to assign ret to 0 here.
>
Ah, yes. Unneeded in this case.
> > +
> > + disp = of_get_display_timing_list(np);
> > +
>
> You can remove the blank line.
>
> > + if (!disp) {
> > + pr_err("%s: no timings specified\n", __func__);
> > + return -EINVAL;
> > + }
> > +
> > + if (index = OF_DEFAULT_TIMING)
> > + index = disp->default_timing;
> > +
> > + ret = videomode_from_timing(disp, vm, index);
> > +
>
> No need for a blank line.
>
> > + if (ret)
> > + return ret;
> > +
> > + display_timings_release(disp);
> > +
> > + if (!vm) {
> > + pr_err("%s: could not get videomode %d\n", __func__, index);
> > + return -EINVAL;
> > + }
>
> This can't happen. If vm is NULL the videomode_from_timing call above will
> return -EINVAL, and this function will then return immediately without
> reaching this code block.
>
Okay.
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_get_videomode);
> > +
> > +#if defined(CONFIG_DRM)
> > +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
> > *dmode)
> > +{
> > + memset(dmode, 0, sizeof(*dmode));
> > +
> > + dmode->hdisplay = vm->hactive;
> > + dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
> > + dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
> > + dmode->htotal = dmode->hsync_end + vm->hback_porch;
> > +
> > + dmode->vdisplay = vm->vactive;
> > + dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
> > + dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
> > + dmode->vtotal = dmode->vsync_end + vm->vback_porch;
> > +
> > + dmode->clock = vm->pixelclock / 1000;
> > +
> > + if (vm->hah)
> > + dmode->flags |= DRM_MODE_FLAG_PHSYNC;
> > + else
> > + dmode->flags |= DRM_MODE_FLAG_NHSYNC;
> > + if (vm->vah)
> > + dmode->flags |= DRM_MODE_FLAG_PVSYNC;
> > + else
> > + dmode->flags |= DRM_MODE_FLAG_NVSYNC;
> > + if (vm->interlaced)
> > + dmode->flags |= DRM_MODE_FLAG_INTERLACE;
> > + if (vm->doublescan)
> > + dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > + drm_mode_set_name(dmode);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(videomode_to_display_mode);
> > +
> > +int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode
> > *dmode,
> > + int index)
>
> Same as above, do we really need to expose this helper function ? If so we
> should at least clearly document (using kerneldoc for instance) that drivers
> should only use it if they need to get a single mode once.
>
> > +{
> > + struct videomode vm;
> > + int ret;
> > +
> > + ret = of_get_videomode(np, &vm, index);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + videomode_to_display_mode(&vm, dmode);
> > +
> > + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
> > + vm.vactive, np->name);
> > + dump_drm_displaymode(dmode);
> > +
> > + return 0;
> > +
> > +}
> > +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
> > +#else
> > +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
> > *dmode)
> > +{
> > + return 0;
> > +}
> > +
> > +int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode
> > *dmode,
> > + int index)
> > +{
> > + return 0;
> > +}
>
> What about not defining those if CONFIG_DRM is not set ? No driver should call
> these functions in that case. If we really need those stubs they should return
> an error.
>
Okay. I will remove them.
> > +#endif
> > +
> > +int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
> > *fbmode)
> > +{
> > + memset(fbmode, 0, sizeof(*fbmode));
> > +
> > + fbmode->xres = vm->hactive;
> > + fbmode->left_margin = vm->hback_porch;
> > + fbmode->right_margin = vm->hfront_porch;
> > + fbmode->hsync_len = vm->hsync_len;
> > +
> > + fbmode->yres = vm->vactive;
> > + fbmode->upper_margin = vm->vback_porch;
> > + fbmode->lower_margin = vm->vfront_porch;
> > + fbmode->vsync_len = vm->vsync_len;
> > +
> > + fbmode->pixclock = KHZ2PICOS(vm->pixelclock) / 1000;
> > +
> > + if (vm->hah)
> > + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> > + if (vm->vah)
> > + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> > + if (vm->interlaced)
> > + fbmode->vmode |= FB_VMODE_INTERLACED;
> > + if (vm->doublescan)
> > + fbmode->vmode |= FB_VMODE_DOUBLE;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
> > +
> > +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> > + int index)
> > +{
> > + struct videomode vm;
> > + int ret;
> > +
> > + ret = of_get_videomode(np, &vm, index);
> > + if (ret)
> > + return ret;
> > +
> > + videomode_to_fb_videomode(&vm, fb);
> > +
> > + pr_info("%s: got %dx%d display mode from %s\n", __func__, vm.hactive,
> > + vm.vactive, np->name);
> > + dump_fb_videomode(fb);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
> > diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
> > new file mode 100644
> > index 0000000..96efe01
> > --- /dev/null
> > +++ b/include/linux/of_videomode.h
> > @@ -0,0 +1,41 @@
> > +/*
> > + * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > + *
> > + * generic videomode description
> > + *
> > + * This file is released under the GPLv2
> > + */
> > +
> > +#ifndef __LINUX_VIDEOMODE_H
> > +#define __LINUX_VIDEOMODE_H
> > +
> > +#include <drm/drmP.h>
> > +
> > +struct videomode {
> > + u32 pixelclock;
> > + u32 refreshrate;
> > +
> > + u32 hactive;
> > + u32 hfront_porch;
> > + u32 hback_porch;
> > + u32 hsync_len;
> > +
> > + u32 vactive;
> > + u32 vfront_porch;
> > + u32 vback_porch;
> > + u32 vsync_len;
> > +
> > + bool hah;
> > + bool vah;
> > + bool interlaced;
> > + bool doublescan;
> > +
> > +};
> > +
> > +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
> > *dmode); +int videomode_to_fb_videomode(struct videomode *vm, struct
> > fb_videomode *fbmode); +int of_get_videomode(struct device_node *np, struct
> > videomode *vm, int index); +int of_get_drm_display_mode(struct device_node
> > *np, struct drm_display_mode *dmode, + int index);
> > +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> > int index); +#endif /* __LINUX_VIDEOMODE_H */
> --
> Regards,
>
> Laurent Pinchart
>
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] da8xx-fb: move panel information from driver to platform file
From: Sekhar Nori @ 2012-10-08 12:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1349445084-9857-2-git-send-email-prakash.pm@ti.com>
Hi Prakash,
On 10/5/2012 7:21 PM, Manjunathappa, Prakash wrote:
> Moving panel information from driver to platform file, patch also made
> compliant to fb_videomode data.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
Why do you have to do this? Just moving panel data from driver to
platform code doesn't seem to buy anything.
If you are passed DT data, then use it else continue the existing
platform data method? Once all the boards using this driver are
converted to DT, then all the panel information can be removed from
driver. That will save code.
This patch looks like needless churn.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] matrox maven: use module_i2c_driver to simplify the code
From: Wei Yongjun @ 2012-10-08 14:07 UTC (permalink / raw)
To: linux-fbdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use the module_i2c_driver() macro to make the code smaller
and a bit simpler.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/matrox/matroxfb_maven.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 217678e..ed05c36 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -1283,19 +1283,9 @@ static struct i2c_driver maven_driver={
.id_table = maven_id,
};
-static int __init matroxfb_maven_init(void)
-{
- return i2c_add_driver(&maven_driver);
-}
-
-static void __exit matroxfb_maven_exit(void)
-{
- i2c_del_driver(&maven_driver);
-}
+module_i2c_driver(maven_driver);
MODULE_AUTHOR("(c) 1999-2002 Petr Vandrovec <vandrove@vc.cvut.cz>");
MODULE_DESCRIPTION("Matrox G200/G400 Matrox MGA-TVO driver");
MODULE_LICENSE("GPL");
-module_init(matroxfb_maven_init);
-module_exit(matroxfb_maven_exit);
/* we do not have __setup() yet */
^ permalink raw reply related
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Stephen Warren @ 2012-10-08 16:10 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Steffen Trumtrar, linux-fbdev, devicetree-discuss, dri-devel,
Tomi Valkeinen, Laurent Pinchart, linux-media
In-Reply-To: <Pine.LNX.4.64.1210081000530.11034@axis700.grange>
On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
> On Fri, 5 Oct 2012, Stephen Warren wrote:
>
>> On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
>>> Hi Steffen
>>>
>>> Sorry for chiming in so late in the game, but I've long been wanting to
>>> have a look at this and compare with what we do for V4L2, so, this seems a
>>> great opportunity to me:-)
>>>
>>> On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
>>
>>>> diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt
>>
>>>> +timings-subnode
>>>> +---------------
>>>> +
>>>> +required properties:
>>>> + - hactive, vactive: Display resolution
>>>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
>>>> + in pixels
>>>> + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
>>>> + lines
>>>> + - clock: displayclock in Hz
>>>
>>> You're going to hate me for this, but eventually we want to actually
>>> reference clock objects in our DT bindings. For now, even if you don't
>>> want to actually add clock phandles and stuff here, I think, using the
>>> standard "clock-frequency" property would be much better!
>>
>> In a definition of a display timing, we will never need to use the clock
>> binding; the clock binding would be used by the HW module that is
>> generating a timing, not by the timing definition itself.
>
> You mean clock consumer bindings will be in the display device DT node?
> And the display-timings node will be its child?
Yes
...
>>>> + - interlaced (bool)
>>>
>>> Is "interlaced" a property of the hardware, i.e. of the board? Can the
>>> same display controller on one board require interlaced data and on
>>> another board - progressive?
>>
>> Interlace is a property of a display mode. It's quite possible for a
>> particular display controller to switch between interlace and
>> progressive output at run-time. For example, reconfiguring the output
>> between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
>> a built-in LCD display, you're probably always going to be driving the
>> single mode required by the panel, and that mode will likely always be
>> progressive. However, since this binding attempts to describe any
>> display timing, I think we still need this property per mode.
>
> But why do you need this in the DT then at all?
Because the driver for the display controller has no idea what display
or panel will be connected to it.
> If it's fixed, as required
> per display controller, then its driver will know it. If it's runtime
> configurable, then it's a purely software parameter and doesn't depend on
> the board?
interlace-vs-progressive isn't "fixed, as required per display
controller", but is a property of the mode being sent by the display
controller, and the requirements for that mode are driven by the
panel/display connected to the display controller, not the display
controller, in general.
...
>>> BTW, I'm not very familiar with display
>>> interfaces, but for interlaced you probably sometimes use a field signal,
>>> whose polarity you also want to specify here? We use a "field-even-active"
>>> integer property for it.
>>
>> I think that's a property of the display controller itself, rather than
>> an individual mode, although I'm not 100% certain. My assertion is that
>> the physical interface that the display controller is driving will
>> determine whether embedded or separate sync is used, and in the separate
>> sync case, how the field signal is defined, and that all interlace modes
>> driven over that interface will use the same field signal definition.
>
> In general, I might be misunderstanding something, but don't we have to
> distinguish between 2 types of information about display timings: (1) is
> defined by the display controller requirements, is known to the display
> driver and doesn't need to be present in timings DT. We did have some of
> these parameters in board data previously, because we didn't have proper
> display controller drivers...
Yes, there probably is data of that kind, but the display mode timings
binding is only address standardized display timings information, not
controller-specific information, and hence doesn't cover this case.
> (2) is board specific configuration, and is
> such it has to be present in DT.
Certainly, yes.
> In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
> to be present in DT?
I don't believe so.
^ permalink raw reply
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Stephen Warren @ 2012-10-08 16:12 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, devicetree-discuss, dri-devel, Laurent Pinchart,
Steffen Trumtrar, Guennadi Liakhovetski, linux-media
In-Reply-To: <1349698816.9437.5.camel@deskari>
On 10/08/2012 06:20 AM, Tomi Valkeinen wrote:
> On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
>> On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
>>> On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski
>>> wrote:
...
>>> Of course, if this is about describing the hardware, the
>>> default-mode property doesn't really fit in...
>>
>> Maybe we should rename it to native-mode then ?
>
> Hmm, right, if it means native mode, then it is describing the
> hardware. But would it make sense to require that the native mode
> is the first mode in the list, then? This would make the separate
> default-mode/native-mode property not needed.
I'm not sure if device-tree guarantees that the nodes enumerate in a
specific order. If it does, then that may be a reasonable solution.
^ permalink raw reply
* RE: [PATCH 1/2] da8xx-fb: move panel information from driver to platform file
From: Manjunathappa, Prakash @ 2012-10-08 16:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1349445084-9857-2-git-send-email-prakash.pm@ti.com>
Hi Sekhar,
On Mon, Oct 08, 2012 at 18:10:12, Nori, Sekhar wrote:
> Hi Prakash,
>
> On 10/5/2012 7:21 PM, Manjunathappa, Prakash wrote:
> > Moving panel information from driver to platform file, patch also made
> > compliant to fb_videomode data.
> >
> > Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
>
> Why do you have to do this? Just moving panel data from driver to
> platform code doesn't seem to buy anything.
>
> If you are passed DT data, then use it else continue the existing
> platform data method? Once all the boards using this driver are
> converted to DT, then all the panel information can be removed from
> driver. That will save code.
>
Because of following reasons I moved it out of driver
1)This patch also converts panel information compliant to fb_videomode.
Patch "of: add display helper"[1] under review expects panel data in fb_videomode format.
2)I felt difficult and unclean to have driver supporting both panel data from driver and panel data from DT.
3)This effort will also ease adding DT support of this driver.
[1]http://marc.info/?l=linux-fbdev&m\x134937359209227&w=2
Thanks,
Prakash
> This patch looks like needless churn.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Mitch Bradley @ 2012-10-08 16:34 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart,
Steffen Trumtrar, Guennadi Liakhovetski,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1349686878.3227.40.camel@deskari>
On 10/7/2012 11:01 PM, Tomi Valkeinen wrote:
> On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
>
>> In general, I might be misunderstanding something, but don't we have to
>> distinguish between 2 types of information about display timings: (1) is
>> defined by the display controller requirements, is known to the display
>> driver and doesn't need to be present in timings DT. We did have some of
>> these parameters in board data previously, because we didn't have proper
>> display controller drivers... (2) is board specific configuration, and is
>> such it has to be present in DT.
>>
>> In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
>> to be present in DT?
>
> As I see it, this DT data is about the display (most commonly LCD
> panel), i.e. what video mode(s) the panel supports. If things were done
> my way, the panel's supported timings would be defined in the driver for
> the panel, and DT would be left to describe board specific data, but
> this approach has its benefits.
>
> Thus, if you connect an interlaced panel to your board,
Do interlaced panels exist? I have never seen one.
you need to tell
> the display controller that this panel requires interlace signal. Also,
> pixel clock source doesn't make sense in this context, as this doesn't
> describe the actual used configuration, but only what the panel
> supports.
>
> Of course, if this is about describing the hardware, the default-mode
> property doesn't really fit in...
>
> Tomi
>
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* Re: [PATCH 1/2] OMAP: VRFB: convert vrfb to platform device
From: Tony Lindgren @ 2012-10-08 17:24 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <1349699429-12736-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121008 05:31]:
> This patch converts vrfb library into a platform device, in an effort to
> remove omap dependencies.
>
> The platform device is registered in arch/arm/plat-omap/fb.c and
> assigned resources depending on whether running on omap2 or omap3.
>
> The vrfb driver will parse those resources and use them to access vrfb
> configuration registers and the vrfb virtual rotation areas.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/plat-omap/fb.c | 53 +++++++++++++++++++
> drivers/video/omap2/vrfb.c | 124 +++++++++++++++++++++++++++++++++++++-------
> 2 files changed, 157 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> index dd6f92c..d231912 100644
> --- a/arch/arm/plat-omap/fb.c
> +++ b/arch/arm/plat-omap/fb.c
> @@ -35,6 +35,59 @@
>
> #include <plat/board.h>
>
> +#if defined(CONFIG_OMAP2_VRFB)
> +static const struct resource omap2_vrfb_resources[] = {
> + DEFINE_RES_MEM(0x68008000u, 0x40),
> + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> +};
> +
> +static const struct resource omap3_vrfb_resources[] = {
> + DEFINE_RES_MEM(0x6C000180u, 0xc0),
> + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> + DEFINE_RES_MEM(0xe0000000u, 0x4000000),
> + DEFINE_RES_MEM(0xe4000000u, 0x4000000),
> + DEFINE_RES_MEM(0xe8000000u, 0x4000000),
> + DEFINE_RES_MEM(0xec000000u, 0x4000000),
> + DEFINE_RES_MEM(0xf0000000u, 0x4000000),
> + DEFINE_RES_MEM(0xf4000000u, 0x4000000),
> + DEFINE_RES_MEM(0xf8000000u, 0x4000000),
> + DEFINE_RES_MEM(0xfc000000u, 0x4000000),
> +};
Maybe add comments describing what these register are in case
we have a framework handling them at some point later on?
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> +#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
> +#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
> +#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
> +#define SMS_ROT_VIRT_BASE(rot) (0x1000000 * (rot))
Can you please also remove the old SMS defines and functions
so other code won't start tinkering with them?
> +static int __init vrfb_probe(struct platform_device *pdev)
> +{
> + struct resource *mem;
> + int i;
> +
> + /* first resource is the register res, the rest are vrfb contexts */
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem) {
> + dev_err(&pdev->dev, "can't get vrfb base address\n");
> + return -EINVAL;
> + }
Now that we assume vrfb is the only user of this, so you must do
request_mem_region here as that's the only protection we have.
If that fails here, then we know something is wrong.
> + vrfb_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> + if (!vrfb_base) {
> + dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
> + return -ENOMEM;
> + }
> +
> + num_ctxs = pdev->num_resources - 1;
> +
> + ctxs = devm_kzalloc(&pdev->dev,
> + sizeof(struct vrfb_ctx) * num_ctxs,
> + GFP_KERNEL);
> +
> + if (!ctxs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_ctxs; ++i) {
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> + if (!mem) {
> + dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
> + i);
> + return -EINVAL;
> + }
> +
> + ctxs[i].base = mem->start;
> + }
And request_mem_region must also be done for these registers to make
sure no other code is using them. Again, if it fails, something is
wrong.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 2/2] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tony Lindgren @ 2012-10-08 17:26 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Archit Taneja, Vaibhav Hiremath
In-Reply-To: <1349699429-12736-2-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121008 05:32]:
> Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
> from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Once the request_mem_region in patch 1/2 are handled:
Acked-by: Tony Lindgren <tony@atomide.com>
Also, can you please do a minimal immutable branch on -rc1 that
we both can use? I need these into my cleanup branch for v3.8
merge window.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/2 v6] of: add helper to parse display timings
From: Laurent Pinchart @ 2012-10-08 17:33 UTC (permalink / raw)
To: Stephen Warren
Cc: Guennadi Liakhovetski, Steffen Trumtrar, linux-fbdev,
devicetree-discuss, dri-devel, Tomi Valkeinen, linux-media
In-Reply-To: <5072FAF7.2090900@wwwdotorg.org>
Hi Stephen,
On Monday 08 October 2012 10:10:31 Stephen Warren wrote:
> On 10/08/2012 02:25 AM, Guennadi Liakhovetski wrote:
> > On Fri, 5 Oct 2012, Stephen Warren wrote:
> >> On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
> >>> Hi Steffen
> >>>
> >>> Sorry for chiming in so late in the game, but I've long been wanting to
> >>> have a look at this and compare with what we do for V4L2, so, this seems
> >>> a great opportunity to me:-)
> >>>
> >>> On Thu, 4 Oct 2012, Steffen Trumtrar wrote:
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/video/display-timings.txt
> >>>> b/Documentation/devicetree/bindings/video/display-timings.txt
> >>>>
> >>>> +timings-subnode
> >>>> +---------------
> >>>> +
> >>>> +required properties:
> >>>> + - hactive, vactive: Display resolution
> >>>> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
> >>>> parameters + in pixels
> >>>> + vfront-porch, vback-porch, vsync-len: Vertical display timing
> >>>> parameters in + lines
> >>>> + - clock: displayclock in Hz
> >>>
> >>> You're going to hate me for this, but eventually we want to actually
> >>> reference clock objects in our DT bindings. For now, even if you don't
> >>> want to actually add clock phandles and stuff here, I think, using the
> >>> standard "clock-frequency" property would be much better!
> >>
> >> In a definition of a display timing, we will never need to use the clock
> >> binding; the clock binding would be used by the HW module that is
> >> generating a timing, not by the timing definition itself.
> >
> > You mean clock consumer bindings will be in the display device DT node?
> > And the display-timings node will be its child?
>
> Yes
>
> ...
>
> >>>> + - interlaced (bool)
> >>>
> >>> Is "interlaced" a property of the hardware, i.e. of the board? Can the
> >>> same display controller on one board require interlaced data and on
> >>> another board - progressive?
> >>
> >> Interlace is a property of a display mode. It's quite possible for a
> >> particular display controller to switch between interlace and
> >> progressive output at run-time. For example, reconfiguring the output
> >> between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to
> >> a built-in LCD display, you're probably always going to be driving the
> >> single mode required by the panel, and that mode will likely always be
> >> progressive. However, since this binding attempts to describe any
> >> display timing, I think we still need this property per mode.
> >
> > But why do you need this in the DT then at all?
>
> Because the driver for the display controller has no idea what display
> or panel will be connected to it.
That's right, but with the current common panel framework (WIP, I plan to
resume working on it this week) the display controller will be able to query
the panel for bus configuration parameters (or the other way around, the panel
driver will set the display controller bus configuration). The panel driver
will still need to receive timing information from DT, but it will be possible
to communicate display bus configuration parameters between the panel driver
and the display controller driver.
This being said, I agree that interlaced is a property of the display mode,
not of the display bus (even though the display bus will then be configured
for interlaced data).
> > If it's fixed, as required per display controller, then its driver will
> > know it. If it's runtime configurable, then it's a purely software
> > parameter and doesn't depend on the board?
>
> interlace-vs-progressive isn't "fixed, as required per display
> controller", but is a property of the mode being sent by the display
> controller, and the requirements for that mode are driven by the
> panel/display connected to the display controller, not the display
> controller, in general.
>
> ...
>
> >>> BTW, I'm not very familiar with display interfaces, but for interlaced
> >>> you probably sometimes use a field signal, whose polarity you also want
> >>> to specify here? We use a "field-even-active" integer property for it.
> >>
> >> I think that's a property of the display controller itself, rather than
> >> an individual mode, although I'm not 100% certain. My assertion is that
> >> the physical interface that the display controller is driving will
> >> determine whether embedded or separate sync is used, and in the separate
> >> sync case, how the field signal is defined, and that all interlace modes
> >> driven over that interface will use the same field signal definition.
> >
> > In general, I might be misunderstanding something, but don't we have to
> > distinguish between 2 types of information about display timings: (1) is
> > defined by the display controller requirements, is known to the display
> > driver and doesn't need to be present in timings DT. We did have some of
> > these parameters in board data previously, because we didn't have proper
> > display controller drivers...
>
> Yes, there probably is data of that kind, but the display mode timings
> binding is only address standardized display timings information, not
> controller-specific information, and hence doesn't cover this case.
>
> > (2) is board specific configuration, and is
> > such it has to be present in DT.
>
> Certainly, yes.
>
> > In that way, doesn't "interlaced" belong to type (1) and thus doesn't need
> > to be present in DT?
>
> I don't believe so.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/2 v6] of: add generic videomode description
From: Laurent Pinchart @ 2012-10-08 20:52 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
linux-media, Tomi Valkeinen
In-Reply-To: <20121008124801.GD20800@pengutronix.de>
Hi Steffen,
On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
> > > Get videomode from devicetree in a format appropriate for the
> > > backend. drm_display_mode and fb_videomode are supported atm.
> > > Uses the display signal timings from of_display_timings
> > >
> > > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > ---
> > >
> > > drivers/of/Kconfig | 5 +
> > > drivers/of/Makefile | 1 +
> > > drivers/of/of_videomode.c | 212 +++++++++++++++++++++++++++++++++++
> > > include/linux/of_videomode.h | 41 ++++++++
> > > 4 files changed, 259 insertions(+)
> > > create mode 100644 drivers/of/of_videomode.c
> > > create mode 100644 include/linux/of_videomode.h
[snip]
> > > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> > > new file mode 100644
> > > index 0000000..76ac16e
> > > --- /dev/null
> > > +++ b/drivers/of/of_videomode.c
[snip]
> > > +int videomode_from_timing(struct display_timings *disp, struct
> > > videomode *vm,
> > > + int index)
> > > +{
> > > + struct signal_timing *st = NULL;
> > > +
> > > + if (!vm)
> > > + return -EINVAL;
> > > +
> >
> > What about making vm a mandatory argument ? It looks to me like a caller
> > bug if vm is NULL.
>
> The caller must provide the struct videomode, yes. Wouldn't the kernel hang
> itself with a NULL pointer exception, if I just work with it ?
The kernel would oops, clearly showing the caller that a non-null vm is needed
:-)
> > > + st = display_timings_get(disp, index);
> > > +
> >
> > You can remove the blank line.
> >
> > > + if (!st) {
> > > + pr_err("%s: no signal timings found\n", __func__);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + vm->pixelclock = signal_timing_get_value(&st->pixelclock, 0);
> > > + vm->hactive = signal_timing_get_value(&st->hactive, 0);
> > > + vm->hfront_porch = signal_timing_get_value(&st->hfront_porch, 0);
> > > + vm->hback_porch = signal_timing_get_value(&st->hback_porch, 0);
> > > + vm->hsync_len = signal_timing_get_value(&st->hsync_len, 0);
> > > +
> > > + vm->vactive = signal_timing_get_value(&st->vactive, 0);
> > > + vm->vfront_porch = signal_timing_get_value(&st->vfront_porch, 0);
> > > + vm->vback_porch = signal_timing_get_value(&st->vback_porch, 0);
> > > + vm->vsync_len = signal_timing_get_value(&st->vsync_len, 0);
> > > +
> > > + vm->vah = st->vsync_pol_active_high;
> > > + vm->hah = st->hsync_pol_active_high;
> > > + vm->interlaced = st->interlaced;
> > > + vm->doublescan = st->doublescan;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int
> > > index)
> >
> > I wonder how to avoid abuse of this functions. It's a useful helper for
> > drivers that need to get a video mode once only, but would result in lower
> > performances if a driver calls it for every mode. Drivers must call
> > of_get_display_timing_list instead in that case and case the display
> > timings. I'm wondering whether we should really expose of_get_videomode.
>
> The intent was to let the driver decide. That way all the other overhead may
> be skipped.
My point is that driver writers might just call of_get_videomode() in a loop,
not knowing that it's expensive. I want to avoid that. We need to at least add
kerneldoc to the function stating that this shouldn't be done.
> > > +{
> > > + struct display_timings *disp;
> > > + int ret = 0;
> >
> > No need to assign ret to 0 here.
>
> Ah, yes. Unneeded in this case.
>
> > > +
> > > + disp = of_get_display_timing_list(np);
> > > +
> >
> > You can remove the blank line.
> >
> > > + if (!disp) {
> > > + pr_err("%s: no timings specified\n", __func__);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (index = OF_DEFAULT_TIMING)
> > > + index = disp->default_timing;
> > > +
> > > + ret = videomode_from_timing(disp, vm, index);
> > > +
> >
> > No need for a blank line.
> >
> > > + if (ret)
> > > + return ret;
> > > +
> > > + display_timings_release(disp);
> > > +
> > > + if (!vm) {
> > > + pr_err("%s: could not get videomode %d\n", __func__, index);
> > > + return -EINVAL;
> > > + }
> >
> > This can't happen. If vm is NULL the videomode_from_timing call above will
> > return -EINVAL, and this function will then return immediately without
> > reaching this code block.
>
> Okay.
>
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_get_videomode);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] da8xx-fb: move panel information from driver to platform file
From: Sekhar Nori @ 2012-10-09 6:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1349445084-9857-2-git-send-email-prakash.pm@ti.com>
On 10/8/2012 10:03 PM, Manjunathappa, Prakash wrote:
> Hi Sekhar,
>
> On Mon, Oct 08, 2012 at 18:10:12, Nori, Sekhar wrote:
>> Hi Prakash,
>>
>> On 10/5/2012 7:21 PM, Manjunathappa, Prakash wrote:
>>> Moving panel information from driver to platform file, patch also made
>>> compliant to fb_videomode data.
>>>
>>> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
>>
>> Why do you have to do this? Just moving panel data from driver to
>> platform code doesn't seem to buy anything.
>>
>> If you are passed DT data, then use it else continue the existing
>> platform data method? Once all the boards using this driver are
>> converted to DT, then all the panel information can be removed from
>> driver. That will save code.
>>
>
> Because of following reasons I moved it out of driver
> 1)This patch also converts panel information compliant to fb_videomode.
> Patch "of: add display helper"[1] under review expects panel data in fb_videomode format.
Sounds like this should be a separate patch as this has got nothing to
do with moving panel information to platform code.
> 2)I felt difficult and unclean to have driver supporting both panel data from driver and panel data from DT.
Do you have any code where you tried this? If it is clean enough, can
you post it so we can all see what the alternate looks like?
> 3)This effort will also ease adding DT support of this driver.
It is still not clear to me why exactly it will ease adding DT support.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 2/2 v6] of: add generic videomode description
From: Steffen Trumtrar @ 2012-10-09 7:26 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
linux-media, Tomi Valkeinen
In-Reply-To: <1737299.6PuzOm7XuT@avalon>
Hi Laurent,
On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
>
> On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > >
> > > > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > > ---
> > > >
> > > > drivers/of/Kconfig | 5 +
> > > > drivers/of/Makefile | 1 +
> > > > drivers/of/of_videomode.c | 212 +++++++++++++++++++++++++++++++++++
> > > > include/linux/of_videomode.h | 41 ++++++++
> > > > 4 files changed, 259 insertions(+)
> > > > create mode 100644 drivers/of/of_videomode.c
> > > > create mode 100644 include/linux/of_videomode.h
>
> [snip]
>
> > > > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> > > > new file mode 100644
> > > > index 0000000..76ac16e
> > > > --- /dev/null
> > > > +++ b/drivers/of/of_videomode.c
>
> [snip]
>
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > > + int index)
> > > > +{
> > > > + struct signal_timing *st = NULL;
> > > > +
> > > > + if (!vm)
> > > > + return -EINVAL;
> > > > +
> > >
> > > What about making vm a mandatory argument ? It looks to me like a caller
> > > bug if vm is NULL.
> >
> > The caller must provide the struct videomode, yes. Wouldn't the kernel hang
> > itself with a NULL pointer exception, if I just work with it ?
>
> The kernel would oops, clearly showing the caller that a non-null vm is needed
> :-)
>
Okay. No error checking it is then.
> > > > + st = display_timings_get(disp, index);
> > > > +
> > >
> > > You can remove the blank line.
> > >
> > > > + if (!st) {
> > > > + pr_err("%s: no signal timings found\n", __func__);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + vm->pixelclock = signal_timing_get_value(&st->pixelclock, 0);
> > > > + vm->hactive = signal_timing_get_value(&st->hactive, 0);
> > > > + vm->hfront_porch = signal_timing_get_value(&st->hfront_porch, 0);
> > > > + vm->hback_porch = signal_timing_get_value(&st->hback_porch, 0);
> > > > + vm->hsync_len = signal_timing_get_value(&st->hsync_len, 0);
> > > > +
> > > > + vm->vactive = signal_timing_get_value(&st->vactive, 0);
> > > > + vm->vfront_porch = signal_timing_get_value(&st->vfront_porch, 0);
> > > > + vm->vback_porch = signal_timing_get_value(&st->vback_porch, 0);
> > > > + vm->vsync_len = signal_timing_get_value(&st->vsync_len, 0);
> > > > +
> > > > + vm->vah = st->vsync_pol_active_high;
> > > > + vm->hah = st->hsync_pol_active_high;
> > > > + vm->interlaced = st->interlaced;
> > > > + vm->doublescan = st->doublescan;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int
> > > > index)
> > >
> > > I wonder how to avoid abuse of this functions. It's a useful helper for
> > > drivers that need to get a video mode once only, but would result in lower
> > > performances if a driver calls it for every mode. Drivers must call
> > > of_get_display_timing_list instead in that case and case the display
> > > timings. I'm wondering whether we should really expose of_get_videomode.
> >
> > The intent was to let the driver decide. That way all the other overhead may
> > be skipped.
>
> My point is that driver writers might just call of_get_videomode() in a loop,
> not knowing that it's expensive. I want to avoid that. We need to at least add
> kerneldoc to the function stating that this shouldn't be done.
>
You're right. That should be made clear in the code.
> > > > +{
> > > > + struct display_timings *disp;
> > > > + int ret = 0;
> > >
> > > No need to assign ret to 0 here.
> >
> > Ah, yes. Unneeded in this case.
> >
> > > > +
> > > > + disp = of_get_display_timing_list(np);
> > > > +
> > >
> > > You can remove the blank line.
> > >
> > > > + if (!disp) {
> > > > + pr_err("%s: no timings specified\n", __func__);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (index = OF_DEFAULT_TIMING)
> > > > + index = disp->default_timing;
> > > > +
> > > > + ret = videomode_from_timing(disp, vm, index);
> > > > +
> > >
> > > No need for a blank line.
> > >
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + display_timings_release(disp);
> > > > +
> > > > + if (!vm) {
> > > > + pr_err("%s: could not get videomode %d\n", __func__, index);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > This can't happen. If vm is NULL the videomode_from_timing call above will
> > > return -EINVAL, and this function will then return immediately without
> > > reaching this code block.
> >
> > Okay.
> >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(of_get_videomode);
>
> --
> Regards,
>
> Laurent Pinchart
>
>
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-09 8:55 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <20121008172440.GI3874@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]
On Mon, 2012-10-08 at 10:24 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121008 05:31]:
> > This patch converts vrfb library into a platform device, in an effort to
> > remove omap dependencies.
> >
> > The platform device is registered in arch/arm/plat-omap/fb.c and
> > assigned resources depending on whether running on omap2 or omap3.
> >
> > The vrfb driver will parse those resources and use them to access vrfb
> > configuration registers and the vrfb virtual rotation areas.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/plat-omap/fb.c | 53 +++++++++++++++++++
> > drivers/video/omap2/vrfb.c | 124 +++++++++++++++++++++++++++++++++++++-------
> > 2 files changed, 157 insertions(+), 20 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> > index dd6f92c..d231912 100644
> > --- a/arch/arm/plat-omap/fb.c
> > +++ b/arch/arm/plat-omap/fb.c
> > @@ -35,6 +35,59 @@
> >
> > #include <plat/board.h>
> >
> > +#if defined(CONFIG_OMAP2_VRFB)
> > +static const struct resource omap2_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x68008000u, 0x40),
> > + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> > +};
> > +
> > +static const struct resource omap3_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x6C000180u, 0xc0),
> > + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe0000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe4000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe8000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xec000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf0000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf4000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf8000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xfc000000u, 0x4000000),
> > +};
>
> Maybe add comments describing what these register are in case
> we have a framework handling them at some point later on?
Sure.
> > --- a/drivers/video/omap2/vrfb.c
> > +++ b/drivers/video/omap2/vrfb.c
> > +#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
> > +#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
> > +#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
> > +#define SMS_ROT_VIRT_BASE(rot) (0x1000000 * (rot))
>
> Can you please also remove the old SMS defines and functions
> so other code won't start tinkering with them?
Ok.
> > +static int __init vrfb_probe(struct platform_device *pdev)
> > +{
> > + struct resource *mem;
> > + int i;
> > +
> > + /* first resource is the register res, the rest are vrfb contexts */
> > +
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb base address\n");
> > + return -EINVAL;
> > + }
>
> Now that we assume vrfb is the only user of this, so you must do
> request_mem_region here as that's the only protection we have.
> If that fails here, then we know something is wrong.
Right, I'll add that.
> > + vrfb_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> > + if (!vrfb_base) {
> > + dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + num_ctxs = pdev->num_resources - 1;
> > +
> > + ctxs = devm_kzalloc(&pdev->dev,
> > + sizeof(struct vrfb_ctx) * num_ctxs,
> > + GFP_KERNEL);
> > +
> > + if (!ctxs)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < num_ctxs; ++i) {
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
> > + i);
> > + return -EINVAL;
> > + }
> > +
> > + ctxs[i].base = mem->start;
> > + }
>
> And request_mem_region must also be done for these registers to make
> sure no other code is using them. Again, if it fails, something is
> wrong.
There's already request_mem_region for the VRFB virtual areas, which is
done later when omapfb or somebody else requests a vrfb context with
omap_vrfb_request_ctx(). The memory areas (they are rotated
framebuffers, not registers as such) are not used until then.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] fb: only enable console lock in fb for VGA console
From: Jun Nie @ 2012-10-09 10:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAGA24M+PmObK3ZJWvtNhBzxO4WkGk_xyveQiZNtZe7xGdHrbFw@mail.gmail.com>
2012/9/30 Paul Mundt <lethal@linux-sh.org>:
> On Sat, Sep 29, 2012 at 01:29:17PM +0800, Jun Nie wrote:
>> diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
>> index 1d00736..7759c82 100644
>> --- a/drivers/video/s3fb.c
>> +++ b/drivers/video/s3fb.c
>> @@ -1445,12 +1444,12 @@ static int s3_pci_suspend(struct pci_dev* dev,
>> pm_message_t state)
>>
>> dev_info(info->device, "suspend\n");
>>
>> - console_lock();
>> + fb_fb_console_lock();
>> mutex_lock(&(par->open_lock));
>>
> Compiling is overrated anyways.
>
>> diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
>> index 8e4a446..e266b6b 100644
>> --- a/drivers/video/tmiofb.c
>> +++ b/drivers/video/tmiofb.c
>> @@ -959,7 +958,7 @@ static int tmiofb_suspend(struct platform_device
>> *dev, pm_message_t state)
>> if (cell->suspend)
>> retval = cell->suspend(dev);
>>
>> - console_unlock();
>> + fb_fb_console_unlock();
>>
>> return retval;
>> }
>> @@ -986,7 +985,7 @@ static int tmiofb_resume(struct platform_device *dev)
>>
>> fb_set_suspend(info, 0);
>> out:
>> - console_unlock();
>> + fb_fb_console_unlock();
>> return retval;
>> }
>> #else
>
> Here too.
>
> Turning locks in to no-ops without auditing every single driver's use of
> said lock and converting to something to protect the work being done
> under lock suggests that this conversion is more mechanical than thought
> out beyond your specific use case.
>
> While you've obviously identified a problem that's worth pursuing, it's
> going to take a bit more work than mechanical conversion, and it's going
> to have to be something that's moved towards incrementally. If you
> haven't even compile tested the impacted drivers, it suggests you haven't
> spent a great deal of time thinking about what they are doing under said
> lock, either..
Paul,
Thanks for pointing out the defect in my pacth. I did not compile for
every arch I changed.
I check console_lock usage and find it is used for three category
operations sync, a) console output. b) console configuration(font,
resize, connection, etc). c) FB system internal sync as Benjamin
mentioned. Usage A does not happen frequenty. Usage B is our target.
Usage C happens frequently and it may hold the lock for a long time,
while it is unrelated to console if framebuffer console is disabled.
For any system whose log relay on non-FB console, it may encounter no
log or partial log when panic. So it is common use case.
How do you think below code for this purpose?
#ifndef CONFIG_FRAMEBUFFER_CONSOLE
static DEFINE_MUTEX(fb_lock);
#endif
void fb_console_lock(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE
console_lock();
#else
mutex_lock(&fb_lock);
#endif
}
EXPORT_SYMBOL(fb_console_lock);
void fb_console_unlock(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE
console_unlock();
#else
mutex_unlock(&fb_lock);
#endif
}
EXPORT_SYMBOL(fb_console_unlock);
^ permalink raw reply
* [PATCH] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Shubhrajyoti D @ 2012-10-09 11:49 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: FlorianSchandinat-Mmb7MZpHnFY, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w, Shubhrajyoti D
In-Reply-To: <1347897325-20684-1-git-send-email-shubhrajyoti@ti.com>
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Thanks to Julia Lawall <julia.lawall@lip6.fr> for automating the conversion
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/video/matrox/matroxfb_maven.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 217678e..fb5c123 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -137,8 +137,19 @@ static int* get_ctrl_ptr(struct maven_data* md, int idx) {
static int maven_get_reg(struct i2c_client* c, char reg) {
char dst;
- struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
- { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
+ struct i2c_msg msgs[] = {{
+ .addr = c->addr,
+ .flags = I2C_M_REV_DIR_ADDR,
+ .len = sizeof(reg),
+ .buf = ®
+ },
+ {
+ .addr = c->addr,
+ .flags = I2C_M_RD | I2C_M_NOSTART,
+ .len = sizeof(dst),
+ .buf = &dst
+ }
+ };
s32 err;
err = i2c_transfer(c->adapter, msgs, 2);
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 0/3] OMAP: VRFB: convert to platform device
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
Hi,
This is second version of the patch series. The changes to v1 are:
* request mem region for VRFB registers
* declare VRFB resources with names
* remove unused VRFB code from sdrc
* vrfb is now tristate, so that it can be built as a module
Tomi
Tomi Valkeinen (3):
OMAP: VRFB: convert vrfb to platform device
OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
OMAP: SDRC: remove VRFB code
arch/arm/mach-omap2/sdrc.c | 16 ----
arch/arm/plat-omap/fb.c | 59 ++++++++++++++
arch/arm/plat-omap/include/plat/sdrc.h | 7 --
arch/arm/plat-omap/include/plat/vrfb.h | 66 ---------------
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
drivers/media/video/omap/omap_voutdef.h | 2 +-
drivers/video/omap2/Kconfig | 2 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 2 +-
drivers/video/omap2/vrfb.c | 126 ++++++++++++++++++++++++-----
include/video/omapvrfb.h | 66 +++++++++++++++
13 files changed, 237 insertions(+), 117 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
--
1.7.9.5
^ permalink raw reply
* [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.
The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.
The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/plat-omap/fb.c | 59 +++++++++++++++
arch/arm/plat-omap/include/plat/vrfb.h | 2 +-
drivers/video/omap2/Kconfig | 2 +-
drivers/video/omap2/vrfb.c | 124 ++++++++++++++++++++++++++------
4 files changed, 165 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index dd6f92c..a390784 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -35,6 +35,65 @@
#include <plat/board.h>
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
+
+/*
+ * The first memory resource is the register region for VRFB,
+ * the rest are VRFB virtual memory areas for each VRFB context.
+ */
+
+static const struct resource omap2_vrfb_resources[] = {
+ DEFINE_RES_MEM_NAMED(0x68008000u, 0x40, "vrfb-regs"),
+ DEFINE_RES_MEM_NAMED(0x70000000u, 0x4000000, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x74000000u, 0x4000000, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x78000000u, 0x4000000, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c000000u, 0x4000000, "vrfb-area-3"),
+};
+
+static const struct resource omap3_vrfb_resources[] = {
+ DEFINE_RES_MEM_NAMED(0x6C000180u, 0xc0, "vrfb-regs"),
+ DEFINE_RES_MEM_NAMED(0x70000000u, 0x4000000, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x74000000u, 0x4000000, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x78000000u, 0x4000000, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c000000u, 0x4000000, "vrfb-area-3"),
+ DEFINE_RES_MEM_NAMED(0xe0000000u, 0x4000000, "vrfb-area-4"),
+ DEFINE_RES_MEM_NAMED(0xe4000000u, 0x4000000, "vrfb-area-5"),
+ DEFINE_RES_MEM_NAMED(0xe8000000u, 0x4000000, "vrfb-area-6"),
+ DEFINE_RES_MEM_NAMED(0xec000000u, 0x4000000, "vrfb-area-7"),
+ DEFINE_RES_MEM_NAMED(0xf0000000u, 0x4000000, "vrfb-area-8"),
+ DEFINE_RES_MEM_NAMED(0xf4000000u, 0x4000000, "vrfb-area-9"),
+ DEFINE_RES_MEM_NAMED(0xf8000000u, 0x4000000, "vrfb-area-10"),
+ DEFINE_RES_MEM_NAMED(0xfc000000u, 0x4000000, "vrfb-area-11"),
+};
+
+static int __init omap_init_vrfb(void)
+{
+ struct platform_device *pdev;
+ const struct resource *res;
+ unsigned int num_res;
+
+ if (cpu_is_omap24xx()) {
+ res = omap2_vrfb_resources;
+ num_res = ARRAY_SIZE(omap2_vrfb_resources);
+ } else if (cpu_is_omap34xx()) {
+ res = omap3_vrfb_resources;
+ num_res = ARRAY_SIZE(omap3_vrfb_resources);
+ } else {
+ return 0;
+ }
+
+ pdev = platform_device_register_resndata(NULL, "omapvrfb", -1,
+ res, num_res, NULL, 0);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+ else
+ return 0;
+}
+
+arch_initcall(omap_init_vrfb);
+#endif
+
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
static bool omapfb_lcd_configured;
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
index 3792bde..dafbb77 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,7 +35,7 @@ struct vrfb {
bool yuv_mode;
};
-#ifdef CONFIG_OMAP2_VRFB
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..4700ca9 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -2,7 +2,7 @@ config OMAP2_VRAM
bool
config OMAP2_VRFB
- bool
+ tristate
source "drivers/video/omap2/dss/Kconfig"
source "drivers/video/omap2/omapfb/Kconfig"
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 7e99022..fda45cc 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -26,9 +26,9 @@
#include <linux/io.h>
#include <linux/bitops.h>
#include <linux/mutex.h>
+#include <linux/platform_device.h>
#include <plat/vrfb.h>
-#include <plat/sdrc.h>
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
@@ -36,10 +36,10 @@
#define DBG(format, ...)
#endif
-#define SMS_ROT_VIRT_BASE(context, rot) \
- (((context >= 4) ? 0xD0000000 : 0x70000000) \
- + (0x4000000 * (context)) \
- + (0x1000000 * (rot)))
+#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
+#define SMS_ROT_VIRT_BASE(rot) (0x1000000 * (rot))
#define OMAP_VRFB_SIZE (2048 * 2048 * 4)
@@ -53,10 +53,16 @@
#define SMS_PW_OFFSET 4
#define SMS_PS_OFFSET 0
-#define VRFB_NUM_CTXS 12
/* bitmap of reserved contexts */
static unsigned long ctx_map;
+struct vrfb_ctx {
+ u32 base;
+ u32 physical_ba;
+ u32 control;
+ u32 size;
+};
+
static DEFINE_MUTEX(ctx_lock);
/*
@@ -65,17 +71,32 @@ static DEFINE_MUTEX(ctx_lock);
* we don't need locking, since no drivers will run until after the wake-up
* has finished.
*/
-static struct {
- u32 physical_ba;
- u32 control;
- u32 size;
-} vrfb_hw_context[VRFB_NUM_CTXS];
+
+static void __iomem *vrfb_base;
+
+static int num_ctxs;
+static struct vrfb_ctx *ctxs;
+
+static void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_CONTROL(ctx));
+}
+
+static void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_SIZE(ctx));
+}
+
+static void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_PHYSICAL_BA(ctx));
+}
static inline void restore_hw_context(int ctx)
{
- omap2_sms_write_rot_control(vrfb_hw_context[ctx].control, ctx);
- omap2_sms_write_rot_size(vrfb_hw_context[ctx].size, ctx);
- omap2_sms_write_rot_physical_ba(vrfb_hw_context[ctx].physical_ba, ctx);
+ omap2_sms_write_rot_control(ctxs[ctx].control, ctx);
+ omap2_sms_write_rot_size(ctxs[ctx].size, ctx);
+ omap2_sms_write_rot_physical_ba(ctxs[ctx].physical_ba, ctx);
}
static u32 get_image_width_roundup(u16 width, u8 bytespp)
@@ -196,9 +217,9 @@ void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
control |= VRFB_PAGE_WIDTH_EXP << SMS_PW_OFFSET;
control |= VRFB_PAGE_HEIGHT_EXP << SMS_PH_OFFSET;
- vrfb_hw_context[ctx].physical_ba = paddr;
- vrfb_hw_context[ctx].size = size;
- vrfb_hw_context[ctx].control = control;
+ ctxs[ctx].physical_ba = paddr;
+ ctxs[ctx].size = size;
+ ctxs[ctx].control = control;
omap2_sms_write_rot_physical_ba(paddr, ctx);
omap2_sms_write_rot_size(size, ctx);
@@ -274,11 +295,11 @@ int omap_vrfb_request_ctx(struct vrfb *vrfb)
mutex_lock(&ctx_lock);
- for (ctx = 0; ctx < VRFB_NUM_CTXS; ++ctx)
+ for (ctx = 0; ctx < num_ctxs; ++ctx)
if ((ctx_map & (1 << ctx)) = 0)
break;
- if (ctx = VRFB_NUM_CTXS) {
+ if (ctx = num_ctxs) {
pr_err("vrfb: no free contexts\n");
r = -EBUSY;
goto out;
@@ -293,7 +314,7 @@ int omap_vrfb_request_ctx(struct vrfb *vrfb)
vrfb->context = ctx;
for (rot = 0; rot < 4; ++rot) {
- paddr = SMS_ROT_VIRT_BASE(ctx, rot);
+ paddr = ctxs[ctx].base + SMS_ROT_VIRT_BASE(rot);
if (!request_mem_region(paddr, OMAP_VRFB_SIZE, "vrfb")) {
pr_err("vrfb: failed to reserve VRFB "
"area for ctx %d, rotation %d\n",
@@ -314,3 +335,66 @@ out:
return r;
}
EXPORT_SYMBOL(omap_vrfb_request_ctx);
+
+static int __init vrfb_probe(struct platform_device *pdev)
+{
+ struct resource *mem;
+ int i;
+
+ /* first resource is the register res, the rest are vrfb contexts */
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "can't get vrfb base address\n");
+ return -EINVAL;
+ }
+
+ vrfb_base = devm_request_and_ioremap(&pdev->dev, mem);
+ if (!vrfb_base) {
+ dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
+ return -ENOMEM;
+ }
+
+ num_ctxs = pdev->num_resources - 1;
+
+ ctxs = devm_kzalloc(&pdev->dev,
+ sizeof(struct vrfb_ctx) * num_ctxs,
+ GFP_KERNEL);
+
+ if (!ctxs)
+ return -ENOMEM;
+
+ for (i = 0; i < num_ctxs; ++i) {
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
+ if (!mem) {
+ dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
+ i);
+ return -EINVAL;
+ }
+
+ ctxs[i].base = mem->start;
+ }
+
+ return 0;
+}
+
+static struct platform_driver vrfb_driver = {
+ .driver.name = "omapvrfb",
+};
+
+static int __init vrfb_init(void)
+{
+ return platform_driver_probe(&vrfb_driver, &vrfb_probe);
+}
+
+static void __exit vrfb_exit(void)
+{
+ platform_driver_unregister(&vrfb_driver);
+}
+
+module_init(vrfb_init);
+module_exit(vrfb_exit);
+
+MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@ti.com>");
+MODULE_DESCRIPTION("OMAP VRFB");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren
Cc: Archit Taneja, Tomi Valkeinen, Vaibhav Hiremath
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/plat-omap/include/plat/vrfb.h | 66 -----------------------------
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
drivers/media/video/omap/omap_voutdef.h | 2 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c | 2 +-
drivers/video/omap2/vrfb.c | 2 +-
include/video/omapvrfb.h | 66 +++++++++++++++++++++++++++++
9 files changed, 73 insertions(+), 73 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
deleted file mode 100644
index dafbb77..0000000
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * VRFB Rotation Engine
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRFB_H__
-#define __OMAP_VRFB_H__
-
-#define OMAP_VRFB_LINE_LEN 2048
-
-struct vrfb {
- u8 context;
- void __iomem *vaddr[4];
- unsigned long paddr[4];
- u16 xres;
- u16 yres;
- u16 xoffset;
- u16 yoffset;
- u8 bytespp;
- bool yuv_mode;
-};
-
-#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
-extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp);
-extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
-extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
-extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height,
- unsigned bytespp, bool yuv_mode);
-extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
-extern void omap_vrfb_restore_context(void);
-
-#else
-static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
-static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
-static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp) {}
-static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
- { return 0; }
-static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
- { return 0; }
-static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
-static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
- { return 0; }
-static inline void omap_vrfb_restore_context(void) {}
-#endif
-#endif /* __VRFB_H */
diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
index f721fd2..940f39f 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -45,7 +45,7 @@
#include <media/v4l2-ioctl.h>
#include <plat/dma.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include <video/omapdss.h>
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -17,7 +17,7 @@
#include <media/v4l2-device.h>
#include <plat/dma.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omap_voutdef.h"
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_voutdef.h b/drivers/media/video/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/omap/omap_voutdef.h
@@ -12,7 +12,7 @@
#define OMAP_VOUTDEF_H
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#define YUYV_BPP 2
#define RGB565_BPP 2
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..55a39be 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -30,7 +30,7 @@
#include <linux/export.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include <plat/vram.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index b103793..742a66b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,7 @@
#include <video/omapdss.h>
#include <plat/vram.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c b/drivers/video/omap2/omapfb/omapfb-sysfs.c
index e8d8cc7..17aa174 100644
--- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
@@ -30,7 +30,7 @@
#include <linux/omapfb.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index fda45cc..e4a0450 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -28,7 +28,7 @@
#include <linux/mutex.h>
#include <linux/platform_device.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
new file mode 100644
index 0000000..dafbb77
--- /dev/null
+++ b/include/video/omapvrfb.h
@@ -0,0 +1,66 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRFB_H__
+#define __OMAP_VRFB_H__
+
+#define OMAP_VRFB_LINE_LEN 2048
+
+struct vrfb {
+ u8 context;
+ void __iomem *vaddr[4];
+ unsigned long paddr[4];
+ u16 xres;
+ u16 yres;
+ u16 xoffset;
+ u16 yoffset;
+ u8 bytespp;
+ bool yuv_mode;
+};
+
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
+extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
+extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp);
+extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
+extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
+extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height,
+ unsigned bytespp, bool yuv_mode);
+extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
+extern void omap_vrfb_restore_context(void);
+
+#else
+static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
+static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
+static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
+ u8 bytespp) {}
+static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
+ { return 0; }
+static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
+ { return 0; }
+static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
+ u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
+static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
+ { return 0; }
+static inline void omap_vrfb_restore_context(void) {}
+#endif
+#endif /* __VRFB_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 3/3] OMAP: SDRC: remove VRFB code
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
Now that VRFB driver handles its registers independently, we can remove
the VRFB related code from OMAP's sdrc.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/sdrc.c | 16 ----------------
arch/arm/plat-omap/include/plat/sdrc.h | 7 -------
2 files changed, 23 deletions(-)
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index e3d345f..4282e6e 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -160,19 +160,3 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
sdrc_write_reg(l, SDRC_POWER);
omap2_sms_save_context();
}
-
-void omap2_sms_write_rot_control(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_CONTROL(ctx));
-}
-
-void omap2_sms_write_rot_size(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_SIZE(ctx));
-}
-
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
-}
-
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h b/arch/arm/plat-omap/include/plat/sdrc.h
index 36d6a76..c68bab2 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -94,9 +94,6 @@
/* SMS register offsets - read/write with sms_{read,write}_reg() */
#define SMS_SYSCONFIG 0x010
-#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
-#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
-#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
/* REVISIT: fill in other SMS registers here */
@@ -137,10 +134,6 @@ int omap2_sdrc_get_params(unsigned long r,
void omap2_sms_save_context(void);
void omap2_sms_restore_context(void);
-void omap2_sms_write_rot_control(u32 val, unsigned ctx);
-void omap2_sms_write_rot_size(u32 val, unsigned ctx);
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
-
#ifdef CONFIG_ARCH_OMAP2
struct memory_timings {
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Hiremath, Vaibhav @ 2012-10-09 12:54 UTC (permalink / raw)
To: Valkeinen, Tomi, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, Tony Lindgren
Cc: Taneja, Archit
In-Reply-To: <1349785827-27055-3-git-send-email-tomi.valkeinen@ti.com>
On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote:
> Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
> from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
>
Which baseline you are using? I tried it with linux-omap/master, patch[1/3] is failing -
patching file arch/arm/plat-omap/include/plat/vrfb.h
patching file drivers/media/video/omap/omap_vout.c
Hunk #1 FAILED at 45.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout.c.rej
patching file drivers/media/video/omap/omap_vout_vrfb.c
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout_vrfb.c.rej
patching file drivers/media/video/omap/omap_voutdef.h
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_voutdef.h.rej
patching file drivers/video/omap2/omapfb/omapfb-ioctl.c
patching file drivers/video/omap2/omapfb/omapfb-main.c
Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line).
patching file drivers/video/omap2/omapfb/omapfb-sysfs.c
patching file drivers/video/omap2/vrfb.c
patching file include/video/omapvrfb.h
Note that, the directory structure has been changed in the mainline,
Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/"
You have to rebase the patches and resend it.
Thanks,
Vaibhav
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
> arch/arm/plat-omap/include/plat/vrfb.h | 66 -----------------------------
> drivers/media/video/omap/omap_vout.c | 2 +-
> drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
> drivers/media/video/omap/omap_voutdef.h | 2 +-
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
> drivers/video/omap2/omapfb/omapfb-sysfs.c | 2 +-
> drivers/video/omap2/vrfb.c | 2 +-
> include/video/omapvrfb.h | 66 +++++++++++++++++++++++++++++
> 9 files changed, 73 insertions(+), 73 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
> create mode 100644 include/video/omapvrfb.h
>
> diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h
> deleted file mode 100644
> index dafbb77..0000000
> --- a/arch/arm/plat-omap/include/plat/vrfb.h
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -/*
> - * VRFB Rotation Engine
> - *
> - * Copyright (C) 2009 Nokia Corporation
> - * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License along
> - * with this program; if not, write to the Free Software Foundation, Inc.,
> - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> - */
> -
> -#ifndef __OMAP_VRFB_H__
> -#define __OMAP_VRFB_H__
> -
> -#define OMAP_VRFB_LINE_LEN 2048
> -
> -struct vrfb {
> - u8 context;
> - void __iomem *vaddr[4];
> - unsigned long paddr[4];
> - u16 xres;
> - u16 yres;
> - u16 xoffset;
> - u16 yoffset;
> - u8 bytespp;
> - bool yuv_mode;
> -};
> -
> -#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
> -extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
> -extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
> -extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> - u8 bytespp);
> -extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
> -extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
> -extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> - u16 width, u16 height,
> - unsigned bytespp, bool yuv_mode);
> -extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
> -extern void omap_vrfb_restore_context(void);
> -
> -#else
> -static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
> -static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
> -static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
> - u8 bytespp) {}
> -static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
> - { return 0; }
> -static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
> - { return 0; }
> -static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> - u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
> -static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
> - { return 0; }
> -static inline void omap_vrfb_restore_context(void) {}
> -#endif
> -#endif /* __VRFB_H */
> diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
> index f721fd2..940f39f 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -45,7 +45,7 @@
> #include <media/v4l2-ioctl.h>
>
> #include <plat/dma.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
> #include <video/omapdss.h>
>
> #include "omap_voutlib.h"
> diff --git a/drivers/media/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c
> index 4be26abf6c..6c37f92 100644
> --- a/drivers/media/video/omap/omap_vout_vrfb.c
> +++ b/drivers/media/video/omap/omap_vout_vrfb.c
> @@ -17,7 +17,7 @@
> #include <media/v4l2-device.h>
>
> #include <plat/dma.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #include "omap_voutdef.h"
> #include "omap_voutlib.h"
> diff --git a/drivers/media/video/omap/omap_voutdef.h b/drivers/media/video/omap/omap_voutdef.h
> index 27a95d2..9ccfe1f 100644
> --- a/drivers/media/video/omap/omap_voutdef.h
> +++ b/drivers/media/video/omap/omap_voutdef.h
> @@ -12,7 +12,7 @@
> #define OMAP_VOUTDEF_H
>
> #include <video/omapdss.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #define YUYV_BPP 2
> #define RGB565_BPP 2
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 606b89f..55a39be 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> @@ -30,7 +30,7 @@
> #include <linux/export.h>
>
> #include <video/omapdss.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
> #include <plat/vram.h>
>
> #include "omapfb.h"
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index b103793..742a66b 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -32,7 +32,7 @@
>
> #include <video/omapdss.h>
> #include <plat/vram.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #include "omapfb.h"
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c b/drivers/video/omap2/omapfb/omapfb-sysfs.c
> index e8d8cc7..17aa174 100644
> --- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
> +++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
> @@ -30,7 +30,7 @@
> #include <linux/omapfb.h>
>
> #include <video/omapdss.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #include "omapfb.h"
>
> diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
> index fda45cc..e4a0450 100644
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> @@ -28,7 +28,7 @@
> #include <linux/mutex.h>
> #include <linux/platform_device.h>
>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #ifdef DEBUG
> #define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
> diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
> new file mode 100644
> index 0000000..dafbb77
> --- /dev/null
> +++ b/include/video/omapvrfb.h
> @@ -0,0 +1,66 @@
> +/*
> + * VRFB Rotation Engine
> + *
> + * Copyright (C) 2009 Nokia Corporation
> + * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + */
> +
> +#ifndef __OMAP_VRFB_H__
> +#define __OMAP_VRFB_H__
> +
> +#define OMAP_VRFB_LINE_LEN 2048
> +
> +struct vrfb {
> + u8 context;
> + void __iomem *vaddr[4];
> + unsigned long paddr[4];
> + u16 xres;
> + u16 yres;
> + u16 xoffset;
> + u16 yoffset;
> + u8 bytespp;
> + bool yuv_mode;
> +};
> +
> +#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
> +extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
> +extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
> +extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> + u8 bytespp);
> +extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
> +extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
> +extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> + u16 width, u16 height,
> + unsigned bytespp, bool yuv_mode);
> +extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
> +extern void omap_vrfb_restore_context(void);
> +
> +#else
> +static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
> +static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
> +static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
> + u8 bytespp) {}
> +static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
> + { return 0; }
> +static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
> + { return 0; }
> +static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> + u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
> +static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
> + { return 0; }
> +static inline void omap_vrfb_restore_context(void) {}
> +#endif
> +#endif /* __VRFB_H */
> --
> 1.7.9.5
>
>
^ permalink raw reply
* RE: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tomi Valkeinen @ 2012-10-09 12:57 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Tony Lindgren, Taneja, Archit
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3A082@DBDE01.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
On Tue, 2012-10-09 at 12:54 +0000, Hiremath, Vaibhav wrote:
> On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote:
> > Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
> > from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
> >
>
> Which baseline you are using? I tried it with linux-omap/master, patch[1/3] is failing -
It's based on omapdss master, which is what I've sent in the pull
request for 3.7.
> patching file arch/arm/plat-omap/include/plat/vrfb.h
> patching file drivers/media/video/omap/omap_vout.c
> Hunk #1 FAILED at 45.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout.c.rej
> patching file drivers/media/video/omap/omap_vout_vrfb.c
> Hunk #1 FAILED at 17.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout_vrfb.c.rej
> patching file drivers/media/video/omap/omap_voutdef.h
> Hunk #1 FAILED at 12.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_voutdef.h.rej
> patching file drivers/video/omap2/omapfb/omapfb-ioctl.c
> patching file drivers/video/omap2/omapfb/omapfb-main.c
> Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line).
> patching file drivers/video/omap2/omapfb/omapfb-sysfs.c
> patching file drivers/video/omap2/vrfb.c
> patching file include/video/omapvrfb.h
>
>
>
> Note that, the directory structure has been changed in the mainline,
> Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/"
>
> You have to rebase the patches and resend it.
Yep, I'll rebase it on top of 3.7-rc1 when that's out, so that Tony can
pull that branch into his tree also. I guess the omap_vout changes
should apply easily, as it's just include filename changes.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Tomi Valkeinen @ 2012-10-09 13:06 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20121005164308.GM3874@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]
On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
> Looks like somehow also output_size won't change when changing
> display output from DVI to HDMI.
>
> If I boot with DVI panel at 1600x1200, then try to switch to the
> HDMI monitor with the following script:
>
> #!/bin/sh
>
> export dvi=display0
> export hdmi=display1
> export overlay=overlay0
>
> echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> echo tv > /sys/devices/platform/omapdss/$overlay/manager
> #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> cat /sys/devices/platform/omapdss/$hdmi/timings
> cat /sys/devices/platform/omapdss/$overlay/output_size
>
> I get the following which may provide more clues:
>
> [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.849670] omapdss HDMI error: failed to power on device
> [64370.855407] omapdss error: failed to power on
> [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.880798] omapdss HDMI error: failed to power on device
> [64370.886505] omapdss error: failed to power on
> 85500,1366/70/213/143,768/3/24/3
> 1600,1200
Well, it's not that simple =). There are three things to consider:
- Framebuffer in the sdram. It has xres and yres parameters.
- Overlay, and it's input size (from fb) and output sizes (must fit into
the display).
- Display, which has certain size depending on video mode.
Only VID overlays can have different input and output sizes, GFX overlay
does not support scaling.
In the script above you don't change the fb at all. You can do that with
when the overlay is disabled, for example:
fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
But that only works if there's enough memory allocated for the
framebuffer, but that is the case for you if the fb was bigger
initially. Otherwise you need to set the new size
with /sys/class/graphics/fb0/size before resizing the fb.
And, of course, the framebuffer cannot be in use at that time by, for
example, X.
Yes, it's complex! I hope omapdrm will make all things simple, and we
can forget omapfb. In hindsight, I should've designed omapfb to be much
simpler, and only use gfx overlay. Making it support all overlays is a
never ending source for problems and complexity.
> FYI, I'm also seeing the DVI monitor blank out on it's own for
> about a second or so on regular basis every 10 minutes or so.
> No idea what's causing that, maybe it's a reminder to take
> a short break :)
Well that's something different. I've recently done some testing with
using DSI PLL for generating pixel clock, and I've seen unstabilities
with that. But perhaps there's something else wrong also, even when
using the PRCM for pix clock as in your case.
Does your monitor ever report something like bad signal or such?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for fbdev
From: David Howells @ 2012-10-09 13:30 UTC (permalink / raw)
To: FlorianSchandinat; +Cc: dhowells, linux-fbdev, linux-kernel
Can you merge the following branch into the fbdev tree please.
This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently. After these patches, userspace
headers will be segregated into:
include/uapi/linux/.../foo.h
for the userspace interface stuff, and:
include/linux/.../foo.h
for the strictly kernel internal stuff.
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-fbdev-20121009
for you to fetch changes up to c86cba891a10fdc9c2218973435d0b7d0f9f5cf0:
UAPI: (Scripted) Disintegrate include/video (2012-10-09 11:15:01 +0100)
----------------------------------------------------------------
(from the branch description for disintegrate-fbdev local branch)
clone of "disintegrate-media"
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate include/video
include/uapi/video/Kbuild | 3 +
include/uapi/video/edid.h | 9 ++
include/uapi/video/sisfb.h | 209 +++++++++++++++++++++++++++++++++++++++++++
include/uapi/video/uvesafb.h | 60 +++++++++++++
include/video/Kbuild | 3 -
include/video/edid.h | 7 +-
include/video/sisfb.h | 189 +-------------------------------------
include/video/uvesafb.h | 58 +-----------
8 files changed, 284 insertions(+), 254 deletions(-)
create mode 100644 include/uapi/video/edid.h
create mode 100644 include/uapi/video/sisfb.h
create mode 100644 include/uapi/video/uvesafb.h
.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox