Re: [PATCH v2] media: V4L2: add temporary clock helpers
Hi Guennadi,
Thanks for the patch.
On Tuesday 30 October 2012 15:18:38 Guennadi Liakhovetski wrote:
Typical video devices like camera sensors require an external clock source.
Many such devices cannot even access their hardware registers without a
running clock. These clock sources should be controlled by their consumers.
This should be performed, using the generic clock framework. Unfortunately
so far only very few systems have been ported to that framework. This patch
adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
Platforms, adopting the clock API, should switch to using it. Eventually
this temporary API should be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2: integrated most fixes from Sylwester Laurent,
(1) do not register identical clocks
(2) add clock refcounting
(3) more robust locking
(4) duplicate strings to prevent dereferencing invalid memory
(5) add a private data pointer
(6) return an error in get_rate() / set_rate() if clock isn't enabled
(7) support .id=NULL per subdevice
Thanks to all reviewers!
drivers/media/v4l2-core/Makefile |2 +-
drivers/media/v4l2-core/v4l2-clk.c | 169 +
include/media/v4l2-clk.h | 51 +++
3 files changed, 221 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
create mode 100644 include/media/v4l2-clk.h
diff --git a/drivers/media/v4l2-core/Makefile
b/drivers/media/v4l2-core/Makefile index 00f64d6..cb5fede 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -5,7 +5,7 @@
tuner-objs := tuner-core.o
videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
\
- v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
+ v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c new file mode 100644
index 000..2496807
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -0,0 +1,169 @@
+/*
+ * V4L2 clock service
+ *
+ * Copyright (C) 2012, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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/atomic.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/string.h
+
+#include media/v4l2-clk.h
+#include media/v4l2-subdev.h
+
+static DEFINE_MUTEX(clk_lock);
+static LIST_HEAD(v4l2_clk);
As Sylwester mentioned, what about s/v4l2_clk/v4l2_clks/ ?
+static struct v4l2_clk *v4l2_clk_find(const char *dev_id, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ list_for_each_entry(clk, v4l2_clk, list) {
+ if (strcmp(dev_id, clk-dev_id))
+ continue;
+
+ if (!id || !clk-id || !strcmp(clk-id, id))
If id != NULL and clk-id == NULL, the unnamed clock will be returned even
though the caller requests a named clock. Isn't that a mistake ?
+ return clk;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+struct v4l2_clk *v4l2_clk_get(struct v4l2_subdev *sd, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ mutex_lock(clk_lock);
+ clk = v4l2_clk_find(sd-name, id);
+
+ if (!IS_ERR(clk) !try_module_get(clk-ops-owner))
+ clk = ERR_PTR(-ENODEV);
+ mutex_unlock(clk_lock);
+
+ return clk;
+}
+EXPORT_SYMBOL(v4l2_clk_get);
+
+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.
One solution would be to add a spinlock to struct v4l2_clk and modify the
enable field from atomic_t to plain unsigned int.
+ return 0;
+}
+EXPORT_SYMBOL(v4l2_clk_enable);
+
+void v4l2_clk_disable(struct v4l2_clk *clk)
+{
+ int enable = atomic_dec_return(clk-enable);
+
+ if (WARN(enable 0, Unbalanced %s()!\n, __func__)) {
Could you add the clock name to the debug message ?
+ atomic_inc(clk-enable);
+ return;
+ }
+
+ if (!enable clk-ops-disable)
+ clk-ops-disable(clk);
+}
[PATCH v7 0/8] of: add display helper
Hi! Finally, v7 of the series. Changes since v6: - get rid of some empty lines etc. - move functions to their subsystems - split of_ from non-of_ functions - add at least some kerneldoc to some functions Regards, Steffen Steffen Trumtrar (8): video: add display_timing struct and helpers of: add helper to parse display timings of: add generic videomode description video: add videomode helpers 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 | 139 +++ drivers/gpu/drm/drm_modes.c| 78 + drivers/of/Kconfig | 12 ++ drivers/of/Makefile|2 + drivers/of/of_display_timings.c| 185 drivers/of/of_videomode.c | 47 + drivers/video/Kconfig | 11 ++ drivers/video/Makefile |2 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 76 drivers/video/videomode.c | 44 + include/drm/drmP.h |8 + include/linux/display_timing.h | 69 include/linux/fb.h |5 + include/linux/of_display_timings.h | 20 +++ include/linux/of_videomode.h | 15 ++ include/linux/videomode.h | 36 17 files changed, 773 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/of/of_display_timings.c create mode 100644 drivers/of/of_videomode.c 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/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
[PATCH v7 1/8] video: add display_timing struct and helpers
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Every timing parameter can be specified as a single value or a range
min typ max.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/Kconfig |5 +++
drivers/video/Makefile |1 +
drivers/video/display_timing.c | 24 ++
include/linux/display_timing.h | 69
4 files changed, 99 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 include/linux/display_timing.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..1421fc8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,11 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool Enable display timings helpers
+ help
+ Say Y here, to use the display timing helpers.
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..552c045 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,4 @@ 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
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..9ccfdb3
--- /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/slab.h
+#include linux/display_timing.h
+
+void timings_release(struct display_timings *disp)
+{
+ int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+}
+
+void display_timings_release(struct display_timings *disp)
+{
+ timings_release(disp);
+ kfree(disp-timings);
+}
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..aa02a12
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include linux/types.h
+
+struct timing_entry {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct display_timing {
+ struct timing_entry pixelclock;
+
+ struct timing_entry hactive;
+ struct timing_entry hfront_porch;
+ struct timing_entry hback_porch;
+ struct timing_entry hsync_len;
+
+ struct timing_entry vactive;
+ struct timing_entry vfront_porch;
+ struct timing_entry vback_porch;
+ struct timing_entry vsync_len;
+
+ unsigned int vsync_pol_active;
+ unsigned int hsync_pol_active;
+ unsigned int de_pol_active;
+ unsigned int pixelclk_pol;
+ bool interlaced;
+ bool doublescan;
+};
+
+struct display_timings {
+ unsigned int num_timings;
+ unsigned int native_mode;
+
+ struct display_timing **timings;
+};
+
+/* placeholder function until ranges are really needed */
+static inline u32 display_timing_get_value(struct timing_entry *te, int index)
+{
+ return te-typ;
+}
+
+static inline struct display_timing *display_timings_get(struct
display_timings *disp,
+int index)
+{
+ struct display_timing *dt;
+
+ if (disp-num_timings index) {
+ dt = disp-timings[index];
+ return dt;
+ } else
+ return NULL;
+}
+
+void timings_release(struct display_timings *disp);
+void display_timings_release(struct display_timings *disp);
+
+#endif
--
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 v7 2/8] of: add helper to parse display timings
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
.../devicetree/bindings/video/display-timings.txt | 139 +++
drivers/of/Kconfig |6 +
drivers/of/Makefile|1 +
drivers/of/of_display_timings.c| 185
include/linux/of_display_timings.h | 20 +++
5 files changed, 351 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/of/of_display_timings.c
create mode 100644 include/linux/of_display_timings.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..04c94a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-timings.txt
@@ -0,0 +1,139 @@
+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: displayclock 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/non-inverted/ignored
+ - interlaced (bool)
+ - doublescan (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
+
+struct display_timing
+===
+
+ +--+-+--+---+
+ | |↑| | |
+ | ||vback_porch | | |
+ | |↓| | |
+ +--###--+---+
+ | #↑# | |
+ | #|# | |
+ | hback #|# hfront | hsync |
+ | porch #| hactive # porch | len |
+ |#---+---#|-|
+ | #|# | |
+ | #|vactive # | |
+ | #|# | |
+ | #↓# | |
+ +--###--+---+
+ | |↑| | |
+ | ||vfront_porch| | |
+ | |↓| | |
+ +--+-+--+---+
+ | |↑| | |
+ | ||vsync_len | | |
+ | |↓| | |
+ +--+-+--+---+
+
+
+Example:
+
+ display-timings {
+ native-mode = timing0;
+ timing0: 1920p24 {
+ /* 1920x1080p24 */
+ clock = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ hfront-porch = 25;
+ hback-porch = 25;
+ hsync-len = 25;
+ vback-porch = 2;
+ vfront-porch = 2;
+ vsync-len = 2;
+ hsync-active = 1;
+ };
+ };
+
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with min typ max-tuples can be used.
+
+Example:
+
+ timing1: timing {
+ /* 1920x1080p24 */
+
[PATCH v7 4/8] video: add videomode helpers
Add helper functions to convert from display timings to a generic videomode
structure. This videomode can then be converted to the corresponding subsystem
mode representation (e.g. fb_videomode).
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile|1 +
drivers/video/videomode.c | 44
include/linux/videomode.h | 36
4 files changed, 87 insertions(+)
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1421fc8..45dd393 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -38,6 +38,12 @@ config DISPLAY_TIMING
help
Say Y here, to use the display timing helpers.
+config VIDEOMODE
+ bool Enable videomode helpers
+ help
+ Say Y here, to use the generic videomode helpers. This allows
+converting from display timings to fb_videomode and drm_display_mode
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 552c045..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -168,3 +168,4 @@ 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/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..a9fe010
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,44 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/errno.h
+#include linux/display_timing.h
+#include linux/videomode.h
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ int index)
+{
+ struct display_timing *dt = NULL;
+
+ dt = display_timings_get(disp, index);
+ if (!dt) {
+ pr_err(%s: no signal timings found\n, __func__);
+ return -EINVAL;
+ }
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, 0);
+ vm-hactive = display_timing_get_value(dt-hactive, 0);
+ vm-hfront_porch = display_timing_get_value(dt-hfront_porch, 0);
+ vm-hback_porch = display_timing_get_value(dt-hback_porch, 0);
+ vm-hsync_len = display_timing_get_value(dt-hsync_len, 0);
+
+ vm-vactive = display_timing_get_value(dt-vactive, 0);
+ vm-vfront_porch = display_timing_get_value(dt-vfront_porch, 0);
+ vm-vback_porch = display_timing_get_value(dt-vback_porch, 0);
+ vm-vsync_len = display_timing_get_value(dt-vsync_len, 0);
+
+ vm-vah = dt-vsync_pol_active;
+ vm-hah = dt-hsync_pol_active;
+ vm-interlaced = dt-interlaced;
+ vm-doublescan = dt-doublescan;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/videomode.h b/include/linux/videomode.h
new file mode 100644
index 000..f932147
--- /dev/null
+++ b/include/linux/videomode.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * generic videomode description
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_VIDEOMODE_H
+#define __LINUX_VIDEOMODE_H
+
+#include linux/display_timing.h
+
+struct videomode {
+ u32 pixelclock;
+ u32 refreshrate;
+
+ u32 hactive;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+
+ u32 vactive;
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+
+ u32 hah;
+ u32 vah;
+ bool interlaced;
+ bool doublescan;
+};
+
+int videomode_from_timing(struct display_timings *disp, struct videomode *vm,
+ int index);
+#endif
--
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 v7 5/8] 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
---
drivers/video/fbmon.c | 36
include/linux/fb.h|2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..b9e6ab3 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1373,6 +1373,42 @@ 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 videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode)
+{
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
+
+ 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-refresh = 60;
+ fbmode-flag = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_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 c7a9571..46c665b 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -714,6 +714,8 @@ 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);
+extern int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode);
+
/* 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
[PATCH v7 6/8] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 40
include/linux/fb.h|3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index b9e6ab3..871aa76 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1408,6 +1408,46 @@ int videomode_to_fb_videomode(struct videomode *vm,
struct fb_videomode *fbmode)
EXPORT_SYMBOL_GPL(videomode_to_fb_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_fb_videomode(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_timing_list
ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ videomode_to_fb_videomode(vm, fb);
+
+ pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+ vm.vactive, np-name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_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 46c665b..9892fd6 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -14,6 +14,8 @@
#include linux/backlight.h
#include linux/slab.h
#include asm/io.h
+#include linux/of.h
+#include linux/of_videomode.h
struct vm_area_struct;
struct fb_info;
@@ -714,6 +716,7 @@ 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);
+extern int of_get_fb_videomode(struct device_node *np, struct fb_videomode
*fb, int index);
extern int videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode);
/* drivers/video/modedb.c */
--
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 v7 7/8] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/drm_modes.c | 36
include/drm/drmP.h |3 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..049624d 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,41 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int videomode_to_display_mode(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(videomode_to_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 3fd8280..e9fa1e3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
#include linux/cdev.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/videomode.h
#if defined(__alpha__) || defined(__powerpc__)
#include asm/pgtable.h /* For pte_wrprotect */
#endif
@@ -1454,6 +1455,8 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+extern int videomode_to_display_mode(struct videomode *vm,
+struct drm_display_mode *dmode);
/* 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 v7 3/8] of: add generic videomode description
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/of/Kconfig |6 ++
drivers/of/Makefile |1 +
drivers/of/of_videomode.c| 47 ++
include/linux/of_videomode.h | 15 ++
4 files changed, 69 insertions(+)
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 781e773..0575ffe 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -89,4 +89,10 @@ config OF_DISPLAY_TIMINGS
help
helper to parse display timings from the devicetree
+config OF_VIDEOMODE
+ def_bool y
+ depends on VIDEOMODE
+ help
+ helper to get videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index c8e9603..09d556f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_DISPLAY_TIMINGS) += of_display_timings.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..91a26fc
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,47 @@
+/*
+ * generic videomode helper
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include linux/of.h
+#include linux/of_display_timings.h
+#include linux/of_videomode.h
+#include linux/export.h
+
+/**
+ * of_get_videomode - get the videomode #index from devicetree
+ * @np - devicenode with the display_timings
+ * @vm - set to return value
+ * @index - index into list of display_timings
+ * DESCRIPTION:
+ * Get a list of all display timings and put the one
+ * specified by index into *vm. This function should only be used, if
+ * only one videomode is to be retrieved. A driver that needs to work
+ * with multiple/all videomodes should work with
+ * of_get_display_timing_list instead.
+ **/
+int of_get_videomode(struct device_node *np, struct videomode *vm, int index)
+{
+ struct display_timings *disp;
+ int ret;
+
+ disp = of_get_display_timing_list(np);
+ if (!disp) {
+ pr_err(%s: no timings specified\n, __func__);
+ return -EINVAL;
+ }
+
+ if (index == OF_USE_NATIVE_MODE)
+ index = disp-native_mode;
+
+ ret = videomode_from_timing(disp, vm, index);
+ if (ret)
+ return ret;
+
+ display_timings_release(disp);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_videomode);
diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
new file mode 100644
index 000..01518e6
--- /dev/null
+++ b/include/linux/of_videomode.h
@@ -0,0 +1,15 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * videomode of-helpers
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_VIDEOMODE_H
+#define __LINUX_OF_VIDEOMODE_H
+
+#include linux/videomode.h
+
+int of_get_videomode(struct device_node *np, struct videomode *vm, int index);
+#endif /* __LINUX_OF_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
[PATCH v7 8/8] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/gpu/drm/drm_modes.c | 42 ++
include/drm/drmP.h |5 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 049624d..d51afe6 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/of.h
#include linux/videomode.h
/**
@@ -540,6 +541,47 @@ int videomode_to_display_mode(struct videomode *vm, struct
drm_display_mode *dmo
EXPORT_SYMBOL_GPL(videomode_to_display_mode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static void dump_drm_displaymode(struct drm_display_mode *m)
+{
+ pr_debug(drm_displaymode = %d %d %d %d %d %d %d %d %d\n,
+m-hdisplay, m-hsync_start, m-hsync_end, m-htotal,
+m-vdisplay, m-vsync_start, m-vsync_end, m-vtotal,
+m-clock);
+}
+
+/**
+ * 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
+ *
+ * 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_timing_list
ond
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np, struct drm_display_mode
*dmode,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ videomode_to_display_mode(vm, dmode);
+
+ pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+ vm.vactive, np-name);
+ dump_drm_displaymode(dmode);
+
+ return 0;
+
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#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 e9fa1e3..4f9c44e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
#include linux/cdev.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/of.h
#include linux/videomode.h
#if defined(__alpha__) || defined(__powerpc__)
#include asm/pgtable.h /* For pte_wrprotect */
@@ -1457,6 +1458,10 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int videomode_to_display_mode(struct videomode *vm,
struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
+
/* 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
[GIT PULL] soc-camera fixes for 3.7
Hi Mauro The following changes since commit 08f05c49749ee655bef921d12160960a273aad47: Return the right error value when dup[23]() newfd argument is too large (2012-10-30 21:27:28 -0700) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 3.7-rc3-fixes for you to fetch changes up to 2819734c24a35207a896373aa055f0ee57c795b0: mt9v022: fix the V4L2_CID_EXPOSURE control (2012-10-31 11:14:05 +0100) Anatolij Gustschin (1): mt9v022: fix the V4L2_CID_EXPOSURE control Guennadi Liakhovetski (7): media: sh_vou: fix const cropping related warnings media: sh_mobile_ceu_camera: fix const cropping related warnings media: pxa_camera: fix const cropping related warnings media: mx3_camera: fix const cropping related warnings media: mx2_camera: fix const cropping related warnings media: mx1_camera: use the default .set_crop() implementation media: omap1_camera: fix const cropping related warnings Wei Yongjun (1): mx2_camera: fix missing unlock on error in mx2_start_streaming() drivers/media/i2c/soc_camera/mt9v022.c | 11 --- drivers/media/platform/sh_vou.c|3 ++- drivers/media/platform/soc_camera/mx1_camera.c |9 - drivers/media/platform/soc_camera/mx2_camera.c | 13 + drivers/media/platform/soc_camera/mx3_camera.c |5 +++-- drivers/media/platform/soc_camera/omap1_camera.c |4 ++-- drivers/media/platform/soc_camera/pxa_camera.c |4 ++-- .../platform/soc_camera/sh_mobile_ceu_camera.c | 13 +++-- 8 files changed, 33 insertions(+), 29 deletions(-) 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: [PATCH 00/23] em28xx: add support fur USB bulk transfers
On Tue, Oct 30, 2012 at 10:39 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Frank Schäfer fschaefer@googlemail.com writes: This patch series adds support for USB bulk transfers to the em28xx driver. I tried these patches on my Raspberry Pi, 3.6.1 kernel, Nanostick 290e options em28xx prefer_bulk=1 core_debug=1 usb_debug=1 options em28xx_dvb debug=1 [5.469510] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [5.890637] em28xx: DVB interface 0 found [6.025292] em28xx #0: chip ID is em28174 [6.515383] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [6.567066] em28xx #0: v4l2 driver version 0.1.3 [6.614720] em28xx #0 em28xx_set_alternate :minimum isoc packet size: 2888 (alt=0) [6.663064] em28xx #0 em28xx_set_alternate :setting alternate 0 with wMaxPacketSize=0 [6.715934] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [6.765694] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [6.793060] em28xx #0: V4L2 video device registered as video0 [6.808200] em28xx #0 em28xx_alloc_urbs :em28xx: called em28xx_alloc_isoc in mode 2 [6.819456] em28xx #0: no endpoint for DVB mode and transfer type 1 [6.829283] em28xx: Failed to pre-allocate USB transfer buffers for DVB. [6.839454] em28xx: probe of 1-1.3.1:1.0 failed with error -22 [6.852511] usbcore: registered new interface driver em28xx [7.255738] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [7.291575] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [7.326200] em28xx #0 em28xx_uninit_usb_xfer :em28xx: called em28xx_uninit_usb_xfer in mode 1 Is the Nanostick 290e just fundamentally incompatible with bulk transfers, or is there hope yet? It works great with isochronous transfers on my PC and the Fedora kernel, but the Raspberry USB host blows up when trying to do isochronous mode. Isn't this completely OT? Anyway, RPI has known issues regarding USB bandwidth. See here https://github.com/ezequielgarcia/stk1160-standalone/issues/8 https://github.com/ezequielgarcia/stk1160-standalone/issues/2 http://www.raspberrypi.org/phpBB3/viewtopic.php?p=196918#p196918 Regards, Ezequiel -- 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 v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Em Tue, 30 Oct 2012 10:03:25 -0200 Fabio Estevam fabio.este...@freescale.com escreveu: During the clock conversion for mx27 the per4_gate clock was missed to get registered as a dependency of mx2-camera driver. In the old mx27 clock driver we used to have: DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, csi_clk1, per4_clk); ,so does the same in the new clock driver Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Sascha Hauer s.ha...@pengutronix.de As it seems that those patches depend on some patches at the arm tree, the better is to merge them via -arm tree. So, Acked-by: Mauro Carvalho Chehab mche...@redhat.com --- Changes since v3: - Use imx27-camera.0 instead of mx2-camera.0, due to recent changes in the imx27 clock (commit 27b76486a3: media: mx2_camera: remove cpu_is_xxx by using platform_device_id) arch/arm/mach-imx/clk-imx27.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 585ab25..2880bd9 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx21-fb.0); clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx21-fb.0); clk_register_clkdev(clk[csi_ahb_gate], ahb, imx27-camera.0); + clk_register_clkdev(clk[per4_gate], per, imx27-camera.0); clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc); clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc); clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc); Cheers, 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 v4 2/2] mx2_camera: Fix regression caused by clock conversion
Em Tue, 30 Oct 2012 10:03:26 -0200
Fabio Estevam fabio.este...@freescale.com escreveu:
Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
By not doing so the camera sensor does not probe correctly:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
mx2-camera mx2-camera.0: Camera driver attached to camera 0
ov2640 0-0030: Product ID error fb:fb
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
6650
Adapt the mx2_camera driver to the new clock framework and make it functional
again.
Tested-by: Gaëtan Carlier gcem...@gmail.com
Tested-by: Javier Martin javier.mar...@vista-silicon.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
As it seems that those patches depend on some patches at the arm tree,
the better is to merge them via -arm tree.
So,
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
---
Changes since v3:
- Drop unneeded clk_unprepare calls as pointed out by Guennadi
Changes since v2:
- Fix clock error handling code as pointed out by Russell King
Changes since v1:
- Rebased against linux-next 20121008.
drivers/media/platform/soc_camera/mx2_camera.c | 39
++--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index e575ae8..558f6a3 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -278,7 +278,8 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_csi_ahb, *clk_csi_per;
void __iomem*base_csi, *base_emma;
@@ -464,7 +465,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable_unprepare(pcdev-clk_csi);
+ clk_disable_unprepare(pcdev-clk_csi_ahb);
+ clk_disable_unprepare(pcdev-clk_csi_per);
writel(0, pcdev-base_csi + CSICR1);
if (is_imx27_camera(pcdev)) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -492,10 +494,14 @@ static int mx2_camera_add_device(struct
soc_camera_device *icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_prepare_enable(pcdev-clk_csi);
+ ret = clk_prepare_enable(pcdev-clk_csi_ahb);
if (ret 0)
return ret;
+ ret = clk_prepare_enable(pcdev-clk_csi_per);
+ if (ret 0)
+ goto exit_csi_ahb;
+
csicr1 = CSICR1_MCLKEN;
if (is_imx27_camera(pcdev))
@@ -512,6 +518,11 @@ static int mx2_camera_add_device(struct
soc_camera_device *icd)
icd-devnum);
return 0;
+
+exit_csi_ahb:
+ clk_disable_unprepare(pcdev-clk_csi_ahb);
+
+ return ret;
}
static void mx2_camera_remove_device(struct soc_camera_device *icd)
@@ -1772,10 +1783,17 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
break;
}
- pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
+ pcdev-clk_csi_ahb = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi_ahb)) {
+ dev_err(pdev-dev, Could not get csi ahb clock\n);
+ err = PTR_ERR(pcdev-clk_csi_ahb);
+ goto exit;
+ }
+
+ pcdev-clk_csi_per = devm_clk_get(pdev-dev, per);
+ if (IS_ERR(pcdev-clk_csi_per)) {
+ dev_err(pdev-dev, Could not get csi per clock\n);
+ err = PTR_ERR(pcdev-clk_csi_per);
goto exit;
}
@@ -1785,12 +1803,13 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
pcdev-platform_flags = pcdev-pdata-flags;
- rate = clk_round_rate(pcdev-clk_csi, pcdev-pdata-clk * 2);
+ rate = clk_round_rate(pcdev-clk_csi_per,
+ pcdev-pdata-clk * 2);
if (rate = 0) {
err = -ENODEV;
goto exit;
}
- err = clk_set_rate(pcdev-clk_csi, rate);
+ err = clk_set_rate(pcdev-clk_csi_per, rate);
if (err 0)
goto exit;
}
@@ -1848,7 +1867,7 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit_free_emma;
dev_info(pdev-dev, MX2 Camera (CSI) driver probed, clock frequency:
%ld\n,
- clk_get_rate(pcdev-clk_csi));
[GIT PULL] soc-camera + VEU for 3.8
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 drivers/media/platform/soc_camera/Kconfig |1 + drivers/media/platform/soc_camera/soc_camera.c | 10 +- include/media/mt9v022.h| 16 + 9 files changed, 1426 insertions(+), 19 deletions(-) create mode 100644 drivers/media/platform/sh_veu.c create mode 100644 include/media/mt9v022.h 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: [PATCH 00/23] em28xx: add support fur USB bulk transfers
Hi Benny, Am 31.10.2012 03:39, schrieb Benny Amorsen: Frank Schäfer fschaefer@googlemail.com writes: This patch series adds support for USB bulk transfers to the em28xx driver. I tried these patches on my Raspberry Pi, 3.6.1 kernel, Nanostick 290e Thank you for testing ! options em28xx prefer_bulk=1 core_debug=1 usb_debug=1 options em28xx_dvb debug=1 [5.469510] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [5.890637] em28xx: DVB interface 0 found [6.025292] em28xx #0: chip ID is em28174 [6.515383] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [6.567066] em28xx #0: v4l2 driver version 0.1.3 [6.614720] em28xx #0 em28xx_set_alternate :minimum isoc packet size: 2888 (alt=0) [6.663064] em28xx #0 em28xx_set_alternate :setting alternate 0 with wMaxPacketSize=0 [6.715934] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [6.765694] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [6.793060] em28xx #0: V4L2 video device registered as video0 [6.808200] em28xx #0 em28xx_alloc_urbs :em28xx: called em28xx_alloc_isoc in mode 2 [6.819456] em28xx #0: no endpoint for DVB mode and transfer type 1 [6.829283] em28xx: Failed to pre-allocate USB transfer buffers for DVB. [6.839454] em28xx: probe of 1-1.3.1:1.0 failed with error -22 [6.852511] usbcore: registered new interface driver em28xx [7.255738] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [7.291575] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [7.326200] em28xx #0 em28xx_uninit_usb_xfer :em28xx: called em28xx_uninit_usb_xfer in mode 1 Is the Nanostick 290e just fundamentally incompatible with bulk transfers, or is there hope yet? It seems like your device has no bulk endpoint for DVB. What does lsusb say ? The module parameter is called prefer_bulk, but what it actually does is force bulk (which doesn't make much sense when the device has no bulk endpoints). I will fix this in v2 of the patch series. It works great with isochronous transfers on my PC and the Fedora kernel, but the Raspberry USB host blows up when trying to do isochronous mode. Is this a regression caused by patches or a general issue with the Raspberry board ? Regards, Frank /Benny -- 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 Laurent
Thanks for the review
On Wed, 31 Oct 2012, Laurent Pinchart wrote:
Hi Guennadi,
Thanks for the patch.
On Tuesday 30 October 2012 15:18:38 Guennadi Liakhovetski wrote:
Typical video devices like camera sensors require an external clock source.
Many such devices cannot even access their hardware registers without a
running clock. These clock sources should be controlled by their consumers.
This should be performed, using the generic clock framework. Unfortunately
so far only very few systems have been ported to that framework. This patch
adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
Platforms, adopting the clock API, should switch to using it. Eventually
this temporary API should be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2: integrated most fixes from Sylwester Laurent,
(1) do not register identical clocks
(2) add clock refcounting
(3) more robust locking
(4) duplicate strings to prevent dereferencing invalid memory
(5) add a private data pointer
(6) return an error in get_rate() / set_rate() if clock isn't enabled
(7) support .id=NULL per subdevice
Thanks to all reviewers!
drivers/media/v4l2-core/Makefile |2 +-
drivers/media/v4l2-core/v4l2-clk.c | 169 +
include/media/v4l2-clk.h | 51 +++
3 files changed, 221 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
create mode 100644 include/media/v4l2-clk.h
diff --git a/drivers/media/v4l2-core/Makefile
b/drivers/media/v4l2-core/Makefile index 00f64d6..cb5fede 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -5,7 +5,7 @@
tuner-objs := tuner-core.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
\
- v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
+ v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
diff --git a/drivers/media/v4l2-core/v4l2-clk.c
b/drivers/media/v4l2-core/v4l2-clk.c new file mode 100644
index 000..2496807
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-clk.c
@@ -0,0 +1,169 @@
+/*
+ * V4L2 clock service
+ *
+ * Copyright (C) 2012, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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/atomic.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/string.h
+
+#include media/v4l2-clk.h
+#include media/v4l2-subdev.h
+
+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.
+static struct v4l2_clk *v4l2_clk_find(const char *dev_id, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ list_for_each_entry(clk, v4l2_clk, list) {
+ if (strcmp(dev_id, clk-dev_id))
+ continue;
+
+ if (!id || !clk-id || !strcmp(clk-id, id))
If id != NULL and clk-id == NULL, the unnamed clock will be returned even
though the caller requests a named clock. Isn't that a mistake ?
If clk-id == NULL this means it's the only clock with this dev_id. We
definitely don't want to allow multiple clocks on one subdev, of which one
has clk-id == NULL. If we don't return a valid pointer here,
v4l2_clk_register() will decide, that there's no conflict and register
this clock, which would be an error. As for v4l2_clk_get() - not sure in
fact. Looking at drivers/clk/clkdev.c::clk_find() if you call
clk_get(dev, con-id) and you've got a clock lookup entry registered with
matching device ID and NULL connection ID, it will match. So, I don't
think it's too important, we can choose either way.
+ return clk;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
+struct v4l2_clk *v4l2_clk_get(struct v4l2_subdev *sd, const char *id)
+{
+ struct v4l2_clk *clk;
+
+ mutex_lock(clk_lock);
+ clk = v4l2_clk_find(sd-name, id);
+
+ if (!IS_ERR(clk) !try_module_get(clk-ops-owner))
+ clk = ERR_PTR(-ENODEV);
+ mutex_unlock(clk_lock);
+
+ return clk;
+}
+EXPORT_SYMBOL(v4l2_clk_get);
+
+void v4l2_clk_put(struct v4l2_clk *clk)
+{
+ if (!IS_ERR(clk))
+ module_put(clk-ops-owner);
+}
+EXPORT_SYMBOL(v4l2_clk_put);
+
+int
Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers
Am 31.10.2012 12:57, schrieb Ezequiel Garcia: On Tue, Oct 30, 2012 at 10:39 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Frank Schäfer fschaefer@googlemail.com writes: This patch series adds support for USB bulk transfers to the em28xx driver. I tried these patches on my Raspberry Pi, 3.6.1 kernel, Nanostick 290e options em28xx prefer_bulk=1 core_debug=1 usb_debug=1 options em28xx_dvb debug=1 [5.469510] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [5.890637] em28xx: DVB interface 0 found [6.025292] em28xx #0: chip ID is em28174 [6.515383] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [6.567066] em28xx #0: v4l2 driver version 0.1.3 [6.614720] em28xx #0 em28xx_set_alternate :minimum isoc packet size: 2888 (alt=0) [6.663064] em28xx #0 em28xx_set_alternate :setting alternate 0 with wMaxPacketSize=0 [6.715934] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [6.765694] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [6.793060] em28xx #0: V4L2 video device registered as video0 [6.808200] em28xx #0 em28xx_alloc_urbs :em28xx: called em28xx_alloc_isoc in mode 2 [6.819456] em28xx #0: no endpoint for DVB mode and transfer type 1 [6.829283] em28xx: Failed to pre-allocate USB transfer buffers for DVB. [6.839454] em28xx: probe of 1-1.3.1:1.0 failed with error -22 [6.852511] usbcore: registered new interface driver em28xx [7.255738] em28xx #0 em28xx_accumulator_set :em28xx Scale: (1,1)-(179,143) [7.291575] em28xx #0 em28xx_capture_area_set :em28xx Area Set: (180,144) [7.326200] em28xx #0 em28xx_uninit_usb_xfer :em28xx: called em28xx_uninit_usb_xfer in mode 1 Is the Nanostick 290e just fundamentally incompatible with bulk transfers, or is there hope yet? It works great with isochronous transfers on my PC and the Fedora kernel, but the Raspberry USB host blows up when trying to do isochronous mode. Isn't this completely OT? Anyway, RPI has known issues regarding USB bandwidth. See here https://github.com/ezequielgarcia/stk1160-standalone/issues/8 https://github.com/ezequielgarcia/stk1160-standalone/issues/2 http://www.raspberrypi.org/phpBB3/viewtopic.php?p=196918#p196918 For DVB, the em28xx always selects the alternate setting with the largest wMaxPacketSize. There is a module parameter 'alt' to select it manually for experiments, but the current code unfortunately applies it for analog capturing only. :( Hope this helps, Frank Regards, Ezequiel -- 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: [media-workshop] Tentative Agenda for the November workshop
Hi all On Mon, 22 Oct 2012, Guennadi Liakhovetski wrote: On Mon, 22 Oct 2012, Hans Verkuil wrote: Hi all, This is the tentative agenda for the media workshop on November 8, 2012. If you have additional things that you want to discuss, or something is wrong or incomplete in this list, please let me know so I can update the list. - Explain current merging process (Mauro) - Open floor for discussions on how to improve it (Mauro) - Write down minimum requirements for new V4L2 (and DVB?) drivers, both for staging and mainline acceptance: which frameworks to use, v4l2-compliance, etc. (Hans Verkuil) - V4L2 ambiguities (Hans Verkuil) - TSMux device (a mux rather than a demux): Alain Volmat - dmabuf status, esp. with regards to being able to test (Mauro/Samsung) - Device tree support (Guennadi, not known yet whether this topic is needed) + asynchronous probing, I guess. It's probably implicitly included though. As the meeting approaches, it would be good to have a decision - do we want to discuss DT / async or not? My flights this time are not quite long enough to prepare for the discussion on them;-) Thanks Guennadi - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available) For those whose name is behind a topic: please prepare something before the meeting. We have currently 17 or 18 attendees of a maximum of 25, so there is room for a few more people. Regards, Hans ___ media-workshop mailing list media-works...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- 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: [RFC 0/5] Generic panel framework
Hi Tomi,
On Wednesday 19 September 2012 14:45:29 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
Hi everybody,
While working on DT bindings for the Renesas Mobile SoC display controller
(a.k.a. LCDC) I quickly realized that display panel implementation based
on board code callbacks would need to be replaced by a driver-based panel
framework.
I thought I'd try to approach the common panel framework by creating
device tree examples that OMAP would need. I only thought about the
connections and organization, not individual properties, so I have not
filled any compatible or such properties.
What I have below is first DT data for OMAP SoC (more or less what omap4
has), then display examples of different board setups. The hardware
examples I have here are all real, so no imaginary use cases =).
We don't need to implement support for all these at once, but I think
the DT data structure should be right from the start, so I'm posting
this to get discussion about the format.
Thank you for working on this proposal.
OMAP SoC
So here's first the SoC specific display nodes. OMAP has a DSS (display
subsystem) block, which contains the following elements:
- DISPC (display controller) reads the pixels from memory and outputs
them using specified video timings. DISPC has three outputs, LCD0, LCD1
and TV. These are SoC internal outputs, they do not go outside the SoC.
- DPI gets its data from DISPC's LCD0, and outputs MIPI DPI (parallel
RBG)
- Two independent DSI modules, which get their data from LCD0 or LCD1,
and output MIPI DSI (a serial two-way video bus)
- HDMI, gets data from DISPC's TV output and outputs HDMI
/ {
ocp {
dss {
dispc {
dss-lcd0: output@0 {
};
dss-lcd1: output@1 {
};
dss-tv: output@2 {
};
};
dpi: dpi {
video-source = dss-lcd0;
};
dsi0: dsi@0 {
video-source = dss-lcd0;
};
dsi1: dsi@1 {
video-source = dss-lcd1;
};
hdmi: hdmi {
video-source = dss-tv;
};
};
};
};
I have defined all the relevant nodes, and video-source property is used
to point to the source for video data. I also define aliases for the SoC
outputs so that panels can use them.
One thing to note is that the video sources for some of the blocks, like
DSI, are not hardcoded in the HW, so dsi0 could get its data from LCD0
or LCD1.
What about the source that are hardwired in hardware ? Shouldn't those be
hardcoded in the driver instead ?
However, I don't think they are usually changed during runtime, and the dss
driver cannot change them independently for sure (meaning that some upper
layer should tell it how to change the config). Thus I specify sane defaults
here, but the board dts files can of course override the video sources.
I'm not sure whether default settings like those really belong to the DT. I'm
no expert on that topic though.
Another thing to note is that we have more outputs from OMAP than we have
outputs from DISPC. This means that the same video source is used by
multiple sinks (LCD0 used by DPI and DSI0). DPI and DSI0 cannot be used at
the same time, obviously.
It might not be really obvious, as I don't see what prevents DPI and DSI0 to
be used at the same time :-) Do they share physical pins ?
And third thing to note, DISPC node defines outputs explicitly, as it has
multiple outputs, whereas the external outputs do not as they have only one
output. Thus the node's output is implicitly the node itself. So, instead of
having:
ds0: dsi@0 {
video-source = dss-lcd0;
dsi0-out0: output@0 {
};
};
I have:
dsi0: dsi@0 {
video-source = dss-lcd0;
};
What about defining the data sinks instead of the data sources ? I find it
more logical for the DSS to get the panel it's connected to than the other way
around.
Of this I'm a bit unsure. I believe in most cases there's only one output,
so it'd be nice to have a shorter representation, but I'm not sure if it's
good to handle the cases for single and multiple outputs differently. Or if
it's good to mix control and data busses, as, for example, dsi0 can be used
as both control and data bus. Having the output defined explicitly would
separate the control and data bus nodes.
Simple DPI panel
Here a board has a DPI panel, which is controlled via i2c. Panel nodes
are children of the control bus, so in this case we
Re: [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Hi Mauro, On Wed, Oct 31, 2012 at 09:56:32AM -0200, Mauro Carvalho Chehab wrote: Em Tue, 30 Oct 2012 10:03:25 -0200 Fabio Estevam fabio.este...@freescale.com escreveu: During the clock conversion for mx27 the per4_gate clock was missed to get registered as a dependency of mx2-camera driver. In the old mx27 clock driver we used to have: DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, csi_clk1, per4_clk); ,so does the same in the new clock driver Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Sascha Hauer s.ha...@pengutronix.de As it seems that those patches depend on some patches at the arm tree, the better is to merge them via -arm tree. Quoting yourself: Forgot to comment: as patch 2 relies on this change, the better, IMHO, is to send both via the same tree. If you decide to do so, please get arm maintainer's ack, instead, and we can merge both via my tree. That's why Fabio resent these patches with my Ack. You are free to take these. 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
Way to request a time discontinuity in a V4L2 encoder device
Hi all, We have developed a V4L2 mem2mem driver for an H264 encoder running on an IP of one of our SoC and would like to have one more v4l2_buffer flag value for that. In the context of this driver, we discovered that the current V4L2 encode API is missing the feature to mention to the IP that a time discontinuity has to be created. Time discontinuity must be triggered when there is a discontinuity in the stream to be encoded, which would for example happen when there is a seek in the data to be encoded. In such case, it means that the IP should reset its bitrate allocation algorithm. Considering that this information should be triggered on a frame basis, the idea is to have it passed via the flags member of v4l2_buffer, with a new flag V4L2_BUF_FLAG_ENCODE_TIME_DISCONTINUITY. The usage for this flag value are: * Queuing a to be encoded v4l2_buffer with flags V4L2_BUF_FLAG_ENCODE_TIME_DISCONTINUITY informs the driver/IP that a time discontinuity (reset in the bitrate allocation algorithm) should be performed before encoding this frame. * The flags bit should be then propagated until the dequeue to let the application know when a buffer is the first one after a time discontinuity. Few words about the driver itself, it is available in the following context. 1. STLinux kernel (www.stlinux.com) rather than vanilla kernel since the board support is only available there for now 2. Multicom (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD18182595.pdf) based V4L2 driver. Multicom is an ST layer to allow to send and serialize commands to our various IP. Regards, Alain -- 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 v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Hi Sascha, On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Quoting yourself: Forgot to comment: as patch 2 relies on this change, the better, IMHO, is to send both via the same tree. If you decide to do so, please get arm maintainer's ack, instead, and we can merge both via my tree. That's why Fabio resent these patches with my Ack. You are free to take these. I have just realized that this patch (1/2) will not apply against media tree because it does not have commit 27b76486a3 (media: mx2_camera: remove cpu_is_xxx by using platform_device_id), which changes from mx2_camera.0 to imx27-camera.0. So it seems to be better to merge this via arm tree to avoid such conflict. Regards, Fabio Estevam -- 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 0/5] Generic panel framework
Hi Inki, On Saturday 20 October 2012 22:10:17 Inki Dae wrote: Hi Laurent. sorry for being late. No worries. 2012/8/17 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi everybody, While working on DT bindings for the Renesas Mobile SoC display controller (a.k.a. LCDC) I quickly realized that display panel implementation based on board code callbacks would need to be replaced by a driver-based panel framework. Several driver-based panel support solution already exist in the kernel. - The LCD device class is implemented in drivers/video/backlight/lcd.c and exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV API for historical reason, uses board code callback for reset and power management, and doesn't include support for standard features available in today's smart panels. - OMAP2+ based systems use custom panel drivers available in drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display controller) specific APIs. - Similarly, Exynos based systems use custom panel drivers available in drivers/video/exynos. Only a single driver (s6e8ax0) is currently available. That driver is based on Exynos display controller specific APIs and on the LCD device class API. I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus Lorentzon (working on panel support for ST/Linaro), and we agreed that a generic panel framework for display devices is needed. These patches implement a first proof of concept. One of the main reasons for creating a new panel framework instead of adding missing features to the LCD framework is to avoid being tied to the FBDEV framework. Panels will be used by DRM drivers as well, and their API should thus be subsystem-agnostic. Note that the panel framework used the fb_videomode structure in its API, this will be replaced by a common video mode structure shared across subsystems (there's only so many hours per day). Panels, as used in these patches, are defined as physical devices combining a matrix of pixels and a controller capable of driving that matrix. Panel physical devices are registered as children of the control bus the panel controller is connected to (depending on the panel type, we can find platform devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... devices). The generic panel framework matches registered panel devices with panel drivers and call the panel drivers probe method, as done by other device classes in the kernel. The driver probe() method is responsible for instantiating a struct panel instance and registering it with the generic panel framework. Display drivers are panel consumers. They register a panel notifier with the framework, which then calls the notifier when a matching panel is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the panel can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling panel through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display and panel drivers would take a reference to each other. Those circular references would make driver unloading impossible. I haven't found a good solution for that problem yet (hence the RFC state of those patches), and I would appreciate your input here. This might also be a hint that the framework design is wrong to start with. I guess I can't get everything right on the first try ;-) Getting hold of the panel is the most complex part. Once done, display drivers can call abstract operations provided by panel drivers to control the panel operation. These patches implement three of those operations (enable, start transfer and get modes). More operations will be needed, and those three operations will likely get modified during review. Most of the panels on devices I own are dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. In addition to the generic panel core, I've implemented MIPI DBI (Display Bus Interface, a parallel bus for panels that supports read/write transfers of commands and data) bus support, as well as three panel drivers (dummy panels with no control bus, and Renesas R61505- and R61517-based panels, both using DBI as their control bus). Only the dummy panel driver has been tested as I lack
Re: [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
On Wed, 31 Oct 2012, Fabio Estevam wrote: Hi Sascha, On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Quoting yourself: Forgot to comment: as patch 2 relies on this change, the better, IMHO, is to send both via the same tree. If you decide to do so, please get arm maintainer's ack, instead, and we can merge both via my tree. That's why Fabio resent these patches with my Ack. You are free to take these. I have just realized that this patch (1/2) will not apply against media tree because it does not have commit 27b76486a3 (media: mx2_camera: remove cpu_is_xxx by using platform_device_id), which changes from mx2_camera.0 to imx27-camera.0. This is exactly the reason why I wasn't able to merge it. The problem was, that this media: mx2_camera: remove cpu_is_xxx by using platform_device_id patch non-trivially touched both arch/arm/ and drivers/media/ directories. And being patch 27/34 I didn't feel like asking the author to redo it again:-) This confirms, that it's better to avoid such overlapping patches whenever possible. So it seems to be better to merge this via arm tree to avoid such conflict. Thanks Guennadi Regards, Fabio Estevam --- 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: [RFC 0/5] Generic panel framework
On 2012-10-31 15:13, Laurent Pinchart wrote:
OMAP SoC
So here's first the SoC specific display nodes. OMAP has a DSS (display
subsystem) block, which contains the following elements:
- DISPC (display controller) reads the pixels from memory and outputs
them using specified video timings. DISPC has three outputs, LCD0, LCD1
and TV. These are SoC internal outputs, they do not go outside the SoC.
- DPI gets its data from DISPC's LCD0, and outputs MIPI DPI (parallel
RBG)
- Two independent DSI modules, which get their data from LCD0 or LCD1,
and output MIPI DSI (a serial two-way video bus)
- HDMI, gets data from DISPC's TV output and outputs HDMI
/ {
ocp {
dss {
dispc {
dss-lcd0: output@0 {
};
dss-lcd1: output@1 {
};
dss-tv: output@2 {
};
};
dpi: dpi {
video-source = dss-lcd0;
};
dsi0: dsi@0 {
video-source = dss-lcd0;
};
dsi1: dsi@1 {
video-source = dss-lcd1;
};
hdmi: hdmi {
video-source = dss-tv;
};
};
};
};
I have defined all the relevant nodes, and video-source property is used
to point to the source for video data. I also define aliases for the SoC
outputs so that panels can use them.
One thing to note is that the video sources for some of the blocks, like
DSI, are not hardcoded in the HW, so dsi0 could get its data from LCD0
or LCD1.
What about the source that are hardwired in hardware ? Shouldn't those be
hardcoded in the driver instead ?
Even if both the DSI and the DISPC are parts of OMAP DSS, and part of
the SoC, they are separate IPs. We should look at them the same way we'd
consider chips that are outside the SoC.
So things that are internal to a device can (and I think should) be
hardcoded in the driver, but integration details, the connections
between the IPs, etc, should be described in the DT data.
Then again, we do have (and need) a driver for the dss node in the
above DT data. This dss represents dss_core, a glue IP that contains
the rest of the DSS blocks and muxes and such. It could be argued that
this dss_core driver does indeed know the integration details, and thus
there's no need to represent them in the DT data.
However, I do think that we should represent the DISPC outputs with
generic display entities inside CPF, just like DSI and the panels. And
we do need to set the connections between these entities. So the
question is, do we get those connections from the DT data, or are they
hardcoded in the dss_core driver.
I don't currently have strong opinions on either direction. Both make
sense to me. But I think this is SoC driver implementation specific, and
the common panel framework doesn't need to force this to either
direction. Both should be possible from CPF's point of view.
However, I don't think they are usually changed during runtime, and the dss
driver cannot change them independently for sure (meaning that some upper
layer should tell it how to change the config). Thus I specify sane defaults
here, but the board dts files can of course override the video sources.
I'm not sure whether default settings like those really belong to the DT. I'm
no expert on that topic though.
I agree. But I also don't have a good solution how the driver would find
good choices for these settings...
Another thing to note is that we have more outputs from OMAP than we have
outputs from DISPC. This means that the same video source is used by
multiple sinks (LCD0 used by DPI and DSI0). DPI and DSI0 cannot be used at
the same time, obviously.
It might not be really obvious, as I don't see what prevents DPI and DSI0 to
be used at the same time :-) Do they share physical pins ?
I think they do, but even if they didn't, there's just one source for
two outputs. So if the SoC design is such that the only video source for
DPI is LCD0, and the only video source for DSI0 is LCD0, and presuming
you can't send the video data to both destinations, then only one of DPI
and DSI0 can be enabled at the same time.
Even if the LCD0 could send the pixel stream to both DPI and DSI0, it'd
be interesting, because the original video timings and pixel clock are
programmed in the LCD0 output, and thus both DPI and DSI0 get the same
timings. If DPI would want to use some other mode, DSI would most likely
go nuts.
So my opinion is that we should only allow 1:1 connections between
sources and sinks. If a component has multiple outputs, and even if
those outputs give the exact same data, it should define
RE: [PATCH v7 5/8] fbmon: add videomode helpers
Hi Steffen,
On Wed, Oct 31, 2012 at 14:58:05, 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
---
drivers/video/fbmon.c | 36
include/linux/fb.h|2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..b9e6ab3 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1373,6 +1373,42 @@ 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 videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode)
+{
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
+
+ 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;
+
pixelclk-inverted property of the panel is not percolated fb_videomode.
Please let me know if I am missing something.
Thanks,
Prakash
+ fbmode-refresh = 60;
+ fbmode-flag = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_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 c7a9571..46c665b 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -714,6 +714,8 @@ 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);
+extern int videomode_to_fb_videomode(struct videomode *vm, struct
fb_videomode *fbmode);
+
/* 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-fbdev 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] staging: media: Fix minor typo in staging/media
Correct spelling typo in comment witin staging/media.
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/staging/media/as102/as10x_cmd_cfg.c | 2 +-
drivers/staging/media/dt3155v4l/dt3155v4l.c | 2 +-
drivers/staging/media/lirc/lirc_sasem.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/as102/as10x_cmd_cfg.c
b/drivers/staging/media/as102/as10x_cmd_cfg.c
index d2a4bce..4a2bbd7 100644
--- a/drivers/staging/media/as102/as10x_cmd_cfg.c
+++ b/drivers/staging/media/as102/as10x_cmd_cfg.c
@@ -197,7 +197,7 @@ out:
* @prsp: pointer to AS10x command response buffer
* @proc_id:id of the command
*
- * Since the contex command reponse does not follow the common
+ * Since the contex command response does not follow the common
* response, a specific parse function is required.
* Return 0 on success or negative value in case of error.
*/
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 2e7b711..0ce1fc5 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -783,7 +783,7 @@ dt3155_init_board(struct pci_dev *pdev)
}
write_i2c_reg(pd-regs, CONFIG, pd-config); /* ACQ_MODE_EVEN */
- /* select chanel 1 for input and set sync level */
+ /* select channel 1 for input and set sync level */
write_i2c_reg(pd-regs, AD_ADDR, AD_CMD_REG);
write_i2c_reg(pd-regs, AD_CMD, VIDEO_CNL_1 | SYNC_CNL_1 | SYNC_LVL_3);
diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c
index f4e4d90..101ac12 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -891,7 +891,7 @@ exit:
}
/**
- * Callback function for USB core API: disonnect
+ * Callback function for USB core API: disconnect
*/
static void sasem_disconnect(struct usb_interface *interface)
{
--
1.8.0.rc3.16.g8ead1bf
--
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 v7 5/8] fbmon: add videomode helpers
Hi Prakash!
On Wed, Oct 31, 2012 at 03:30:03PM +, Manjunathappa, Prakash wrote:
Hi Steffen,
On Wed, Oct 31, 2012 at 14:58:05, 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
---
drivers/video/fbmon.c | 36
include/linux/fb.h|2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..b9e6ab3 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1373,6 +1373,42 @@ 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 videomode_to_fb_videomode(struct videomode *vm, struct fb_videomode
*fbmode)
+{
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
+
+ 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;
+
pixelclk-inverted property of the panel is not percolated fb_videomode.
Please let me know if I am missing something.
You are right. I forgot that :(
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 v7 1/8] video: add display_timing struct and helpers
Hi Steffen,
Thanks for the patch.
As we'll need a v8 anyway due to the comment on patch 5/8, here are a couple
of other small comments.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Every timing parameter can be specified as a single value or a range
min typ max.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/Kconfig |5 +++
drivers/video/Makefile |1 +
drivers/video/display_timing.c | 24 ++
include/linux/display_timing.h | 69 +
4 files changed, 99 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 include/linux/display_timing.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..1421fc8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,11 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool Enable display timings helpers
+ help
+ Say Y here, to use the display timing helpers.
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..552c045 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,4 @@ 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
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..9ccfdb3
--- /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/slab.h
+#include linux/display_timing.h
I try to keep #include's sorted alphabetically, but I won't push for that.
+void timings_release(struct display_timings *disp)
+{
+ int i;
+
+ for (i = 0; i disp-num_timings; i++)
disp-num_timings is an unsigned int, i should be an unsigned int as well to
avoid signed vs. unsigned comparisons.
+ kfree(disp-timings[i]);
+}
+
+void display_timings_release(struct display_timings *disp)
+{
+ timings_release(disp);
+ kfree(disp-timings);
+}
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..aa02a12
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include linux/types.h
+
+struct timing_entry {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct display_timing {
+ struct timing_entry pixelclock;
+
+ struct timing_entry hactive;
+ struct timing_entry hfront_porch;
+ struct timing_entry hback_porch;
+ struct timing_entry hsync_len;
+
+ struct timing_entry vactive;
+ struct timing_entry vfront_porch;
+ struct timing_entry vback_porch;
+ struct timing_entry vsync_len;
+
+ unsigned int vsync_pol_active;
+ unsigned int hsync_pol_active;
+ unsigned int de_pol_active;
+ unsigned int pixelclk_pol;
+ bool interlaced;
+ bool doublescan;
+};
+
+struct display_timings {
+ unsigned int num_timings;
+ unsigned int native_mode;
+
+ struct display_timing **timings;
+};
+
+/* placeholder function until ranges are really needed */
+static inline u32 display_timing_get_value(struct timing_entry *te, int
index)
What is the index parameter for ?
+{
+ return te-typ;
+}
+
+static inline struct display_timing *display_timings_get(struct
display_timings *disp,
+ int index)
+{
+ struct display_timing *dt;
+
+ if (disp-num_timings index) {
index should be an unsigned int for the same reason as above.
+ dt = disp-timings[index];
+ return dt;
Maybe just
return disp-timings[index];
?
+ } else
+ return NULL;
+}
+
+void timings_release(struct display_timings *disp);
+void display_timings_release(struct display_timings *disp);
+
+#endif
--
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 v7 1/8] video: add display_timing struct and helpers
Hi Steffen,
One more comment.
On Wednesday 31 October 2012 10:28:01 Steffen Trumtrar wrote:
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Every timing parameter can be specified as a single value or a range
min typ max.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/Kconfig |5 +++
drivers/video/Makefile |1 +
drivers/video/display_timing.c | 24 ++
include/linux/display_timing.h | 69 +
4 files changed, 99 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 include/linux/display_timing.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..1421fc8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,11 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool Enable display timings helpers
+ help
+ Say Y here, to use the display timing helpers.
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..552c045 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,4 @@ 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
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..9ccfdb3
--- /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/slab.h
+#include linux/display_timing.h
+
+void timings_release(struct display_timings *disp)
+{
+ int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+}
This function doesn't seem to be called externally, you can make it static.
+void display_timings_release(struct display_timings *disp)
+{
+ timings_release(disp);
+ kfree(disp-timings);
+}
diff --git a/include/linux/display_timing.h b/include/linux/display_timing.h
new file mode 100644
index 000..aa02a12
--- /dev/null
+++ b/include/linux/display_timing.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * description of display timings
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_DISPLAY_TIMINGS_H
+#define __LINUX_DISPLAY_TIMINGS_H
+
+#include linux/types.h
+
+struct timing_entry {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct display_timing {
+ struct timing_entry pixelclock;
+
+ struct timing_entry hactive;
+ struct timing_entry hfront_porch;
+ struct timing_entry hback_porch;
+ struct timing_entry hsync_len;
+
+ struct timing_entry vactive;
+ struct timing_entry vfront_porch;
+ struct timing_entry vback_porch;
+ struct timing_entry vsync_len;
+
+ unsigned int vsync_pol_active;
+ unsigned int hsync_pol_active;
+ unsigned int de_pol_active;
+ unsigned int pixelclk_pol;
+ bool interlaced;
+ bool doublescan;
+};
+
+struct display_timings {
+ unsigned int num_timings;
+ unsigned int native_mode;
+
+ struct display_timing **timings;
+};
+
+/* placeholder function until ranges are really needed */
+static inline u32 display_timing_get_value(struct timing_entry *te, int
index) +{
+ return te-typ;
+}
+
+static inline struct display_timing *display_timings_get(struct
display_timings *disp, +
int index)
+{
+ struct display_timing *dt;
+
+ if (disp-num_timings index) {
+ dt = disp-timings[index];
+ return dt;
+ } else
+ return NULL;
+}
+void timings_release(struct display_timings *disp);
+void display_timings_release(struct display_timings *disp);
+
+#endif
--
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 v7 4/8] video: add videomode helpers
Hi Steffen,
Thanks for the patch.
On Wednesday 31 October 2012 10:28:04 Steffen Trumtrar wrote:
Add helper functions to convert from display timings to a generic videomode
structure. This videomode can then be converted to the corresponding
subsystem mode representation (e.g. fb_videomode).
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile|1 +
drivers/video/videomode.c | 44 ++
include/linux/videomode.h | 36
4 files changed, 87 insertions(+)
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1421fc8..45dd393 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -38,6 +38,12 @@ config DISPLAY_TIMING
help
Say Y here, to use the display timing helpers.
+config VIDEOMODE
+ bool Enable videomode helpers
Shouldn't this option should be automatically selected through a select
statement in other options that depend on it instead of manually selected ?
Same for the DISPLAY_TIMING option in 1/8.
There's so little code here, do you think it would be a good idea to merge
patches 1/8 and 4/8 and have a single Kconfig option ?
+ help
+ Say Y here, to use the generic videomode helpers. This allows
+ converting from display timings to fb_videomode and drm_display_mode
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 552c045..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -168,3 +168,4 @@ 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/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..a9fe010
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,44 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de,
Pengutronix + *
+ * This file is released under the GPLv2
+ */
+
+#include linux/kernel.h
+#include linux/export.h
+#include linux/errno.h
+#include linux/display_timing.h
+#include linux/videomode.h
As in 1/8, I try to keep #include's sorted alphabetically, but I won't push
for it here either :-)
+
+int videomode_from_timing(struct display_timings *disp, struct videomode
*vm,
+ int index)
unsigned int for index ?
+{
+ struct display_timing *dt = NULL;
No need to initialize dt to NULL.
+ dt = display_timings_get(disp, index);
+ if (!dt) {
+ pr_err(%s: no signal timings found\n, __func__);
I wonder whether this really deserves a pr_err() here. Would this be a caller
bug, or can there be valid use cases where this function would return an error
?
+ return -EINVAL;
+ }
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, 0);
+ vm-hactive = display_timing_get_value(dt-hactive, 0);
+ vm-hfront_porch = display_timing_get_value(dt-hfront_porch, 0);
+ vm-hback_porch = display_timing_get_value(dt-hback_porch, 0);
+ vm-hsync_len = display_timing_get_value(dt-hsync_len, 0);
+
+ vm-vactive = display_timing_get_value(dt-vactive, 0);
+ vm-vfront_porch = display_timing_get_value(dt-vfront_porch, 0);
+ vm-vback_porch = display_timing_get_value(dt-vback_porch, 0);
+ vm-vsync_len = display_timing_get_value(dt-vsync_len, 0);
+
+ vm-vah = dt-vsync_pol_active;
+ vm-hah = dt-hsync_pol_active;
+ vm-interlaced = dt-interlaced;
+ vm-doublescan = dt-doublescan;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_from_timing);
diff --git a/include/linux/videomode.h b/include/linux/videomode.h
new file mode 100644
index 000..f932147
--- /dev/null
+++ b/include/linux/videomode.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2012 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * generic videomode description
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_VIDEOMODE_H
+#define __LINUX_VIDEOMODE_H
+
+#include linux/display_timing.h
+
+struct videomode {
+ u32 pixelclock;
+ u32 refreshrate;
+
+ u32 hactive;
+ u32 hfront_porch;
+ u32 hback_porch;
+ u32 hsync_len;
+
+ u32 vactive;
+ u32 vfront_porch;
+ u32 vback_porch;
+ u32 vsync_len;
+
+ u32 hah;
+ u32 vah;
+ bool interlaced;
+ bool doublescan;
+};
+
+int videomode_from_timing(struct display_timings *disp, struct videomode
*vm,
+ int index);
+#endif
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list:
Re: Diversity support?
Al 17/10/12 19:12, En/na Luca Olivetti ha escrit: Hello, if I look at the vl4-dvb wiki, it says that diversity isn't currently supported http://www.linuxtv.org/wiki/index.php?title=Special%3ASearchsearch=diversitygo=Go however grepping the git tree there are various mentions of diversity at least for some dibcom based devices: http://git.linuxtv.org/linux-2.6.git?a=searchh=HEADst=greps=diversity So, what's the real status of diversity support? Nobody knows? Bye -- Luca -- 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 v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Em Wed, 31 Oct 2012 14:53:47 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: On Wed, 31 Oct 2012, Fabio Estevam wrote: Hi Sascha, On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Quoting yourself: Forgot to comment: as patch 2 relies on this change, the better, IMHO, is to send both via the same tree. If you decide to do so, please get arm maintainer's ack, instead, and we can merge both via my tree. That's why Fabio resent these patches with my Ack. You are free to take these. I have just realized that this patch (1/2) will not apply against media tree because it does not have commit 27b76486a3 (media: mx2_camera: remove cpu_is_xxx by using platform_device_id), which changes from mx2_camera.0 to imx27-camera.0. This is exactly the reason why I wasn't able to merge it. The problem was, that this media: mx2_camera: remove cpu_is_xxx by using platform_device_id patch non-trivially touched both arch/arm/ and drivers/media/ directories. And being patch 27/34 I didn't feel like asking the author to redo it again:-) This confirms, that it's better to avoid such overlapping patches whenever possible. So it seems to be better to merge this via arm tree to avoid such conflict. I agree with Fabio and Guennadi. There are so many changes happening at arm that merging those two patches there will likely be easier for everybody. Otherwise, I'll need to pull from some arm tree that never rebase, with the needed patches, and coordinate with you during the merge window, to be sure that patches will arrive there at the right order, from the right tree. Cheers, 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 v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
On Wed, Oct 31, 2012 at 04:53:03PM -0200, Mauro Carvalho Chehab wrote: Em Wed, 31 Oct 2012 14:53:47 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: On Wed, 31 Oct 2012, Fabio Estevam wrote: Hi Sascha, On Wed, Oct 31, 2012 at 11:16 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Quoting yourself: Forgot to comment: as patch 2 relies on this change, the better, IMHO, is to send both via the same tree. If you decide to do so, please get arm maintainer's ack, instead, and we can merge both via my tree. That's why Fabio resent these patches with my Ack. You are free to take these. I have just realized that this patch (1/2) will not apply against media tree because it does not have commit 27b76486a3 (media: mx2_camera: remove cpu_is_xxx by using platform_device_id), which changes from mx2_camera.0 to imx27-camera.0. This is exactly the reason why I wasn't able to merge it. The problem was, that this media: mx2_camera: remove cpu_is_xxx by using platform_device_id patch non-trivially touched both arch/arm/ and drivers/media/ directories. And being patch 27/34 I didn't feel like asking the author to redo it again:-) This confirms, that it's better to avoid such overlapping patches whenever possible. So it seems to be better to merge this via arm tree to avoid such conflict. I agree with Fabio and Guennadi. There are so many changes happening at arm that merging those two patches there will likely be easier for everybody. Ok, then I'll take them. I wasn't aware in arm-soc are sitting patches for this driver already. Otherwise, I'll need to pull from some arm tree that never rebase, with the needed patches, and coordinate with you during the merge window, to be sure that patches will arrive there at the right order, from the right tree. Hopefully these kind of cross dependencies become fewer over time. SoC code is getting smaller and gets better abstracted from the drivers, so chances are good. 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 v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Em Wed, 31 Oct 2012 20:02:49 +0100 Sascha Hauer s.ha...@pengutronix.de escreveu: On Wed, Oct 31, 2012 at 04:53:03PM -0200, Mauro Carvalho Chehab wrote: Em Wed, 31 Oct 2012 14:53:47 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: On Wed, 31 Oct 2012, Fabio Estevam wrote: I agree with Fabio and Guennadi. There are so many changes happening at arm that merging those two patches there will likely be easier for everybody. Ok, then I'll take them. I wasn't aware in arm-soc are sitting patches for this driver already. Thank you! Otherwise, I'll need to pull from some arm tree that never rebase, with the needed patches, and coordinate with you during the merge window, to be sure that patches will arrive there at the right order, from the right tree. Hopefully these kind of cross dependencies become fewer over time. SoC code is getting smaller and gets better abstracted from the drivers, so chances are good. Yes, I'm expecting so. 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 00/23] em28xx: add support fur USB bulk transfers
Frank Schäfer fschaefer@googlemail.com writes: It seems like your device has no bulk endpoint for DVB. What does lsusb say ? lsusb mentions 4 different end points, all isochronous. So out of luck there. I did not know I could use lsusb to find this out. The module parameter is called prefer_bulk, but what it actually does is force bulk (which doesn't make much sense when the device has no bulk endpoints). I will fix this in v2 of the patch series. Well, I was hoping to get force_bulk, so that part is not a problem for me. Am 31.10.2012 03:39, schrieb Benny Amorsen: It works great with isochronous transfers on my PC and the Fedora kernel, but the Raspberry USB host blows up when trying to do isochronous mode. Is this a regression caused by patches or a general issue with the Raspberry board ? It is a general issue with the Raspberry USB host controller or driver. Bulk transfers work, isochronous transfers have problems. I was hoping I could somehow convince the Nanostick to use bulk transfers instead of isochronous transfers. Since that seems to require a firmware change, I will have to give up on it. /Benny -- 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 00/23] em28xx: add support fur USB bulk transfers
Ezequiel Garcia elezegar...@gmail.com writes: Isn't this completely OT? It may be off topic, but those issues were the reason I was testing the patches... Anyway, RPI has known issues regarding USB bandwidth. Indeed. Thank you for the links, I had not followed the latest development and did not know about Gordon implementing EHCI in firmware. That will be interesting. /Benny -- 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 00/23] em28xx: add support fur USB bulk transfers
Frank Schäfer fschaefer@googlemail.com writes: For DVB, the em28xx always selects the alternate setting with the largest wMaxPacketSize. There is a module parameter 'alt' to select it manually for experiments, but the current code unfortunately applies it for analog capturing only. :( What is the meaning of alternate setting here? Would I gain anything if the driver was modified to apply alternate setting for DVB as well? /Benny -- 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 00/23] em28xx: add support fur USB bulk transfers
Benny, On Wed, Oct 31, 2012 at 4:58 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Is this a regression caused by patches or a general issue with the Raspberry board ? It is a general issue with the Raspberry USB host controller or driver. Bulk transfers work, isochronous transfers have problems. I was hoping I could somehow convince the Nanostick to use bulk transfers instead of isochronous transfers. Since that seems to require a firmware change, I will have to give up on it. Very interesting. Let me see if I understand this: you say it's not a problem with USB bandwidth, but with isochronous transfers, in the sense it could achieve enough speed for streaming if bulk transfers were used? Do you have any links supporting this? Thanks, Ezequiel -- 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:Wed Oct 31 19:00:23 CET 2012 git hash:8f7e91a31fb95c50880c76505b416630c0326d93 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 00/23] em28xx: add support fur USB bulk transfers
Ezequiel Garcia elezegar...@gmail.com writes: Very interesting. Let me see if I understand this: you say it's not a problem with USB bandwidth, but with isochronous transfers, in the sense it could achieve enough speed for streaming if bulk transfers were used? It is more of a hope than a statement... I have no proof. Do you have any links supporting this? Only old stuff like http://www.mail-archive.com/linux-usb@vger.kernel.org/msg04232.html There are quite a few reports of problems with USB cameras in general and Kinect in particular. That seems to point at problems with isochronous transfers. A typical USB camera does not need particularly much bandwidth. The Nanostick only needs 40Mbps + overhead for me -- the size of the largest MUX in the UK currently. That is less than 10% of the 480Mbps theoretically available. The other problem reports tend to be about full speed (11Mbps) USB devices which are difficult for the Pi hardware to handle. Most of the reports are getting old, some have reported that driver upgrades fixed the problems. I believe most people experience stable ethernet performance (and the ethernet is USB attached as you are undoubtedly aware). That is a lot more demanding than a USB camera or a Nanostick. However, the ethernet chip uses bulk transfers, not isochronous ones. /Benny -- 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 2/2] media: V4L2: support asynchronous subdevice registration
Hi Guennadi,
On 10/29/2012 08:52 AM, Guennadi Liakhovetski wrote:
+/*
+ * Typically this function will be called during bridge driver probing. It
+ * installs bus notifiers to handle asynchronously probing subdevice
drivers.
+ * Once the bridge driver probing completes, subdevice drivers, waiting in
+ * EPROBE_DEFER state are re-probed, at which point they get their
platform
+ * data, which allows them to complete probing.
+ */
+int v4l2_async_group_probe(struct v4l2_async_group *group)
+{
+ struct v4l2_async_subdev *asd, *tmp;
+ bool i2c_used = false, platform_used = false;
+ int ret;
+
+ /* This group is inactive so far - no notifiers yet */
+ list_for_each_entry_safe(asd, tmp,group-group, list) {
+ if (asd-sdpd.subdev) {
+ /* Simulate a BIND event */
+ if (group-bind_cb)
+ group-bind_cb(group, asd);
+
Still we can't be sure at this moment asd-sdpd.subdev's driver is
valid and not unloaded, can we ?
In the case when a sub-device driver is probed after the host driver
(a caller of this function) I assume doing
asd-sdpd.subdev = i2c_get_clientdata(to_i2c_client(dev));
...
ret = v4l2_device_register_subdev(v4l2_dev, asd-sdpd.subdev);
is safe, because it is done in the i2c bus notifier callback itself,
i.e. under device_lock(dev).
But for these already probed sub-devices, how do we prevent races from
subdev module unloading ? By not setting CONFIG_MODULE_UNLOAD?... ;)
Right, I also think there's a race there. I have a solution for it - in
the current mainline version of sh_mobile_ceu_camera.c look at the code
around the line
err = bus_register_notifier(platform_bus_type,wait.notifier);
sh_mobile_ceu_probe(). I think, that guarantees, that we either lock the
module _safely_ in memory per try_module_get(dev-driver-owner) or get
notified, that the module is unavailable. It looks ugly, but I don't have
a better solution ATM. We could do the same here too.
IMHO even ugly solution is better than completely ignoring the problem.
I have some doubts whether your method eliminates the race issue. Firstly,
shouldn't the bus_notify callback [1] be active on BUS_NOTIFY_UNBIND_DRIVER,
rather than US_NOTIFY_UNBOUND_DRIVER ? Upon US_NOTIFY_UNBOUND_DRIVER
dev-driver is already NULL and still it is being referenced in a call to
try_module_get() (line 2224, [1]).
Secondly, what guarantees that before bus_register_notifier() call [1],
we are not already after blocking_notifier_call_chain() (line 504, [2])
which means we miss the notification and the sub-device driver is going
away together with its module under our feet ?
[1]
http://lxr.linux.no/#linux+v3.6/drivers/media/video/sh_mobile_ceu_camera.c#L2055
[2] http://lxr.linux.no/#linux+v3.6/drivers/base/dd.c#L478
--
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 2/2] media: V4L2: support asynchronous subdevice registration
On 11/01/2012 12:09 AM, Sylwester Nawrocki wrote:
Hi Guennadi,
On 10/29/2012 08:52 AM, Guennadi Liakhovetski wrote:
+/*
+ * Typically this function will be called during bridge driver probing. It
+ * installs bus notifiers to handle asynchronously probing subdevice drivers.
+ * Once the bridge driver probing completes, subdevice drivers, waiting in
+ * EPROBE_DEFER state are re-probed, at which point they get their platform
+ * data, which allows them to complete probing.
+ */
+int v4l2_async_group_probe(struct v4l2_async_group *group)
+{
+ struct v4l2_async_subdev *asd, *tmp;
+ bool i2c_used = false, platform_used = false;
+ int ret;
+
+ /* This group is inactive so far - no notifiers yet */
+ list_for_each_entry_safe(asd, tmp,group-group, list) {
+ if (asd-sdpd.subdev) {
+ /* Simulate a BIND event */
+ if (group-bind_cb)
+ group-bind_cb(group, asd);
+
Still we can't be sure at this moment asd-sdpd.subdev's driver is
valid and not unloaded, can we ?
In the case when a sub-device driver is probed after the host driver
(a caller of this function) I assume doing
asd-sdpd.subdev = i2c_get_clientdata(to_i2c_client(dev));
...
ret = v4l2_device_register_subdev(v4l2_dev, asd-sdpd.subdev);
is safe, because it is done in the i2c bus notifier callback itself,
i.e. under device_lock(dev).
But for these already probed sub-devices, how do we prevent races from
subdev module unloading ? By not setting CONFIG_MODULE_UNLOAD?... ;)
Right, I also think there's a race there. I have a solution for it - in
the current mainline version of sh_mobile_ceu_camera.c look at the code
around the line
err = bus_register_notifier(platform_bus_type,wait.notifier);
sh_mobile_ceu_probe(). I think, that guarantees, that we either lock the
module _safely_ in memory per try_module_get(dev-driver-owner) or get
notified, that the module is unavailable. It looks ugly, but I don't have
a better solution ATM. We could do the same here too.
IMHO even ugly solution is better than completely ignoring the problem.
I have some doubts whether your method eliminates the race issue. Firstly,
shouldn't the bus_notify callback [1] be active on BUS_NOTIFY_UNBIND_DRIVER,
rather than US_NOTIFY_UNBOUND_DRIVER ? Upon US_NOTIFY_UNBOUND_DRIVER
dev-driver is already NULL and still it is being referenced in a call to
try_module_get() (line 2224, [1]).
Secondly, what guarantees that before bus_register_notifier() call [1],
we are not already after blocking_notifier_call_chain() (line 504, [2])
which means we miss the notification and the sub-device driver is going
away together with its module under our feet ?
Hmm, please ignore that one, of course in this case dev-driver is NULL
and branch after this line
if (!csi2_pdev-dev.driver) {
is entered.
[1]
http://lxr.linux.no/#linux+v3.6/drivers/media/video/sh_mobile_ceu_camera.c#L2055
[2] http://lxr.linux.no/#linux+v3.6/drivers/base/dd.c#L478
--
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
