[PATCH] bttv: Filter debugging messages
My logfiles and dmesg output have become almost unreadable due to repeated, almost empty lines. [ 3606.212316] [ 3606.212738] ... [ 3627.177280] [ 3627.15] ... They start one hour after vdr daemon is launched. Each section contains 13 lines and is repeated every 21 seconds. Kernel driver for my AverMedia DVB-T 771 is bttv, kernel is 3.6.6-1-ARCH (Arch Linux). I installed v4l-dvb from git and get the same result but with one line appended to each section [ 3688.860166] [ 3688.860570] [ 3691.188200] dvb_frontend_poll: 8 callbacks suppressed The attached patch suppresses at least the useless output. diff -ur a/drivers/media/pci/bt8xx/bttv-i2c.c b/drivers/media/pci/bt8xx/bttv-i2c.c --- a/drivers/media/pci/bt8xx/bttv-i2c.c 2012-11-22 09:56:25.817307254 +0100 +++ b/drivers/media/pci/bt8xx/bttv-i2c.c 2012-11-22 10:01:46.014371997 +0100 @@ -174,7 +174,7 @@ if (i2c_debug) pr_cont( %02x, msg-buf[cnt]); } - if (!(xmit BT878_I2C_NOSTOP)) + if (i2c_debug !(xmit BT878_I2C_NOSTOP)) pr_cont(\n); return msg-len;
[PATCH v2 1/2] s5p-fimc: Don't use mutex_lock_interruptible() in device release()
Use uninterruptible mutex_lock in the release() file op to make
sure all resources are properly freed when a process is being
terminated. Returning -ERESTARTSYS has no effect for a terminating
process and this caused driver resources not to be released. Not
releasing the buffer queue also prevented other drivers to free
memory, e.g. in MMAP - USERPTR scenario.
This patch is required for stable kernels v3.6+.
Cc: sta...@vger.kernel.org
Reported-by: Kamil Debski k.deb...@samsung.com
Reported-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
- previous patch split in t make it applicable to relevant
stable kernels
drivers/media/platform/s5p-fimc/fimc-capture.c |3 +--
drivers/media/platform/s5p-fimc/fimc-m2m.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 3fc896b..891ee87 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -556,8 +556,7 @@ static int fimc_capture_close(struct file *file)
dbg(pid: %d, state: 0x%lx, task_pid_nr(current), fimc-state);
- if (mutex_lock_interruptible(fimc-lock))
- return -ERESTARTSYS;
+ mutex_lock(fimc-lock);
if (--fimc-vid_cap.refcnt == 0) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index 4500e44..62afed3 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -718,8 +718,7 @@ static int fimc_m2m_release(struct file *file)
dbg(pid: %d, state: 0x%lx, refcnt= %d,
task_pid_nr(current), fimc-state, fimc-m2m.refcnt);
- if (mutex_lock_interruptible(fimc-lock))
- return -ERESTARTSYS;
+ mutex_lock(fimc-lock);
v4l2_m2m_ctx_release(ctx-m2m_ctx);
fimc_ctrls_delete(ctx);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/6] fbmon: add videomode helpers
Hi Steffen,
Sorry, I've just found another small bug below.
On Tuesday 20 November 2012 16:54:53 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 46 ++
include/linux/fb.h|6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..c1939a6 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,51 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ 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);
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ 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;
+ if (vm-de)
+ fbmode-sync |= FB_SYNC_DATA_ENABLE_HIGH_ACT;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+ vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+ vm-vsync_len;
+ fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal);
This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution
is probably to use 64-bit computation.
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..920cbe3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,7 @@
#include linux/backlight.h
#include linux/slab.h
#include asm/io.h
+#include linux/videomode.h
struct vm_area_struct;
struct fb_info;
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode
*modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int
margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter
*adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 3/7] video: add of helper for display timings/videomode
This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified, the first subnode will be used. For cases, where the graphics drivers knows, there can be only one mode description or where the driver only supports one mode, a helper function of_get_videomode is added, that gets a struct videomode from DT. (As this function is implemented in an expensive fashion, it should only be used in the aforementioned case). This also demonstrates how of_display_timings may be utilized. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Stephen Warren swar...@nvidia.com Reviewed-by: Thierry Reding thierry.red...@avionic-design.de Acked-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/video/Kconfig | 15 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 223 drivers/video/of_videomode.c | 48 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 18 ++ 7 files changed, 433 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..2b25d58 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,107 @@ +display-timings bindings + + +display-timings node + + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +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-frequency: display clock in Hz + +optional properties: + - hsync-active: Hsync pulse is active low/high/ignored + - vsync-active: Vsync pulse is active low/high/ignored + - de-active: Data-Enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ + non-inverted (active on rising edge)/ +ignored (ignore property) + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + - doubleclk (bool) + +All the optional properties that are not bool follow the following logic: +1: high active +0: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The devicetree +representation corresponds to the one commonly found in datasheets for displays. +If a display supports multiple signal timings, the native-mode can be specified. + +The parameters are defined as + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |#---+---#|-| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | +
[PATCHv13 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig |6 +++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24 ++
drivers/video/videomode.c | 45 +
include/linux/display_timing.h | 104
include/linux/videomode.h | 52
6 files changed, 233 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/display_timing.h
create mode 100644 include/linux/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/display_timing.h
+#include linux/export.h
+#include linux/slab.h
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp-timings) {
+ unsigned int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+ kfree(disp-timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..86a8558
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,45 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/errno.h
+#include linux/display_timing.h
+#include linux/kernel.h
+#include linux/videomode.h
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, TE_TYP);
+ vm-hactive =
[PATCHv13 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 42 +-
include/linux/fb.h|6 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index a6a564d..cd0a035 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,7 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
-#include linux/videomode.h
+#include linux/of_videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1416,6 +1416,46 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n,
+m-xres, m-yres, m-refresh, 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);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(const struct device_node *np, struct fb_videomode *fb,
+ unsigned int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_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_fb_videomode);
+#endif
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 4404ec2..43a2f81 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(const struct device_node *np,
+ struct fb_videomode *fb,
+ unsigned int index);
+#endif
#if IS_ENABLED(CONFIG_VIDEOMODE)
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |6 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..0073b27 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include linux/videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *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;
+
+ dmode-flags = 0;
+ 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(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..3d0ccaa 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1454,6 +1455,11 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+#endif
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-fimc: Prevent race conditions during subdevs registration
Make sure when fimc and fimc-lite capture video node is registered
it has valid pipeline_ops assigned to it. Otherwise when a video
node is opened right after is was registered there, might be an
attempt to use ops that are just being assigned, after function
v4l2_device_register_subdev() returns.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c |7 ++-
drivers/media/platform/s5p-fimc/fimc-lite.c|3 +++
drivers/media/platform/s5p-fimc/fimc-mdevice.c |4 ++--
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 3d39d97..3fc896b 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1774,9 +1774,13 @@ static int fimc_capture_subdev_registered(struct
v4l2_subdev *sd)
if (ret)
return ret;
+ fimc-pipeline_ops = v4l2_get_subdev_hostdata(sd);
+
ret = fimc_register_capture_device(fimc, sd-v4l2_dev);
- if (ret)
+ if (ret) {
fimc_unregister_m2m_device(fimc);
+ fimc-pipeline_ops = NULL;
+ }
return ret;
}
@@ -1793,6 +1797,7 @@ static void fimc_capture_subdev_unregistered(struct
v4l2_subdev *sd)
if (video_is_registered(fimc-vid_cap.vfd)) {
video_unregister_device(fimc-vid_cap.vfd);
media_entity_cleanup(fimc-vid_cap.vfd.entity);
+ fimc-pipeline_ops = NULL;
}
kfree(fimc-vid_cap.ctx);
fimc-vid_cap.ctx = NULL;
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 9db246b..23f203e 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -1263,10 +1263,12 @@ static int fimc_lite_subdev_registered(struct
v4l2_subdev *sd)
return ret;
video_set_drvdata(vfd, fimc);
+ fimc-pipeline_ops = v4l2_get_subdev_hostdata(sd);
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret 0) {
media_entity_cleanup(vfd-entity);
+ fimc-pipeline_ops = NULL;
return ret;
}
@@ -1285,6 +1287,7 @@ static void fimc_lite_subdev_unregistered(struct
v4l2_subdev *sd)
if (video_is_registered(fimc-vfd)) {
video_unregister_device(fimc-vfd);
media_entity_cleanup(fimc-vfd.entity);
+ fimc-pipeline_ops = NULL;
}
}
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 38ea4d1..df6e6ef 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -352,6 +352,7 @@ static int fimc_register_callback(struct device *dev, void
*p)
sd = fimc-vid_cap.subdev;
sd-grp_id = FIMC_GROUP_ID;
+ v4l2_set_subdev_hostdata(sd, fimc_pipeline_ops);
ret = v4l2_device_register_subdev(fmd-v4l2_dev, sd);
if (ret) {
@@ -360,7 +361,6 @@ static int fimc_register_callback(struct device *dev, void
*p)
return ret;
}
- fimc-pipeline_ops = fimc_pipeline_ops;
fmd-fimc[fimc-id] = fimc;
return 0;
}
@@ -375,6 +375,7 @@ static int fimc_lite_register_callback(struct device *dev,
void *p)
return 0;
fimc-subdev.grp_id = FLITE_GROUP_ID;
+ v4l2_set_subdev_hostdata(fimc-subdev, fimc_pipeline_ops);
ret = v4l2_device_register_subdev(fmd-v4l2_dev, fimc-subdev);
if (ret) {
@@ -384,7 +385,6 @@ static int fimc_lite_register_callback(struct device *dev,
void *p)
return ret;
}
- fimc-pipeline_ops = fimc_pipeline_ops;
fmd-fimc_lite[fimc-index] = fimc;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.7-rc] Samsung SoC media driver fixes
Hi Mauro, The following changes since commit 30677fd9ac7b9a06555318ec4f9a0db39804f9b2: s5p-fimc: Fix potential NULL pointer dereference (2012-11-22 10:15:40 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung media_fixes_for_v3.7 for you to fetch changes up to 28f497f26c67ab734bdb923b457016122368f69a: s5p-mfc: Handle multi-frame input buffer (2012-11-22 15:13:53 +0100) This is a bunch of quite important fixes for the Exynos SoC drivers, please apply for v3.7 if possible. This depends on my previous pull request (I've applied the patches you indicated you take for v3.7 previously to the media_fixes_for_v3.7 branch as well). Arun Kumar K (2): s5p-mfc: Bug fix of timestamp/timecode copy mechanism s5p-mfc: Handle multi-frame input buffer Shaik Ameer Basha (1): exynos-gsc: Fix settings for input and output image RGB type Sylwester Nawrocki (5): s5p-fimc: Prevent race conditions during subdevs registration s5p-fimc: Don't use mutex_lock_interruptible() in device release() fimc-lite: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Add missing video device vfl_dir flag initialization drivers/media/platform/exynos-gsc/gsc-m2m.c |4 ++-- drivers/media/platform/exynos-gsc/gsc-regs.h| 16 drivers/media/platform/s5p-fimc/fimc-capture.c | 10 +++--- drivers/media/platform/s5p-fimc/fimc-lite.c |6 -- drivers/media/platform/s5p-fimc/fimc-m2m.c |3 +-- drivers/media/platform/s5p-fimc/fimc-mdevice.c |4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc.c|7 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |2 +- 8 files changed, 27 insertions(+), 25 deletions(-) --- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 5/7] fbmon: add of_videomode helpers
Hi Steffen,
On Thursday 22 November 2012 17:00:13 Steffen Trumtrar wrote:
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
This patch results in the following build warning:
drivers/video/fbmon.c: In function 'of_get_fb_videomode':
drivers/video/fbmon.c:1445: warning: passing argument 1 of 'of_get_videomode'
discards qualifiers from pointer target type
include/linux/of_videomode.h:15: note: expected 'struct device_node *' but
argument is of type 'const struct device_node *'
---
drivers/video/fbmon.c | 42 +-
include/linux/fb.h|6 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index a6a564d..cd0a035 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,7 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
-#include linux/videomode.h
+#include linux/of_videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1416,6 +1416,46 @@ int fb_videomode_from_videomode(const struct
videomode *vm, EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n,
+ m-xres, m-yres, m-refresh, 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);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is
to be + * read from DT. To get multiple modes start with
of_get_display_timings ond + * work with that instead.
+ */
+int of_get_fb_videomode(const struct device_node *np, struct fb_videomode
*fb, +unsigned int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_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_fb_videomode);
+#endif
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 4404ec2..43a2f81 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,11 @@ extern void fb_destroy_modedb(struct fb_videomode
*modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int
margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter
*adapter);
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(const struct device_node *np,
+struct fb_videomode *fb,
+unsigned int index);
+#endif
#if IS_ENABLED(CONFIG_VIDEOMODE)
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 133/493] remove use of __devexit_p
On Monday 19 November 2012 13:21:22 Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. [snip] drivers/media/platform/omap3isp/isp.c| 2 +- Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.7-rc] Samsung SoC media driver fixes
Hi Sylwester, On Thursday 22 November 2012 19:21:42 Sylwester Nawrocki wrote: Hi Mauro, this is what I've just sent (this time from the office my samsung.com account) to linux-media@vger.kernel.org. And can't see it neither on the mailing list nor at the patchwork. Nothing like that coming from you in my mail server logs. It looks like an SMTP server in the chain silently drops the e-mail. On 11/22/2012 07:15 PM, Sylwester Nawrocki wrote: Hi Mauro, The following changes since commit 30677fd9ac7b9a06555318ec4f9a0db39804f9b2: s5p-fimc: Fix potential NULL pointer dereference (2012-11-22 10:15:40 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung media_fixes_for_v3.7 for you to fetch changes up to 28f497f26c67ab734bdb923b457016122368f69a: s5p-mfc: Handle multi-frame input buffer (2012-11-22 15:13:53 +0100) This is a bunch of quite important fixes for the Exynos SoC drivers, please apply for v3.7 if possible. This depends on my previous pull request (I've applied the patches you indicated you take for v3.7 previously to the media_fixes_for_v3.7 branch as well). Arun Kumar K (2): s5p-mfc: Bug fix of timestamp/timecode copy mechanism s5p-mfc: Handle multi-frame input buffer Shaik Ameer Basha (1): exynos-gsc: Fix settings for input and output image RGB type Sylwester Nawrocki (5): s5p-fimc: Prevent race conditions during subdevs registration s5p-fimc: Don't use mutex_lock_interruptible() in device release() fimc-lite: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Add missing video device vfl_dir flag initialization drivers/media/platform/exynos-gsc/gsc-m2m.c |4 ++-- drivers/media/platform/exynos-gsc/gsc-regs.h| 16 drivers/media/platform/s5p-fimc/fimc-capture.c | 10 +++--- drivers/media/platform/s5p-fimc/fimc-lite.c |6 -- drivers/media/platform/s5p-fimc/fimc-m2m.c |3 +-- drivers/media/platform/s5p-fimc/fimc-mdevice.c |4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc.c|7 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |2 +- 8 files changed, 27 insertions(+), 25 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca - ov534: Fix the light frequency filter
(fix lack of signature)
From: Jean-François Moine moin...@free.fr
The exchanges relative to the light frequency filter were adapted
from a description found in a ms-windows driver. It seems that the
registers were the ones of some other sensor.
This patch was done thanks to the documentation of the right
OmniVision sensors.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- val = val ? 0x9e : 0x00;
- if (sd-sensor == SENSOR_OV767x) {
- sccb_reg_write(gspca_dev, 0x2a, 0x00);
- if (val)
- val = 0x9d; /* insert dummy to 25fps for 50Hz */
- }
- sccb_reg_write(gspca_dev, 0x2b, val);
+ if (!val)
+ sccb_reg_write(gspca_dev, 0x13, /* off */
+ sccb_reg_read(gspca_dev, 0x13) ~0x20);
+ else
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
}
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] v4l: There's no __unsigned
On Friday 16 November 2012 22:51:44 Sakari Ailus wrote: Correct a typo. v4l2_plane.m.userptr is unsigned long, not __unsigned long. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/media/v4l/io.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index bcd1c8f7..1565f31 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -736,7 +736,7 @@ should set this to 0./entry /row row entry/entry - entry__unsigned long/entry + entryunsigned long/entry entrystructfielduserptr/structfield/entry entryWhen the memory type in the containing v4l2-buffer; is constantV4L2_MEMORY_USERPTR/constant, this is a userspace -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] exynos-gsc: propagate timestamps from src to dst buffers
Make gsc-m2m propagate the timestamp field from source to destination
buffers
Signed-off-by: John Sheu s...@google.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-gsc/gsc-m2m.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 047f0f0..39dff20 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -99,22 +99,28 @@ static void gsc_m2m_job_abort(void *priv)
gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
}
-static int gsc_fill_addr(struct gsc_ctx *ctx)
+static int gsc_get_bufs(struct gsc_ctx *ctx)
{
struct gsc_frame *s_frame, *d_frame;
- struct vb2_buffer *vb = NULL;
+ struct vb2_buffer *src_vb, *dst_vb;
int ret;
s_frame = ctx-s_frame;
d_frame = ctx-d_frame;
- vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
- ret = gsc_prepare_addr(ctx, vb, s_frame, s_frame-addr);
+ src_vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = gsc_prepare_addr(ctx, src_vb, s_frame, s_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ ret = gsc_prepare_addr(ctx, dst_vb, d_frame, d_frame-addr);
if (ret)
return ret;
- vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
- return gsc_prepare_addr(ctx, vb, d_frame, d_frame-addr);
+ dst_vb-v4l2_buf.timestamp = src_vb-v4l2_buf.timestamp;
+
+ return 0;
}
static void gsc_m2m_device_run(void *priv)
@@ -148,7 +154,7 @@ static void gsc_m2m_device_run(void *priv)
goto put_device;
}
- ret = gsc_fill_addr(ctx);
+ ret = gsc_get_bufs(ctx);
if (ret) {
pr_err(Wrong address);
goto put_device;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] soc-camera + VEU for 3.8
Em Wed, 31 Oct 2012 13:01:19 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro Please pull driver updates for 3.8. Apart from usual soc-camera development this pull request also includes a new VEU MEM2MEM driver. The following changes since commit 016e804df1632fa99b1d96825df4c0db075ac196: media: sh_vou: fix const cropping related warnings (2012-10-31 11:35:51 +0100) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.8 for you to fetch changes up to 223916e1817ce458e947a5f99026ee7d05acaa66: media: add a VEU MEM2MEM format conversion and scaling driver (2012-10-31 12:54:58 +0100) Anatolij Gustschin (4): V4L: soc_camera: allow reading from video device if supported mt9v022: add v4l2 controls for blanking mt9v022: support required register settings in snapshot mode mt9v022: set y_skip_top field to zero as default Frank SchÀfer (1): ov2640: add support for V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_RGB565_2X8_BE Guennadi Liakhovetski (1): media: add a VEU MEM2MEM format conversion and scaling driver Shawn Guo (1): media: mx1_camera: mark the driver BROKEN arch/arm/mach-pxa/pcm990-baseboard.c |6 + drivers/media/i2c/soc_camera/mt9v022.c | 88 ++- drivers/media/i2c/soc_camera/ov2640.c | 49 +- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile|2 + drivers/media/platform/sh_veu.c| 1264 Applied, thanks! Please submit a MAINTAINERS entry for this new driver. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
one tuner of a PVR-500 not returning any data
I have a PVR-500 in a machine here where one of the /dev/video* devices
can successfully be opened and return data while the other can be
opened but returns to data to a read(2). i.e.:
open(/dev/video3, O_RDONLY|O_LARGEFILE) = 3
dup3(3, 0, 0) = 0
close(3)= 0
fstat64(0, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 11), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc7f568) = -1 EINVAL (Invalid
argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7423000
read(0,
and the process blocks there.
Any idea why this might be happening? Kernel is 3.2.0-33-generic which
I believe is 3.2.1 based.
b.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v12 3/6] fbmon: add videomode helpers
On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote: Hi Sascha, On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote: On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote: Hi Steffen, + + htotal = vm-hactive + vm-hfront_porch + vm-hback_porch + +vm-hsync_len; + vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch + +vm-vsync_len; + fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal); This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution is probably to use 64-bit computation. You have displays with a pixelclock 4GHz? vm-pixelclock is expressed in Hz. vm-pixelclock * 1000 will thus overflow if the clock frequency is = ~4.3 MHz. I have displays with a clock frequency higher than that :-) If vm-pixelclock is in Hz, then the * 1000 above is wrong. Sascha -- 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- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/6] fbmon: add videomode helpers
Hi Laurent, On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote: Hi Steffen, + + htotal = vm-hactive + vm-hfront_porch + vm-hback_porch + +vm-hsync_len; + vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch + +vm-vsync_len; + fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal); This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution is probably to use 64-bit computation. You have displays with a pixelclock 4GHz? Sascha -- 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- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types
Hi Hans, On Wed, Nov 21, 2012 at 11:53:02PM +0100, Hans Verkuil wrote: On Wed November 21 2012 20:13:22 Sakari Ailus wrote: Define video buffer flags for different timestamp types. Everything up to now have used either realtime clock or monotonic clock, without a way to tell which clock the timestamp was taken from. Also document that the clock source of the timestamp in the timestamp field depends on buffer flags. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! :-) But see my comments below for a separate matter... --- Since v1.1: - Change the description of the timestamp field; say that the type of the timestamp is dependent on the flags field. Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/io.xml | 53 ++-- Documentation/DocBook/media/v4l/v4l2.xml | 12 ++- include/uapi/linux/videodev2.h |4 ++ 4 files changed, 69 insertions(+), 12 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b5..651ca52 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.8/title + orderedlist +listitem + paraAdded timestamp types to + structfieldflags/structfield field in + structnamev4l2_buffer/structname. See xref + linkend=buffer-flags /./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 7e2f3d7..1243fa1 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,17 +582,19 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the -system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the -nominal frame rate determined by the current video standard in -enqueued order. Applications can for example zero this field to -display frames as soon as possible. The driver stores the time at -which the first data byte was actually sent out in the -structfieldtimestamp/structfield field. This permits -applications to monitor the drift between the video and system -clock./para/entry + entryparaFor input streams this is time when the first data + byte was captured, What should we do with this? In most drivers the timestamp is actually the time that the *last* byte was captured. The reality is that the application doesn't know whether it is the first or the last. One option is to add a new flag for this, or to leave it open. The last makes me uncomfortable, since there can be quite a difference between the time of the first or last byte, and that definitely has an effect on the A/V sync. Very true. I'd also prefer to have this defined so the information would be available to the user space. This is a separate topic that should be handled in a separate patch, but I do think we need to take a closer look at this. I'm not against one more buffer flag to tell which one it is. :-) There are hardly any other options than the frame start and frame end. On the other hand, the FRAME_SYNC event is supported by some drivers and that can be used to obtain the timestamp from frame start. Not all drivers support it nor the applications can be expected to use this just to get a timestamp, though. as returned by the + functionclock_gettime()/function function for the relevant + clock id; see constantV4L2_BUF_FLAG_TIMESTAMP_*/constant in + xref linkend=buffer-flags /. For output streams the data + will not be displayed before this time, secondary to the nominal + frame rate determined by the current video standard in enqueued + order. Applications can for example zero this field to display + frames as soon as possible. There is not a single driver that supports this feature. There is also no way an application can query the driver whether this feature is supported. Personally I don't think this should be the task of a driver anyway: if you want to postpone displaying a frame, then just wait before calling QBUF. Don't add complicated logic in drivers/vb2 where it needs
Re: [GIT PULL] soc-camera + VEU for 3.8
Em Thu, 22 Nov 2012 11:41:05 -0200 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Wed, 31 Oct 2012 13:01:19 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro Please pull driver updates for 3.8. Apart from usual soc-camera development this pull request also includes a new VEU MEM2MEM driver. The following changes since commit 016e804df1632fa99b1d96825df4c0db075ac196: media: sh_vou: fix const cropping related warnings (2012-10-31 11:35:51 +0100) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.8 for you to fetch changes up to 223916e1817ce458e947a5f99026ee7d05acaa66: media: add a VEU MEM2MEM format conversion and scaling driver (2012-10-31 12:54:58 +0100) Anatolij Gustschin (4): V4L: soc_camera: allow reading from video device if supported mt9v022: add v4l2 controls for blanking mt9v022: support required register settings in snapshot mode mt9v022: set y_skip_top field to zero as default Frank SchÀfer (1): ov2640: add support for V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_RGB565_2X8_BE Guennadi Liakhovetski (1): media: add a VEU MEM2MEM format conversion and scaling driver Shawn Guo (1): media: mx1_camera: mark the driver BROKEN arch/arm/mach-pxa/pcm990-baseboard.c |6 + drivers/media/i2c/soc_camera/mt9v022.c | 88 ++- drivers/media/i2c/soc_camera/ov2640.c | 49 +- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile|2 + drivers/media/platform/sh_veu.c| 1264 Applied, thanks! Please submit a MAINTAINERS entry for this new driver. Hmm... there are also some new warnings introduced by it (compiled on x86_64): drivers/media/platform/sh_veu.c: In function 'sh_veu_process': drivers/media/platform/sh_veu.c:269:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat] drivers/media/platform/sh_veu.c:276:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat] drivers/media/platform/sh_veu.c: In function 'sh_veu_probe': drivers/media/platform/sh_veu.c:1199:2: warning: passing argument 1 of 'v4l2_m2m_init' discards 'const' qualifier from pointer target type [enabled by default] In file included from drivers/media/platform/sh_veu.c:27:0: include/media/v4l2-mem2mem.h:125:22: note: expected 'struct v4l2_m2m_ops *' but argument is of type 'const struct v4l2_m2m_ops *' I'll just drop media: add a VEU MEM2MEM format conversion and scaling driver and wait for a warning-free version with a MAINTAINERS entry patch series. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers
Hi Sakari, From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Wednesday, November 21, 2012 8:40 PM Hi Sylwester and Shaik, On Mon, Nov 19, 2012 at 11:06:34PM +0100, Sylwester Nawrocki wrote: On 11/07/2012 07:40 AM, Shaik Ameer Basha wrote: Make gsc-m2m propagate the timestamp field from source to destination buffers We probably need some means for letting know the mem-to-mem drivers and applications whether timestamps are copied from OUTPUT to CAPTURE or not. Timestamps at only OUTPUT interface are normally used to control buffer processing time [1]. struct timeval timestamp For input streams this is the system time (as returned by the gettimeofday() function) when the first data byte was captured. For output streams Thanks for notifying me; this is going to be dependent on the timestamp type. Also most drivers use the time the buffer is finished rather than when the first data byte was captured, but that's separate I think. the data will not be displayed before this time, secondary to the nominal frame rate determined by the current video standard in enqueued order. Applications can for example zero this field to display frames as soon as possible. The driver stores the time at which the first data byte was actually sent out in the timestamp field. This permits applications to monitor the drift between the video and system clock. In some use cases it might be useful to know exact frame processing time, where driver would be filling OUTPUT and CAPTURE value with exact monotonic clock values corresponding to a frame processing start and end time. Shouldn't this always be done in memory-to-memory processing? I could imagine only performance measurements can benefit from other kind of timestamps. We could use different timestamp type to tell the timestamp source isn't any system clock but an input buffer. I hope that by input buffer you mean the OUTPUT buffer. So the timestamp is copied from the OUTPUT buffer to the corresponding CAPTURE buffer. What do you think? Definite yes, if my assumption above is true. I did reply to your RFC suggesting to include this, but got no reply whatsoever. Maybe it got lost somewhere. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.8] [RESEND] V4L2 driver for S3C24XX/S3C64XX SoC series camera interface
Hi Mauro, (resending as it seems the original message didn't make it through to the mailing list) The following changes since commit 2c4e11b7c15af70580625657a154ea7ea70b8c76: [media] siano: fix RC compilation (2012-11-07 11:09:08 +0100) are available in the git repository at: git://linuxtv.org/snawrocki/media.git mainline/s3c-camif This is a V4L2 driver for camera host interface embedded in some older generation Samsung SoC series - S3C24XX and S3C64XX. Some more information about the driver can be found in a cover letter to the first patch version [1]. Sylwester Nawrocki (2): V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface MAINTAINERS: Add entry for S3C24XX/S3C64XX SoC CAMIF driver MAINTAINERS |8 + drivers/media/platform/Kconfig | 12 + drivers/media/platform/Makefile |1 + drivers/media/platform/s3c-camif/Makefile|5 + drivers/media/platform/s3c-camif/camif-capture.c | 1675 ++ drivers/media/platform/s3c-camif/camif-core.c| 662 + drivers/media/platform/s3c-camif/camif-core.h| 393 + drivers/media/platform/s3c-camif/camif-regs.c| 606 drivers/media/platform/s3c-camif/camif-regs.h| 269 include/media/s3c_camif.h| 45 + 10 files changed, 3676 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/s3c-camif/Makefile create mode 100644 drivers/media/platform/s3c-camif/camif-capture.c create mode 100644 drivers/media/platform/s3c-camif/camif-core.c create mode 100644 drivers/media/platform/s3c-camif/camif-core.h create mode 100644 drivers/media/platform/s3c-camif/camif-regs.c create mode 100644 drivers/media/platform/s3c-camif/camif-regs.h create mode 100644 include/media/s3c_camif.h [1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11849.html Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.8] V4L2 driver for S3C24XX/S3C64XX SoC series camera interface
Hi Mauro, The following changes since commit 2c4e11b7c15af70580625657a154ea7ea70b8c76: [media] siano: fix RC compilation (2012-11-07 11:09:08 +0100) are available in the git repository at: git://linuxtv.org/snawrocki/media.git mainline/s3c-camif This is a V4L2 driver for camera host interface embedded in some older generation Samsung SoC series - S3C24XX and S3C64XX. Some more information about the driver can be found in a cover letter to the first patch version [1]. Sylwester Nawrocki (2): V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface MAINTAINERS: Add entry for S3C24XX/S3C64XX SoC CAMIF driver MAINTAINERS |8 + drivers/media/platform/Kconfig | 12 + drivers/media/platform/Makefile |1 + drivers/media/platform/s3c-camif/Makefile|5 + drivers/media/platform/s3c-camif/camif-capture.c | 1675 ++ drivers/media/platform/s3c-camif/camif-core.c| 662 + drivers/media/platform/s3c-camif/camif-core.h| 393 + drivers/media/platform/s3c-camif/camif-regs.c| 606 drivers/media/platform/s3c-camif/camif-regs.h| 269 include/media/s3c_camif.h| 45 + 10 files changed, 3676 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/s3c-camif/Makefile create mode 100644 drivers/media/platform/s3c-camif/camif-capture.c create mode 100644 drivers/media/platform/s3c-camif/camif-core.c create mode 100644 drivers/media/platform/s3c-camif/camif-core.h create mode 100644 drivers/media/platform/s3c-camif/camif-regs.c create mode 100644 drivers/media/platform/s3c-camif/camif-regs.h create mode 100644 include/media/s3c_camif.h [1] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg11849.html Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: i.MX27: Add platform support for IRAM.
On 16 November 2012 13:48, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Nov 05, 2012 at 04:59:44PM +0100, Javier Martin wrote:
Add support for IRAM to i.MX27 non-DT platforms using
iram_init() function.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-imx/mm-imx27.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
index e7e24af..fd2416d 100644
--- a/arch/arm/mach-imx/mm-imx27.c
+++ b/arch/arm/mach-imx/mm-imx27.c
@@ -27,6 +27,7 @@
#include asm/pgtable.h
#include asm/mach/map.h
#include mach/iomux-v1.h
+#include mach/iram.h
/* MX27 memory map definition */
static struct map_desc imx27_io_desc[] __initdata = {
@@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
/* imx27 has the imx21 type audmux */
platform_device_register_simple(imx21-audmux, 0, imx27_audmux_res,
ARRAY_SIZE(imx27_audmux_res));
+ /* imx27 has an iram of 46080 bytes size */
+ iram_init(MX27_IRAM_BASE_ADDR, 46080);
For this rather Philipps sram allocater patches should be used. This
would also solve the problem that mach/iram.h cannot be accessed anymore
in current -next. Fabio already sent a patch addressing this, but I
think we should go for a proper fix rather than just moving iram.h
to include/linux/
Fine, I'll take a look at Philipps' patches.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 133/493] remove use of __devexit_p
On Mon, Nov 19, 2012 at 11:51 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. [snip] drivers/media/platform/davinci/dm355_ccdc.c | 2 +- drivers/media/platform/davinci/dm644x_ccdc.c | 2 +- drivers/media/platform/davinci/isif.c| 2 +- drivers/media/platform/davinci/vpbe_display.c| 2 +- drivers/media/platform/davinci/vpfe_capture.c| 2 +- drivers/media/platform/davinci/vpif.c| 2 +- drivers/media/platform/davinci/vpss.c| 2 +- Acked-by: Prabhakar Lad prabhakar@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Selections targets at V4L2 video mem-to-mem interface
Hi Sylwester,
On Wed, Nov 7, 2012 at 3:52 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
Hi All,
I'd like to clarify the meaning of selection targets on a mem-to-mem video
device, in order to document it and to make sure new m2m drivers get it
right, and also that the existing ones, using originally the crop ioctls,
are converted to the selection ioctls properly.
Until the selections API was introduced we used the CROP ioctls to configure
cropping on OUTPUT buffer queue and composition onto CAPTURE buffer.
Looking at Figure 1.2, [1] it seems obvious that there should be applied
following mapping of the CROP to SELECTION ioctls:
S_CROP(V4L2_BUF_TYPE_VIDEO_OUTPUT) -
S_SELECTION(V4L2_BUF_TYPE_VIDEO_OUTPUT,
V4L2_SEL_TGT_CROP)
S_CROP(V4L2_BUF_TYPE_VIDEO_CAPTURE) -
S_SELECTION(V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_SEL_TGT_COMPOSE)
And that's how selections are currently documented at video output and
capture interfaces:
*Configuration of video output*
For output devices targets and ioctls are used similarly to the video
capture
case. The composing rectangle refers to the insertion of an image into a
video
signal. The cropping rectangles refer to a memory buffer.
*Configuration of video capture*
... The top left corner, width and height of the source rectangle, that is
the
area actually sampled, is given by the V4L2_SEL_TGT_CROP target.
...
The composing targets refer to a memory buffer.
If we apply this mapping, then current VIDIOC_S/G_CROP -
VIDIOC_S/G_SELECTION
ioctl fallback code wouldn't be valid, as we have there, e.g.
static int v4l_s_crop(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
struct v4l2_crop *p = arg;
struct v4l2_selection s = {
.type = p-type,
.r = p-c,
};
if (ops-vidioc_s_crop)
return ops-vidioc_s_crop(file, fh, p);
/* simulate capture crop using selection api */
/* crop means compose for output devices */
if (V4L2_TYPE_IS_OUTPUT(p-type))
s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
else
s.target = V4L2_SEL_TGT_CROP_ACTIVE;
return ops-vidioc_s_selection(file, fh, s);
}
i.e. it does exactly opposite to what we would expect for M2M.
You are right. Instead of handling this confusion in driver, as you
mentioned, we can use
vfl_dir field to select the target before sending it to the driver.
apart from using this vfl_dir field, I can't able to see any other
solution here.
Regards,
Shaik Ameer Basha
One possible solution would be to get hold of struct video_device and
do proper targets conversion after checking the vfl_dir field.
Does anyone have suggestions on this ?
BTW, we still have some V4L2_SEL_TGT*_ACTIVE symbols left, I'll write
a patch to clean this up.
[1] http://hverkuil.home.xs4all.nl/spec/media.html#idp9025504
[2] http://hverkuil.home.xs4all.nl/spec/media.html#idp9031840
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] s5p-mfc: Flush DPB buffers during stream off
Flushing of delay DPB buffers have to be done during stream off.
In MFC v6, it is done with a risc to host command.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Arun Mankuzhi aru...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c|6 ++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 15 +--
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 17 +++--
4 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d3cd738..b73b6f2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -691,6 +691,12 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
s5p_mfc_handle_stream_complete(ctx, reason, err);
break;
+ case S5P_MFC_R2H_CMD_DPB_FLUSH_RET:
+ clear_work_bit(ctx);
+ ctx-state = MFCINST_RUNNING;
+ wake_up(ctx-queue);
+ goto irq_cleanup_hw;
+
default:
mfc_debug(2, Unknown int reason\n);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index f02e049..3b9b600 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -145,6 +145,7 @@ enum s5p_mfc_inst_state {
MFCINST_RETURN_INST,
MFCINST_ERROR,
MFCINST_ABORT,
+ MFCINST_FLUSH,
MFCINST_RES_CHANGE_INIT,
MFCINST_RES_CHANGE_FLUSH,
MFCINST_RES_CHANGE_END,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index eb6a70b..4ba62f6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -977,24 +977,35 @@ static int s5p_mfc_stop_streaming(struct vb2_queue *q)
S5P_MFC_R2H_CMD_FRAME_DONE_RET, 0);
aborted = 1;
}
- spin_lock_irqsave(dev-irqlock, flags);
if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ spin_lock_irqsave(dev-irqlock, flags);
s5p_mfc_hw_call(dev-mfc_ops, cleanup_queue, ctx-dst_queue,
ctx-vq_dst);
INIT_LIST_HEAD(ctx-dst_queue);
ctx-dst_queue_cnt = 0;
ctx-dpb_flush_flag = 1;
ctx-dec_dst_flag = 0;
+ spin_unlock_irqrestore(dev-irqlock, flags);
+ if (IS_MFCV6(dev) (ctx-state == MFCINST_RUNNING)) {
+ ctx-state = MFCINST_FLUSH;
+ set_work_bit_irqsave(ctx);
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
+ if (s5p_mfc_wait_for_done_ctx(ctx,
+ S5P_MFC_R2H_CMD_DPB_FLUSH_RET, 0))
+ mfc_err(Err flushing buffers\n);
+ }
}
if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ spin_lock_irqsave(dev-irqlock, flags);
s5p_mfc_hw_call(dev-mfc_ops, cleanup_queue, ctx-src_queue,
ctx-vq_src);
INIT_LIST_HEAD(ctx-src_queue);
ctx-src_queue_cnt = 0;
+ spin_unlock_irqrestore(dev-irqlock, flags);
}
if (aborted)
ctx-state = MFCINST_RUNNING;
- spin_unlock_irqrestore(dev-irqlock, flags);
return 0;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 3a8cfd9..a47e6db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1253,12 +1253,14 @@ int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
static inline void s5p_mfc_set_flush(struct s5p_mfc_ctx *ctx, int flush)
{
struct s5p_mfc_dev *dev = ctx-dev;
- unsigned int dpb;
- if (flush)
- dpb = READL(S5P_FIMV_SI_CH0_DPB_CONF_CTRL) | (1 14);
- else
- dpb = READL(S5P_FIMV_SI_CH0_DPB_CONF_CTRL) ~(1 14);
- WRITEL(dpb, S5P_FIMV_SI_CH0_DPB_CONF_CTRL);
+
+ if (flush) {
+ dev-curr_ctx = ctx-num;
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ WRITEL(ctx-inst_no, S5P_FIMV_INSTANCE_ID_V6);
+ s5p_mfc_hw_call(dev-mfc_cmds, cmd_host2risc, dev,
+ S5P_FIMV_H2R_CMD_FLUSH_V6, NULL);
+ }
}
/* Decode a single frame */
@@ -1656,6 +1658,9 @@ void s5p_mfc_try_run_v6(struct s5p_mfc_dev *dev)
case MFCINST_HEAD_PARSED:
ret = s5p_mfc_run_init_dec_buffers(ctx);
break;
+
[PATCH] s5p-mfc: Context handling in open() bugfix
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d5182d6..31eeb03 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -856,16 +856,16 @@ err_queue_init:
s5p_mfc_deinit_hw(dev);
err_init_hw:
err_load_fw:
- dev-ctx[ctx-num] = NULL;
- del_timer_sync(dev-watchdog_timer);
err_pwr_enable:
if (dev-num_inst == 1) {
if (s5p_mfc_power_off() 0)
mfc_err(power off failed\n);
+ del_timer_sync(dev-watchdog_timer);
}
err_ctrls_setup:
s5p_mfc_dec_ctrls_delete(ctx);
err_bad_node:
+ dev-ctx[ctx-num] = NULL;
err_no_ctx:
v4l2_fh_del(ctx-fh);
v4l2_fh_exit(ctx-fh);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/6] fbmon: add videomode helpers
Hi Sascha, On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote: On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote: Hi Steffen, + + htotal = vm-hactive + vm-hfront_porch + vm-hback_porch + + vm-hsync_len; + vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch + + vm-vsync_len; + fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal); This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution is probably to use 64-bit computation. You have displays with a pixelclock 4GHz? vm-pixelclock is expressed in Hz. vm-pixelclock * 1000 will thus overflow if the clock frequency is = ~4.3 MHz. I have displays with a clock frequency higher than that :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/6] fbmon: add videomode helpers
On Thursday 22 November 2012 09:53:42 Sascha Hauer wrote: On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote: On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote: On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote: Hi Steffen, + + htotal = vm-hactive + vm-hfront_porch + vm-hback_porch + + vm-hsync_len; + vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch + + vm-vsync_len; + fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal); This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution is probably to use 64-bit computation. You have displays with a pixelclock 4GHz? vm-pixelclock is expressed in Hz. vm-pixelclock * 1000 will thus overflow if the clock frequency is = ~4.3 MHz. I have displays with a clock frequency higher than that :-) If vm-pixelclock is in Hz, then the * 1000 above is wrong. My bad, I though refresh was expressed in mHz. So yes, the above computation is wrong. BTW it seems that the refreshrate field in struct videomode isn't used. It should then be removed. I've just realized that the struct videomode fields are not documented. kerneldoc in include/linux/videomode.h would be a good addition. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.2 1/4] v4l: Define video buffer flags for timestamp types
On Wed November 21 2012 20:13:22 Sakari Ailus wrote: Define video buffer flags for different timestamp types. Everything up to now have used either realtime clock or monotonic clock, without a way to tell which clock the timestamp was taken from. Also document that the clock source of the timestamp in the timestamp field depends on buffer flags. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com But see my comments below for a separate matter... --- Since v1.1: - Change the description of the timestamp field; say that the type of the timestamp is dependent on the flags field. Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/io.xml | 53 ++-- Documentation/DocBook/media/v4l/v4l2.xml | 12 ++- include/uapi/linux/videodev2.h |4 ++ 4 files changed, 69 insertions(+), 12 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b5..651ca52 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.8/title + orderedlist +listitem + paraAdded timestamp types to + structfieldflags/structfield field in + structnamev4l2_buffer/structname. See xref + linkend=buffer-flags /./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 7e2f3d7..1243fa1 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,17 +582,19 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the -system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the -nominal frame rate determined by the current video standard in -enqueued order. Applications can for example zero this field to -display frames as soon as possible. The driver stores the time at -which the first data byte was actually sent out in the -structfieldtimestamp/structfield field. This permits -applications to monitor the drift between the video and system -clock./para/entry + entryparaFor input streams this is time when the first data + byte was captured, What should we do with this? In most drivers the timestamp is actually the time that the *last* byte was captured. The reality is that the application doesn't know whether it is the first or the last. One option is to add a new flag for this, or to leave it open. The last makes me uncomfortable, since there can be quite a difference between the time of the first or last byte, and that definitely has an effect on the A/V sync. This is a separate topic that should be handled in a separate patch, but I do think we need to take a closer look at this. as returned by the + functionclock_gettime()/function function for the relevant + clock id; see constantV4L2_BUF_FLAG_TIMESTAMP_*/constant in + xref linkend=buffer-flags /. For output streams the data + will not be displayed before this time, secondary to the nominal + frame rate determined by the current video standard in enqueued + order. Applications can for example zero this field to display + frames as soon as possible. There is not a single driver that supports this feature. There is also no way an application can query the driver whether this feature is supported. Personally I don't think this should be the task of a driver anyway: if you want to postpone displaying a frame, then just wait before calling QBUF. Don't add complicated logic in drivers/vb2 where it needs to hold buffers back if the time hasn't been reached yet. What might be much more interesting for output devices is if the timestamp field is filled in with the expected display time on return of QBUF. That would be very useful for regulating the flow of new frames. What do you think? The driver stores the time at which + the first data byte was actually sent out in the + structfieldtimestamp/structfield field. Same problem as with the capture time: does the timestamp refer to the first or last byte that's sent out? I think all output drivers set it to the time of the last byte (== when the DMA of the
Re: [GIT PULL FOR 3.8] V4L2 driver for S3C24XX/S3C64XX SoC series camera interface
Hi Mauro,
On 11/21/2012 10:31 PM, Sylwester Nawrocki wrote:
The following changes since commit
2c4e11b7c15af70580625657a154ea7ea70b8c76:
[media] siano: fix RC compilation (2012-11-07 11:09:08 +0100)
are available in the git repository at:
git://linuxtv.org/snawrocki/media.git mainline/s3c-camif
I've found a bug and have updated this branch:
The following changes since commit 2c4e11b7c15af70580625657a154ea7ea70b8c76:
[media] siano: fix RC compilation (2012-11-07 11:09:08 +0100)
are available in the git repository at:
git://linuxtv.org/snawrocki/media.git mainline/s3c-camif
Sylwester Nawrocki (2):
V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface
MAINTAINERS: Add entry for S3C24XX/S3C64XX SoC CAMIF driver
MAINTAINERS |8 +
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/s3c-camif/Makefile|5 +
drivers/media/platform/s3c-camif/camif-capture.c | 1672
++
drivers/media/platform/s3c-camif/camif-core.c| 662 +
drivers/media/platform/s3c-camif/camif-core.h| 393 +
drivers/media/platform/s3c-camif/camif-regs.c| 606
drivers/media/platform/s3c-camif/camif-regs.h| 269
include/media/s3c_camif.h| 45 +
10 files changed, 3673 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/platform/s3c-camif/Makefile
create mode 100644 drivers/media/platform/s3c-camif/camif-capture.c
create mode 100644 drivers/media/platform/s3c-camif/camif-core.c
create mode 100644 drivers/media/platform/s3c-camif/camif-core.h
create mode 100644 drivers/media/platform/s3c-camif/camif-regs.c
create mode 100644 drivers/media/platform/s3c-camif/camif-regs.h
create mode 100644 include/media/s3c_camif.h
And here is the diff:
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index ef0b0ed..0812e2e 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -599,8 +599,7 @@ static int s3c_camif_close(struct file *file)
pr_debug([vp%d] state: %#x, owner: %p, pid: %d\n, vp-id,
vp-state, vp-owner, task_pid_nr(current));
- if (mutex_lock_interruptible(camif-lock))
- return -ERESTARTSYS;
+ mutex_lock(camif-lock);
if (vp-owner == file-private_data) {
camif_stop_capture(vp);
@@ -624,9 +623,7 @@ static unsigned int s3c_camif_poll(struct file *file,
struct camif_dev *camif = vp-camif;
int ret;
- if (mutex_lock_interruptible(camif-lock))
- return -ERESTARTSYS;
-
+ mutex_lock(camif-lock);
if (vp-owner vp-owner != file-private_data)
ret = -EBUSY;
else
---
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.7-rc] Samsung SoC media driver fixes
Hi Laurent. On 11/22/2012 07:55 PM, Laurent Pinchart wrote: On Thursday 22 November 2012 19:21:42 Sylwester Nawrocki wrote: Hi Mauro, this is what I've just sent (this time from the office my samsung.com account) to linux-media@vger.kernel.org. And can't see it neither on the mailing list nor at the patchwork. Nothing like that coming from you in my mail server logs. It looks like an SMTP server in the chain silently drops the e-mail. Thanks for checking it. It seems the vger mailing list are working now, and nothing got lost, just delayed for 1 day or so. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Nov 22 19:00:22 CET 2012 git hash:304a0807a22852fe3095a62c24b25c4d0e16d003 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers
Hi Kamil, On Thu, Nov 22, 2012 at 10:32:09AM +0100, Kamil Debski wrote: Hi Sakari, From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Wednesday, November 21, 2012 8:40 PM Hi Sylwester and Shaik, On Mon, Nov 19, 2012 at 11:06:34PM +0100, Sylwester Nawrocki wrote: On 11/07/2012 07:40 AM, Shaik Ameer Basha wrote: Make gsc-m2m propagate the timestamp field from source to destination buffers We probably need some means for letting know the mem-to-mem drivers and applications whether timestamps are copied from OUTPUT to CAPTURE or not. Timestamps at only OUTPUT interface are normally used to control buffer processing time [1]. struct timeval timestamp For input streams this is the system time (as returned by the gettimeofday() function) when the first data byte was captured. For output streams Thanks for notifying me; this is going to be dependent on the timestamp type. Also most drivers use the time the buffer is finished rather than when the first data byte was captured, but that's separate I think. the data will not be displayed before this time, secondary to the nominal frame rate determined by the current video standard in enqueued order. Applications can for example zero this field to display frames as soon as possible. The driver stores the time at which the first data byte was actually sent out in the timestamp field. This permits applications to monitor the drift between the video and system clock. In some use cases it might be useful to know exact frame processing time, where driver would be filling OUTPUT and CAPTURE value with exact monotonic clock values corresponding to a frame processing start and end time. Shouldn't this always be done in memory-to-memory processing? I could imagine only performance measurements can benefit from other kind of timestamps. We could use different timestamp type to tell the timestamp source isn't any system clock but an input buffer. I hope that by input buffer you mean the OUTPUT buffer. So the timestamp is copied from the OUTPUT buffer to the corresponding CAPTURE buffer. Correct. Input for the device. I think the OMAP 3 ISP also uses these names; should it, that's another question. OUTPUT and CAPTURE are good. What do you think? Definite yes, if my assumption above is true. I did reply to your RFC suggesting to include this, but got no reply whatsoever. Maybe it got lost somewhere. Could be. Anyway, I think we can then say that we agree. :-) Who will write the patch? :-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca - ov534: Fix the light frequency filter.
From: Jean-François Moine moin...@free.fr
The exchanges relative to the light frequency filter were adapted
from a description found in a ms-windows driver. It seems that the
registers were the ones of some other sensor.
This patch was done thanks to the documentation of the right
OmniVision sensors.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- val = val ? 0x9e : 0x00;
- if (sd-sensor == SENSOR_OV767x) {
- sccb_reg_write(gspca_dev, 0x2a, 0x00);
- if (val)
- val = 0x9d; /* insert dummy to 25fps for 50Hz */
- }
- sccb_reg_write(gspca_dev, 0x2b, val);
+ if (!val)
+ sccb_reg_write(gspca_dev, 0x13, /* off */
+ sccb_reg_read(gspca_dev, 0x13) ~0x20);
+ else
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
}
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers
Hi Sakari, On 11/21/2012 08:39 PM, Sakari Ailus wrote: Hi Sylwester and Shaik, On Mon, Nov 19, 2012 at 11:06:34PM +0100, Sylwester Nawrocki wrote: On 11/07/2012 07:40 AM, Shaik Ameer Basha wrote: Make gsc-m2m propagate the timestamp field from source to destination buffers We probably need some means for letting know the mem-to-mem drivers and applications whether timestamps are copied from OUTPUT to CAPTURE or not. Timestamps at only OUTPUT interface are normally used to control buffer processing time [1]. struct timevaltimestamp For input streams this is the system time (as returned by the gettimeofday() function) when the first data byte was captured. For output streams Thanks for notifying me; this is going to be dependent on the timestamp type. Also most drivers use the time the buffer is finished rather than when the first data byte was captured, but that's separate I think. Yes, that's an another ambiguity that might need to be resolved. the data will not be displayed before this time, secondary to the nominal frame rate determined by the current video standard in enqueued order. Applications can for example zero this field to display frames as soon as possible. The driver stores the time at which the first data byte was actually sent out in the timestamp field. This permits applications to monitor the drift between the video and system clock. In some use cases it might be useful to know exact frame processing time, where driver would be filling OUTPUT and CAPTURE value with exact monotonic clock values corresponding to a frame processing start and end time. Shouldn't this always be done in memory-to-memory processing? I could imagine only performance measurements can benefit from other kind of timestamps. We could use different timestamp type to tell the timestamp source isn't any system clock but an input buffer. What do you think? Yes, it makes sense to me to report with the buffer flag that the source of timestamp is just an OUTPUT buffer. At least this would solve the reporting part of the issue. Oh wait, could applications tell by setting buffer flag what timestamping behaviour they expect from a driver ? I can't see an important use of timestamping m2m buffers at device drivers. Performance measurement can probably be done in user space with sufficient accuracy as well. However, it wouldn't be difficult for drivers to implement multiple time stamping techniques, e.g. OUTPUT - CAPTURE timestamp copying or getting timestamps from monotonic clock at frame processing beginning and end for OUTPUT and CAPTURE respectively. I believe the buffer flags might be a good solution. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 0/5] Common Display Framework
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Hi everybody, Here's the second RFC of what was previously known as the Generic Panel Framework. I won't repeat all the background information from the first version here, you can read it at http://lwn.net/Articles/512363/. Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. After discussing the Generic Panel Framework at Linaro Connect we came to the conclusion that panel is too limiting a name. In addition to panel drivers we also want to share transmitter and bridge drivers between DRM and FBDEV. I have thus introduced the concept of a display entity in this version to represent any hardware block that sources, processes or sinks display-related video streams. This patch set implements the Common Display Framework (CDF). Display entities are connected to at least one video data bus, and optionally to a control bus. The video data busses carry display-related video data out of sources (such as a CRTC in a display controller) to sinks (such as a panel or a monitor), optionally going through transmitters, encoders, decoders, bridges or other similar devices. A CRTC or a panel will usually be connected to a single data bus, while an encoder or a transmitter will be connected to two data busses. While some display entities don't require any configuration (DPI panels are a good example), many of them are connected to a control bus accessible to the CPU. Control requests can be sent on a dedicated control bus (such as I2C or SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To support both options the CDF display entity model separates the control and data busses in different APIs. Display entities are abstract object that must be implemented by a real device. The device sits on its control bus and is registered with the Linux device core and matched with his driver using the control bus specific API. The CDF doesn't create a display entity class or bus, display entity drivers thus standard Linux kernel drivers using existing busses. When a display entity driver probes a device it must create an instance of the display_entity structure, initialize it and register it with the CDF core. The display entity exposes abstract operations through function pointers, and the entity driver must implement those operations. They are divided in two groups, control operations and video operations. Control operations are called by upper-level drivers, usually in response to a request originating from userspace. They control the display entity state and operation. Currently defined control operations are - set_state(), to control the state of the entity (off, standby or on) - update(), to trigger a display update (for entities that implement manual update, such as manual-update panels that store frames in their internal frame buffer) - get_modes(), to retrieve the video modes supported by the entity - get_params(), to retrive the data bus parameters at the entity input (sink) - get_size(), to retrive the entity physical size (applicable to panels only) Video operations are called by downstream entities on upstream entities (from a video data bus point of view) to control the video operation. The only currently defined video operation is - set_stream(), to start (in continuous or single-shot mode) the video stream http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver implemented using the CDF interacts with the other components in the system. The first page shows the panel driver receiving control request from the display controller driver at its top side, usually in response to a DRM or FBDEV API call. It then issues requests on its control bus (several possible control busses are shown on the diagram, the panel driver uses one of them only) and calls video operations of the display controller on its left side to control the video stream. The second page shows a slightly more complex use case, with a display controller that includes an LVDS transceiver (shown as two separate entities on the left hand side), connected to an LVDS to DSI converter that is itself connected to a DSI panel module. The panel module contains a DSI panel controller that drives the LCD panel. While this particular example is probably too theoretical to be found in real devices, it illustrates the concept of display entities chains. The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most
[RFC v2 1/5] video: Add generic display entity core
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig|1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig|4 +
drivers/video/display/Makefile |1 +
drivers/video/display/display-core.c | 362 ++
include/video/display.h | 150 ++
6 files changed, 519 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/Kconfig
create mode 100644 drivers/video/display/Makefile
create mode 100644 drivers/video/display/display-core.c
create mode 100644 include/video/display.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c5b7bcf..e91f03e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2442,6 +2442,7 @@ source drivers/video/omap/Kconfig
source drivers/video/omap2/Kconfig
source drivers/video/exynos/Kconfig
source drivers/video/backlight/Kconfig
+source drivers/video/display/Kconfig
if VT
source drivers/video/console/Kconfig
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b936b00..0a4cfea 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs := $(fb-y)
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
obj-y+= backlight/
+obj-y+= display/
obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+ tristate Display Core
+ ---help---
+ Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
diff --git a/drivers/video/display/display-core.c
b/drivers/video/display/display-core.c
new file mode 100644
index 000..358c089
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,362 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.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.
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/videomode.h
+
+#include video/display.h
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/*
-
+ * Control operations
+ */
+
+/**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See enum display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+ int ret;
+
+ if (entity-state == state)
+ return 0;
+
+ if (!entity-ops.ctrl || !entity-ops.ctrl-set_state)
+ return 0;
+
+ ret = entity-ops.ctrl-set_state(entity, state);
+ if (ret 0)
+ return ret;
+
+ entity-state = state;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame
transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+ if (!entity-ops.ctrl || !entity-ops.ctrl-update)
+ return 0;
+
+ return entity-ops.ctrl-update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity The display entity
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
[RFC v2 4/5] video: panel: Add R61505 panel support
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com The R61505 is a SYS-80 bus panel controller from Renesas. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/video/display/Kconfig|9 + drivers/video/display/Makefile |1 + drivers/video/display/panel-r61505.c | 554 ++ include/video/panel-r61505.h | 27 ++ 4 files changed, 591 insertions(+), 0 deletions(-) create mode 100644 drivers/video/display/panel-r61505.c create mode 100644 include/video/panel-r61505.h diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig index b04c8be..c88999c 100644 --- a/drivers/video/display/Kconfig +++ b/drivers/video/display/Kconfig @@ -18,4 +18,13 @@ config DISPLAY_PANEL_DPI If you are in doubt, say N. +config DISPLAY_PANEL_R61505 + tristate Renesas R61505-based Display Panel + select DISPLAY_MIPI_DBI + ---help--- + Support panels based on the Renesas R61505 panel controller. + Those panels are controlled through a MIPI DBI interface. + + If you are in doubt, say N. + endif # DISPLAY_CORE diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile index 00ef1c2..4c68465 100644 --- a/drivers/video/display/Makefile +++ b/drivers/video/display/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o +obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o diff --git a/drivers/video/display/panel-r61505.c b/drivers/video/display/panel-r61505.c new file mode 100644 index 000..d72d324 --- /dev/null +++ b/drivers/video/display/panel-r61505.c @@ -0,0 +1,554 @@ +/* + * Renesas R61505-based Display Panels + * + * Copyright (C) 2012 Renesas Solutions Corp. + * Based on SuperH MigoR Quarter VGA LCD Panel + * Copyright (C) 2008 Magnus Damm + * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd. + * Copyright (c) 2007 Ujjwal Pande + * + * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.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. + */ + +#include linux/delay.h +#include linux/err.h +#include linux/gpio.h +#include linux/init.h +#include linux/kernel.h +#include linux/module.h +#include linux/slab.h + +#include video/display.h +#include video/mipi-dbi-bus.h +#include video/panel-r61505.h + +#define R61505_DEVICE_CODE 0x +#define R61505_DEVICE_CODE_VALUE 0x1505 +#define R61505_DRIVER_OUTPUT_CONTROL 0x0001 +#define R61505_DRIVER_OUTPUT_CONTROL_SM(1 10) +#define R61505_DRIVER_OUTPUT_CONTROL_SS(1 8) +#define R61505_LCD_WAVEFORM0x0002 +#define R61505_LCD_WAVEFORM_BC0(1 9) +#define R61505_LCD_WAVEFORM_EOR(1 8) +#define R61505_ENTRY_MODE 0x0003 +#define R61505_ENTRY_MODE_TRIREG (1 15) +#define R61505_ENTRY_MODE_DFM (1 14) +#define R61505_ENTRY_MODE_BGR (1 12) +#define R61505_ENTRY_MODE_HWM (1 9) +#define R61505_ENTRY_MODE_ORG (1 7) +#define R61505_ENTRY_MODE_ID1 (1 5) +#define R61505_ENTRY_MODE_ID0 (1 4) +#define R61505_ENTRY_MODE_AM (1 3) +#define R61505_RESIZE_CONTROL 0x0004 +#define R61505_RESIZE_CONTROL_RCV(n) (((n) 3) 8) +#define R61505_RESIZE_CONTROL_RCH(n) (((n) 3) 4) +#define R61505_RESIZE_CONTROL_RSZ_4(3 0) +#define R61505_RESIZE_CONTROL_RSZ_2(1 0) +#define R61505_RESIZE_CONTROL_RSZ_1(0 0) +#define R61505_DISPLAY_CONTROL10x0007 +#define R61505_DISPLAY_CONTROL1_PTDE1 (1 13) +#define R61505_DISPLAY_CONTROL1_PTDE0 (1 12) +#define R61505_DISPLAY_CONTROL1_BASEE (1 8) +#define R61505_DISPLAY_CONTROL1_VON(1 6) +#define R61505_DISPLAY_CONTROL1_GON(1 5) +#define R61505_DISPLAY_CONTROL1_DTE(1 4) +#define R61505_DISPLAY_CONTROL1_COL(1 3) +#define R61505_DISPLAY_CONTROL1_D1 (1 1) +#define R61505_DISPLAY_CONTROL1_D0 (1 0) +#define R61505_DISPLAY_CONTROL20x0008 +#define R61505_DISPLAY_CONTROL2_FP(n) (((n) 0xf) 8) +#define R61505_DISPLAY_CONTROL2_BP(n) (((n) 0xf) 0) +#define R61505_DISPLAY_CONTROL30x0009 +#define R61505_DISPLAY_CONTROL3_PTS(n) (((n) 7) 8) +#define R61505_DISPLAY_CONTROL3_PTG(n) (((n) 3) 3) +#define R61505_DISPLAY_CONTROL3_ICS(n) (((n) 0xf) 0) +#define R61505_DISPLAY_CONTROL40x000a +#define
[RFC v2 5/5] video: panel: Add R61517 panel support
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
The R61517 is a MIPI DBI panel controller from Renesas.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|9 +
drivers/video/display/Makefile |1 +
drivers/video/display/panel-r61517.c | 447 ++
include/video/panel-r61517.h | 28 ++
4 files changed, 485 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/panel-r61517.c
create mode 100644 include/video/panel-r61517.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index c88999c..13b6aaf 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -27,4 +27,13 @@ config DISPLAY_PANEL_R61505
If you are in doubt, say N.
+config DISPLAY_PANEL_R61517
+ tristate Renesas R61517-based Display Panel
+ select DISPLAY_MIPI_DBI
+ ---help---
+ Support panels based on the Renesas R61517 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 4c68465..482bec7 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DISPLAY_CORE) += display-core.o
obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/display/panel-r61517.c
b/drivers/video/display/panel-r61517.c
new file mode 100644
index 000..b4dced4
--- /dev/null
+++ b/drivers/video/display/panel-r61517.c
@@ -0,0 +1,447 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.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.
+ */
+
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/gpio.h
+
+#include video/display.h
+#include video/mipi-dbi-bus.h
+#include video/mipi_display.h
+#include video/panel-r61517.h
+
+struct r61517 {
+ struct display_entity entity;
+ struct mipi_dbi_device *dbi;
+ const struct panel_r61517_platform_data *pdata;
+};
+
+#define to_panel(p)container_of(p, struct r61517, entity)
+
+/*
-
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 cmd)
+{
+ mipi_dbi_write_command(panel-dbi, cmd);
+}
+
+static void r61517_write_data(struct r61517 *panel, u8 data)
+{
+ mipi_dbi_write_data(panel-dbi, data, 1);
+}
+
+static int r61517_read_data(struct r61517 *panel)
+{
+ u8 data;
+ int ret;
+
+ ret = mipi_dbi_read_data(panel-dbi, data, 1);
+ if (ret 0)
+ return ret;
+
+ return data;
+}
+
+static void r61517_write(struct r61517 *panel, u8 reg, const u8 *data,
+size_t len)
+{
+ mipi_dbi_write_command(panel-dbi, reg);
+ mipi_dbi_write_data(panel-dbi, data, len);
+}
+
+static void r61517_write8(struct r61517 *panel, u8 reg, u8 data)
+{
+ r61517_write(panel, reg, data, 1);
+}
+
+static void r61517_write16(struct r61517 *panel, u8 reg, u16 data)
+{
+ u8 buffer[2] = { (data 8) 0xff, (data 0) 0xff };
+
+ r61517_write(panel, reg, buffer, 2);
+}
+
+static void r61517_write32(struct r61517 *panel, u8 reg, u32 data)
+{
+ u8 buffer[4] = { (data 24) 0xff, (data 16) 0xff,
+(data 8) 0xff, (data 0) 0xff };
+
+ r61517_write(panel, reg, buffer, 4);
+}
+
+#define r61517_write_array(p, c, a) \
+ r61517_write((p), (c), (a), ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+ gpio_set_value(panel-pdata-protect, 0); /* PROTECT/ - L */
+ gpio_set_value(panel-pdata-reset, 0); /* LCD_RST/ - L */
+ gpio_set_value(panel-pdata-protect, 1); /* PROTECT/ - H */
+ usleep_range(1100, 1200);
+ gpio_set_value(panel-pdata-reset, 1); /* LCD_RST/ - H */
+ usleep_range(10, 100);
+ gpio_set_value(panel-pdata-protect, 0); /* PROTECT/ - L */
+ msleep(20);
+}
+
+/*
-
+ * Configuration
+ */
+
+static const u8 data_frame_if[] = {
+ 0x02, /* WEMODE: 1=cont,
[RFC v2 3/5] video: display: Add MIPI DBI bus support
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig|4 +
drivers/video/display/Makefile |1 +
drivers/video/display/mipi-dbi-bus.c | 228 ++
include/video/display.h |5 +
include/video/mipi-dbi-bus.h | 125 +++
5 files changed, 363 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 include/video/mipi-dbi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 0f9b990..b04c8be 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -5,6 +5,10 @@ menuconfig DISPLAY_CORE
if DISPLAY_CORE
+config DISPLAY_MIPI_DBI
+ tristate
+ default n
+
config DISPLAY_PANEL_DPI
tristate DPI (Parallel) Display Panels
---help---
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index 47978d4..00ef1c2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/mipi-dbi-bus.c
b/drivers/video/display/mipi-dbi-bus.c
new file mode 100644
index 000..bd39a97
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
@@ -0,0 +1,228 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.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.
+ */
+
+#include linux/device.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/pm.h
+#include linux/pm_runtime.h
+
+#include video/mipi-dbi-bus.h
+
+/*
-
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
+{
+ if (width != 8 width != 16)
+ return -EINVAL;
+
+ dev-data_width = width;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+ return dev-bus-ops-write_command(dev-bus, dev, cmd);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
+
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+ size_t len)
+{
+ return dev-bus-ops-write_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
+
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
+{
+ return dev-bus-ops-read_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
+
+/*
-
+ * Bus type
+ */
+
+static const struct mipi_dbi_device_id *
+mipi_dbi_match_id(const struct mipi_dbi_device_id *id,
+ struct mipi_dbi_device *dev)
+{
+ while (id-name[0]) {
+ if (strcmp(dev-name, id-name) == 0) {
+ dev-id_entry = id;
+ return id;
+ }
+ id++;
+ }
+ return NULL;
+}
+
+static int mipi_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+ struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_drv);
+
+ if (drv-id_table)
+ return mipi_dbi_match_id(drv-id_table, dev) != NULL;
+
+ return (strcmp(dev-name, _drv-name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+ int len = snprintf(buf, PAGE_SIZE, MIPI_DBI_MODULE_PREFIX %s\n,
+ dev-name);
+
+ return (len = PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute mipi_dbi_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL,
+};
+
+static int mipi_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+
+ add_uevent_var(env, MODALIAS=%s%s, MIPI_DBI_MODULE_PREFIX,
+ dev-name);
+ return 0;
+}
+
+static const struct dev_pm_ops mipi_dbi_dev_pm_ops = {
+ .runtime_suspend = pm_generic_runtime_suspend,
+ .runtime_resume = pm_generic_runtime_resume,
+ .runtime_idle = pm_generic_runtime_idle,
+ .suspend = pm_generic_suspend,
+ .resume = pm_generic_resume,
+ .freeze = pm_generic_freeze,
+ .thaw = pm_generic_thaw,
+
[RFC v2 2/5] video: panel: Add DPI panel support
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig | 13 +++
drivers/video/display/Makefile|1 +
drivers/video/display/panel-dpi.c | 147 +
include/video/panel-dpi.h | 24 ++
4 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 include/video/panel-dpi.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..0f9b990 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,16 @@ menuconfig DISPLAY_CORE
tristate Display Core
---help---
Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+ tristate DPI (Parallel) Display Panels
+ ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
+
+ If you are in doubt, say N.
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..47978d4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/panel-dpi.c
b/drivers/video/display/panel-dpi.c
new file mode 100644
index 000..c56197a
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,147 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include video/display.h
+#include video/panel-dpi.h
+
+struct panel_dpi {
+ struct display_entity entity;
+ const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p)container_of(p, struct panel_dpi,
entity)
+
+static const struct display_entity_interface_params panel_dpi_params = {
+ .type = DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+static int panel_dpi_set_state(struct display_entity *entity,
+ enum display_entity_state state)
+{
+ switch (state) {
+ case DISPLAY_ENTITY_STATE_OFF:
+ case DISPLAY_ENTITY_STATE_STANDBY:
+ display_entity_set_stream(entity-source,
+ DISPLAY_ENTITY_STREAM_STOPPED);
+ break;
+
+ case DISPLAY_ENTITY_STATE_ON:
+ display_entity_set_stream(entity-source,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS);
+ break;
+ }
+
+ return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+ const struct videomode **modes)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ *modes = panel-pdata-mode;
+ return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ *width = panel-pdata-width;
+ *height = panel-pdata-height;
+ return 0;
+}
+
+static int panel_dpi_get_params(struct display_entity *entity,
+ struct display_entity_interface_params *params)
+{
+ *params = panel_dpi_params;
+ return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+ .set_state = panel_dpi_set_state,
+ .get_modes = panel_dpi_get_modes,
+ .get_size = panel_dpi_get_size,
+ .get_params = panel_dpi_get_params,
+};
+
+static void panel_dpi_release(struct display_entity *entity)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ kfree(panel);
+}
+
+static int panel_dpi_remove(struct platform_device *pdev)
+{
+ struct panel_dpi *panel = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ display_entity_unregister(panel-entity);
+
+ return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+ const struct panel_dpi_platform_data *pdata = pdev-dev.platform_data;
+ struct panel_dpi *panel;
+ int ret;
+
+ if (pdata == NULL)
+ return -ENODEV;
+
+ panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+ if (panel == NULL)
+ return -ENOMEM;
+
+ panel-pdata = pdata;
+ panel-entity.dev = pdev-dev;
+ panel-entity.release =
Re: [PATCH v2] [media] exynos-gsc: propagate timestamps from src to dst buffers
Hi Shaik, On 11/22/2012 06:25 AM, Shaik Ameer Basha wrote: Make gsc-m2m propagate the timestamp field from source to destination buffers Signed-off-by: John Sheus...@google.com Signed-off-by: Shaik Ameer Bashashaik.am...@samsung.com I've applied this patch to my tree for v3.8. Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 2/6] video: add of helper for videomode
Hi!
On Wed, Nov 21, 2012 at 09:03:38AM -0600, Rob Herring wrote:
On 11/21/2012 05:52 AM, Thierry Reding wrote:
On Wed, Nov 21, 2012 at 12:48:43PM +0100, Steffen Trumtrar wrote:
Hi!
On Wed, Nov 21, 2012 at 10:12:43AM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Tue, Nov 20, 2012 at 21:24:52, Steffen Trumtrar wrote:
+/**
+ * of_get_display_timings - parse all display_timing entries from a
device_node
+ * @np: device_node with the subnodes
+ **/
+struct display_timings *of_get_display_timings(const struct device_node
*np)
+{
+struct device_node *timings_np;
+struct device_node *entry;
+struct device_node *native_mode;
+struct display_timings *disp;
+
+if (!np) {
+pr_err(%s: no devicenode given\n, __func__);
+return NULL;
+}
+
+timings_np = of_find_node_by_name(np, display-timings);
I get below build warnings on this line
drivers/video/of_display_timing.c: In function 'of_get_display_timings':
drivers/video/of_display_timing.c:109:2: warning: passing argument 1 of
'of_find_node_by_name' discards qualifiers from pointer target type
include/linux/of.h:167:28: note: expected 'struct device_node *' but
argument is of type 'const struct device_node *'
+ * of_display_timings_exists - check if a display-timings node is
provided
+ * @np: device_node with the timing
+ **/
+int of_display_timings_exists(const struct device_node *np)
+{
+struct device_node *timings_np;
+
+if (!np)
+return -EINVAL;
+
+timings_np = of_parse_phandle(np, display-timings, 0);
Also here:
drivers/video/of_display_timing.c: In function
'of_display_timings_exists':
drivers/video/of_display_timing.c:209:2: warning: passing argument 1 of
'of_parse_phandle' discards qualifiers from pointer target type
include/linux/of.h:258:28: note: expected 'struct device_node *' but
argument is of type 'const struct device_node *'
The warnings are because the of-functions do not use const pointers where
they
should. I had two options: don't use const pointers even if they should be
and
have no warnings or use const pointers and have a correct API. (Third
option:
send patches for of-functions). I chose the second option.
Maybe a better approach would be a combination of 1 and 3: don't use
const pointers for struct device_node for now and bring the issue up
with the OF maintainers, possibly with patches attached that fix the
problematic functions.
Why does this need to be const? Since some DT functions increment
refcount the node, I'm not sure that making struct device_node const in
general is right thing to do. I do think it should be okay for
of_parse_phandle.
Okay, that seems right. I went a little to far with const'ing.
I will send a patch for of_parse_phandle as this function does
not seem to change the pointer it is given, but returns a new one
on which the refcount gets incremented.
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- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 44
include/linux/fb.h|6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..a6a564d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,49 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ 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);
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ 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;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 3/6] fbmon: add videomode helpers
On Thu, Nov 22, 2012 at 10:07:07AM +0100, Laurent Pinchart wrote: On Thursday 22 November 2012 09:53:42 Sascha Hauer wrote: On Thu, Nov 22, 2012 at 09:50:10AM +0100, Laurent Pinchart wrote: On Thursday 22 November 2012 07:20:00 Sascha Hauer wrote: On Wed, Nov 21, 2012 at 11:02:44PM +0100, Laurent Pinchart wrote: Hi Steffen, + + htotal = vm-hactive + vm-hfront_porch + vm-hback_porch + +vm-hsync_len; + vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch + +vm-vsync_len; + fbmode-refresh = (vm-pixelclock * 1000) / (htotal * vtotal); This will fail if vm-pixelclock = ((1 32) / 1000). The easiest solution is probably to use 64-bit computation. You have displays with a pixelclock 4GHz? vm-pixelclock is expressed in Hz. vm-pixelclock * 1000 will thus overflow if the clock frequency is = ~4.3 MHz. I have displays with a clock frequency higher than that :-) If vm-pixelclock is in Hz, then the * 1000 above is wrong. My bad, I though refresh was expressed in mHz. So yes, the above computation is wrong. Okay. I will fix that with the next version... BTW it seems that the refreshrate field in struct videomode isn't used. It should then be removed. ...and remove this field. I've just realized that the struct videomode fields are not documented. kerneldoc in include/linux/videomode.h would be a good addition. 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- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 34 +-
include/drm/drmP.h |6 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0073b27..2d6edfa 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,7 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
-#include linux/videomode.h
+#include linux/of_videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -541,6 +541,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, unsigned int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(vm, dmode);
+
+ pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+ vm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3d0ccaa..84ecabd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -86,6 +86,7 @@ struct drm_file;
struct drm_device;
struct videomode;
+struct device_node;
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ unsigned int index);
+#endif
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 0/7] of: add display helper
Hi! Changes since v12: - rename struct display_timing to via_display_timing in via subsystem - fix refreshrate calculation - fix const struct * warnings (reported by: Manjunathappa, Prakash prakash...@ti.com) - some CodingStyle fixes - rewrite parts of commit messages and display-timings.txt - let display_timing_get_value get all values instead of just typical Regards, Steffen Steffen Trumtrar (7): viafb: rename display_timing to via_display_timing video: add display_timing and videomode video: add of helper for display timings/videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/gpu/drm/drm_modes.c| 69 ++ drivers/video/Kconfig | 21 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 84 drivers/video/of_display_timing.c | 223 drivers/video/of_videomode.c | 48 + drivers/video/via/hw.c |6 +- drivers/video/via/hw.h |2 +- drivers/video/via/lcd.c|2 +- drivers/video/via/share.h |2 +- drivers/video/via/via_modesetting.c|8 +- drivers/video/via/via_modesetting.h|6 +- drivers/video/videomode.c | 45 include/drm/drmP.h | 12 ++ include/linux/display_timing.h | 104 + include/linux/fb.h | 12 ++ include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 18 ++ include/linux/videomode.h | 52 + 21 files changed, 856 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h create mode 100644 include/linux/videomode.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv13 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, that is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var-xres - cxres) / 2, dy = (var-yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var-xres, cyres ? cyres : var-yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info-lcd_panel_hres;
int panel_vres = plvds_setting_info-lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include debug.h
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total / 8 - 5;
raw.hor_addr = timing-hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total - 1;
raw.hor_addr = timing-hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing
[PATCH v2 2/2] fimc-lite: Don't use mutex_lock_interruptible() in device release()
Use uninterruptible mutex_lock in the release() file op to make
sure all resources are properly freed when a process is being
terminated. Returning -ERESTARTSYS has no effect for a terminating
process and this may cause driver resources not to be released.
This patch is required for stable kernels v3.5+.
Cc: sta...@vger.kernel.org
Reported-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-lite.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 23f203e..1b309a7 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -491,8 +491,7 @@ static int fimc_lite_close(struct file *file)
struct fimc_lite *fimc = video_drvdata(file);
int ret;
- if (mutex_lock_interruptible(fimc-lock))
- return -ERESTARTSYS;
+ mutex_lock(fimc-lock);
if (--fimc-ref_count == 0 fimc-out_path == FIMC_IO_DMA) {
clear_bit(ST_FLITE_IN_USE, fimc-state);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 4/7] fbmon: add videomode helpers
Hi Steffen,
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 44
include/linux/fb.h|6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..a6a564d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,49 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ 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);
This results in a division by 0 if vm-pixelclock is equal to zero. As the
information is missing from many board files, what would you think about the
following ?
fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ 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;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+ vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+ vm-vsync_len;
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode
*modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int
margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter
*adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.7-rc] Samsung SoC media driver fixes
Hi Mauro, this is what I've just sent (this time from the office my samsung.com account) to linux-media@vger.kernel.org. And can't see it neither on the mailing list nor at the patchwork. Regards, Sylwester On 11/22/2012 07:15 PM, Sylwester Nawrocki wrote: Hi Mauro, The following changes since commit 30677fd9ac7b9a06555318ec4f9a0db39804f9b2: s5p-fimc: Fix potential NULL pointer dereference (2012-11-22 10:15:40 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung media_fixes_for_v3.7 for you to fetch changes up to 28f497f26c67ab734bdb923b457016122368f69a: s5p-mfc: Handle multi-frame input buffer (2012-11-22 15:13:53 +0100) This is a bunch of quite important fixes for the Exynos SoC drivers, please apply for v3.7 if possible. This depends on my previous pull request (I've applied the patches you indicated you take for v3.7 previously to the media_fixes_for_v3.7 branch as well). Arun Kumar K (2): s5p-mfc: Bug fix of timestamp/timecode copy mechanism s5p-mfc: Handle multi-frame input buffer Shaik Ameer Basha (1): exynos-gsc: Fix settings for input and output image RGB type Sylwester Nawrocki (5): s5p-fimc: Prevent race conditions during subdevs registration s5p-fimc: Don't use mutex_lock_interruptible() in device release() fimc-lite: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Don't use mutex_lock_interruptible() in device release() exynos-gsc: Add missing video device vfl_dir flag initialization drivers/media/platform/exynos-gsc/gsc-m2m.c |4 ++-- drivers/media/platform/exynos-gsc/gsc-regs.h| 16 drivers/media/platform/s5p-fimc/fimc-capture.c | 10 +++--- drivers/media/platform/s5p-fimc/fimc-lite.c |6 -- drivers/media/platform/s5p-fimc/fimc-m2m.c |3 +-- drivers/media/platform/s5p-fimc/fimc-mdevice.c |4 ++-- drivers/media/platform/s5p-mfc/s5p_mfc.c|7 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |2 +- 8 files changed, 27 insertions(+), 25 deletions(-) --- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca - stv06xx: Fix a regression with the bridge/sensor vv6410
From: Jean-François Moine moin...@free.fr
Setting the H and V flip controls at webcam connection time prevents
the webcam to work correctly.
This patch checks if the webcam is streaming before setting the flips.
It does not set the flips (nor other controls) at webcam start time.
Tested-by: Philippe ROUBACH philippe.roub...@free.fr
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
+++ b/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
@@ -52,9 +52,13 @@
switch (ctrl-id) {
case V4L2_CID_HFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_hflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_VFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_vflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_GAIN:
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: V4L2: add temporary clock helpers
Hi All,
On 11/14/2012 02:06 PM, Laurent Pinchart wrote:
...
+
+static DEFINE_MUTEX(clk_lock);
+static LIST_HEAD(v4l2_clk);
As Sylwester mentioned, what about s/v4l2_clk/v4l2_clks/ ?
Don't you think naming of a static variable isn't important enough?
;-) I think code authors should have enough freedom to at least pick
up single vs. plural form:-) clks is too many consonants for my
taste, if it were anything important I'd rather agree to clk_head or
clk_list or something similar.
clk_list makes sense IMO since the clk_ prefis is the same.
FWIW, clk_list looks fine for me as well.
+void v4l2_clk_put(struct v4l2_clk *clk)
+{
+ if (!IS_ERR(clk))
+ module_put(clk-ops-owner);
+}
+EXPORT_SYMBOL(v4l2_clk_put);
+
+int v4l2_clk_enable(struct v4l2_clk *clk)
+{
+ if (atomic_inc_return(clk-enable) == 1 clk-ops-enable) {
+ int ret = clk-ops-enable(clk);
+ if (ret 0)
+ atomic_dec(clk-enable);
+ return ret;
+ }
I think you need a spinlock here instead of atomic operations. You
could get preempted after atomic_inc_return() and before
clk-ops-enable() by another process that would call
v4l2_clk_enable(). The function would return with enabling the
clock.
Sorry, what's the problem then? Our instance will succeed and call
-enable() and the preempting instance will see the enable count 1
and just return.
The clock is guaranteed to be enabled only after the call has returned.
The second caller of v4lw_clk_enable() thus may proceed without the
clock being enabled.
In principle enable() might also want to sleep, so how about using a
mutex for the purpose instead of a spinlock?
If enable() needs to sleep we should split the enable call into prepare
and enable, like the common clock framework did.
I'm pretty sure we won't need to toggle this from interrupt context which is
what the clock framework does, AFAIU. Accessing i2c subdevs mandates
sleeping already.
We might not need to have a mutex either if no driver needs to sleep for
this, still I guess this is more likely. I'm ok with both; just thought to
mention this.
Right, I'm fine with a mutex for now, we'll split enable into enable and
prepare later if needed.
How about just dropping reference counting from this code entirely ?
What would be use cases for multiple users of a single clock ? E.g. multiple
sensors case where each one uses same clock provided by a host interface ?
If we allow the sensor subdev drivers to be setting the clock frequency and
each sensor uses different frequency, then I can't see how this can work
reliably. I mean it's the clock's provider that should coordinate and
reference count the clock users. If a clock is enabled for one sensor and
some other sensor is attempting to set different frequency then the
set_rate
callback should return an error. The clock provider will need use
internally
a lock for the clock anyway, and to track the clock reference count too.
So I'm inclined to leave all this refcounting bits out to individual clock
providers.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 234/493] media: remove use of __devinit
On Mon, 19 Nov 2012, Bill Pemberton wrote: drivers/media/platform/sh_vou.c| 2 +- drivers/media/platform/soc_camera/atmel-isi.c | 2 +- drivers/media/platform/soc_camera/mx2_camera.c | 4 ++-- drivers/media/platform/soc_camera/mx3_camera.c | 2 +- drivers/media/platform/soc_camera/pxa_camera.c | 2 +- .../platform/soc_camera/sh_mobile_ceu_camera.c | 2 +- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 2 +- drivers/media/platform/soc_camera/soc_camera.c | 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fc2580: write some registers conditionally
It was a bad idea, as comment also says, to write some don't care
registers as 0xff value. Fix it.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/fc2580.c | 61 +--
1 file changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index aff39ae..81f38aa 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -35,8 +35,6 @@
* Currently it blind writes bunch of static registers from the
* fc2580_freq_regs_lut[] when fc2580_set_params() is called. Add some
* logic to reduce unneeded register writes.
- * There is also don't-care registers, initialized with value 0xff, and those
- * are also written to the chip currently (yes, not wise).
*/
/* write multiple registers */
@@ -111,6 +109,17 @@ static int fc2580_rd_reg(struct fc2580_priv *priv, u8 reg,
u8 *val)
return fc2580_rd_regs(priv, reg, val, 1);
}
+/* write single register conditionally only when value differs from 0xff
+ * XXX: This is special routine meant only for writing fc2580_freq_regs_lut[]
+ * values. Do not use for the other purposes. */
+static int fc2580_wr_reg_ff(struct fc2580_priv *priv, u8 reg, u8 val)
+{
+ if (val == 0xff)
+ return 0;
+ else
+ return fc2580_wr_regs(priv, reg, val, 1);
+}
+
static int fc2580_set_params(struct dvb_frontend *fe)
{
struct fc2580_priv *priv = fe-tuner_priv;
@@ -213,99 +222,99 @@ static int fc2580_set_params(struct dvb_frontend *fe)
if (i == ARRAY_SIZE(fc2580_freq_regs_lut))
goto err;
- ret = fc2580_wr_reg(priv, 0x25, fc2580_freq_regs_lut[i].r25_val);
+ ret = fc2580_wr_reg_ff(priv, 0x25, fc2580_freq_regs_lut[i].r25_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x27, fc2580_freq_regs_lut[i].r27_val);
+ ret = fc2580_wr_reg_ff(priv, 0x27, fc2580_freq_regs_lut[i].r27_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x28, fc2580_freq_regs_lut[i].r28_val);
+ ret = fc2580_wr_reg_ff(priv, 0x28, fc2580_freq_regs_lut[i].r28_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x29, fc2580_freq_regs_lut[i].r29_val);
+ ret = fc2580_wr_reg_ff(priv, 0x29, fc2580_freq_regs_lut[i].r29_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x2b, fc2580_freq_regs_lut[i].r2b_val);
+ ret = fc2580_wr_reg_ff(priv, 0x2b, fc2580_freq_regs_lut[i].r2b_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x2c, fc2580_freq_regs_lut[i].r2c_val);
+ ret = fc2580_wr_reg_ff(priv, 0x2c, fc2580_freq_regs_lut[i].r2c_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x2d, fc2580_freq_regs_lut[i].r2d_val);
+ ret = fc2580_wr_reg_ff(priv, 0x2d, fc2580_freq_regs_lut[i].r2d_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x30, fc2580_freq_regs_lut[i].r30_val);
+ ret = fc2580_wr_reg_ff(priv, 0x30, fc2580_freq_regs_lut[i].r30_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x44, fc2580_freq_regs_lut[i].r44_val);
+ ret = fc2580_wr_reg_ff(priv, 0x44, fc2580_freq_regs_lut[i].r44_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x50, fc2580_freq_regs_lut[i].r50_val);
+ ret = fc2580_wr_reg_ff(priv, 0x50, fc2580_freq_regs_lut[i].r50_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x53, fc2580_freq_regs_lut[i].r53_val);
+ ret = fc2580_wr_reg_ff(priv, 0x53, fc2580_freq_regs_lut[i].r53_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x5f, fc2580_freq_regs_lut[i].r5f_val);
+ ret = fc2580_wr_reg_ff(priv, 0x5f, fc2580_freq_regs_lut[i].r5f_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x61, fc2580_freq_regs_lut[i].r61_val);
+ ret = fc2580_wr_reg_ff(priv, 0x61, fc2580_freq_regs_lut[i].r61_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x62, fc2580_freq_regs_lut[i].r62_val);
+ ret = fc2580_wr_reg_ff(priv, 0x62, fc2580_freq_regs_lut[i].r62_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x63, fc2580_freq_regs_lut[i].r63_val);
+ ret = fc2580_wr_reg_ff(priv, 0x63, fc2580_freq_regs_lut[i].r63_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x67, fc2580_freq_regs_lut[i].r67_val);
+ ret = fc2580_wr_reg_ff(priv, 0x67, fc2580_freq_regs_lut[i].r67_val);
if (ret 0)
goto err;
- ret = fc2580_wr_reg(priv, 0x68, fc2580_freq_regs_lut[i].r68_val);
+ ret = fc2580_wr_reg_ff(priv, 0x68, fc2580_freq_regs_lut[i].r68_val);
if (ret
[GIT PULL FOR 3.8] fc2580: write some registers conditionally
The following changes since commit 304a0807a22852fe3095a62c24b25c4d0e16d003: [media] drivers/media/usb/hdpvr/hdpvr-core.c: fix error return code (2012-11-22 14:22:31 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.8-fc2580 for you to fetch changes up to a91e0faf4074c4b160a33a5448cc1084d4fab419: fc2580: write some registers conditionally (2012-11-23 01:01:01 +0200) Antti Palosaari (1): fc2580: write some registers conditionally drivers/media/tuners/fc2580.c | 61 +++-- 1 file changed, 35 insertions(+), 26 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 4/7] fbmon: add videomode helpers
On Thu, Nov 22, 2012 at 07:31:39PM +0100, Laurent Pinchart wrote:
Hi Steffen,
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 44
include/linux/fb.h|6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..a6a564d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,49 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ 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);
This results in a division by 0 if vm-pixelclock is equal to zero. As the
information is missing from many board files, what would you think about the
following ?
fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
Grrr...you are right. I will fix that...
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+
...and obviously this, too.
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- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] rtl28xxu: add NOXON DAB/DAB+ USB dongle rev 2
On 11/13/2012 08:09 PM, Juergen Lock wrote:
This just adds the usbid to the rtl28xxu driver, that's all that's
needed to make the stick work for DVB.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -250,6 +250,7 @@
#define USB_PID_TERRATEC_T3 0x10a0
#define USB_PID_TERRATEC_T5 0x10a1
#define USB_PID_NOXON_DAB_STICK 0x00b3
+#define USB_PID_NOXON_DAB_STICK_REV2 0x00e0
#define USB_PID_PINNACLE_EXPRESSCARD_320CX0x022e
#define USB_PID_PINNACLE_PCTV2000E0x022c
#define USB_PID_PINNACLE_PCTV_DVB_T_FLASH 0x0228
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1338,6 +1338,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, G-Tek Electronics Group Lifeview LV5TDLX
DVB-T, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK,
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
+ rtl2832u_props, NOXON DAB/DAB+ USB dongle (rev 2), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Applied thanks! I will pull-request that for Kernel 3.8
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/for_v3.8-rtl28xxu
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.8] rtl28xxu: new device IDs
The following changes since commit 304a0807a22852fe3095a62c24b25c4d0e16d003: [media] drivers/media/usb/hdpvr/hdpvr-core.c: fix error return code (2012-11-22 14:22:31 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.8-rtl28xxu for you to fetch changes up to 37afa053cf6ac2c6dbd2bbe13f473916751c0621: rtl28xxu: add NOXON DAB/DAB+ USB dongle rev 2 (2012-11-23 01:24:36 +0200) Andrew Karpow (1): rtl28xxu: 0ccd:00d7 TerraTec Cinergy T Stick+ Antti Palosaari (1): rtl28xxu: 1d19:1102 Dexatek DK mini DVB-T Dongle Juergen Lock (1): rtl28xxu: add NOXON DAB/DAB+ USB dongle rev 2 drivers/media/dvb-core/dvb-usb-ids.h| 1 + drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 6 ++ 2 files changed, 7 insertions(+) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 4/7] fbmon: add videomode helpers
On Friday 23 November 2012 00:09:49 Steffen Trumtrar wrote:
On Thu, Nov 22, 2012 at 07:31:39PM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 44 ++
include/linux/fb.h|6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..a6a564d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,49 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ 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);
This results in a division by 0 if vm-pixelclock is equal to zero. As the
information is missing from many board files, what would you think about
the following ?
fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
Grrr...you are right. I will fix that...
Thank you.
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+ vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+ vm-vsync_len;
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+
...and obviously this, too.
That one is less of an issue in my opinion. A mode with a zero htotal or
vtotal is clearly invalid, while we have modes with no pixel clock value.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar and others, On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation As discussed, here's the todo list for inclusion to staging. - User space interface refinement - Controls should be used when possible rather than private ioctl - No enums should be used - Use of MC and V4L2 subdev APIs when applicable - Single interface header might suffice - Current interface forces to configure everything at once - Get rid of the dm365_ipipe_hw.[ch] layer - Active external sub-devices defined by link configuration; no strcmp needed - More generic platform data (i2c adapters) - The driver should have no knowledge of possible external subdevs; see struct vpfe_subdev_id - Some of the hardware control should be refactorede - Check proper serialisation (through mutexes and spinlocks) - Names that are visible in kernel global namespace should have a common prefix (or a few) This list likely isn't complete, but some items such as the locking one is there simply because I'm not certain of the state of it. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] [media] exynos-gsc: Some fixes
Patch series build tested and based on samsung/for_v3.8 branch of git://linuxtv.org/snawrocki/media.git. Sachin Kamat (4): [media] exynos-gsc: Rearrange error messages for valid prints [media] exynos-gsc: Remove gsc_clk_put call from gsc_clk_get [media] exynos-gsc: Use devm_clk_get() [media] exynos-gsc: Fix checkpatch warning in gsc-m2m.c drivers/media/platform/exynos-gsc/gsc-core.c | 21 - drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +- 2 files changed, 9 insertions(+), 14 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] [media] exynos-gsc: Rearrange error messages for valid prints
In case of clk_prepare failure, the function gsc_clk_get also prints
failed to get clock which is not correct. Hence move the error
messages to their respective blocks. While at it, also renamed the labels
meaningfully.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 6d6f65d..45bcfa7 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1017,25 +1017,26 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc-clock))
- goto err_print;
+ if (IS_ERR(gsc-clock)) {
+ dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
+ GSC_CLOCK_GATE_NAME);
+ goto err_clk_get;
+ }
ret = clk_prepare(gsc-clock);
if (ret 0) {
+ dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
+ GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err;
+ goto err_clk_prepare;
}
return 0;
-err:
- dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_prepare:
gsc_clk_put(gsc);
-err_print:
- dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_get:
return -ENXIO;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] [media] exynos-gsc: Remove gsc_clk_put call from gsc_clk_get
Since this function just returns (since gsc-clock is NULL),
remove it and make the exit code simpler.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 45bcfa7..99ee1a9 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1020,7 +1020,7 @@ static int gsc_clk_get(struct gsc_dev *gsc)
if (IS_ERR(gsc-clock)) {
dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
GSC_CLOCK_GATE_NAME);
- goto err_clk_get;
+ goto err;
}
ret = clk_prepare(gsc-clock);
@@ -1029,14 +1029,12 @@ static int gsc_clk_get(struct gsc_dev *gsc)
GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err_clk_prepare;
+ goto err;
}
return 0;
-err_clk_prepare:
- gsc_clk_put(gsc);
-err_clk_get:
+err:
return -ENXIO;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] [media] exynos-gsc: Use devm_clk_get()
devm_clk_get() is a device managed function and makes error handling
a bit simpler.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 99ee1a9..b89afec 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1006,8 +1006,6 @@ static void gsc_clk_put(struct gsc_dev *gsc)
return;
clk_unprepare(gsc-clock);
- clk_put(gsc-clock);
- gsc-clock = NULL;
}
static int gsc_clk_get(struct gsc_dev *gsc)
@@ -1016,7 +1014,7 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
- gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
+ gsc-clock = devm_clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
if (IS_ERR(gsc-clock)) {
dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
GSC_CLOCK_GATE_NAME);
@@ -1027,8 +1025,6 @@ static int gsc_clk_get(struct gsc_dev *gsc)
if (ret 0) {
dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
GSC_CLOCK_GATE_NAME);
- clk_put(gsc-clock);
- gsc-clock = NULL;
goto err;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] [media] exynos-gsc: Fix checkpatch warning in gsc-m2m.c
Fixes the following warning:
WARNING: space prohibited between function name and open parenthesis '('
FILE: media/platform/exynos-gsc/gsc-m2m.c:606:
ctx = kzalloc(sizeof (*ctx), GFP_KERNEL);
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 39dff20..10036d6 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -603,7 +603,7 @@ static int gsc_m2m_open(struct file *file)
if (mutex_lock_interruptible(gsc-lock))
return -ERESTARTSYS;
- ctx = kzalloc(sizeof (*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
ret = -ENOMEM;
goto unlock;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 444/493] media: remove use of __devexit
On Mon, 19 Nov 2012, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. drivers/media/platform/sh_vou.c | 2 +- drivers/media/platform/soc_camera/atmel-isi.c| 2 +- drivers/media/platform/soc_camera/mx2_camera.c | 2 +- drivers/media/platform/soc_camera/mx3_camera.c | 2 +- drivers/media/platform/soc_camera/pxa_camera.c | 2 +- drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 2 +- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 2 +- drivers/media/platform/soc_camera/soc_camera.c | 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 5/7] fbmon: add of_videomode helpers
Hi Laurent, On Thu, Nov 22, 2012 at 06:58:09PM +0100, Laurent Pinchart wrote: Hi Steffen, On Thursday 22 November 2012 17:00:13 Steffen Trumtrar wrote: Add helper to get fb_videomode from devicetree. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Reviewed-by: Thierry Reding thierry.red...@avionic-design.de Acked-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This patch results in the following build warning: drivers/video/fbmon.c: In function 'of_get_fb_videomode': drivers/video/fbmon.c:1445: warning: passing argument 1 of 'of_get_videomode' discards qualifiers from pointer target type include/linux/of_videomode.h:15: note: expected 'struct device_node *' but argument is of type 'const struct device_node *' This I don't get. Well, looking at the code, the warning is correct. I fixed that now. But, I do not get the warning. Just tried it again before fixing: cleaned, cleaned and touching file, just make drivers/video/fbmon.o. Nothing. Weird. So, thanks for reporting it. 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- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stv090x: possible bug with 8psk,fec=5/6
Оригинално писмо От: N. D. nam...@abv.bg Относно: stv090x: possible bug with 8psk,fec=5/6 До: linux-media@vger.kernel.org Изпратено на: Четвъртък, 2012, Юни 14 22:33:06 EEST I own a Skystar USB HD which I use with vdr. Ever since I bought the card I have been having some strange issues with 11817V on Astra 23.5E. Femon reports that there is a lock and sound comes but the image is completely garbled. The same setup (Kernel: 3.3.8, VDR: 1.7.27) works fine with an HVR-4000. So I started to suspect that there might be something wrong with the driver. Trying to find out some more information I came across this forum: http://rickcaylor.websitetoolbox.com/post/stv0900_core.c-patch-5481028 I tried the patch which is supposed to (among other things) make the tuner lock on high bitrate transponders (60Mbps). But it did not help. So using the stock driver I gave dvbsnoop a whirl to see if there was something amiss. Astra 3B 11817.00 V DVB-S2 8PSK 27500 5/6 66.6 Mbps packets read: 122/(343292) d_time: 0.001 s = 183488.000 kbit/s (Avrg: 66142.860 kbit/s) [bad: 2] packets read: 42/(343334) d_time: 0.001 s = 63168.000 kbit/s (Avrg: 66150.953 kbit/s) [bad: 0] packets read: 38/(343372) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66158.274 kbit/s) [bad: 2] packets read: 34/(343406) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 66164.825 kbit/s) [bad: 1] packets read: 35/(343441) d_time: 0.001 s = 52640.000 kbit/s (Avrg: 66171.569 kbit/s) [bad: 2] packets read: 31/(343472) d_time: 0.001 s = 46624.000 kbit/s (Avrg: 66177.541 kbit/s) [bad: 4] packets read: 16/(343488) d_time: 0.001 s = 24064.000 kbit/s (Avrg: 66180.624 kbit/s) [bad: 0] packets read: 29/(343517) d_time: 0.008 s = 5452.000 kbit/s (Avrg: 66118.450 kbit/s) [bad: 1] packets read: 116/(343633) d_time: 0.001 s = 174464.000 kbit/s (Avrg: 66140.777 kbit/s) [bad: 1] packets read: 38/(343671) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66148.091 kbit/s) [bad: 1] packets read: 34/(343705) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 66154.635 kbit/s) [bad: 1] packets read: 30/(343735) d_time: 0.001 s = 45120.000 kbit/s (Avrg: 66160.410 kbit/s) [bad: 0] packets read: 37/(343772) d_time: 0.001 s = 55648.000 kbit/s (Avrg: 66167.531 kbit/s) [bad: 2] packets read: 38/(343810) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66174.845 kbit/s) [bad: 1] packets read: 30/(343840) d_time: 0.001 s = 45120.000 kbit/s (Avrg: 66180.619 kbit/s) [bad: 0] Then I experimented with a lot of other transponders and found another one with the same behavior. HotBird 13C 11411.00 H DVB-S2 8PSK 27500 5/6 68.2 Mbps packets read: 40/(259860) d_time: 0.001 s = 60160.000 kbit/s (Avrg: 65498.482 kbit/s) [bad: 0] packets read: 39/(259899) d_time: 0.001 s = 58656.000 kbit/s (Avrg: 65508.312 kbit/s) [bad: 0] packets read: 34/(259933) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65516.882 kbit/s) [bad: 1] packets read: 34/(259967) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65525.451 kbit/s) [bad: 0] packets read: 36/(260003) d_time: 0.001 s = 54144.000 kbit/s (Avrg: 65534.525 kbit/s) [bad: 2] packets read: 11/(260014) d_time: 0.001 s = 16544.000 kbit/s (Avrg: 65537.298 kbit/s) [bad: 1] packets read: 349/(260363) d_time: 0.008 s = 65612.000 kbit/s (Avrg: 65537.398 kbit/s) [bad: 7] packets read: 25/(260388) d_time: 0.008 s = 4700.000 kbit/s (Avrg: 65456.051 kbit/s) [bad: 0] packets read: 129/(260517) d_time: 0.001 s = 194016.000 kbit/s (Avrg: 65488.479 kbit/s) [bad: 2] packets read: 35/(260552) d_time: 0.001 s = 52640.000 kbit/s (Avrg: 65497.277 kbit/s) [bad: 0] packets read: 37/(260589) d_time: 0.001 s = 55648.000 kbit/s (Avrg: 65506.578 kbit/s) [bad: 2] packets read: 34/(260623) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65515.125 kbit/s) [bad: 2] packets read: 36/(260659) d_time: 0.001 s = 54144.000 kbit/s (Avrg: 65524.174 kbit/s) [bad: 3] packets read: 34/(260693) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65532.721 kbit/s) [bad: 0] packets read: 21/(260714) d_time: 0.001 s = 31584.000 kbit/s (Avrg: 65538.000 kbit/s) [bad: 0] Both of these are 8psk 5/6 and have an average bitrate of over 65Mbps. The high bitrate per se could not explain what is wrong because there are a number of ~65Mbps transponders on Hotbird which are OK. For example: HotBird 13B 11785.00 H DVB-S2 8PSK 29900 3/4 65.1 Mbps packets read: 33/(434934) d_time: 0.001 s = 49632.000 kbit/s (Avrg: 65101.586 kbit/s) [bad: 0] packets read: 38/(434972) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 65107.274 kbit/s) [bad: 0] packets read: 34/(435006) d_time: 0.001 s =
