Re: [PATCHv13 4/7] fbmon: add videomode helpers
On Fri, Nov 23, 2012 at 12:52:08AM +0100, Laurent Pinchart wrote:
On Friday 23 November 2012 00:09:49 Steffen Trumtrar wrote:
On Thu, Nov 22, 2012 at 07:31:39PM +0100, Laurent Pinchart wrote:
On Thursday 22 November 2012 17:00:12 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/fbmon.c | 44 ++
include/linux/fb.h|6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..a6a564d 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,49 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ fbmode-pixclock = KHZ2PICOS(vm-pixelclock / 1000);
This results in a division by 0 if vm-pixelclock is equal to zero. As the
information is missing from many board files, what would you think about
the following ?
fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
Grrr...you are right. I will fix that...
Thank you.
I have to thank you for bulletproofing my code o/\o
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+
...and obviously this, too.
That one is less of an issue in my opinion. A mode with a zero htotal or
vtotal is clearly invalid, while we have modes with no pixel clock value.
Yes, you I are right. But while I'm on it, might as well prevent an error.
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
[PATCHv14 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 34 +-
include/drm/drmP.h |6 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 0073b27..2d6edfa 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,7 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
-#include linux/videomode.h
+#include linux/of_videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -541,6 +541,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, unsigned int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(vm, dmode);
+
+ pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+ vm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3d0ccaa..84ecabd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -86,6 +86,7 @@ struct drm_file;
struct drm_device;
struct videomode;
+struct device_node;
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1459,6 +1460,11 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ unsigned int index);
+#endif
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv14 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 42 +-
include/linux/fb.h|6 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index bcbfe8f..287e66b 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,7 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
-#include linux/videomode.h
+#include linux/of_videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1421,6 +1421,46 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n,
+m-xres, m-yres, m-refresh, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ unsigned int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(vm, fb);
+
+ pr_info(%s: got %dx%d display mode from %s\n, __func__, vm.hactive,
+ vm.vactive, np-name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 4404ec2..7e1c8cf 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ unsigned int index);
+#endif
#if IS_ENABLED(CONFIG_VIDEOMODE)
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv14 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig |6 +++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24 ++
drivers/video/videomode.c | 45 +
include/linux/display_timing.h | 104
include/linux/videomode.h | 52
6 files changed, 233 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/linux/display_timing.h
create mode 100644 include/linux/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..ac9bbbc
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/display_timing.h
+#include linux/export.h
+#include linux/slab.h
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp-timings) {
+ unsigned int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+ kfree(disp-timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..86a8558
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,45 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/errno.h
+#include linux/display_timing.h
+#include linux/kernel.h
+#include linux/videomode.h
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, TE_TYP);
+ vm-hactive =
[PATCHv14 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, that is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var-xres - cxres) / 2, dy = (var-yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var-xres, cyres ? cyres : var-yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info-lcd_panel_hres;
int panel_vres = plvds_setting_info-lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include debug.h
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total / 8 - 5;
raw.hor_addr = timing-hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total - 1;
raw.hor_addr = timing-hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing
[PATCHv14 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 49 +
include/linux/fb.h|6 ++
2 files changed, 55 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..bcbfe8f 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,54 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-hah)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-vah)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-interlaced)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-doublescan)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ /* prevent division by zero */
+ if (htotal vtotal)
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+ else
+ fbmode-refresh = vm-pixelclock;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv14 0/7] of: add display helper
Hi! Changes since v13: - fix const struct * warning (reported by: Laurent Pinchart laurent.pinch...@ideasonboard.com) - prevent division by zero in fb_videomode_from_videomode Changes since v12: - rename struct display_timing to via_display_timing in via subsystem - fix refreshrate calculation - fix const struct * warnings (reported by: Manjunathappa, Prakash prakash...@ti.com) - some CodingStyle fixes - rewrite parts of commit messages and display-timings.txt - let display_timing_get_value get all values instead of just typical Changes since v11: - make pointers const where applicable - add reviewed-by Laurent Pinchart Changes since v10: - fix function name (drm_)display_mode_from_videomode - add acked-by, reviewed-by, tested-by Changes since v9: - don't leak memory when previous timings were correct - CodingStyle fixes - move blank lines around Changes since v8: - fix memory leaks - change API to be more consistent (foo_from_bar(struct bar, struct foo)) - include headers were necessary - misc minor bufixe Changes since v7: - move of_xxx to drivers/video - remove non-binding documentation from display-timings.txt - squash display_timings and videomode in one patch - misc minor fixes 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 Changes since v5: - removed all display stuff and just describe timings Changes since v4: - refactored functions Changes since v3: - print error messages - free alloced memory - general cleanup Changes since v2: - use hardware-near property-names - provide a videomode structure - allow ranges for all properties (min,typ,max) - functions to get display_mode or fb_videomode Steffen Trumtrar (7): viafb: rename display_timing to via_display_timing video: add display_timing and videomode video: add of helper for display timings/videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/gpu/drm/drm_modes.c| 69 ++ drivers/video/Kconfig | 21 ++ drivers/video/Makefile |4 + drivers/video/display_timing.c | 24 +++ drivers/video/fbmon.c | 89 drivers/video/of_display_timing.c | 223 drivers/video/of_videomode.c | 48 + drivers/video/via/hw.c |6 +- drivers/video/via/hw.h |2 +- drivers/video/via/lcd.c|2 +- drivers/video/via/share.h |2 +- drivers/video/via/via_modesetting.c|8 +- drivers/video/via/via_modesetting.h|6 +- drivers/video/videomode.c | 45 include/drm/drmP.h | 12 ++ include/linux/display_timing.h | 104 + include/linux/fb.h | 12 ++ include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 18 ++ include/linux/videomode.h | 52 + 21 files changed, 861 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/display_timing.h create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h create mode 100644 include/linux/videomode.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv14 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |6 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..0073b27 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include linux/videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = vm-hactive;
+ dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+ dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+ dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+ dmode-vdisplay = vm-vactive;
+ dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+ dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+ dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+ dmode-clock = vm-pixelclock / 1000;
+
+ dmode-flags = 0;
+ if (vm-hah)
+ dmode-flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ dmode-flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm-vah)
+ dmode-flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ dmode-flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm-interlaced)
+ dmode-flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm-doublescan)
+ dmode-flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..3d0ccaa 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1454,6 +1455,11 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+#endif
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv14 3/7] video: add of helper for display timings/videomode
This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified, the first subnode will be used. For cases, where the graphics drivers knows, there can be only one mode description or where the driver only supports one mode, a helper function of_get_videomode is added, that gets a struct videomode from DT. (As this function is implemented in an expensive fashion, it should only be used in the aforementioned case). This also demonstrates how of_display_timings may be utilized. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Stephen Warren swar...@nvidia.com Reviewed-by: Thierry Reding thierry.red...@avionic-design.de Acked-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- .../devicetree/bindings/video/display-timings.txt | 107 ++ drivers/video/Kconfig | 15 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 223 drivers/video/of_videomode.c | 48 + include/linux/of_display_timings.h | 20 ++ include/linux/of_videomode.h | 18 ++ 7 files changed, 433 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/linux/of_display_timings.h create mode 100644 include/linux/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..2b25d58 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,107 @@ +display-timings bindings + + +display-timings node + + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timings subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock-frequency: display clock in Hz + +optional properties: + - hsync-active: Hsync pulse is active low/high/ignored + - vsync-active: Vsync pulse is active low/high/ignored + - de-active: Data-Enable pulse is active low/high/ignored + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/ + non-inverted (active on rising edge)/ +ignored (ignore property) + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + - doubleclk (bool) + +All the optional properties that are not bool follow the following logic: +1: high active +0: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The devicetree +representation corresponds to the one commonly found in datasheets for displays. +If a display supports multiple signal timings, the native-mode can be specified. + +The parameters are defined as + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |#---+---#|-| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | +
Re: [PATCH 1/4] [media] exynos-gsc: Rearrange error messages for valid prints
Hi Sachin,
Thanks for the patches.
On 11/23/2012 05:44 AM, Sachin Kamat wrote:
In case of clk_prepare failure, the function gsc_clk_get also prints
failed to get clock which is not correct. Hence move the error
messages to their respective blocks. While at it, also renamed the labels
meaningfully.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 6d6f65d..45bcfa7 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1017,25 +1017,26 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc-clock))
- goto err_print;
+ if (IS_ERR(gsc-clock)) {
+ dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
+ GSC_CLOCK_GATE_NAME);
+ goto err_clk_get;
You could also just return PTR_ERR(gsc-clock) here and remove
err_clk_get label entirely.
+ }
ret = clk_prepare(gsc-clock);
if (ret 0) {
+ dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
+ GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err;
+ goto err_clk_prepare;
}
return 0;
-err:
- dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_prepare:
gsc_clk_put(gsc);
This call can be removed too. I would remove all labels and gotos in
this function. Since there is only one clock, you need to only call
clk_put when clk_prepare() fails, there is no need for gsc_clk_put().
-err_print:
- dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_get:
return -ENXIO;
}
As a general remark, I think changes like in this series have to be
validated before we can think of applying it. I guess Shaik or
somebody else would need to test it. I still have no board I could
test Exynos5 Gscaler IP.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [media] exynos-gsc: Rearrange error messages for valid prints
Hi Sylwester,
Thanks for the review.
On 23 November 2012 15:01, Sylwester Nawrocki s.nawro...@samsung.com wrote:
Hi Sachin,
Thanks for the patches.
On 11/23/2012 05:44 AM, Sachin Kamat wrote:
In case of clk_prepare failure, the function gsc_clk_get also prints
failed to get clock which is not correct. Hence move the error
messages to their respective blocks. While at it, also renamed the labels
meaningfully.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 6d6f65d..45bcfa7 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1017,25 +1017,26 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc-clock))
- goto err_print;
+ if (IS_ERR(gsc-clock)) {
+ dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
+ GSC_CLOCK_GATE_NAME);
+ goto err_clk_get;
You could also just return PTR_ERR(gsc-clock) here and remove
err_clk_get label entirely.
OK.
+ }
ret = clk_prepare(gsc-clock);
if (ret 0) {
+ dev_err(gsc-pdev-dev, clock prepare failed for clock:
%s\n,
+ GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err;
+ goto err_clk_prepare;
}
return 0;
-err:
- dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_prepare:
gsc_clk_put(gsc);
This call can be removed too. I would remove all labels and gotos in
this function. Since there is only one clock, you need to only call
clk_put when clk_prepare() fails, there is no need for gsc_clk_put().
I have removed gsc_clk_put() in the subsequent patch in this series.
I will probably incorporate your previous comment and remove the label
altogether (in patch 3)
and send it again.
-err_print:
- dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_get:
return -ENXIO;
}
As a general remark, I think changes like in this series have to be
validated before we can think of applying it. I guess Shaik or
somebody else would need to test it. I still have no board I could
test Exynos5 Gscaler IP.
Yes you are right. I have already talked to Shaik about it.
He has agreed to test the same.
--
Regards,
Sylwester
--
With warm regards,
Sachin
--
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/4] [media] exynos-gsc: Remove gsc_clk_put call from gsc_clk_get
On 11/23/2012 05:45 AM, Sachin Kamat wrote:
Since this function just returns (since gsc-clock is NULL),
remove it and make the exit code simpler.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 45bcfa7..99ee1a9 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1020,7 +1020,7 @@ static int gsc_clk_get(struct gsc_dev *gsc)
if (IS_ERR(gsc-clock)) {
dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
GSC_CLOCK_GATE_NAME);
- goto err_clk_get;
+ goto err;
}
ret = clk_prepare(gsc-clock);
@@ -1029,14 +1029,12 @@ static int gsc_clk_get(struct gsc_dev *gsc)
GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err_clk_prepare;
+ goto err;
}
return 0;
-err_clk_prepare:
- gsc_clk_put(gsc);
-err_clk_get:
Hmm, ok, here come the remaining part of the cleanup..
I think this patch can be folded into the previous one.
+err:
return -ENXIO;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [media] exynos-gsc: Rearrange error messages for valid prints
On 11/23/2012 10:47 AM, Sachin Kamat wrote: +err_clk_prepare: gsc_clk_put(gsc); This call can be removed too. I would remove all labels and gotos in this function. Since there is only one clock, you need to only call clk_put when clk_prepare() fails, there is no need for gsc_clk_put(). I have removed gsc_clk_put() in the subsequent patch in this series. I will probably incorporate your previous comment and remove the label altogether (in patch 3) and send it again. OK, sounds good to me that way too. -- 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: [PATCHv14 3/7] video: add of helper for display timings/videomode
Hello Steffen,
On Fri, Nov 23, 2012 at 2:34 PM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.
If no native mode is specified, the first subnode will be used.
For cases, where the graphics drivers knows, there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.
(As this function is implemented in an expensive fashion, it should only
be used in the aforementioned case).
This also demonstrates how of_display_timings may be utilized.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/video/display-timings.txt | 107 ++
drivers/video/Kconfig | 15 ++
drivers/video/Makefile |2 +
drivers/video/of_display_timing.c | 223
drivers/video/of_videomode.c | 48 +
include/linux/of_display_timings.h | 20 ++
include/linux/of_videomode.h | 18 ++
7 files changed, 433 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/video/of_display_timing.c
create mode 100644 drivers/video/of_videomode.c
create mode 100644 include/linux/of_display_timings.h
create mode 100644 include/linux/of_videomode.h
snip
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
new file mode 100644
index 000..645f43d
--- /dev/null
+++ b/drivers/video/of_display_timing.c
@@ -0,0 +1,223 @@
+/*
+ * OF helpers for parsing display timings
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de,
Pengutronix
+ *
+ * based on of_videomode.c by Sascha Hauer s.ha...@pengutronix.de
+ *
+ * This file is released under the GPLv2
+ */
+#include linux/of.h
+#include linux/slab.h
+#include linux/export.h
+#include linux/of_display_timings.h
+
+/**
+ * parse_property - parse timing_entry from device_node
+ * @np: device_node with the property
+ * @name: name of the property
+ * @result: will be set to the return value
+ *
+ * DESCRIPTION:
+ * Every display_timing can be specified with either just the typical value
or
+ * a range consisting of min/typ/max. This function helps handling this
+ **/
+static int parse_property(const struct device_node *np, const char *name,
+ struct timing_entry *result)
+{
+ struct property *prop;
+ int length, cells, ret;
+
+ prop = of_find_property(np, name, length);
+ if (!prop) {
+ pr_err(%s: could not find property %s\n, __func__, name);
+ return -EINVAL;
+ }
+
+ cells = length / sizeof(u32);
+ if (cells == 1) {
+ ret = of_property_read_u32(np, name, result-typ);
+ result-min = result-typ;
+ result-max = result-typ;
+ } else if (cells == 3) {
+ ret = of_property_read_u32_array(np, name, result-min,
cells);
+ } else {
+ pr_err(%s: illegal timing specification in %s\n, __func__,
+ name);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * of_get_display_timing - parse display_timing entry from device_node
+ * @np: device_node with the properties
+ **/
+static struct display_timing *of_get_display_timing(const struct device_node
+ *np)
+{
+ struct display_timing *dt;
+ int ret = 0;
+
+ dt = kzalloc(sizeof(*dt), GFP_KERNEL);
+ if (!dt) {
+ pr_err(%s: could not allocate display_timing struct\n,
+ __func__);
+ return NULL;
+ }
+
+ ret |= parse_property(np, hback-porch, dt-hback_porch);
+ ret |= parse_property(np, hfront-porch, dt-hfront_porch);
+ ret |= parse_property(np, hactive, dt-hactive);
+ ret |= parse_property(np, hsync-len, dt-hsync_len);
+ ret |= parse_property(np, vback-porch, dt-vback_porch);
+ ret |= parse_property(np, vfront-porch, dt-vfront_porch);
+ ret |= parse_property(np, vactive, dt-vactive);
+ ret |=
Re: drivers without explicit MAINTAINERS entry - was: Re: [media-workshop] Tentative Agenda for the November workshop
Hi Alexey, On Mon November 12 2012 19:41:57 Alexey Klimov wrote: Hi Mauro, Hans, all, On Fri, Nov 2, 2012 at 6:34 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 2 Nov 2012 14:47:49 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Fri November 2 2012 14:13:10 Mauro Carvalho Chehab wrote: Em Thu, 1 Nov 2012 14:12:44 -0200 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Thu, 1 Nov 2012 16:44:50 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Thu October 25 2012 19:27:01 Mauro Carvalho Chehab wrote: Hi Hans, Em Mon, 22 Oct 2012 10:35:56 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: 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. Thank you for taking care of it. - 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) - Creating/selecting contexts for hardware that supports this (Samsung, only if time is available) I have an extra theme for discussions there: what should we do with the drivers that don't have any MAINTAINERS entry. I've added this topic to the list. Thanks! It probably makes sense to mark them as Orphan (or, at least, have some criteria to mark them as such). Perhaps before doing that, we could try to see if are there any developer at the community with time and patience to handle them. This could of course be handled as part of the discussions about how to improve the merge process, but I suspect that this could generate enough discussions to be handled as a separate theme. Do we have a 'Maintainer-Light' category? I have a lot of hardware that I can test. So while I wouldn't like to be marked as 'The Maintainer of driver X' (since I simply don't have the time for that), I wouldn't mind being marked as someone who can at least test patches if needed. There are several maintainance status there: S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete:Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. (btw, I just realized that I should be changing the EDAC drivers I maintain to Supported; the media drivers I maintain should be kept as Maintained). I suspect that the maintainer-light category for those radio and similar old stuff is likely Odd Fixes. There are some issues by not having a MAINTAINERS entry: - patches may not flow into the driver maintainer; - patches will likely be applied without tests/reviews or may stay for a long time queued; - ./scripts/get_maintainer.pl at --no-git-fallback won't return any maintainer[1]. [1] Letting get_maintainer.pl is very time/CPU consuming. Letting it would delay a lot the patch review process, if applied for every patch, with unreliable and doubtful results. I don't do it, due to the large volume of patches, and because the 'other' results aren't typically the driver maintainer. An example of this is the results for a patch I just applied (changeset 2866aed103b915ca8ba0ff76d5790caea4e62ced): $ git show --pretty=email|./scripts/get_maintainer.pl Mauro Carvalho Chehab mche...@infradead.org (maintainer:MEDIA INPUT INFRA...,commit_signer:7/7=100%) Hans Verkuil hans.verk...@cisco.com (commit_signer:4/7=57%) Anatolij Gustschin ag...@denx.de (commit_signer:1/7=14%) Wei Yongjun
Re: [PATCHv14 3/7] video: add of helper for display timings/videomode
On Fri, Nov 23, 2012 at 03:49:37PM +0530, Leela Krishna Amudala wrote:
Hello Steffen,
On Fri, Nov 23, 2012 at 2:34 PM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.
If no native mode is specified, the first subnode will be used.
For cases, where the graphics drivers knows, there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.
(As this function is implemented in an expensive fashion, it should only
be used in the aforementioned case).
This also demonstrates how of_display_timings may be utilized.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Stephen Warren swar...@nvidia.com
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/video/display-timings.txt | 107 ++
drivers/video/Kconfig | 15 ++
drivers/video/Makefile |2 +
drivers/video/of_display_timing.c | 223
drivers/video/of_videomode.c | 48 +
include/linux/of_display_timings.h | 20 ++
include/linux/of_videomode.h | 18 ++
7 files changed, 433 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/display-timings.txt
create mode 100644 drivers/video/of_display_timing.c
create mode 100644 drivers/video/of_videomode.c
create mode 100644 include/linux/of_display_timings.h
create mode 100644 include/linux/of_videomode.h
snip
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
new file mode 100644
index 000..645f43d
--- /dev/null
+++ b/drivers/video/of_display_timing.c
@@ -0,0 +1,223 @@
+/*
+ * OF helpers for parsing display timings
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de,
Pengutronix
+ *
+ * based on of_videomode.c by Sascha Hauer s.ha...@pengutronix.de
+ *
+ * This file is released under the GPLv2
+ */
+#include linux/of.h
+#include linux/slab.h
+#include linux/export.h
+#include linux/of_display_timings.h
+
+/**
+ * parse_property - parse timing_entry from device_node
+ * @np: device_node with the property
+ * @name: name of the property
+ * @result: will be set to the return value
+ *
+ * DESCRIPTION:
+ * Every display_timing can be specified with either just the typical
value or
+ * a range consisting of min/typ/max. This function helps handling this
+ **/
+static int parse_property(const struct device_node *np, const char *name,
+ struct timing_entry *result)
+{
+ struct property *prop;
+ int length, cells, ret;
+
+ prop = of_find_property(np, name, length);
+ if (!prop) {
+ pr_err(%s: could not find property %s\n, __func__, name);
+ return -EINVAL;
+ }
+
+ cells = length / sizeof(u32);
+ if (cells == 1) {
+ ret = of_property_read_u32(np, name, result-typ);
+ result-min = result-typ;
+ result-max = result-typ;
+ } else if (cells == 3) {
+ ret = of_property_read_u32_array(np, name, result-min,
cells);
+ } else {
+ pr_err(%s: illegal timing specification in %s\n, __func__,
+ name);
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * of_get_display_timing - parse display_timing entry from device_node
+ * @np: device_node with the properties
+ **/
+static struct display_timing *of_get_display_timing(const struct
device_node
+ *np)
+{
+ struct display_timing *dt;
+ int ret = 0;
+
+ dt = kzalloc(sizeof(*dt), GFP_KERNEL);
+ if (!dt) {
+ pr_err(%s: could not allocate display_timing struct\n,
+ __func__);
+ return NULL;
+ }
+
+ ret |= parse_property(np, hback-porch, dt-hback_porch);
+ ret |= parse_property(np, hfront-porch, dt-hfront_porch);
+ ret |= parse_property(np, hactive, dt-hactive);
+ ret |= parse_property(np, hsync-len, dt-hsync_len);
+
Re: [PATCHv14 4/7] fbmon: add videomode helpers
Hi Steffen,
On Friday 23 November 2012 10:04:24 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 49 ++
include/linux/fb.h|6 ++
2 files changed, 55 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..bcbfe8f 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
You could move this one line up to keep headers sorted alphabetically
(assuming they are in the first place).
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,54 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
This is inside the #if CONFIG_FB_MODE_HELPERS block, is that intentional ?
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-hah)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-vah)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-interlaced)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-doublescan)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+ vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+ vm-vsync_len;
+ /* prevent division by zero */
+ if (htotal vtotal)
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+ else
+ fbmode-refresh = vm-pixelclock;
What about returning an error if htotal * vtotal == 0 ? The input is clearly
invalid in that case. I would then set fbmode-refresh to 0, setting it to vm-
pixelclock doesn't really make sense.
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
A single blank line should be enough.
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..4404ec2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,11 @@ extern void fb_destroy_modedb(struct fb_videomode
*modedb); extern int fb_find_mode_cvt(struct fb_videomode *mode, int
margins, int rb); extern unsigned char *fb_ddc_read(struct i2c_adapter
*adapter);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+struct fb_videomode *fbmode);
+#endif
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] [media] exynos-gsc: Some fixes
Changes since v1: Removed the label 'err' from function gsc_clk_get as suggested by Sylwester Nawrocki s.nawro...@samsung.com in patch 3/4. Other patches remain the same. Patch series build tested and based on samsung/for_v3.8 branch of git://linuxtv.org/snawrocki/media.git. Sachin Kamat (4): [media] exynos-gsc: Rearrange error messages for valid prints [media] exynos-gsc: Remove gsc_clk_put call from gsc_clk_get [media] exynos-gsc: Use devm_clk_get() [media] exynos-gsc: Fix checkpatch warning in gsc-m2m.c drivers/media/platform/exynos-gsc/gsc-core.c | 21 - drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +- 2 files changed, 9 insertions(+), 14 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] [media] exynos-gsc: Rearrange error messages for valid prints
In case of clk_prepare failure, the function gsc_clk_get also prints
failed to get clock which is not correct. Hence move the error
messages to their respective blocks. While at it, also renamed the labels
meaningfully.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 6d6f65d..45bcfa7 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1017,25 +1017,26 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc-clock))
- goto err_print;
+ if (IS_ERR(gsc-clock)) {
+ dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
+ GSC_CLOCK_GATE_NAME);
+ goto err_clk_get;
+ }
ret = clk_prepare(gsc-clock);
if (ret 0) {
+ dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
+ GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err;
+ goto err_clk_prepare;
}
return 0;
-err:
- dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_prepare:
gsc_clk_put(gsc);
-err_print:
- dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
- GSC_CLOCK_GATE_NAME);
+err_clk_get:
return -ENXIO;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] [media] exynos-gsc: Remove gsc_clk_put call from gsc_clk_get
Since this function just returns (since gsc-clock is NULL),
remove it and make the exit code simpler.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 45bcfa7..99ee1a9 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1020,7 +1020,7 @@ static int gsc_clk_get(struct gsc_dev *gsc)
if (IS_ERR(gsc-clock)) {
dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
GSC_CLOCK_GATE_NAME);
- goto err_clk_get;
+ goto err;
}
ret = clk_prepare(gsc-clock);
@@ -1029,14 +1029,12 @@ static int gsc_clk_get(struct gsc_dev *gsc)
GSC_CLOCK_GATE_NAME);
clk_put(gsc-clock);
gsc-clock = NULL;
- goto err_clk_prepare;
+ goto err;
}
return 0;
-err_clk_prepare:
- gsc_clk_put(gsc);
-err_clk_get:
+err:
return -ENXIO;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] [media] exynos-gsc: Fix checkpatch warning in gsc-m2m.c
Fixes the following warning:
WARNING: space prohibited between function name and open parenthesis '('
FILE: media/platform/exynos-gsc/gsc-m2m.c:606:
ctx = kzalloc(sizeof (*ctx), GFP_KERNEL);
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-m2m.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 39dff20..10036d6 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -603,7 +603,7 @@ static int gsc_m2m_open(struct file *file)
if (mutex_lock_interruptible(gsc-lock))
return -ERESTARTSYS;
- ctx = kzalloc(sizeof (*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
ret = -ENOMEM;
goto unlock;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] [media] exynos-gsc: Use devm_clk_get()
devm_clk_get() is a device managed function and makes error handling
a bit simpler.
Cc: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 99ee1a9..5a285b2 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1006,8 +1006,6 @@ static void gsc_clk_put(struct gsc_dev *gsc)
return;
clk_unprepare(gsc-clock);
- clk_put(gsc-clock);
- gsc-clock = NULL;
}
static int gsc_clk_get(struct gsc_dev *gsc)
@@ -1016,26 +1014,21 @@ static int gsc_clk_get(struct gsc_dev *gsc)
dev_dbg(gsc-pdev-dev, gsc_clk_get Called\n);
- gsc-clock = clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
+ gsc-clock = devm_clk_get(gsc-pdev-dev, GSC_CLOCK_GATE_NAME);
if (IS_ERR(gsc-clock)) {
dev_err(gsc-pdev-dev, failed to get clock~~~: %s\n,
GSC_CLOCK_GATE_NAME);
- goto err;
+ return PTR_ERR(gsc-clock);
}
ret = clk_prepare(gsc-clock);
if (ret 0) {
dev_err(gsc-pdev-dev, clock prepare failed for clock: %s\n,
GSC_CLOCK_GATE_NAME);
- clk_put(gsc-clock);
- gsc-clock = NULL;
- goto err;
+ return ret;
}
return 0;
-
-err:
- return -ENXIO;
}
static int gsc_m2m_suspend(struct gsc_dev *gsc)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/15] Adding entries for various drivers to MAINTAINERS.
This adds 'Supported' entries for the adv7604/ad9389b drivers. In addition there is a bunch of other drivers that I maintain or can do odd fixes for. Regards, Hans -- 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 01/15] MAINTAINERS: add adv7604/ad9389b entries.
From: Hans Verkuil hans.verk...@cisco.com Cisco maintains these drivers. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS | 12 1 file changed, 12 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b623679..6f0a8b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -557,6 +557,18 @@ L: linux-r...@vger.kernel.org S: Maintained F: drivers/infiniband/hw/amso1100/ +ANALOG DEVICES INC AD9389B DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/ad9389b* + +ANALOG DEVICES INC ADV7604 DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv7604* + ANALOG DEVICES INC ASOC CODEC DRIVERS M: Lars-Peter Clausen l...@metafoo.de L: device-drivers-de...@blackfin.uclinux.org -- 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 03/15] MAINTAINERS: add entry for the quickcam parallel port webcams.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4db8384..5d5462d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6069,6 +6069,14 @@ L: linux-hexa...@vger.kernel.org S: Supported F: arch/hexagon/ +QUICKCAM PARALLEL PORT WEBCAMS +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Odd Fixes +F: drivers/media/parport/*-qcam* + RADOS BLOCK DEVICE (RBD) M: Yehuda Sadeh yeh...@inktank.com M: Sage Weil s...@inktank.com -- 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 04/15] MAINTAINERS: add radio-keene entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5d5462d..95f1181 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4275,6 +4275,14 @@ W: http://lse.sourceforge.net/kdump/ S: Maintained F: Documentation/kdump/ +KEENE FM RADIO TRANSMITTER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-keene* + KERNEL AUTOMOUNTER v4 (AUTOFS4) M: Ian Kent ra...@themaw.net L: aut...@vger.kernel.org -- 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 02/15] MAINTAINERS: add cx2341x entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6f0a8b4..4db8384 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2179,6 +2179,15 @@ F: Documentation/video4linux/cx18.txt F: drivers/media/pci/cx18/ F: include/uapi/linux/ivtv* +CX2341X MPEG ENCODER HELPER MODULE +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/cx2341x* +F: include/media/cx2341x* + CX88 VIDEO4LINUX DRIVER M: Mauro Carvalho Chehab mche...@redhat.com L: linux-media@vger.kernel.org -- 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 09/15] MAINTAINERS: add radio-gemtek entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 12377a2..5758e93 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3318,6 +3318,14 @@ W: http://www.icp-vortex.com/ S: Supported F: drivers/scsi/gdt* +GEMTEK FM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-gemtek* + GENERIC GPIO I2C DRIVER M: Haavard Skinnemoen hskinnem...@gmail.com S: Supported -- 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 11/15] MAINTAINERS: add radio-miropcm20 entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4870e1b..bd09f47 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4974,6 +4974,14 @@ S: Supported F: Documentation/mips/ F: arch/mips/ +MIROSOUND PCM20 FM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Odd Fixes +F: drivers/media/radio/radio-miropcm20* + MODULE SUPPORT M: Rusty Russell ru...@rustcorp.com.au S: Maintained -- 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 14/15] MAINTAINERS: add usbvision entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c12be91..4a61ea4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8030,6 +8030,14 @@ S: Maintained F: drivers/media/usb/uvc/ F: include/uapi/linux/uvcvideo.h +USB VISION DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Odd Fixes +F: drivers/media/usb/usbvision/ + USB WIRELESS RNDIS DRIVER (rndis_wlan) M: Jussi Kivilinna jussi.kivili...@mbnet.fi L: linux-wirel...@vger.kernel.org -- 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 13/15] MAINTAINERS: add saa6588 entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1c10922..c12be91 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6422,6 +6422,14 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: drivers/mmc/host/s3cmci.* +SAA6588 RDS RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Odd Fixes +F: drivers/media/i2c/saa6588* + SAA7134 VIDEO4LINUX DRIVER M: Mauro Carvalho Chehab mche...@redhat.com L: linux-media@vger.kernel.org -- 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 07/15] MAINTAINERS: add radio-aztech entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ebacbd5..89db772 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1499,6 +1499,14 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/usb/dvb-usb-v2/az6007.c +AZTECH FM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-aztech* + B43 WIRELESS DRIVER M: Stefano Brivio stefano.bri...@polimi.it L: linux-wirel...@vger.kernel.org -- 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 15/15] MAINTAINERS: add vivi entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4a61ea4..80b8f68 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8185,6 +8185,14 @@ L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/via/via-velocity.* +VIVI VIRTUAL VIDEO DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/platform/vivi* + VLAN (802.1Q) M: Patrick McHardy ka...@trash.net L: net...@vger.kernel.org -- 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 12/15] MAINTAINERS: add pms entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index bd09f47..1c10922 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4913,6 +4913,14 @@ F: include/uapi/linux/meye.h F: include/uapi/linux/ivtv* F: include/uapi/linux/uvcvideo.h +MEDIAVISION PRO MOVIE STUDIO DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Odd Fixes +F: drivers/media/parport/pms* + MEGARAID SCSI DRIVERS M: Neela Syam Kolli megaraidli...@lsi.com L: linux-s...@vger.kernel.org -- 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 08/15] MAINTAINERS: add radio-aimslab entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 89db772..12377a2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -463,6 +463,14 @@ S: Maintained F: drivers/scsi/aic7xxx/ F: drivers/scsi/aic7xxx_old/ +AIMSLAB FM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-aimslab* + AIO M: Benjamin LaHaise b...@kvack.org L: linux-...@kvack.org -- 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 10/15] MAINTAINERS: add radio-maxiradio entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5758e93..4870e1b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4883,6 +4883,14 @@ S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c +MAXIRADIO FM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-maxiradio* + MEDIA INPUT INFRASTRUCTURE (V4L/DVB) M: Mauro Carvalho Chehab mche...@redhat.com P: LinuxTV.org Project -- 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 05/15] MAINTAINERS: add radio-cadet entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 95f1181..2eb2951 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1781,6 +1781,14 @@ S: Supported F: Documentation/filesystems/caching/cachefiles.txt F: fs/cachefiles/ +CADET FM/AM RADIO RECEIVER DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-cadet* + CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER M: Jonathan Corbet cor...@lwn.net L: linux-media@vger.kernel.org -- 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 06/15] MAINTAINERS: add radio-isa entry.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2eb2951..ebacbd5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4126,6 +4126,14 @@ F: Documentation/isapnp.txt F: drivers/pnp/isapnp/ F: include/linux/isapnp.h +ISA RADIO MODULE +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/radio/radio-isa* + iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER M: Peter Jones pjo...@redhat.com M: Konrad Rzeszutek Wilk kon...@kernel.org -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch review 01/02] add driver for Masterkit MA901 usb radio
Hi Alexey, Some (small) comments below... On Mon October 29 2012 02:41:10 Alexey Klimov wrote: This patch creates a new usb-radio driver, radio-ma901.c, that supports Masterkit MA 901 USB FM radio devices. This device plugs into both the USB and an analog audio input or headphones, so this thing only deals with initialization and frequency setting. Signed-off-by: Alexey Klimov klimov.li...@gmail.com diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 8090b87..ead9928 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -124,6 +124,18 @@ config USB_KEENE To compile this driver as a module, choose M here: the module will be called radio-keene. +config USB_MA901 + tristate Masterkit MA901 USB FM radio support + depends on USB VIDEO_V4L2 + ---help--- + Say Y here if you want to connect this type of radio to your + computer's USB port. Note that the audio is not digital, and + you must connect the line out connector to a sound card or a + set of speakers or headphones. + + To compile this driver as a module, choose M here: the + module will be called radio-ma901. + config RADIO_TEA5764 tristate TEA5764 I2C FM radio support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index c03ce4f..303eaeb 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_RADIO_SI470X) += si470x/ obj-$(CONFIG_USB_MR800) += radio-mr800.o obj-$(CONFIG_USB_KEENE) += radio-keene.o +obj-$(CONFIG_USB_MA901) += radio-ma901.o obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o diff --git a/drivers/media/radio/radio-ma901.c b/drivers/media/radio/radio-ma901.c new file mode 100644 index 000..987e4db --- /dev/null +++ b/drivers/media/radio/radio-ma901.c @@ -0,0 +1,461 @@ +/* + * Driver for the MasterKit MA901 USB FM radio. This device plugs + * into the USB port and an analog audio input or headphones, so this thing + * only deals with initialization, frequency setting, volume. + * + * Copyright (c) 2012 Alexey Klimov klimov.li...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/init.h +#include linux/slab.h +#include linux/input.h +#include linux/videodev2.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/v4l2-ctrls.h +#include media/v4l2-event.h +#include linux/usb.h +#include linux/mutex.h + +#define DRIVER_AUTHOR Alexey Klimov klimov.li...@gmail.com +#define DRIVER_DESC Masterkit MA901 USB FM radio driver +#define DRIVER_VERSION 0.0.1 + +MODULE_AUTHOR(DRIVER_AUTHOR); +MODULE_DESCRIPTION(DRIVER_DESC); +MODULE_LICENSE(GPL); +MODULE_VERSION(DRIVER_VERSION); + +#define USB_MA901_VENDOR 0x16c0 +#define USB_MA901_PRODUCT 0x05df + +/* dev_warn macro with driver name */ +#define MA901_DRIVER_NAME radio-ma901 +#define ma901radio_dev_warn(dev, fmt, arg...) \ + dev_warn(dev, MA901_DRIVER_NAME - fmt, ##arg) + +#define ma901radio_dev_err(dev, fmt, arg...) \ + dev_err(dev, MA901_DRIVER_NAME - fmt, ##arg) + +/* Probably USB_TIMEOUT should be modified in module parameter */ +#define BUFFER_LENGTH 8 +#define USB_TIMEOUT 500 + +#define FREQ_MIN 87.5 +#define FREQ_MAX 108.0 +#define FREQ_MUL 16000 + +#define MA901_VOLUME_MAX 16 +#define MA901_VOLUME_MIN 0 + +/* Commands that device should understand + * List isn't full and will be updated with implementation of new functions + */ +#define MA901_RADIO_SET_FREQ 0x03 +#define MA901_RADIO_SET_VOLUME 0x04 +#define MA901_RADIO_SET_MONO_STEREO 0x05 + +/* Comfortable defines for ma901radio_set_stereo */ +#define MA901_WANT_STEREO0x50 +#define MA901_WANT_MONO 0xd0 + +/* module parameter */ +static int radio_nr = -1; +module_param(radio_nr, int, 0); +MODULE_PARM_DESC(radio_nr, Radio file number); + +/* Data for one (physical) device */
[PATCH 0/6][media] s5p-*: Use devm_clk_get APIs
This series is based on samsung/for_v3.8 branch of git://linuxtv.org/snawrocki/media.git tree. MFC and FIMC have been tested on Origen board. Others build tested. Sachin Kamat (6): [media] s5p-fimc: Use devm_clk_get in mipi-csis.c [media] s5p-fimc: Use devm_clk_get in fimc-core.c [media] s5p-fimc: Use devm_clk_get in fimc-lite.c [media] s5p-g2d: Use devm_clk_get APIs. [media] s5p-jpeg: Use devm_clk_get APIs. [media] s5p-mfc: Use devm_clk_get APIs drivers/media/platform/s5p-fimc/fimc-core.c | 10 ++ drivers/media/platform/s5p-fimc/fimc-lite.c |8 +--- drivers/media/platform/s5p-fimc/mipi-csis.c |6 +- drivers/media/platform/s5p-g2d/g2d.c| 14 -- drivers/media/platform/s5p-jpeg/jpeg-core.c |4 +--- drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 14 -- 6 files changed, 13 insertions(+), 43 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] [media] s5p-fimc: Use devm_clk_get in mipi-csis.c
devm_clk_get is device managed and makes error handling and cleanup
a bit simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-fimc/mipi-csis.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 4c961b1..d624bfa 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -341,8 +341,6 @@ static void s5pcsis_clk_put(struct csis_state *state)
if (IS_ERR_OR_NULL(state-clock[i]))
continue;
clk_unprepare(state-clock[i]);
- clk_put(state-clock[i]);
- state-clock[i] = NULL;
}
}
@@ -352,13 +350,11 @@ static int s5pcsis_clk_get(struct csis_state *state)
int i, ret;
for (i = 0; i NUM_CSIS_CLOCKS; i++) {
- state-clock[i] = clk_get(dev, csi_clock_name[i]);
+ state-clock[i] = devm_clk_get(dev, csi_clock_name[i]);
if (IS_ERR(state-clock[i]))
goto err;
ret = clk_prepare(state-clock[i]);
if (ret 0) {
- clk_put(state-clock[i]);
- state-clock[i] = NULL;
goto err;
}
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] [media] s5p-fimc: Use devm_clk_get in fimc-core.c
devm_clk_get is device managed and makes error handling and cleanup
a bit simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-fimc/fimc-core.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.c
b/drivers/media/platform/s5p-fimc/fimc-core.c
index 8d0d2b9..0c45127 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.c
+++ b/drivers/media/platform/s5p-fimc/fimc-core.c
@@ -814,8 +814,6 @@ static void fimc_clk_put(struct fimc_dev *fimc)
if (IS_ERR_OR_NULL(fimc-clock[i]))
continue;
clk_unprepare(fimc-clock[i]);
- clk_put(fimc-clock[i]);
- fimc-clock[i] = NULL;
}
}
@@ -824,19 +822,15 @@ static int fimc_clk_get(struct fimc_dev *fimc)
int i, ret;
for (i = 0; i MAX_FIMC_CLOCKS; i++) {
- fimc-clock[i] = clk_get(fimc-pdev-dev, fimc_clocks[i]);
+ fimc-clock[i] = devm_clk_get(fimc-pdev-dev, fimc_clocks[i]);
if (IS_ERR(fimc-clock[i]))
goto err;
ret = clk_prepare(fimc-clock[i]);
- if (ret 0) {
- clk_put(fimc-clock[i]);
- fimc-clock[i] = NULL;
+ if (ret 0)
goto err;
- }
}
return 0;
err:
- fimc_clk_put(fimc);
dev_err(fimc-pdev-dev, failed to get clock: %s\n,
fimc_clocks[i]);
return -ENXIO;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] [media] s5p-fimc: Use devm_clk_get in fimc-lite.c
devm_clk_get is device managed and makes error handling and cleanup
a bit simpler.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-fimc/fimc-lite.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 70bcf39..02d0ff9 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -1382,23 +1382,17 @@ static void fimc_lite_clk_put(struct fimc_lite *fimc)
return;
clk_unprepare(fimc-clock);
- clk_put(fimc-clock);
- fimc-clock = NULL;
}
static int fimc_lite_clk_get(struct fimc_lite *fimc)
{
int ret;
- fimc-clock = clk_get(fimc-pdev-dev, FLITE_CLK_NAME);
+ fimc-clock = devm_clk_get(fimc-pdev-dev, FLITE_CLK_NAME);
if (IS_ERR(fimc-clock))
return PTR_ERR(fimc-clock);
ret = clk_prepare(fimc-clock);
- if (ret 0) {
- clk_put(fimc-clock);
- fimc-clock = NULL;
- }
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] [media] s5p-g2d: Use devm_clk_get APIs.
devm_clk_get() is device managed function and makes error handling
and exit code a bit simpler.
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-g2d/g2d.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/s5p-g2d/g2d.c
b/drivers/media/platform/s5p-g2d/g2d.c
index 1bfbc32..77819d3 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -714,7 +714,7 @@ static int g2d_probe(struct platform_device *pdev)
return -ENOENT;
}
- dev-clk = clk_get(pdev-dev, sclk_fimg2d);
+ dev-clk = devm_clk_get(pdev-dev, sclk_fimg2d);
if (IS_ERR_OR_NULL(dev-clk)) {
dev_err(pdev-dev, failed to get g2d clock\n);
return -ENXIO;
@@ -726,7 +726,7 @@ static int g2d_probe(struct platform_device *pdev)
goto put_clk;
}
- dev-gate = clk_get(pdev-dev, fimg2d);
+ dev-gate = devm_clk_get(pdev-dev, fimg2d);
if (IS_ERR_OR_NULL(dev-gate)) {
dev_err(pdev-dev, failed to get g2d clock gate\n);
ret = -ENXIO;
@@ -736,7 +736,7 @@ static int g2d_probe(struct platform_device *pdev)
ret = clk_prepare(dev-gate);
if (ret) {
dev_err(pdev-dev, failed to prepare g2d clock gate\n);
- goto put_clk_gate;
+ goto unprep_clk;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -752,7 +752,7 @@ static int g2d_probe(struct platform_device *pdev)
0, pdev-name, dev);
if (ret) {
dev_err(pdev-dev, failed to install IRQ\n);
- goto put_clk_gate;
+ goto unprep_clk;
}
dev-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev);
@@ -804,13 +804,9 @@ alloc_ctx_cleanup:
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx);
unprep_clk_gate:
clk_unprepare(dev-gate);
-put_clk_gate:
- clk_put(dev-gate);
unprep_clk:
clk_unprepare(dev-clk);
put_clk:
- clk_put(dev-clk);
-
return ret;
}
@@ -824,9 +820,7 @@ static int g2d_remove(struct platform_device *pdev)
v4l2_device_unregister(dev-v4l2_dev);
vb2_dma_contig_cleanup_ctx(dev-alloc_ctx);
clk_unprepare(dev-gate);
- clk_put(dev-gate);
clk_unprepare(dev-clk);
- clk_put(dev-clk);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] [media] s5p-mfc: Use devm_clk_get APIs
devm_clk_get() is device managed function and makes error handling
and exit code a bit simpler.
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 2895333..4864d93 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -37,7 +37,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
pm = dev-pm;
p_dev = dev;
- pm-clock_gate = clk_get(dev-plat_dev-dev, MFC_GATE_CLK_NAME);
+ pm-clock_gate = devm_clk_get(dev-plat_dev-dev, MFC_GATE_CLK_NAME);
if (IS_ERR(pm-clock_gate)) {
mfc_err(Failed to get clock-gating control\n);
ret = PTR_ERR(pm-clock_gate);
@@ -47,10 +47,10 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
ret = clk_prepare(pm-clock_gate);
if (ret) {
mfc_err(Failed to preapre clock-gating control\n);
- goto err_p_ip_clk;
+ goto err_g_ip_clk;
}
- pm-clock = clk_get(dev-plat_dev-dev, dev-variant-mclk_name);
+ pm-clock = devm_clk_get(dev-plat_dev-dev, dev-variant-mclk_name);
if (IS_ERR(pm-clock)) {
mfc_err(Failed to get MFC clock\n);
ret = PTR_ERR(pm-clock);
@@ -60,7 +60,7 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
ret = clk_prepare(pm-clock);
if (ret) {
mfc_err(Failed to prepare MFC clock\n);
- goto err_p_ip_clk_2;
+ goto err_g_ip_clk_2;
}
atomic_set(pm-power, 0);
@@ -72,12 +72,8 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
atomic_set(clk_ref, 0);
#endif
return 0;
-err_p_ip_clk_2:
- clk_put(pm-clock);
err_g_ip_clk_2:
clk_unprepare(pm-clock_gate);
-err_p_ip_clk:
- clk_put(pm-clock_gate);
err_g_ip_clk:
return ret;
}
@@ -85,9 +81,7 @@ err_g_ip_clk:
void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
{
clk_unprepare(pm-clock_gate);
- clk_put(pm-clock_gate);
clk_unprepare(pm-clock);
- clk_put(pm-clock);
#ifdef CONFIG_PM_RUNTIME
pm_runtime_disable(pm-device);
#endif
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv14 4/7] fbmon: add videomode helpers
Hi Laurent,
On Fri, Nov 23, 2012 at 11:53:10AM +0100, Laurent Pinchart wrote:
Hi Steffen,
On Friday 23 November 2012 10:04:24 Steffen Trumtrar wrote:
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 49 ++
include/linux/fb.h|6 ++
2 files changed, 55 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..bcbfe8f 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include linux/videomode.h
You could move this one line up to keep headers sorted alphabetically
(assuming they are in the first place).
Because of the careless mistake below, I will do that.
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,54 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
This is inside the #if CONFIG_FB_MODE_HELPERS block, is that intentional ?
Yes. Intentional. It is a fb_mode helper, that is why ... oh, wait. I should
add a depends on to the Kconfig then.
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode-pixclock = vm-pixelclock ? KHZ2PICOS(vm-pixelclock / 1000) :
0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-hah)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-vah)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-interlaced)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-doublescan)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ /* prevent division by zero */
+ if (htotal vtotal)
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+ else
+ fbmode-refresh = vm-pixelclock;
What about returning an error if htotal * vtotal == 0 ? The input is clearly
invalid in that case. I would then set fbmode-refresh to 0, setting it to vm-
pixelclock doesn't really make sense.
Yes, pixelclock makes no sense. It was supposed to be 0. I was careless here.
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
+
A single blank line should be enough.
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
[PATCH] stk1160: Replace BUG_ON with WARN_ON
This situation is not even an error condition so it's stupid to BUG_ON.
Learn the lesson:
http://permalink.gmane.org/gmane.linux.kernel/1347333
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
drivers/media/usb/stk1160/stk1160-video.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-video.c
b/drivers/media/usb/stk1160/stk1160-video.c
index f8dcf6d..07186c7 100644
--- a/drivers/media/usb/stk1160/stk1160-video.c
+++ b/drivers/media/usb/stk1160/stk1160-video.c
@@ -78,7 +78,7 @@ struct stk1160_buffer *stk1160_next_buffer(struct stk1160
*dev)
unsigned long flags = 0;
/* Current buffer must be NULL when this functions gets called */
- BUG_ON(dev-urb_ctl.buf);
+ WARN_ON(dev-urb_ctl.buf);
spin_lock_irqsave(dev-buf_lock, flags);
if (!list_empty(dev-avail_bufs)) {
--
1.7.8.6
--
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 4/6] uvcvideo: Set device_caps in VIDIOC_QUERYCAP
Hi Hans, Thanks for the review. On Friday 16 November 2012 15:00:29 Hans Verkuil wrote: On Thu September 27 2012 17:16:18 Laurent Pinchart wrote: Set the capabilities field to global capabilities, and the device_caps field to the video node capabilities. This issue was found by the v4l2-compliance tool. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/usb/uvc/uvc_driver.c |5 + drivers/media/usb/uvc/uvc_v4l2.c | 10 ++ drivers/media/usb/uvc/uvcvideo.h |2 ++ 3 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 5967081..ae24f7d 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1741,6 +1741,11 @@ static int uvc_register_video(struct uvc_device *dev, return ret; } + if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) + stream-chain-caps |= V4L2_CAP_VIDEO_CAPTURE; + else + stream-chain-caps |= V4L2_CAP_VIDEO_OUTPUT; + atomic_inc(dev-nstreams); return 0; } diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 3bd9373..b1aa55f 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -565,12 +565,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg) usb_make_path(stream-dev-udev, cap-bus_info, sizeof(cap-bus_info)); cap-version = LINUX_VERSION_CODE; + cap-capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING + | chain-caps; if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) - cap-capabilities = V4L2_CAP_VIDEO_CAPTURE - | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_CAPTURE +| V4L2_CAP_STREAMING; else - cap-capabilities = V4L2_CAP_VIDEO_OUTPUT - | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_OUTPUT +| V4L2_CAP_STREAMING; This seems weird. Wouldn't it be easier to do: cap-device_caps = chain-caps | V4L2_CAP_STREAMING; You don't need the if/else here. No, because chain-caps can be V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT as a chain can contain several video nodes. We want to caps of this particular video node only here. break; } -- 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 6/6] uvcvideo: Add VIDIOC_[GS]_PRIORITY support
Hi Hans, Thank you for the review. On Friday 16 November 2012 15:07:42 Hans Verkuil wrote: On Thu September 27 2012 17:16:20 Laurent Pinchart wrote: Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/usb/uvc/uvc_driver.c |3 ++ drivers/media/usb/uvc/uvc_v4l2.c | 45 +++ drivers/media/usb/uvc/uvcvideo.h |1 + 3 files changed, 49 insertions(+), 0 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index ae24f7d..22f14d2 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c [snip] @@ -1722,6 +1723,8 @@ static int uvc_register_video(struct uvc_device *dev, vdev-v4l2_dev = dev-vdev; vdev-fops = uvc_fops; vdev-release = uvc_release; + vdev-prio = stream-chain-prio; + set_bit(V4L2_FL_USE_FH_PRIO, vdev-flags); This set_bit() doesn't do anything as long as you are not using video_ioctl2(). The bit also makes v4l2_fh_(add|del)() call v4l2_prio_(open|close)(). And why aren't you using video_ioctl2()? This is the last driver to do it all manually. If you'd switch to video_ioctl2(), then setting this bit would be all you had to do. I have a patch for that, I need to resurect it. if (stream-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) vdev-vfl_dir = VFL_DIR_TX; strlcpy(vdev-name, dev-name, sizeof vdev-name); diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index bf9d073..d6aa402 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c [snip] This patch is hard to read since I can't see for which ioctls you check the prio. Can you regenerate the patch with more context lines? The patch as it is will probably not apply reliably due to the same reason. My bad. I'll resend it. In particular, make sure you also check for the UVC-specific ioctls (UVCIOC_CTRL_MAP might need this, but I'm not sure about that). The UVC-specific ioctls are only control operations, they don't require priority handling. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] uvcvideo: Add VIDIOC_[GS]_PRIORITY support
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_driver.c |3 ++
drivers/media/usb/uvc/uvc_v4l2.c | 45
drivers/media/usb/uvc/uvcvideo.h |1 +
3 files changed, 49 insertions(+), 0 deletions(-)
Resent with larger contexts to make review easier.
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index ae24f7d..22f14d2 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1560,10 +1560,11 @@ static int uvc_scan_device(struct uvc_device *dev)
return -ENOMEM;
INIT_LIST_HEAD(chain-entities);
mutex_init(chain-ctrl_mutex);
chain-dev = dev;
+ v4l2_prio_init(chain-prio);
if (uvc_scan_chain(chain, term) 0) {
kfree(chain);
continue;
}
@@ -1720,10 +1721,12 @@ static int uvc_register_video(struct uvc_device *dev,
* get another one.
*/
vdev-v4l2_dev = dev-vdev;
vdev-fops = uvc_fops;
vdev-release = uvc_release;
+ vdev-prio = stream-chain-prio;
+ set_bit(V4L2_FL_USE_FH_PRIO, vdev-flags);
if (stream-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
vdev-vfl_dir = VFL_DIR_TX;
strlcpy(vdev-name, dev-name, sizeof vdev-name);
/* Set the driver data before calling video_register_device, otherwise
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index bf9d073..d6aa402 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -574,10 +574,23 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
cap-device_caps = V4L2_CAP_VIDEO_OUTPUT
| V4L2_CAP_STREAMING;
break;
}
+ /* Priority */
+ case VIDIOC_G_PRIORITY:
+ *(u32 *)arg = v4l2_prio_max(vdev-prio);
+ break;
+
+ case VIDIOC_S_PRIORITY:
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
+
+ return v4l2_prio_change(vdev-prio, handle-vfh.prio,
+ *(u32 *)arg);
+
/* Get, Set Query control */
case VIDIOC_QUERYCTRL:
return uvc_query_v4l2_ctrl(chain, arg);
case VIDIOC_G_CTRL:
@@ -604,10 +617,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_S_CTRL:
{
struct v4l2_control *ctrl = arg;
struct v4l2_ext_control xctrl;
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
+
memset(xctrl, 0, sizeof xctrl);
xctrl.id = ctrl-id;
xctrl.value = ctrl-value;
ret = uvc_ctrl_begin(chain);
@@ -651,10 +668,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
ret = uvc_ctrl_rollback(handle);
break;
}
case VIDIOC_S_EXT_CTRLS:
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
+
case VIDIOC_TRY_EXT_CTRLS:
{
struct v4l2_ext_controls *ctrls = arg;
struct v4l2_ext_control *ctrl = ctrls-controls;
unsigned int i;
@@ -745,10 +766,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
case VIDIOC_S_INPUT:
{
u32 input = *(u32 *)arg + 1;
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
+
if ((ret = uvc_acquire_privileges(handle)) 0)
return ret;
if (chain-selector == NULL ||
(chain-dev-quirks UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
@@ -798,10 +823,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
return uvc_v4l2_try_format(stream, arg, probe, NULL, NULL);
}
case VIDIOC_S_FMT:
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
+
if ((ret = uvc_acquire_privileges(handle)) 0)
return ret;
return uvc_v4l2_set_format(stream, arg);
@@ -900,10 +929,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
/* Get Set streaming parameters */
case VIDIOC_G_PARM:
return uvc_v4l2_get_streamparm(stream, arg);
case VIDIOC_S_PARM:
+ ret =
Re: [PATCH 4/6] uvcvideo: Set device_caps in VIDIOC_QUERYCAP
On Fri November 23 2012 13:20:10 Laurent Pinchart wrote: Hi Hans, Thanks for the review. On Friday 16 November 2012 15:00:29 Hans Verkuil wrote: On Thu September 27 2012 17:16:18 Laurent Pinchart wrote: Set the capabilities field to global capabilities, and the device_caps field to the video node capabilities. This issue was found by the v4l2-compliance tool. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/usb/uvc/uvc_driver.c |5 + drivers/media/usb/uvc/uvc_v4l2.c | 10 ++ drivers/media/usb/uvc/uvcvideo.h |2 ++ 3 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 5967081..ae24f7d 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1741,6 +1741,11 @@ static int uvc_register_video(struct uvc_device *dev, return ret; } + if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) + stream-chain-caps |= V4L2_CAP_VIDEO_CAPTURE; + else + stream-chain-caps |= V4L2_CAP_VIDEO_OUTPUT; + atomic_inc(dev-nstreams); return 0; } diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c index 3bd9373..b1aa55f 100644 --- a/drivers/media/usb/uvc/uvc_v4l2.c +++ b/drivers/media/usb/uvc/uvc_v4l2.c @@ -565,12 +565,14 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd, void *arg) usb_make_path(stream-dev-udev, cap-bus_info, sizeof(cap-bus_info)); cap-version = LINUX_VERSION_CODE; + cap-capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING + | chain-caps; if (stream-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) - cap-capabilities = V4L2_CAP_VIDEO_CAPTURE - | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_CAPTURE + | V4L2_CAP_STREAMING; else - cap-capabilities = V4L2_CAP_VIDEO_OUTPUT - | V4L2_CAP_STREAMING; + cap-device_caps = V4L2_CAP_VIDEO_OUTPUT + | V4L2_CAP_STREAMING; This seems weird. Wouldn't it be easier to do: cap-device_caps = chain-caps | V4L2_CAP_STREAMING; You don't need the if/else here. No, because chain-caps can be V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT as a chain can contain several video nodes. We want to caps of this particular video node only here. That explains it :-) Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans -- 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 6/6] uvcvideo: Add VIDIOC_[GS]_PRIORITY support
Hi Laurent,
You were right about your remark about setting USE_FH_PRIO: you do need to do
that here.
Thanks for reposting with more context, now I can see where the prio checks are
added :-)
I have just one small remark:
On Fri November 23 2012 13:32:05 Laurent Pinchart wrote:
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_driver.c |3 ++
drivers/media/usb/uvc/uvc_v4l2.c | 45
drivers/media/usb/uvc/uvcvideo.h |1 +
3 files changed, 49 insertions(+), 0 deletions(-)
Resent with larger contexts to make review easier.
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index ae24f7d..22f14d2 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -651,10 +668,14 @@ static long uvc_v4l2_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
ret = uvc_ctrl_rollback(handle);
break;
}
case VIDIOC_S_EXT_CTRLS:
+ ret = v4l2_prio_check(vdev-prio, handle-vfh.prio);
+ if (ret 0)
+ return ret;
Please add a /* fall through */ comment here.
+
case VIDIOC_TRY_EXT_CTRLS:
{
struct v4l2_ext_controls *ctrls = arg;
struct v4l2_ext_control *ctrl = ctrls-controls;
unsigned int i;
After making that change you can add my Acked-by:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.8] uvcvideo patches
Hi Mauro, The following changes since commit 304a0807a22852fe3095a62c24b25c4d0e16d003: [media] drivers/media/usb/hdpvr/hdpvr-core.c: fix error return code (2012-11-22 14:22:31 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Laurent Pinchart (8): uvcvideo: Set error_idx properly for extended controls API failures uvcvideo: Return -EACCES when trying to access a read/write-only control uvcvideo: Don't fail when an unsupported format is requested uvcvideo: Set device_caps in VIDIOC_QUERYCAP uvcvideo: Return -ENOTTY for unsupported ioctls uvcvideo: Add VIDIOC_[GS]_PRIORITY support uvcvideo: Mark first output terminal as default video node uvcvideo: Fix control value clamping for unsigned integer controls drivers/media/usb/uvc/uvc_ctrl.c | 29 +++ drivers/media/usb/uvc/uvc_driver.c | 10 drivers/media/usb/uvc/uvc_entity.c |2 + drivers/media/usb/uvc/uvc_v4l2.c | 89 --- drivers/media/usb/uvc/uvc_video.c |1 + drivers/media/usb/uvc/uvcvideo.h |8 +++ 6 files changed, 110 insertions(+), 29 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Taking over saa7146 maintainership from Michael Hunold
Since I have enough saa7146-type cards to test almost all saa7146-based drivers (except for budget cards with analog input. If anyone has a spare, please contact me) and I have doing a fair amount of work for saa7146 over the years, Michael and I decided that I should replace Michael as maintainer of the saa7146-based V4L2 drivers and the core saa7146 code. These patches change the saa7146 maintainer and add three new entries for the i2c drivers used in the saa7146 mxb driver. Many thanks to Michael for maintaining this driver all those years! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] MAINTAINERS: Taking over saa7146 maintainership from Michael Hunold.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 80b8f68..76b1c1d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6440,10 +6440,9 @@ F: Documentation/video4linux/saa7134/ F: drivers/media/pci/saa7134/ SAA7146 VIDEO4LINUX-2 DRIVER -M: Michael Hunold mich...@mihu.de +M: Hans Verkuil hverk...@xs4all.nl L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git -W: http://www.mihu.de/linux/saa7146 S: Maintained F: drivers/media/common/saa7146/ F: drivers/media/pci/saa7146/ -- 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 2/2] MAINTAINERS: add tda9840, tea6415c and tea6420 entries.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS | 24 1 file changed, 24 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 76b1c1d..c25ade7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,6 +7412,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda8290.* +TDA9840 MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tda9840* + TEA5761 TUNER DRIVER M: Mauro Carvalho Chehab mche...@redhat.com L: linux-media@vger.kernel.org @@ -7428,6 +7436,22 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/tuners/tea5767.* +TEA6415C MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tea6415c* + +TEA6420 MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tea6420* + TEAM DRIVER M: Jiri Pirko jpi...@redhat.com L: net...@vger.kernel.org -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar and others, (Just resending; Laurent's e-mail address corrected, cc Hans, too.) On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation As discussed, here's the todo list for inclusion to staging. - User space interface refinement - Controls should be used when possible rather than private ioctl - No enums should be used - Use of MC and V4L2 subdev APIs when applicable - Single interface header might suffice - Current interface forces to configure everything at once - Get rid of the dm365_ipipe_hw.[ch] layer - Active external sub-devices defined by link configuration; no strcmp needed - More generic platform data (i2c adapters) - The driver should have no knowledge of possible external subdevs; see struct vpfe_subdev_id - Some of the hardware control should be refactorede - Check proper serialisation (through mutexes and spinlocks) - Names that are visible in kernel global namespace should have a common prefix (or a few) This list likely isn't complete, but some items such as the locking one is there simply because I'm not certain of the state of it. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Sakari, On Fri, Nov 23, 2012 at 6:43 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Prabhakar and others, (Just resending; Laurent's e-mail address corrected, cc Hans, too.) On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation As discussed, here's the todo list for inclusion to staging. - User space interface refinement - Controls should be used when possible rather than private ioctl - No enums should be used - Use of MC and V4L2 subdev APIs when applicable - Single interface header might suffice - Current interface forces to configure everything at once - Get rid of the dm365_ipipe_hw.[ch] layer - Active external sub-devices defined by link configuration; no strcmp needed - More generic platform data (i2c adapters) - The driver should have no knowledge of possible external subdevs; see struct vpfe_subdev_id - Some of the hardware control should be refactorede - Check proper serialisation (through mutexes and spinlocks) - Names that are visible in kernel global namespace should have a common prefix (or a few) This list likely isn't complete, but some items such as the locking one is there simply because I'm not certain of the state of it. Thanks a lot. I'll include this TODO's in documentation patch itself, But I am not sure if the driver is going in staging, the documentation file would still be present under Documentation directory or even this should go in staging directory itself ? Regards, --Prabhakar Lad -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: one tuner of a PVR-500 not returning any data
On 12-11-22 07:33 AM, Brian J. Murrell wrote:
I have a PVR-500 in a machine here where one of the /dev/video* devices
can successfully be opened and return data while the other can be
opened but returns to data to a read(2). i.e.:
open(/dev/video3, O_RDONLY|O_LARGEFILE) = 3
dup3(3, 0, 0) = 0
close(3)= 0
fstat64(0, {st_mode=S_IFCHR|0660, st_rdev=makedev(81, 11), ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc7f568) = -1 EINVAL (Invalid
argument)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7423000
read(0,
and the process blocks there.
FWIW, simply rmoving and inserting the ivtv module seems to have fixed this.
But really odd (to me at least) that it's just one tuner of a dual-tuner
card. So like 1 piece of hardware, with only 1 submodule not working.
b.
signature.asc
Description: OpenPGP digital signature
Re: avermedia, new version of avertv volar green hd
Bonjour,
A little in late but here is the pic location :
http://dl.free.fr/n7m8Gfe5q
cordialement,
Le 07/11/2012 16:23, Antti Palosaari a écrit :
Hello
If possible put those pictures somewhere to the net and give link
everyone could take a look. If that's not possible then I am still happy
to get those pics to my that email address.
regards
Antti
On 11/07/2012 03:39 PM, moebius wrote:
Bonjour,
This is not possible anymore : the device has returned to the seller !
But AV3007 is perhaps a compagny chip (AV = avermedia ?)
cordialement,
PS : if you give me an adress, I can post the picture of the opened
device
Le 06/11/2012 22:09, Antti Palosaari a écrit :
Also lsusb -vvd 07ca:3835 could be nice to see.
Antti
On 11/06/2012 10:33 PM, Antti Palosaari wrote:
Any idea about chipset? Those listed didn't sound any familiar. What
are
driver file names?
regards
Antti
On 11/05/2012 02:37 PM, Árvai Zoltán wrote:
Hi,
I asked the local guy from Avermedia about this tuner.
He said it is a new product called AVerTV Volar HD M (A835M). It
has
probably the same hardware like the Volar Green, but it has extended
software bundle (e.g. Mac support).
http://www.avermedia.com/Product/ProductDetail.aspx?Id=517
Regards,
Zoltan
On 11/04/2012 07:43 PM, moebius wrote:
Bonjour,
It's a dvb-t usb dongle
It's the same name than a former device but with new id : 07ca:3835
instead of 07ca:a835 and probably new hardware ; and it doesn't
work...
I've tried to enter a new device in the v4l-dvb web list but nothing
has happened ; the source, can be found at
http://www.linuxtv.org/wiki/index.php?title=DVB-T_USB_Devices_ListData/Helperaction=editsection=1
I've made a photo too but don't know how I can upload it.
Anyway, here is the source :
AVerMedia AVerTV Volar Green HD 07ca:3835
{{DeviceDisplayMedium|AVerMedia AVerTV Volar Green HD 07ca:3835}}
/noincludeincludeonly
{renderwith}}}|src=USB_Device_Data|selatt1={{{selatt1|}}}|selval1={{{selval1|}}}|selatt2={{{selatt2|}}}|selval2={{{selval2|}}}|selatt3={{{selatt3|}}}|selval3={{{selval3|}}}|selatt4={{{selatt4|}}}|selval4={{{selval4|}}}
| did=AVerMedia AVerTV Volar Green HD 07ca:3835
| vendor=[[AVerMedia]]
| device=[[AVerMedia AVerTV Volar Green HD | AVerTV Volar Green HD]]
| standard=DVB-T
| supported={{no}}
| pic=
| pic=
| url=
| url=
| hostinterface=USB2.0
| usbid=07ca:3835
| hw=unknown (see pic)
| tuner=
| demodulator=
| usbbridge=
| fw=
| comment= New version with same name ; main chipset (square, 4x12
pins) named AV3007 SXB1102 ; a little chip with 8 pins named 402R6
K207, another one with 5 pins 215L1(or I instead of 1) AC1H ;
last
small chip with metal on top T120 WtBF.
This device don't work on recent ubuntu kernel (3.2.0-23-lowlatency),
even with the last (04/11/2012) v4l drivers that I've downloaded and
install today.
}}
cordialement,
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/15] [media] marvell-ccic: add soc camera support on marvell-ccic
The following patches series will add soc camera support on marvell-ccic Change log v2: - remove register definition patch - split big patch to some small patches - split mcam-core.c to mcam-core.c and mcam-core-standard.c - add mcam-core-soc.c for soc camera support - split 3 frame buffers support patch into 2 patches [PATCH 01/15] [media] marvell-ccic: use internal variable replace [PATCH 02/15] [media] marvell-ccic: add MIPI support for marvell-ccic driver [PATCH 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver [PATCH 04/15] [media] marvell-ccic: reset ccic phy when stop streaming for stability [PATCH 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function [PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver [PATCH 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver [PATCH 08/15] [media] marvell-ccic: switch to resource managed allocation and request [PATCH 09/15] [media] marvell-ccic: refine vb2_ops for marvell-ccic driver [PATCH 10/15] [media] marvell-ccic: split mcam core into 2 parts for soc_camera support [PATCH 11/15] [media] marvell-ccic: add soc_camera support in mcam core [PATCH 12/15] [media] marvell-ccic: add soc_camera support in mmp driver [PATCH 13/15] [media] marvell-ccic: add dma burst mode support in marvell-ccic driver [PATCH 14/15] [media] marvell-ccic: use unsigned int type replace int type [PATCH 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode v1: [PATCH 1/4] [media] mmp: add register definition for marvell ccic [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core [PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver [PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode Thanks Albert Wang -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/15] [media] marvell-ccic: add soc camera support on marvell-ccic
The following patches series will add soc camera support on marvell-ccic Change log v2: - remove register definition patch - split big patch to some small patches - split mcam-core.c to mcam-core.c and mcam-core-standard.c - add mcam-core-soc.c for soc camera support - split 3 frame buffers support patch into 2 patches [PATCH 01/15] [media] marvell-ccic: use internal variable replace [PATCH 02/15] [media] marvell-ccic: add MIPI support for marvell-ccic driver [PATCH 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver [PATCH 04/15] [media] marvell-ccic: reset ccic phy when stop streaming for stability [PATCH 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function [PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver [PATCH 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver [PATCH 08/15] [media] marvell-ccic: switch to resource managed allocation and request [PATCH 09/15] [media] marvell-ccic: refine vb2_ops for marvell-ccic driver [PATCH 10/15] [media] marvell-ccic: split mcam core into 2 parts for soc_camera support [PATCH 11/15] [media] marvell-ccic: add soc_camera support in mcam core [PATCH 12/15] [media] marvell-ccic: add soc_camera support in mmp driver [PATCH 13/15] [media] marvell-ccic: add dma burst mode support in marvell-ccic driver [PATCH 14/15] [media] marvell-ccic: use unsigned int type replace int type [PATCH 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode v1: [PATCH 1/4] [media] mmp: add register definition for marvell ccic [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core [PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver [PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode Thanks Albert Wang -- 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 01/15] [media] marvell-ccic: use internal variable replace global frame stats variable
From: Libin Yang lby...@marvell.com
This patch replaces the global frame stats variables by using
internal variables in mcam_camera structure.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 30 ++-
drivers/media/platform/marvell-ccic/mcam-core.h |9 +++
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..7012913f 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -30,13 +30,6 @@
#include mcam-core.h
-/*
- * Basic frame stats - to be deleted shortly
- */
-static int frames;
-static int singles;
-static int delivered;
-
#ifdef MCAM_MODE_VMALLOC
/*
* Internal DMA buffer management. Since the controller cannot do S/G I/O,
@@ -367,10 +360,10 @@ static void mcam_frame_tasklet(unsigned long data)
if (!test_bit(bufno, cam-flags))
continue;
if (list_empty(cam-buffers)) {
- singles++;
+ cam-frame_state.singles++;
break; /* Leave it valid, hope for better later */
}
- delivered++;
+ cam-frame_state.delivered++;
clear_bit(bufno, cam-flags);
buf = list_first_entry(cam-buffers, struct mcam_vb_buffer,
queue);
@@ -452,7 +445,7 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
set_bit(CF_SINGLE_BUFFER, cam-flags);
- singles++;
+ cam-frame_state.singles++;
return;
}
/*
@@ -485,7 +478,7 @@ static void mcam_dma_contig_done(struct mcam_camera *cam,
int frame)
struct mcam_vb_buffer *buf = cam-vb_bufs[frame];
if (!test_bit(CF_SINGLE_BUFFER, cam-flags)) {
- delivered++;
+ cam-frame_state.delivered++;
mcam_buffer_done(cam, frame, buf-vb_buf);
}
mcam_set_contig_buffer(cam, frame);
@@ -578,13 +571,13 @@ static void mcam_dma_sg_done(struct mcam_camera *cam, int
frame)
*/
} else {
set_bit(CF_SG_RESTART, cam-flags);
- singles++;
+ cam-frame_state.singles++;
cam-vb_bufs[0] = NULL;
}
/*
* Now we can give the completed frame back to user space.
*/
- delivered++;
+ cam-frame_state.delivered++;
mcam_buffer_done(cam, frame, buf-vb_buf);
}
@@ -1545,7 +1538,9 @@ static int mcam_v4l_open(struct file *filp)
filp-private_data = cam;
- frames = singles = delivered = 0;
+ cam-frame_state.frames = 0;
+ cam-frame_state.singles = 0;
+ cam-frame_state.delivered = 0;
mutex_lock(cam-s_mutex);
if (cam-users == 0) {
ret = mcam_setup_vb2(cam);
@@ -1566,8 +1561,9 @@ static int mcam_v4l_release(struct file *filp)
{
struct mcam_camera *cam = filp-private_data;
- cam_dbg(cam, Release, %d frames, %d singles, %d delivered\n, frames,
- singles, delivered);
+ cam_dbg(cam, Release, %d frames, %d singles, %d delivered\n,
+ cam-frame_state.frames, cam-frame_state.singles,
+ cam-frame_state.delivered);
mutex_lock(cam-s_mutex);
(cam-users)--;
if (cam-users == 0) {
@@ -1660,7 +1656,7 @@ static void mcam_frame_complete(struct mcam_camera *cam,
int frame)
clear_bit(CF_DMA_ACTIVE, cam-flags);
cam-next_buf = frame;
cam-buf_seq[frame] = ++(cam-sequence);
- frames++;
+ cam-frame_state.frames++;
/*
* This should never happen
*/
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..e226de4 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -73,6 +73,14 @@ static inline int mcam_buffer_mode_supported(enum
mcam_buffer_mode mode)
}
}
+/*
+ * Basic frame states
+ */
+struct mmp_frame_state {
+ unsigned int frames;
+ unsigned int singles;
+ unsigned int delivered;
+};
/*
* A description of one of our devices.
@@ -108,6 +116,7 @@ struct mcam_camera {
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
+ struct mmp_frame_state frame_state; /* Frame state counter */
/*
* Subsystem structures.
*/
--
1.7.9.5
--
To unsubscribe from
[PATCH 02/15] [media] marvell-ccic: add MIPI support for marvell-ccic driver
From: Libin Yang lby...@marvell.com
This patch adds the MIPI support for marvell-ccic.
Board driver should determine whether using MIPI or not.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 60 ++
drivers/media/platform/marvell-ccic/mcam-core.h | 21 ++-
drivers/media/platform/marvell-ccic/mmp-driver.c | 72 +-
include/media/mmp-camera.h |9 +++
4 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 7012913f..b111f0d 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -253,6 +253,46 @@ static void mcam_ctlr_stop(struct mcam_camera *cam)
mcam_reg_clear_bit(cam, REG_CTRL0, C0_ENABLE);
}
+static int mcam_config_mipi(struct mcam_camera *mcam, int enable)
+{
+ if (mcam-bus_type == V4L2_MBUS_CSI2_LANES enable) {
+ /* Using MIPI mode and enable MIPI */
+ cam_dbg(mcam, camera: DPHY3=0x%x, DPHY5=0x%x, DPHY6=0x%x\n,
+ (*mcam-dphy)[0], (*mcam-dphy)[1], (*mcam-dphy)[2]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY3, (*mcam-dphy)[0]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY6, (*mcam-dphy)[2]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY5, (*mcam-dphy)[1]);
+
+ if (mcam-mipi_enabled == 0) {
+ /*
+* 0x41 actives 1 lane
+* 0x43 actives 2 lanes
+* 0x47 actives 4 lanes
+* There is no 3 lanes case
+*/
+ if (mcam-lane == 1)
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x41);
+ else if (mcam-lane == 2)
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x43);
+ else if (mcam-lane == 4)
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x47);
+ else {
+ cam_err(mcam, camera: lane number set err);
+ return -EINVAL;
+ }
+ mcam-mipi_enabled = 1;
+ }
+ } else {
+ /* Using para mode or disable MIPI */
+ mcam_reg_write(mcam, REG_CSI2_DPHY3, 0x0);
+ mcam_reg_write(mcam, REG_CSI2_DPHY6, 0x0);
+ mcam_reg_write(mcam, REG_CSI2_DPHY5, 0x0);
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x0);
+ mcam-mipi_enabled = 0;
+ }
+ return 0;
+}
+
/* --- */
#ifdef MCAM_MODE_VMALLOC
@@ -656,6 +696,15 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
*/
mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC,
C0_SIFM_MASK);
+
+ /*
+* This field controls the generation of EOF(DVP only)
+*/
+ if (cam-bus_type != V4L2_MBUS_CSI2_LANES) {
+ mcam_reg_set_bit(cam, REG_CTRL0,
+ C0_EOF_VSYNC | C0_VEDGE_CTRL);
+ mcam_reg_write(cam, REG_CTRL3, 0x4);
+ }
}
@@ -886,6 +935,16 @@ static int mcam_read_setup(struct mcam_camera *cam)
spin_lock_irqsave(cam-dev_lock, flags);
clear_bit(CF_DMA_ACTIVE, cam-flags);
mcam_reset_buffers(cam);
+ /*
+* Update CSI2_DPHY value
+*/
+ if (cam-calc_dphy)
+ cam-calc_dphy(cam);
+ cam_dbg(cam, camera: DPHY sets: dphy3=0x%x, dphy5=0x%x, dphy6=0x%x\n,
+ (*cam-dphy)[0], (*cam-dphy)[1], (*cam-dphy)[2]);
+ ret = mcam_config_mipi(cam, 1);
+ if (ret 0)
+ return ret;
mcam_ctlr_irq_enable(cam);
cam-state = S_STREAMING;
if (!test_bit(CF_SG_RESTART, cam-flags))
@@ -1569,6 +1628,7 @@ static int mcam_v4l_release(struct file *filp)
if (cam-users == 0) {
mcam_ctlr_stop_dma(cam);
mcam_cleanup_vb2(cam);
+ mcam_config_mipi(cam, 0);
mcam_ctlr_power_down(cam);
if (cam-buffer_mode == B_vmalloc alloc_bufs_at_read)
mcam_free_dma_bufs(cam);
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index e226de4..2d444a1 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -101,11 +101,18 @@ struct mcam_camera {
short int clock_speed; /* Sensor clock speed, default 30 */
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
+
+ /* MIPI support */
+ int bus_type;
+
[PATCH 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver
From: Libin Yang lby...@marvell.com
This patch adds the clock tree support for marvell-ccic.
Each board may require different clk enabling sequence.
Developer need add the clk_name in correct sequence in board driver
to use this feature.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.h |6 +++
drivers/media/platform/marvell-ccic/mmp-driver.c | 57 ++
include/media/mmp-camera.h |5 ++
3 files changed, 68 insertions(+)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 2d444a1..0df6b1c 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -88,6 +88,7 @@ struct mmp_frame_state {
* the dev_lock spinlock; they are marked as such by comments.
* dev_lock is also required for access to device registers.
*/
+#define NR_MCAM_CLK 4
struct mcam_camera {
/*
* These fields should be set by the platform code prior to
@@ -107,6 +108,11 @@ struct mcam_camera {
int (*dphy)[3];
int mipi_enabled;
int lane; /* lane number */
+
+ /* clock tree support */
+ struct clk *clk[NR_MCAM_CLK];
+ int clk_num;
+
/*
* Callbacks from the core to the platform code.
*/
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 9d7aa79..80977b0 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -104,6 +104,23 @@ static struct mmp_camera *mmpcam_find_device(struct
platform_device *pdev)
#define REG_CCIC_DCGCR 0x28/* CCIC dyn clock gate ctrl reg */
#define REG_CCIC_CRCR 0x50/* CCIC clk reset ctrl reg */
+static void mcam_clk_set(struct mcam_camera *mcam, int on)
+{
+ unsigned int i;
+
+ if (on) {
+ for (i = 0; i mcam-clk_num; i++) {
+ if (mcam-clk[i])
+ clk_enable(mcam-clk[i]);
+ }
+ } else {
+ for (i = 0; i mcam-clk_num; i++) {
+ if (mcam-clk[i])
+ clk_disable(mcam-clk[i]);
+ }
+ }
+}
+
/*
* Power control.
*/
@@ -134,6 +151,8 @@ static void mmpcam_power_up(struct mcam_camera *mcam)
mdelay(5);
gpio_set_value(pdata-sensor_reset_gpio, 1); /* reset is active low */
mdelay(5);
+
+ mcam_clk_set(mcam, 1);
}
static void mmpcam_power_down(struct mcam_camera *mcam)
@@ -151,6 +170,8 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
pdata = cam-pdev-dev.platform_data;
gpio_set_value(pdata-sensor_power_gpio, 0);
gpio_set_value(pdata-sensor_reset_gpio, 0);
+
+ mcam_clk_set(mcam, 0);
}
/*
@@ -229,6 +250,37 @@ static irqreturn_t mmpcam_irq(int irq, void *data)
return IRQ_RETVAL(handled);
}
+static void mcam_init_clk(struct mcam_camera *mcam,
+ struct mmp_camera_platform_data *pdata, int init)
+{
+ unsigned int i;
+
+ if (NR_MCAM_CLK pdata-clk_num) {
+ dev_warn(mcam-dev, Too many mcam clocks defined\n);
+ mcam-clk_num = 0;
+ return;
+ }
+
+ if (init) {
+ for (i = 0; i pdata-clk_num; i++) {
+ if (pdata-clk_name[i] != NULL)
+ mcam-clk[i] = clk_get(mcam-dev,
+ pdata-clk_name[i]);
+ if (IS_ERR(mcam-clk[i]))
+ dev_warn(mcam-dev, Could not get clk: %s\n,
+pdata-clk_name[i]);
+ }
+ mcam-clk_num = pdata-clk_num;
+ } else {
+ for (i = 0; i pdata-clk_num; i++) {
+ if (mcam-clk[i]) {
+ clk_put(mcam-clk[i]);
+ mcam-clk[i] = NULL;
+ }
+ }
+ mcam-clk_num = 0;
+ }
+}
static int mmpcam_probe(struct platform_device *pdev)
{
@@ -290,6 +342,8 @@ static int mmpcam_probe(struct platform_device *pdev)
ret = -ENODEV;
goto out_unmap1;
}
+
+ mcam_init_clk(mcam, pdata, 1);
/*
* Find the i2c adapter. This assumes, of course, that the
* i2c bus is already up and functioning.
@@ -317,6 +371,7 @@ static int mmpcam_probe(struct platform_device *pdev)
goto out_gpio;
}
gpio_direction_output(pdata-sensor_reset_gpio, 0);
+
/*
* Power the device up and hand it off to the core.
*/
@@ -349,6 +404,7 @@ out_gpio2:
out_gpio:
[PATCH 04/15] [media] marvell-ccic: reset ccic phy when stop streaming for stability
From: Libin Yang lby...@marvell.com
This patch adds the reset ccic phy operation when stop streaming.
Without reset ccic phy, the next start streaming may be unstable.
Also need add CCIC2 definition when PXA688/PXA2128 support dual ccics.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c |5 +
drivers/media/platform/marvell-ccic/mcam-core.h |2 ++
drivers/media/platform/marvell-ccic/mmp-driver.c | 25 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index b111f0d..760e8ea 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1053,6 +1053,11 @@ static int mcam_vb_stop_streaming(struct vb2_queue *vq)
return -EINVAL;
mcam_ctlr_stop_dma(cam);
/*
+* Reset the CCIC PHY after stopping streaming,
+* otherwise, the CCIC may be unstable.
+*/
+ cam-ctlr_reset(cam);
+ /*
* VB2 reclaims the buffers, so we need to forget
* about them.
*/
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 0df6b1c..40368f6 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -103,6 +103,7 @@ struct mcam_camera {
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
+ int ccic_id;
/* MIPI support */
int bus_type;
int (*dphy)[3];
@@ -119,6 +120,7 @@ struct mcam_camera {
void (*plat_power_up) (struct mcam_camera *cam);
void (*plat_power_down) (struct mcam_camera *cam);
void (*calc_dphy)(struct mcam_camera *cam);
+ void (*ctlr_reset)(struct mcam_camera *cam);
/*
* Everything below here is private to the mcam core and
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 80977b0..20046d0 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -103,6 +103,7 @@ static struct mmp_camera *mmpcam_find_device(struct
platform_device *pdev)
#define CPU_SUBSYS_PMU_BASE0xd4282800
#define REG_CCIC_DCGCR 0x28/* CCIC dyn clock gate ctrl reg */
#define REG_CCIC_CRCR 0x50/* CCIC clk reset ctrl reg */
+#define REG_CCIC2_CRCR 0xf4/* CCIC2 clk reset ctrl reg */
static void mcam_clk_set(struct mcam_camera *mcam, int on)
{
@@ -174,6 +175,28 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
mcam_clk_set(mcam, 0);
}
+void mcam_ctlr_reset(struct mcam_camera *mcam)
+{
+ unsigned long val;
+ struct mmp_camera *cam = mcam_to_cam(mcam);
+
+ if (mcam-ccic_id) {
+ /*
+* Using CCIC2
+*/
+ val = ioread32(cam-power_regs + REG_CCIC2_CRCR);
+ iowrite32(val ~0x2, cam-power_regs + REG_CCIC2_CRCR);
+ iowrite32(val | 0x2, cam-power_regs + REG_CCIC2_CRCR);
+ } else {
+ /*
+* Using CCIC1
+*/
+ val = ioread32(cam-power_regs + REG_CCIC_CRCR);
+ iowrite32(val ~0x2, cam-power_regs + REG_CCIC_CRCR);
+ iowrite32(val | 0x2, cam-power_regs + REG_CCIC_CRCR);
+ }
+}
+
/*
* calc the dphy register values
* There are three dphy registers being used.
@@ -301,9 +324,11 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam = cam-mcam;
mcam-plat_power_up = mmpcam_power_up;
mcam-plat_power_down = mmpcam_power_down;
+ mcam-ctlr_reset = mcam_ctlr_reset;
mcam-calc_dphy = mmpcam_calc_dphy;
mcam-dev = pdev-dev;
mcam-use_smbus = 0;
+ mcam-ccic_id = pdev-id;
mcam-bus_type = pdata-bus_type;
mcam-dphy = (pdata-dphy);
mcam-mipi_enabled = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function
From: Libin Yang lby...@marvell.com
This patch refines mcam_set_contig_buffer() in mcam core
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 760e8ea..67d4f2f 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -481,22 +481,21 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
*/
if (list_empty(cam-buffers)) {
buf = cam-vb_bufs[frame ^ 0x1];
- cam-vb_bufs[frame] = buf;
- mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
set_bit(CF_SINGLE_BUFFER, cam-flags);
cam-frame_state.singles++;
- return;
+ } else {
+ /*
+* OK, we have a buffer we can use.
+*/
+ buf = list_first_entry(cam-buffers, struct mcam_vb_buffer,
+ queue);
+ list_del_init(buf-queue);
+ clear_bit(CF_SINGLE_BUFFER, cam-flags);
}
- /*
-* OK, we have a buffer we can use.
-*/
- buf = list_first_entry(cam-buffers, struct mcam_vb_buffer, queue);
- list_del_init(buf-queue);
+
+ cam-vb_bufs[frame] = buf;
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
- cam-vb_bufs[frame] = buf;
- clear_bit(CF_SINGLE_BUFFER, cam-flags);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver
From: Libin Yang lby...@marvell.com
This patch adds the SOFx/EOFx pair check for marvell-ccic.
When switching format, the last EOF may not arrive when stop streamning.
And the EOF will be detected in the next start streaming.
Must ensure clear the obsolete frame flags before every really start streaming.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 33 ++-
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index c9f7250..16da8ae 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -93,6 +93,9 @@ MODULE_PARM_DESC(buffer_mode,
#define CF_CONFIG_NEEDED 4 /* Must configure hardware */
#define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
#define CF_SG_RESTART 6 /* SG restart needed */
+#define CF_FRAME_SOF0 7 /* Frame 0 started */
+#define CF_FRAME_SOF1 8
+#define CF_FRAME_SOF2 9
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam-sensor, o, f, ##args)
@@ -250,8 +253,10 @@ static void mcam_reset_buffers(struct mcam_camera *cam)
int i;
cam-next_buf = -1;
- for (i = 0; i cam-nbufs; i++)
+ for (i = 0; i cam-nbufs; i++) {
clear_bit(i, cam-flags);
+ clear_bit(CF_FRAME_SOF0 + i, cam-flags);
+ }
}
static inline int mcam_needs_config(struct mcam_camera *cam)
@@ -1130,6 +1135,7 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ unsigned int frame;
if (cam-state != S_IDLE) {
INIT_LIST_HEAD(cam-buffers);
@@ -1147,6 +1153,14 @@ static int mcam_vb_start_streaming(struct vb2_queue *vq,
unsigned int count)
cam-state = S_BUFWAIT;
return 0;
}
+
+ /*
+* Ensure clear the obsolete frame flags
+* before every really start streaming
+*/
+ for (frame = 0; frame cam-nbufs; frame++)
+ clear_bit(CF_FRAME_SOF0 + frame, cam-flags);
+
return mcam_read_setup(cam);
}
@@ -1865,9 +1879,11 @@ int mccic_irq(struct mcam_camera *cam, unsigned int irqs)
* each time.
*/
for (frame = 0; frame cam-nbufs; frame++)
- if (irqs (IRQ_EOF0 frame)) {
+ if (irqs (IRQ_EOF0 frame)
+ test_bit(CF_FRAME_SOF0 + frame, cam-flags)) {
mcam_frame_complete(cam, frame);
handled = 1;
+ clear_bit(CF_FRAME_SOF0 + frame, cam-flags);
if (cam-buffer_mode == B_DMA_sg)
break;
}
@@ -1876,11 +1892,14 @@ int mccic_irq(struct mcam_camera *cam, unsigned int
irqs)
* code assumes that we won't get multiple frame interrupts
* at once; may want to rethink that.
*/
- if (irqs (IRQ_SOF0 | IRQ_SOF1 | IRQ_SOF2)) {
- set_bit(CF_DMA_ACTIVE, cam-flags);
- handled = 1;
- if (cam-buffer_mode == B_DMA_sg)
- mcam_ctlr_stop(cam);
+ for (frame = 0; frame cam-nbufs; frame++) {
+ if (irqs (IRQ_SOF0 frame)) {
+ set_bit(CF_DMA_ACTIVE, cam-flags);
+ set_bit(CF_FRAME_SOF0 + frame, cam-flags);
+ handled = IRQ_HANDLED;
+ if (cam-buffer_mode == B_DMA_sg)
+ mcam_ctlr_stop(cam);
+ }
}
return handled;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 178 ++-
drivers/media/platform/marvell-ccic/mcam-core.h |6 +
2 files changed, 151 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 67d4f2f..c9f7250 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -110,6 +110,30 @@ static struct mcam_format_struct {
.bpp= 2,
},
{
+ .desc = UYVY 4:2:2,
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:2 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV422P,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV420,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_1_5X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YVU 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YVU420,
+ .mbus_code = V4L2_MBUS_FMT_YVYU8_1_5X8,
+ .bpp= 2,
+ },
+ {
.desc = RGB 444,
.pixelformat= V4L2_PIX_FMT_RGB444,
.mbus_code = V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE,
@@ -168,6 +192,12 @@ struct mcam_dma_desc {
u32 segment_len;
};
+struct yuv_pointer_t {
+ dma_addr_t y;
+ dma_addr_t u;
+ dma_addr_t v;
+};
+
/*
* Our buffer type for working with videobuf2. Note that the vb2
* developers have decreed that struct vb2_buffer must be at the
@@ -179,6 +209,7 @@ struct mcam_vb_buffer {
struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
dma_addr_t dma_desc_pa; /* Descriptor physical address */
int dma_desc_nent; /* Number of mapped descriptors */
+ struct yuv_pointer_t yuv_p;
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
@@ -465,6 +496,18 @@ static inline int mcam_check_dma_buffers(struct
mcam_camera *cam)
/*
* DMA-contiguous code.
*/
+
+static bool mcam_fmt_is_planar(__u32 pfmt)
+{
+ switch (pfmt) {
+ case V4L2_PIX_FMT_YUV422P:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ return true;
+ }
+ return false;
+}
+
/*
* Set up a contiguous buffer for the given frame. Here also is where
* the underrun strategy is set: if there is no buffer available, reuse
@@ -476,6 +519,8 @@ static inline int mcam_check_dma_buffers(struct mcam_camera
*cam)
static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
{
struct mcam_vb_buffer *buf;
+ struct v4l2_pix_format *fmt = cam-pix_format;
+
/*
* If there are no available buffers, go into single mode
*/
@@ -494,8 +539,13 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
}
cam-vb_bufs[frame] = buf;
- mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
+ mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR, buf-yuv_p.y);
+ if (mcam_fmt_is_planar(fmt-pixelformat)) {
+ mcam_reg_write(cam, frame == 0 ?
+ REG_U0BAR : REG_U1BAR, buf-yuv_p.u);
+ mcam_reg_write(cam, frame == 0 ?
+ REG_V0BAR : REG_V1BAR, buf-yuv_p.v);
+ }
}
/*
@@ -653,49 +703,91 @@ static inline void mcam_sg_restart(struct mcam_camera
*cam)
*/
static void mcam_ctlr_image(struct mcam_camera *cam)
{
- int imgsz;
struct v4l2_pix_format *fmt = cam-pix_format;
+ u32 widthy = 0, widthuv = 0, imgsz_h, imgsz_w;
+
+ cam_dbg(cam, camera: bytesperline = %d; height = %d\n,
+ fmt-bytesperline, fmt-sizeimage / fmt-bytesperline);
+ imgsz_h = (fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK;
+ imgsz_w = fmt-bytesperline IMGSZ_H_MASK;
+
+ if (fmt-pixelformat == V4L2_PIX_FMT_YUV420
+ || fmt-pixelformat == V4L2_PIX_FMT_YVU420)
+ imgsz_w = (fmt-bytesperline * 4 / 3) IMGSZ_H_MASK;
+ else if (fmt-pixelformat == V4L2_PIX_FMT_JPEG)
+ imgsz_h = (fmt-sizeimage / fmt-bytesperline) IMGSZ_V_SHIFT;
+
+ switch (fmt-pixelformat) {
+ case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_UYVY:
+ widthy = fmt-width * 2;
+
[PATCH 08/15] [media] marvell-ccic: switch to resource managed allocation and request
From: Libin Yang lby...@marvell.com
This patch switchs to resource managed allocation and request in mmp-driver.
It can remove free resource operations.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mmp-driver.c | 35 +++---
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 20046d0..c3031e7 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -315,7 +315,7 @@ static int mmpcam_probe(struct platform_device *pdev)
pdata = pdev-dev.platform_data;
- cam = kzalloc(sizeof(*cam), GFP_KERNEL);
+ cam = devm_kzalloc(pdev-dev, sizeof(*cam), GFP_KERNEL);
if (cam == NULL)
return -ENOMEM;
cam-pdev = pdev;
@@ -342,14 +342,12 @@ static int mmpcam_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(pdev-dev, no iomem resource!\n);
- ret = -ENODEV;
- goto out_free;
+ return -ENODEV;
}
- mcam-regs = ioremap(res-start, resource_size(res));
+ mcam-regs = devm_request_and_ioremap(pdev-dev, res);
if (mcam-regs == NULL) {
dev_err(pdev-dev, MMIO ioremap fail\n);
- ret = -ENODEV;
- goto out_free;
+ return -ENODEV;
}
/*
* Power/clock memory is elsewhere; get it too. Perhaps this
@@ -358,14 +356,12 @@ static int mmpcam_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (res == NULL) {
dev_err(pdev-dev, no power resource!\n);
- ret = -ENODEV;
- goto out_unmap1;
+ return -ENODEV;
}
- cam-power_regs = ioremap(res-start, resource_size(res));
+ cam-power_regs = devm_request_and_ioremap(pdev-dev, res);
if (cam-power_regs == NULL) {
dev_err(pdev-dev, power MMIO ioremap fail\n);
- ret = -ENODEV;
- goto out_unmap1;
+ return -ENODEV;
}
mcam_init_clk(mcam, pdata, 1);
@@ -375,9 +371,8 @@ static int mmpcam_probe(struct platform_device *pdev)
*/
mcam-i2c_adapter = platform_get_drvdata(pdata-i2c_device);
if (mcam-i2c_adapter == NULL) {
- ret = -ENODEV;
dev_err(pdev-dev, No i2c adapter\n);
- goto out_unmap2;
+ return -ENODEV;
}
/*
* Sensor GPIO pins.
@@ -386,7 +381,7 @@ static int mmpcam_probe(struct platform_device *pdev)
if (ret) {
dev_err(pdev-dev, Can't get sensor power gpio %d,
pdata-sensor_power_gpio);
- goto out_unmap2;
+ return ret;
}
gpio_direction_output(pdata-sensor_power_gpio, 0);
ret = gpio_request(pdata-sensor_reset_gpio, cam-reset);
@@ -414,7 +409,7 @@ static int mmpcam_probe(struct platform_device *pdev)
goto out_unregister;
}
cam-irq = res-start;
- ret = request_irq(cam-irq, mmpcam_irq, IRQF_SHARED,
+ ret = devm_request_irq(pdev-dev, cam-irq, mmpcam_irq, IRQF_SHARED,
mmp-camera, mcam);
if (ret == 0) {
mmpcam_add_device(cam);
@@ -428,13 +423,7 @@ out_gpio2:
gpio_free(pdata-sensor_reset_gpio);
out_gpio:
gpio_free(pdata-sensor_power_gpio);
-out_unmap2:
mcam_init_clk(mcam, pdata, 0);
- iounmap(cam-power_regs);
-out_unmap1:
- iounmap(mcam-regs);
-out_free:
- kfree(cam);
return ret;
}
@@ -445,16 +434,12 @@ static int mmpcam_remove(struct mmp_camera *cam)
struct mmp_camera_platform_data *pdata;
mmpcam_remove_device(cam);
- free_irq(cam-irq, mcam);
mccic_shutdown(mcam);
mmpcam_power_down(mcam);
pdata = cam-pdev-dev.platform_data;
gpio_free(pdata-sensor_reset_gpio);
gpio_free(pdata-sensor_power_gpio);
- iounmap(cam-power_regs);
- iounmap(mcam-regs);
mcam_init_clk(mcam, pdata, 0);
- kfree(cam);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] [media] marvell-ccic: refine vb2_ops for marvell-ccic driver
This patch adds buf_init and buf_cleanup callback in vb2_ops.
Also adds get_mcam() which is prepared for adding soc_camera support.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 55 ++-
drivers/media/platform/marvell-ccic/mcam-core.h |5 +++
2 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 16da8ae..9a935a2 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -213,6 +213,7 @@ struct mcam_vb_buffer {
dma_addr_t dma_desc_pa; /* Descriptor physical address */
int dma_desc_nent; /* Number of mapped descriptors */
struct yuv_pointer_t yuv_p;
+ int list_init_flag;
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
@@ -1058,7 +1059,7 @@ static int mcam_vb_queue_setup(struct vb2_queue *vq,
unsigned int *num_planes, unsigned int sizes[],
void *alloc_ctxs[])
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
int minbufs = (cam-buffer_mode == B_DMA_contig) ? 3 : 2;
sizes[0] = cam-pix_format.sizeimage;
@@ -1074,14 +1075,17 @@ static int mcam_vb_queue_setup(struct vb2_queue *vq,
static void mcam_vb_buf_queue(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
- struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+ struct mcam_camera *cam = get_mcam(vb-vb2_queue);
struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
dma_addr_t dma_handle;
+ unsigned long size;
u32 base_size = fmt-width * fmt-height;
spin_lock_irqsave(cam-dev_lock, flags);
+ size = vb2_plane_size(vb, 0);
+ vb2_set_plane_payload(vb, 0, size);
dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
BUG_ON(!dma_handle);
start = (cam-state == S_BUFWAIT) !list_empty(cam-buffers);
@@ -1117,14 +1121,14 @@ static void mcam_vb_buf_queue(struct vb2_buffer *vb)
*/
static void mcam_vb_wait_prepare(struct vb2_queue *vq)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
mutex_unlock(cam-s_mutex);
}
static void mcam_vb_wait_finish(struct vb2_queue *vq)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
mutex_lock(cam-s_mutex);
}
@@ -1134,9 +1138,12 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
*/
static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
unsigned int frame;
+ if (count 2)
+ return -EINVAL;
+
if (cam-state != S_IDLE) {
INIT_LIST_HEAD(cam-buffers);
return -EINVAL;
@@ -1166,7 +1173,7 @@ static int mcam_vb_start_streaming(struct vb2_queue *vq,
unsigned int count)
static int mcam_vb_stop_streaming(struct vb2_queue *vq)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
unsigned long flags;
if (cam-state == S_BUFWAIT) {
@@ -1177,6 +1184,7 @@ static int mcam_vb_stop_streaming(struct vb2_queue *vq)
if (cam-state != S_STREAMING)
return -EINVAL;
mcam_ctlr_stop_dma(cam);
+ cam-state = S_IDLE;
/*
* Reset the CCIC PHY after stopping streaming,
* otherwise, the CCIC may be unstable.
@@ -1192,10 +1200,37 @@ static int mcam_vb_stop_streaming(struct vb2_queue *vq)
return 0;
}
+static void mcam_videobuf_cleanup(struct vb2_buffer *vb)
+{
+ struct mcam_vb_buffer *buf =
+ container_of(vb, struct mcam_vb_buffer, vb_buf);
+
+ /*
+* queue list must be initialized before del
+*/
+ if (buf-list_init_flag)
+ list_del_init(buf-queue);
+ buf-list_init_flag = 0;
+}
+
+/*
+ * only the list that queued could be initialized
+ */
+static int mcam_videobuf_init(struct vb2_buffer *vb)
+{
+ struct mcam_vb_buffer *buf =
+ container_of(vb, struct mcam_vb_buffer, vb_buf);
+
+ INIT_LIST_HEAD(buf-queue);
+ buf-list_init_flag = 1;
+ return 0;
+}
static const struct vb2_ops mcam_vb2_ops = {
.queue_setup= mcam_vb_queue_setup,
.buf_queue = mcam_vb_buf_queue,
+ .buf_cleanup= mcam_videobuf_cleanup,
+ .buf_init = mcam_videobuf_init,
.start_streaming= mcam_vb_start_streaming,
.stop_streaming = mcam_vb_stop_streaming,
.wait_prepare
[PATCH 10/15] [media] marvell-ccic: split mcam core into 2 parts for soc_camera support
This patch splits mcam core into 2 parts to prepare for soc_camera support.
The first part remains in mcam-core. This part includes the HW operations
and vb2 callback functions.
The second part is moved to mcam-core-standard.c. This part is relevant with
the implementation of using v4l2.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/Makefile |4 +-
.../platform/marvell-ccic/mcam-core-standard.c | 767 +
.../platform/marvell-ccic/mcam-core-standard.h | 28 +
drivers/media/platform/marvell-ccic/mcam-core.c| 873 +---
drivers/media/platform/marvell-ccic/mcam-core.h| 45 +
5 files changed, 883 insertions(+), 834 deletions(-)
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-standard.c
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-standard.h
diff --git a/drivers/media/platform/marvell-ccic/Makefile
b/drivers/media/platform/marvell-ccic/Makefile
index 05a792c..595ebdf 100755
--- a/drivers/media/platform/marvell-ccic/Makefile
+++ b/drivers/media/platform/marvell-ccic/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
cafe_ccic-y := cafe-driver.o mcam-core.o
-obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o
-mmp_camera-y := mmp-driver.o mcam-core.o
+obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera_standard.o
+mmp_camera_standard-y := mmp-driver.o mcam-core.o mcam-core-standard.o
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-standard.c
b/drivers/media/platform/marvell-ccic/mcam-core-standard.c
new file mode 100644
index 000..bff9ed0
--- /dev/null
+++ b/drivers/media/platform/marvell-ccic/mcam-core-standard.c
@@ -0,0 +1,767 @@
+/*
+ * The Marvell camera core. This device appears in a number of settings,
+ * so it needs platform-specific support outside of the core.
+ *
+ * Copyright 2011 Jonathan Corbet cor...@lwn.net
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/spinlock.h
+#include linux/slab.h
+#include linux/device.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/vmalloc.h
+#include linux/io.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/ov7670.h
+#include media/videobuf2-vmalloc.h
+#include media/videobuf2-dma-contig.h
+#include media/videobuf2-dma-sg.h
+
+#include mcam-core.h
+#include mcam-core-standard.h
+
+static const enum v4l2_mbus_pixelcode mcam_def_mbus_code =
+ V4L2_MBUS_FMT_YUYV8_2X8;
+
+static struct mcam_format_struct {
+ __u8 *desc;
+ __u32 pixelformat;
+ int bpp; /* Bytes per pixel */
+ enum v4l2_mbus_pixelcode mbus_code;
+} mcam_formats[] = {
+ {
+ .desc = YUYV 4:2:2,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = UYVY 4:2:2,
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:2 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV422P,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV420,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_1_5X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YVU 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YVU420,
+ .mbus_code = V4L2_MBUS_FMT_YVYU8_1_5X8,
+ .bpp= 2,
+ },
+ {
+ .desc = RGB 444,
+ .pixelformat= V4L2_PIX_FMT_RGB444,
+ .mbus_code = V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE,
+ .bpp= 2,
+ },
+ {
+ .desc = RGB 565,
+ .pixelformat= V4L2_PIX_FMT_RGB565,
+ .mbus_code = V4L2_MBUS_FMT_RGB565_2X8_LE,
+ .bpp= 2,
+ },
+ {
+ .desc = Raw RGB Bayer,
+ .pixelformat= V4L2_PIX_FMT_SBGGR8,
+ .mbus_code = V4L2_MBUS_FMT_SBGGR8_1X8,
+ .bpp= 1
+ },
+};
+#define N_MCAM_FMTS ARRAY_SIZE(mcam_formats)
+
+/*
+ * The default format we use until somebody says otherwise.
+ */
+static const struct v4l2_pix_format mcam_def_pix_format = {
+ .width = VGA_WIDTH,
+ .height =
[PATCH 11/15] [media] marvell-ccic: add soc_camera support in mcam core
From: Albert Wang twan...@marvell.com
This patch adds the soc_camera support in mcam core.
It creates the file mcam-core-soc.c and mcam-core-soc.h
to support soc_camera in mcam core.
To use the soc_camera feature, platform driver, such as mmp-driver.c,
should also be modified.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/Makefile |2 +
.../media/platform/marvell-ccic/mcam-core-soc.c| 414
.../media/platform/marvell-ccic/mcam-core-soc.h| 19 +
drivers/media/platform/marvell-ccic/mcam-core.c| 13 +-
drivers/media/platform/marvell-ccic/mcam-core.h| 37 ++
include/media/mmp-camera.h |3 +
6 files changed, 485 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-soc.c
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-soc.h
diff --git a/drivers/media/platform/marvell-ccic/Makefile
b/drivers/media/platform/marvell-ccic/Makefile
index 595ebdf..b3e87d4 100755
--- a/drivers/media/platform/marvell-ccic/Makefile
+++ b/drivers/media/platform/marvell-ccic/Makefile
@@ -4,3 +4,5 @@ cafe_ccic-y := cafe-driver.o mcam-core.o
obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera_standard.o
mmp_camera_standard-y := mmp-driver.o mcam-core.o mcam-core-standard.o
+obj-$(CONFIG_VIDEO_MMP_SOC_CAMERA) += mmp_camera_soc.o
+mmp_camera_soc-y := mmp-driver.o mcam-core.o mcam-core-soc.o
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-soc.c
b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
new file mode 100644
index 000..a0df8b4
--- /dev/null
+++ b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
@@ -0,0 +1,414 @@
+/*
+ * The Marvell camera soc core. This device appears in a number of
settings,
+ * so it needs platform-specific support outside of the core.
+ *
+ * Copyright (C) 2009-2012 Marvell International Ltd.
+ *
+ * Author: Libin Yang lby...@marvell.com
+ * Albert Wang twan...@marvell.com
+ *
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/spinlock.h
+#include linux/slab.h
+#include linux/device.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/vmalloc.h
+#include linux/io.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/videobuf2-vmalloc.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#include mcam-core.h
+#include mcam-core-soc.h
+
+static const enum v4l2_mbus_pixelcode mcam_def_mbus_code =
+ V4L2_MBUS_FMT_YUYV8_2X8;
+
+static const struct soc_mbus_pixelfmt mcam_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = YUV422PACKED,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV422P,
+ .name = YUV422PLANAR,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .name = YUV420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVU420,
+ .name = YVU420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+};
+
+static const struct v4l2_pix_format mcam_def_pix_format = {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_NONE,
+ .bytesperline = VGA_WIDTH*2,
+ .sizeimage = VGA_WIDTH*VGA_HEIGHT*2,
+};
+
+static int mcam_camera_add_device(struct soc_camera_device *icd)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct mcam_camera *mcam = ici-priv;
+ int ret = 0;
+
+ if (mcam-icd)
+ return -EBUSY;
+
+ mcam-frame_complete = mcam_dma_contig_done;
+ mcam-frame_state.frames = 0;
+ mcam-frame_state.singles = 0;
+ mcam-frame_state.delivered = 0;
+
+ mcam-flags = 0;
+ mcam-icd = icd;
+ mcam-state = S_IDLE;
+ mcam-dma_setup = mcam_ctlr_dma_contig;
+ mcam_ctlr_power_up(mcam);
+ mcam_ctlr_stop(mcam);
+ mcam_set_config_needed(mcam, 1);
+ mcam_reg_write(mcam, REG_CTRL1,
+ C1_RESERVED | C1_DMAPOSTED);
+
[PATCH 12/15] [media] marvell-ccic: add soc_camera support in mmp driver
This patch adds the soc_camera support in the platform driver: mmp-driver.c.
Specified board driver also should be modified to support soc_camera by passing
some platform datas to platform driver.
Currently the soc_camera mode in mmp driver only supports B_DMA_contig mode.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/Makefile |4 +-
drivers/media/platform/marvell-ccic/Kconfig | 22 ++
drivers/media/platform/marvell-ccic/mmp-driver.c | 80 +++---
include/media/mmp-camera.h |2 +
4 files changed, 97 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index baaa550..feae003 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -11,8 +11,8 @@ obj-$(CONFIG_VIDEO_TIMBERDALE)+= timblogiw.o
obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
-obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
-obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
+
+obj-$(CONFIG_VIDEO_MARVELL_CCIC) += marvell-ccic/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/
diff --git a/drivers/media/platform/marvell-ccic/Kconfig
b/drivers/media/platform/marvell-ccic/Kconfig
index bf739e3..6e3eaa0 100755
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -1,23 +1,45 @@
+config VIDEO_MARVELL_CCIC
+ tristate
+config VIDEO_MRVL_SOC_CAMERA
+ tristate
+
config VIDEO_CAFE_CCIC
tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support
depends on PCI I2C VIDEO_V4L2
select VIDEO_OV7670
select VIDEOBUF2_VMALLOC
select VIDEOBUF2_DMA_CONTIG
+ select VIDEO_MARVELL_CCIC
---help---
This is a video4linux2 driver for the Marvell 88ALP01 integrated
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+choice
+ prompt Camera support on Marvell MMP
+ depends on ARCH_MMP VIDEO_V4L2
+ optional
config VIDEO_MMP_CAMERA
tristate Marvell Armada 610 integrated camera controller support
depends on ARCH_MMP I2C VIDEO_V4L2
select VIDEO_OV7670
select I2C_GPIO
select VIDEOBUF2_DMA_SG
+ select VIDEO_MARVELL_CCIC
---help---
This is a Video4Linux2 driver for the integrated camera
controller found on Marvell Armada 610 application
processors (and likely beyond). This is the controller found
in OLPC XO 1.75 systems.
+config VIDEO_MMP_SOC_CAMERA
+ bool Marvell MMP camera driver based on SOC_CAMERA
+ depends on VIDEO_DEV SOC_CAMERA ARCH_MMP VIDEO_V4L2
+ select VIDEOBUF2_DMA_CONTIG
+ select VIDEO_MARVELL_CCIC
+ select VIDEO_MRVL_SOC_CAMERA
+ ---help---
+ This is a Video4Linux2 driver for the Marvell Mobile Soc
+ PXA910/PXA688/PXA2128/PXA988 CCIC
+ (CMOS Camera Interface Controller)
+endchoice
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index c3031e7..bea7224 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -4,6 +4,12 @@
*
* Copyright 2011 Jonathan Corbet cor...@lwn.net
*
+ * History:
+ * Support Soc Camera
+ * Support MIPI interface and Dual CCICs in Soc Camera mode
+ * Sep-2012: Libin Yang lby...@marvell.com
+ * Albert Wang twan...@marvell.com
+ *
* This file may be distributed under the terms of the GNU General
* Public License, version 2.
*/
@@ -28,6 +34,10 @@
#include linux/list.h
#include linux/pm.h
#include linux/clk.h
+#include linux/regulator/consumer.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include mcam-core.h
@@ -40,6 +50,8 @@ struct mmp_camera {
struct platform_device *pdev;
struct mcam_camera mcam;
struct list_head devlist;
+ /* will change here */
+ struct clk *clk[3]; /* CCIC_GATE, CCIC_RST, CCIC_DBG clocks */
int irq;
};
@@ -135,7 +147,9 @@ static void mmpcam_power_up_ctlr(struct mmp_camera *cam)
static void mmpcam_power_up(struct mcam_camera *mcam)
{
struct mmp_camera *cam = mcam_to_cam(mcam);
+#ifndef CONFIG_VIDEO_MMP_SOC_CAMERA
struct mmp_camera_platform_data *pdata;
+#endif
/*
* Turn on power and clocks to the controller.
*/
@@ -144,34 +158,40 @@ static void mmpcam_power_up(struct mcam_camera *mcam)
* Provide power to the sensor.
*/
mcam_reg_write(mcam, REG_CLKCTRL, 0x6002);
+#ifndef CONFIG_VIDEO_MMP_SOC_CAMERA
pdata = cam-pdev-dev.platform_data;
gpio_set_value(pdata-sensor_power_gpio, 1);
mdelay(5);
+#endif
[PATCH 13/15] [media] marvell-ccic: add dma burst mode support in marvell-ccic driver
This patch adds the dma burst size config support for marvell-ccic.
Developer can set the dma burst size in specified board driver.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
.../media/platform/marvell-ccic/mcam-core-soc.c|2 +-
drivers/media/platform/marvell-ccic/mcam-core.h|7 ---
drivers/media/platform/marvell-ccic/mmp-driver.c | 11 +++
include/media/mmp-camera.h |1 +
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-soc.c
b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
index a0df8b4..518e6dc 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core-soc.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
@@ -100,7 +100,7 @@ static int mcam_camera_add_device(struct soc_camera_device
*icd)
mcam_ctlr_stop(mcam);
mcam_set_config_needed(mcam, 1);
mcam_reg_write(mcam, REG_CTRL1,
- C1_RESERVED | C1_DMAPOSTED);
+ mcam-burst | C1_RESERVED | C1_DMAPOSTED);
mcam_reg_write(mcam, REG_CLKCTRL,
(mcam-mclk_src 29) | mcam-mclk_div);
cam_dbg(mcam, camera: set sensor mclk = %dMHz\n, mcam-mclk_min);
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index e149aa3..999b581 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -132,6 +132,7 @@ struct mcam_camera {
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
+ int burst;
int mclk_min;
int mclk_src;
int mclk_div;
@@ -419,9 +420,9 @@ int mcam_soc_camera_host_register(struct mcam_camera *mcam);
#define C1_DESC_3WORD 0x0200 /* Three-word descriptors used */
#define C1_444ALPHA 0x00f0/* Alpha field in RGB444 */
#define C1_ALPHA_SHFT 20
-#define C1_DMAB32 0x/* 32-byte DMA burst */
-#define C1_DMAB16 0x0200/* 16-byte DMA burst */
-#define C1_DMAB64 0x0400/* 64-byte DMA burst */
+#define C1_DMAB64 0x/* 64-byte DMA burst */
+#define C1_DMAB128 0x0200/* 128-byte DMA burst */
+#define C1_DMAB256 0x0400/* 256-byte DMA burst */
#define C1_DMAB_MASK0x0600
#define C1_TWOBUFS 0x0800/* Use only two DMA buffers */
#define C1_PWRDWN 0x1000/* Power down */
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index bea7224..e840941 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -365,6 +365,17 @@ static int mmpcam_probe(struct platform_device *pdev)
mcam-dphy = (pdata-dphy);
mcam-mipi_enabled = 0;
mcam-lane = pdata-lane;
+ switch (pdata-dma_burst) {
+ case 128:
+ mcam-burst = C1_DMAB128;
+ break;
+ case 256:
+ mcam-burst = C1_DMAB256;
+ break;
+ default:
+ mcam-burst = C1_DMAB64;
+ break;
+ }
INIT_LIST_HEAD(mcam-buffers);
/*
diff --git a/include/media/mmp-camera.h b/include/media/mmp-camera.h
index 731f81f..7a5e63c 100755
--- a/include/media/mmp-camera.h
+++ b/include/media/mmp-camera.h
@@ -11,6 +11,7 @@ struct mmp_camera_platform_data {
int mclk_src;
int mclk_div;
int chip_id;
+ int dma_burst;
/*
* MIPI support
*/
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
This patch adds support of 3 frame buffers in DMA-contiguous mode.
In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support at most 3 frame buffers.
Currently 2 frame buffers mode will be used by default.
To use 3 frame buffers mode, can do:
define MAX_FRAME_BUFS 3
in mcam-core.h
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 59 +--
drivers/media/platform/marvell-ccic/mcam-core.h | 11 +
2 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 2d200d6..3b75594 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -401,13 +401,32 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
struct mcam_vb_buffer *buf;
struct v4l2_pix_format *fmt = cam-pix_format;
- /*
-* If there are no available buffers, go into single mode
-*/
if (list_empty(cam-buffers)) {
- buf = cam-vb_bufs[frame ^ 0x1];
- set_bit(CF_SINGLE_BUFFER, cam-flags);
- cam-frame_state.singles++;
+ /*
+* If there are no available buffers
+* go into single buffer mode
+*
+* If CCIC use Two Buffers mode
+* will use another remaining frame buffer
+* frame 0 - buf 1
+* frame 1 - buf 0
+*
+* If CCIC use Three Buffers mode
+* will use the 2rd remaining frame buffer
+* frame 0 - buf 2
+* frame 1 - buf 0
+* frame 2 - buf 1
+*/
+ buf = cam-vb_bufs[(frame + (MAX_FRAME_BUFS - 1))
+ % MAX_FRAME_BUFS];
+ if (cam-frame_state.tribufs == 0)
+ cam-frame_state.tribufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.tribufs 2)
+ cam-frame_state.tribufs++;
+ }
} else {
/*
* OK, we have a buffer we can use.
@@ -416,15 +435,15 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
queue);
list_del_init(buf-queue);
clear_bit(CF_SINGLE_BUFFER, cam-flags);
+ if (cam-frame_state.tribufs != (3 - MAX_FRAME_BUFS))
+ cam-frame_state.tribufs--;
}
cam-vb_bufs[frame] = buf;
- mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR, buf-yuv_p.y);
+ mcam_reg_write(cam, REG_Y0BAR + (frame 2), buf-yuv_p.y);
if (mcam_fmt_is_planar(fmt-pixelformat)) {
- mcam_reg_write(cam, frame == 0 ?
- REG_U0BAR : REG_U1BAR, buf-yuv_p.u);
- mcam_reg_write(cam, frame == 0 ?
- REG_V0BAR : REG_V1BAR, buf-yuv_p.v);
+ mcam_reg_write(cam, REG_U0BAR + (frame 2), buf-yuv_p.u);
+ mcam_reg_write(cam, REG_V0BAR + (frame 2), buf-yuv_p.v);
}
}
@@ -433,10 +452,14 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, unsigned int frame)
*/
void mcam_ctlr_dma_contig(struct mcam_camera *cam)
{
- mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
- cam-nbufs = 2;
- mcam_set_contig_buffer(cam, 0);
- mcam_set_contig_buffer(cam, 1);
+ unsigned int frame;
+
+ cam-nbufs = MAX_FRAME_BUFS;
+ for (frame = 0; frame cam-nbufs; frame++)
+ mcam_set_contig_buffer(cam, frame);
+
+ if (cam-nbufs == 2)
+ mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
}
/*
@@ -1043,6 +1066,12 @@ static int mcam_vb_start_streaming(struct vb2_queue *vq,
unsigned int count)
for (frame = 0; frame cam-nbufs; frame++)
clear_bit(CF_FRAME_SOF0 + frame, cam-flags);
+ /*
+* If CCIC use Two Buffers mode, init tribufs == 1
+* If CCIC use Three Buffers mode, init tribufs == 0
+*/
+ cam-frame_state.tribufs = 3 - MAX_FRAME_BUFS;
+
return mcam_read_setup(cam);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 5b2cf6e..6420754 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -68,6 +68,13 @@ enum mcam_state {
#define MAX_DMA_BUFS 3
/*
+ * CCIC can support at most 3 frame buffers in DMA_CONTIG buffer mode
+ * 2 - Use Two Buffers mode
+ * 3 - Use Three Buffers mode
+ */
+#define
[PATCH 14/15] [media] marvell-ccic: use unsigned int type replace int type
This patch use unsigned int type replace int type in marvell-ccic.
These variables: frame number, buf number, irq... should be unsigned.
Signed-off-by: Albert Wang twan...@marvell.com
---
.../media/platform/marvell-ccic/mcam-core-soc.h|2 +-
.../platform/marvell-ccic/mcam-core-standard.h | 10 -
drivers/media/platform/marvell-ccic/mcam-core.c| 22 ++--
drivers/media/platform/marvell-ccic/mcam-core.h|2 +-
drivers/media/platform/marvell-ccic/mmp-driver.c |2 +-
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-soc.h
b/drivers/media/platform/marvell-ccic/mcam-core-soc.h
index a5b5fa6..bff8b2a 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core-soc.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core-soc.h
@@ -11,7 +11,7 @@ extern const struct vb2_ops mcam_soc_vb2_ops;
extern void mcam_ctlr_power_up(struct mcam_camera *cam);
extern void mcam_ctlr_power_down(struct mcam_camera *cam);
-extern void mcam_dma_contig_done(struct mcam_camera *cam, int frame);
+extern void mcam_dma_contig_done(struct mcam_camera *cam, unsigned int frame);
extern void mcam_ctlr_stop(struct mcam_camera *cam);
extern int mcam_config_mipi(struct mcam_camera *mcam, int enable);
extern void mcam_ctlr_image(struct mcam_camera *cam);
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-standard.h
b/drivers/media/platform/marvell-ccic/mcam-core-standard.h
index 148a1a1..090c1a2 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core-standard.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core-standard.h
@@ -4,8 +4,8 @@
* Copyright 2011 Jonathan Corbet cor...@lwn.net
*/
extern bool alloc_bufs_at_read;
-extern int n_dma_bufs;
-extern int buffer_mode;
+extern unsigned int n_dma_bufs;
+extern unsigned int buffer_mode;
extern const struct vb2_ops mcam_vb2_sg_ops;
extern const struct vb2_ops mcam_vb2_ops;
@@ -17,12 +17,12 @@ extern void mcam_ctlr_init(struct mcam_camera *cam);
extern int mcam_cam_init(struct mcam_camera *cam);
extern void mcam_free_dma_bufs(struct mcam_camera *cam);
extern void mcam_ctlr_dma_sg(struct mcam_camera *cam);
-extern void mcam_dma_sg_done(struct mcam_camera *cam, int frame);
+extern void mcam_dma_sg_done(struct mcam_camera *cam, unsigned int frame);
extern int mcam_check_dma_buffers(struct mcam_camera *cam);
extern void mcam_set_config_needed(struct mcam_camera *cam, int needed);
extern int __mcam_cam_reset(struct mcam_camera *cam);
extern int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime);
extern void mcam_ctlr_dma_contig(struct mcam_camera *cam);
-extern void mcam_dma_contig_done(struct mcam_camera *cam, int frame);
+extern void mcam_dma_contig_done(struct mcam_camera *cam, unsigned int frame);
extern void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam);
-extern void mcam_vmalloc_done(struct mcam_camera *cam, int frame);
+extern void mcam_vmalloc_done(struct mcam_camera *cam, unsigned int frame);
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 3b05d8c..2d200d6 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -111,7 +111,7 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
/*
* Hand a completed buffer back to user space.
*/
-static void mcam_buffer_done(struct mcam_camera *cam, int frame,
+static void mcam_buffer_done(struct mcam_camera *cam, unsigned int frame,
struct vb2_buffer *vbuf)
{
vbuf-v4l2_buf.bytesused = cam-pix_format.sizeimage;
@@ -125,7 +125,7 @@ static void mcam_buffer_done(struct mcam_camera *cam, int
frame,
*/
static void mcam_reset_buffers(struct mcam_camera *cam)
{
- int i;
+ unsigned int i;
cam-next_buf = -1;
for (i = 0; i cam-nbufs; i++) {
@@ -216,7 +216,7 @@ int mcam_config_mipi(struct mcam_camera *mcam, int enable)
*/
int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
{
- int i;
+ unsigned int i;
mcam_set_config_needed(cam, 1);
if (loadtime)
@@ -257,7 +257,7 @@ int mcam_alloc_dma_bufs(struct mcam_camera *cam, int
loadtime)
void mcam_free_dma_bufs(struct mcam_camera *cam)
{
- int i;
+ unsigned int i;
for (i = 0; i cam-nbufs; i++) {
dma_free_coherent(cam-dev, cam-dma_buf_size,
@@ -296,7 +296,7 @@ void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam)
static void mcam_frame_tasklet(unsigned long data)
{
struct mcam_camera *cam = (struct mcam_camera *) data;
- int i;
+ unsigned int i;
unsigned long flags;
struct mcam_vb_buffer *buf;
@@ -344,7 +344,7 @@ int mcam_check_dma_buffers(struct mcam_camera *cam)
return 0;
}
-void mcam_vmalloc_done(struct mcam_camera *cam, int frame)
+void mcam_vmalloc_done(struct mcam_camera *cam, unsigned int frame)
{
Re: stv090x: possible bug with 8psk,fec=5/6
Оригинално писмо От: N. D. nam...@abv.bg Относно: Re: stv090x: possible bug with 8psk,fec=5/6 До: N. D. nam...@abv.bg Изпратено на: Петък, 2012, Ноември 23 09:48:20 EET Оригинално писмо От: N. D. nam...@abv.bg Относно: stv090x: possible bug with 8psk,fec=5/6 До: linux-media@vger.kernel.org Изпратено на: Четвъртък, 2012, Юни 14 22:33:06 EEST I own a Skystar USB HD which I use with vdr. Ever since I bought the card I have been having some strange issues with 11817V on Astra 23.5E. Femon reports that there is a lock and sound comes but the image is completely garbled. The same setup (Kernel: 3.3.8, VDR: 1.7.27) works fine with an HVR-4000. So I started to suspect that there might be something wrong with the driver. Trying to find out some more information I came across this forum: http://rickcaylor.websitetoolbox.com/post/stv0900_core.c-patch-5481028 I tried the patch which is supposed to (among other things) make the tuner lock on high bitrate transponders (60Mbps). But it did not help. So using the stock driver I gave dvbsnoop a whirl to see if there was something amiss. Astra 3B 11817.00 V DVB-S2 8PSK 27500 5/6 66.6 Mbps packets read: 122/(343292) d_time: 0.001 s = 183488.000 kbit/s (Avrg: 66142.860 kbit/s) [bad: 2] packets read: 42/(343334) d_time: 0.001 s = 63168.000 kbit/s (Avrg: 66150.953 kbit/s) [bad: 0] packets read: 38/(343372) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66158.274 kbit/s) [bad: 2] packets read: 34/(343406) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 66164.825 kbit/s) [bad: 1] packets read: 35/(343441) d_time: 0.001 s = 52640.000 kbit/s (Avrg: 66171.569 kbit/s) [bad: 2] packets read: 31/(343472) d_time: 0.001 s = 46624.000 kbit/s (Avrg: 66177.541 kbit/s) [bad: 4] packets read: 16/(343488) d_time: 0.001 s = 24064.000 kbit/s (Avrg: 66180.624 kbit/s) [bad: 0] packets read: 29/(343517) d_time: 0.008 s = 5452.000 kbit/s (Avrg: 66118.450 kbit/s) [bad: 1] packets read: 116/(343633) d_time: 0.001 s = 174464.000 kbit/s (Avrg: 66140.777 kbit/s) [bad: 1] packets read: 38/(343671) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66148.091 kbit/s) [bad: 1] packets read: 34/(343705) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 66154.635 kbit/s) [bad: 1] packets read: 30/(343735) d_time: 0.001 s = 45120.000 kbit/s (Avrg: 66160.410 kbit/s) [bad: 0] packets read: 37/(343772) d_time: 0.001 s = 55648.000 kbit/s (Avrg: 66167.531 kbit/s) [bad: 2] packets read: 38/(343810) d_time: 0.001 s = 57152.000 kbit/s (Avrg: 66174.845 kbit/s) [bad: 1] packets read: 30/(343840) d_time: 0.001 s = 45120.000 kbit/s (Avrg: 66180.619 kbit/s) [bad: 0] Then I experimented with a lot of other transponders and found another one with the same behavior. HotBird 13C 11411.00 H DVB-S2 8PSK 27500 5/6 68.2 Mbps packets read: 40/(259860) d_time: 0.001 s = 60160.000 kbit/s (Avrg: 65498.482 kbit/s) [bad: 0] packets read: 39/(259899) d_time: 0.001 s = 58656.000 kbit/s (Avrg: 65508.312 kbit/s) [bad: 0] packets read: 34/(259933) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65516.882 kbit/s) [bad: 1] packets read: 34/(259967) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65525.451 kbit/s) [bad: 0] packets read: 36/(260003) d_time: 0.001 s = 54144.000 kbit/s (Avrg: 65534.525 kbit/s) [bad: 2] packets read: 11/(260014) d_time: 0.001 s = 16544.000 kbit/s (Avrg: 65537.298 kbit/s) [bad: 1] packets read: 349/(260363) d_time: 0.008 s = 65612.000 kbit/s (Avrg: 65537.398 kbit/s) [bad: 7] packets read: 25/(260388) d_time: 0.008 s = 4700.000 kbit/s (Avrg: 65456.051 kbit/s) [bad: 0] packets read: 129/(260517) d_time: 0.001 s = 194016.000 kbit/s (Avrg: 65488.479 kbit/s) [bad: 2] packets read: 35/(260552) d_time: 0.001 s = 52640.000 kbit/s (Avrg: 65497.277 kbit/s) [bad: 0] packets read: 37/(260589) d_time: 0.001 s = 55648.000 kbit/s (Avrg: 65506.578 kbit/s) [bad: 2] packets read: 34/(260623) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65515.125 kbit/s) [bad: 2] packets read: 36/(260659) d_time: 0.001 s = 54144.000 kbit/s (Avrg: 65524.174 kbit/s) [bad: 3] packets read: 34/(260693) d_time: 0.001 s = 51136.000 kbit/s (Avrg: 65532.721 kbit/s) [bad: 0] packets read: 21/(260714) d_time: 0.001 s = 31584.000 kbit/s (Avrg: 65538.000 kbit/s) [bad: 0]
[PATCH 08/15] [media] marvell-ccic: switch to resource managed allocation and request
From: Libin Yang lby...@marvell.com
This patch switchs to resource managed allocation and request in mmp-driver.
It can remove free resource operations.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mmp-driver.c | 35 +++---
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 20046d0..c3031e7 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -315,7 +315,7 @@ static int mmpcam_probe(struct platform_device *pdev)
pdata = pdev-dev.platform_data;
- cam = kzalloc(sizeof(*cam), GFP_KERNEL);
+ cam = devm_kzalloc(pdev-dev, sizeof(*cam), GFP_KERNEL);
if (cam == NULL)
return -ENOMEM;
cam-pdev = pdev;
@@ -342,14 +342,12 @@ static int mmpcam_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(pdev-dev, no iomem resource!\n);
- ret = -ENODEV;
- goto out_free;
+ return -ENODEV;
}
- mcam-regs = ioremap(res-start, resource_size(res));
+ mcam-regs = devm_request_and_ioremap(pdev-dev, res);
if (mcam-regs == NULL) {
dev_err(pdev-dev, MMIO ioremap fail\n);
- ret = -ENODEV;
- goto out_free;
+ return -ENODEV;
}
/*
* Power/clock memory is elsewhere; get it too. Perhaps this
@@ -358,14 +356,12 @@ static int mmpcam_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (res == NULL) {
dev_err(pdev-dev, no power resource!\n);
- ret = -ENODEV;
- goto out_unmap1;
+ return -ENODEV;
}
- cam-power_regs = ioremap(res-start, resource_size(res));
+ cam-power_regs = devm_request_and_ioremap(pdev-dev, res);
if (cam-power_regs == NULL) {
dev_err(pdev-dev, power MMIO ioremap fail\n);
- ret = -ENODEV;
- goto out_unmap1;
+ return -ENODEV;
}
mcam_init_clk(mcam, pdata, 1);
@@ -375,9 +371,8 @@ static int mmpcam_probe(struct platform_device *pdev)
*/
mcam-i2c_adapter = platform_get_drvdata(pdata-i2c_device);
if (mcam-i2c_adapter == NULL) {
- ret = -ENODEV;
dev_err(pdev-dev, No i2c adapter\n);
- goto out_unmap2;
+ return -ENODEV;
}
/*
* Sensor GPIO pins.
@@ -386,7 +381,7 @@ static int mmpcam_probe(struct platform_device *pdev)
if (ret) {
dev_err(pdev-dev, Can't get sensor power gpio %d,
pdata-sensor_power_gpio);
- goto out_unmap2;
+ return ret;
}
gpio_direction_output(pdata-sensor_power_gpio, 0);
ret = gpio_request(pdata-sensor_reset_gpio, cam-reset);
@@ -414,7 +409,7 @@ static int mmpcam_probe(struct platform_device *pdev)
goto out_unregister;
}
cam-irq = res-start;
- ret = request_irq(cam-irq, mmpcam_irq, IRQF_SHARED,
+ ret = devm_request_irq(pdev-dev, cam-irq, mmpcam_irq, IRQF_SHARED,
mmp-camera, mcam);
if (ret == 0) {
mmpcam_add_device(cam);
@@ -428,13 +423,7 @@ out_gpio2:
gpio_free(pdata-sensor_reset_gpio);
out_gpio:
gpio_free(pdata-sensor_power_gpio);
-out_unmap2:
mcam_init_clk(mcam, pdata, 0);
- iounmap(cam-power_regs);
-out_unmap1:
- iounmap(mcam-regs);
-out_free:
- kfree(cam);
return ret;
}
@@ -445,16 +434,12 @@ static int mmpcam_remove(struct mmp_camera *cam)
struct mmp_camera_platform_data *pdata;
mmpcam_remove_device(cam);
- free_irq(cam-irq, mcam);
mccic_shutdown(mcam);
mmpcam_power_down(mcam);
pdata = cam-pdev-dev.platform_data;
gpio_free(pdata-sensor_reset_gpio);
gpio_free(pdata-sensor_power_gpio);
- iounmap(cam-power_regs);
- iounmap(mcam-regs);
mcam_init_clk(mcam, pdata, 0);
- kfree(cam);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/15] [media] marvell-ccic: add soc_camera support in mcam core
This patch adds the soc_camera support in mcam core.
It creates the file mcam-core-soc.c and mcam-core-soc.h
to support soc_camera in mcam core.
To use the soc_camera feature, platform driver, such as mmp-driver.c,
should also be modified.
Signed-off-by: Libin Yang lby...@marvell.com
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/Makefile |2 +
.../media/platform/marvell-ccic/mcam-core-soc.c| 414
.../media/platform/marvell-ccic/mcam-core-soc.h| 19 +
drivers/media/platform/marvell-ccic/mcam-core.c| 13 +-
drivers/media/platform/marvell-ccic/mcam-core.h| 37 ++
include/media/mmp-camera.h |3 +
6 files changed, 485 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-soc.c
create mode 100644 drivers/media/platform/marvell-ccic/mcam-core-soc.h
diff --git a/drivers/media/platform/marvell-ccic/Makefile
b/drivers/media/platform/marvell-ccic/Makefile
index 595ebdf..b3e87d4 100755
--- a/drivers/media/platform/marvell-ccic/Makefile
+++ b/drivers/media/platform/marvell-ccic/Makefile
@@ -4,3 +4,5 @@ cafe_ccic-y := cafe-driver.o mcam-core.o
obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera_standard.o
mmp_camera_standard-y := mmp-driver.o mcam-core.o mcam-core-standard.o
+obj-$(CONFIG_VIDEO_MMP_SOC_CAMERA) += mmp_camera_soc.o
+mmp_camera_soc-y := mmp-driver.o mcam-core.o mcam-core-soc.o
diff --git a/drivers/media/platform/marvell-ccic/mcam-core-soc.c
b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
new file mode 100644
index 000..a0df8b4
--- /dev/null
+++ b/drivers/media/platform/marvell-ccic/mcam-core-soc.c
@@ -0,0 +1,414 @@
+/*
+ * The Marvell camera soc core. This device appears in a number of
settings,
+ * so it needs platform-specific support outside of the core.
+ *
+ * Copyright (C) 2009-2012 Marvell International Ltd.
+ *
+ * Author: Libin Yang lby...@marvell.com
+ * Albert Wang twan...@marvell.com
+ *
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/spinlock.h
+#include linux/slab.h
+#include linux/device.h
+#include linux/wait.h
+#include linux/list.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/vmalloc.h
+#include linux/io.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/videobuf2-vmalloc.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#include mcam-core.h
+#include mcam-core-soc.h
+
+static const enum v4l2_mbus_pixelcode mcam_def_mbus_code =
+ V4L2_MBUS_FMT_YUYV8_2X8;
+
+static const struct soc_mbus_pixelfmt mcam_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = YUV422PACKED,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV422P,
+ .name = YUV422PLANAR,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .name = YUV420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVU420,
+ .name = YVU420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+};
+
+static const struct v4l2_pix_format mcam_def_pix_format = {
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_NONE,
+ .bytesperline = VGA_WIDTH*2,
+ .sizeimage = VGA_WIDTH*VGA_HEIGHT*2,
+};
+
+static int mcam_camera_add_device(struct soc_camera_device *icd)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct mcam_camera *mcam = ici-priv;
+ int ret = 0;
+
+ if (mcam-icd)
+ return -EBUSY;
+
+ mcam-frame_complete = mcam_dma_contig_done;
+ mcam-frame_state.frames = 0;
+ mcam-frame_state.singles = 0;
+ mcam-frame_state.delivered = 0;
+
+ mcam-flags = 0;
+ mcam-icd = icd;
+ mcam-state = S_IDLE;
+ mcam-dma_setup = mcam_ctlr_dma_contig;
+ mcam_ctlr_power_up(mcam);
+ mcam_ctlr_stop(mcam);
+ mcam_set_config_needed(mcam, 1);
+ mcam_reg_write(mcam, REG_CTRL1,
+ C1_RESERVED | C1_DMAPOSTED);
+ mcam_reg_write(mcam, REG_CLKCTRL,
+
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
Hi Prabhakar, On Fri, Nov 23, 2012 at 06:51:28PM +0530, Prabhakar Lad wrote: Hi Sakari, On Fri, Nov 23, 2012 at 6:43 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Prabhakar and others, (Just resending; Laurent's e-mail address corrected, cc Hans, too.) On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation As discussed, here's the todo list for inclusion to staging. - User space interface refinement - Controls should be used when possible rather than private ioctl - No enums should be used - Use of MC and V4L2 subdev APIs when applicable - Single interface header might suffice - Current interface forces to configure everything at once - Get rid of the dm365_ipipe_hw.[ch] layer - Active external sub-devices defined by link configuration; no strcmp needed - More generic platform data (i2c adapters) - The driver should have no knowledge of possible external subdevs; see struct vpfe_subdev_id - Some of the hardware control should be refactorede - Check proper serialisation (through mutexes and spinlocks) - Names that are visible in kernel global namespace should have a common prefix (or a few) This list likely isn't complete, but some items such as the locking one is there simply because I'm not certain of the state of it. Thanks a lot. I'll include this TODO's in documentation patch itself, But I am not sure if the driver is going in staging, the documentation file would still be present under Documentation directory or even this should go in staging directory itself ? I think it should go under staging, the same directory as the driver. Hans, Mauro: could you confirm this? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/12] Media Controller capture driver for DM365
On Fri November 23 2012 14:57:53 Sakari Ailus wrote: Hi Prabhakar, On Fri, Nov 23, 2012 at 06:51:28PM +0530, Prabhakar Lad wrote: Hi Sakari, On Fri, Nov 23, 2012 at 6:43 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Prabhakar and others, (Just resending; Laurent's e-mail address corrected, cc Hans, too.) On Fri, Nov 16, 2012 at 08:15:02PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Manjunath Hadli (12): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpss: dm365: enable ISP registers davinci: vpss: dm365: set vpss clk ctrl davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation As discussed, here's the todo list for inclusion to staging. - User space interface refinement - Controls should be used when possible rather than private ioctl - No enums should be used - Use of MC and V4L2 subdev APIs when applicable - Single interface header might suffice - Current interface forces to configure everything at once - Get rid of the dm365_ipipe_hw.[ch] layer - Active external sub-devices defined by link configuration; no strcmp needed - More generic platform data (i2c adapters) - The driver should have no knowledge of possible external subdevs; see struct vpfe_subdev_id - Some of the hardware control should be refactorede - Check proper serialisation (through mutexes and spinlocks) - Names that are visible in kernel global namespace should have a common prefix (or a few) This list likely isn't complete, but some items such as the locking one is there simply because I'm not certain of the state of it. Thanks a lot. I'll include this TODO's in documentation patch itself, But I am not sure if the driver is going in staging, the documentation file would still be present under Documentation directory or even this should go in staging directory itself ? I think it should go under staging, the same directory as the driver. Hans, Mauro: could you confirm this? I agree with that, that way things stay together in one directory. Regards, Hans -- 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 v2 0/5] Common Display Framework
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
Nice work! Thanks for working on this.
I was doing some testing with the code, seeing how to use it in omapdss.
Here are some thoughts:
In your model the DSS gets the panel devices connected to it from
platform data. After the DSS and the panel drivers are loaded, DSS gets
a notification and connects DSS and the panel.
I think it's a bit limited way. First of all, it'll make the DT data a
bit more complex (although this is not a major problem). With your
model, you'll need something like:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
dpi0 {
panel = dpi-panel;
};
/ {
dpi-panel: dpi-panel {
...panel data...;
};
};
Second, it'll prevent hotplug, and even if real hotplug would not be
supported, it'll prevent cases where the connected panel must be found
dynamically (like reading ID from eeprom).
Third, it kinda creates a cyclical dependency: the DSS needs to know
about the panel and calls ops in the panel, and the panel calls ops in
the DSS. I'm not sure if this is an actual problem, but I usually find
it simpler if calls are done only in one direction.
What I suggest is take a simpler approach, something alike to how
regulators or gpios are used, even if slightly more complex than those:
the entity that has a video output (SoC's DSS, external chips) offers
that video output as resource. It doesn't know or care who uses it. The
user of the video output (panel, external chips) will find the video
output (to which it is connected in the HW) by some means, and will use
different operations on that output to operate the device.
This would give us something like the following DT data:
soc-base.dtsi:
dss {
dpi0: dpi {
};
};
board.dts:
/ {
dpi-panel: dpi-panel {
source = dpi0;
...panel data...;
};
};
The panel driver would do something like this in its probe:
int dpi_panel_probe()
{
// Find the video source, increase ref
src = get_video_source_from_of(source);
// Reserve the video source for us. others can still get and
// observe it, but cannot use it as video data source.
// I think this should cascade upstream, so that after this call
// each video entity from the panel to the SoC's CRTC is
// reserved and locked for this video pipeline.
reserve_video_source(src);
// set DPI HW configuration, like DPI data lines. The
// configuration would come from panel's platform data
set_dpi_config(src, config);
// register this panel as a display.
register_display(this);
}
The DSS's dpi driver would do something like:
int dss_dpi_probe()
{
// register as a DPI video source
register_video_source(this);
}
A DSI-2-DPI chip would do something like:
int dsi2dpi_probe()
{
// get, reserve and config the DSI bus from SoC
src = get_video_source_from_of(source);
reserve_video_source(src);
set_dsi_config(src, config);
// register as a DPI video source
register_video_source(this);
}
Here we wouldn't have similar display_entity as you have, but video
sources and displays. Video sources are elements in the video pipeline,
and a video source is used only by the next downstream element. The last
element in the pipeline would not be a video source, but a display,
which would be used by the upper layer.
Video source's ops would deal with things related to the video bus in
question, like configuring data lanes, sending DSI packets, etc. The
display ops would be more high level things, like enable, update, etc.
Actually, I guess you could consider the display to represent and deal
with the whole pipeline, while video source deals with the bus between
two display entities.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH RFC 0/3] s5c73m3 camera sensor driver
This patch series adds V4L2 driver for S5C73M3 camera sensor. This is I2C driver with SPI bus used for firmware upload. Driver exposes two sub-devices: - pure sensor with two source pads (ISP, JPEG), - output-interface pad with two sink sensors (ISP, JPEG) and one source pad. ISP and JPEG pads are connected by immutable links. Two pads allow support for custom camera format V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 in which each frame contains two images in UYVY and JPEG format. Size of each image can be configured independently using pads. Regards Andrzej -- 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 RFC 3/3] s5p-fimc: improved pipeline try format routine
Function support variable number of subdevs in pipe-line.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c | 100 +++-
1 file changed, 64 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 3acbea3..39c4555 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -794,6 +794,21 @@ static int fimc_cap_enum_fmt_mplane(struct file *file,
void *priv,
return 0;
}
+static struct media_entity *fimc_pipeline_get_head(struct media_entity *me)
+{
+ struct media_pad *pad = me-pads[0];
+
+ while (!(pad-flags MEDIA_PAD_FL_SOURCE)) {
+ pad = media_entity_remote_source(pad);
+ if (!pad)
+ break;
+ me = pad-entity;
+ pad = me-pads[0];
+ }
+
+ return me;
+}
+
/**
* fimc_pipeline_try_format - negotiate and/or set formats at pipeline
*elements
@@ -809,65 +824,78 @@ static int fimc_pipeline_try_format(struct fimc_ctx *ctx,
{
struct fimc_dev *fimc = ctx-fimc_dev;
struct v4l2_subdev *sd = fimc-pipeline.subdevs[IDX_SENSOR];
- struct v4l2_subdev *csis = fimc-pipeline.subdevs[IDX_CSIS];
struct v4l2_subdev_format sfmt;
struct v4l2_mbus_framefmt *mf = sfmt.format;
- struct fimc_fmt *ffmt = NULL;
- int ret, i = 0;
+ struct media_entity *me;
+ struct fimc_fmt *ffmt;
+ struct media_pad *pad;
+ int ret, i = 1;
+ u32 fcc;
if (WARN_ON(!sd || !tfmt))
return -EINVAL;
memset(sfmt, 0, sizeof(sfmt));
sfmt.format = *tfmt;
-
sfmt.which = set ? V4L2_SUBDEV_FORMAT_ACTIVE : V4L2_SUBDEV_FORMAT_TRY;
+
+ me = fimc_pipeline_get_head(sd-entity);
+
while (1) {
+
ffmt = fimc_find_format(NULL, mf-code != 0 ? mf-code : NULL,
FMT_FLAGS_CAM, i++);
- if (ffmt == NULL) {
- /*
-* Notify user-space if common pixel code for
-* host and sensor does not exist.
-*/
+ if (ffmt == NULL)
return -EINVAL;
- }
+
mf-code = tfmt-code = ffmt-mbus_code;
- ret = v4l2_subdev_call(sd, pad, set_fmt, NULL, sfmt);
- if (ret)
- return ret;
- if (mf-code != tfmt-code) {
- mf-code = 0;
- continue;
+ /* set format on all pipeline subdevs */
+ while (me != fimc-vid_cap.subdev.entity) {
+ sd = media_entity_to_v4l2_subdev(me);
+
+ sfmt.pad = 0;
+ ret = v4l2_subdev_call(sd, pad, set_fmt, NULL, sfmt);
+ if (ret)
+ return ret;
+
+ if (me-pads[0].flags MEDIA_PAD_FL_SINK) {
+ sfmt.pad = me-num_pads - 1;
+ mf-code = tfmt-code;
+ ret = v4l2_subdev_call(sd, pad, set_fmt, NULL,
+ sfmt);
+ if (ret)
+ return ret;
+ }
+
+ pad = media_entity_remote_source(me-pads[sfmt.pad]);
+ if (!pad)
+ return -EINVAL;
+ me = pad-entity;
}
- if (mf-width != tfmt-width || mf-height != tfmt-height) {
- u32 fcc = ffmt-fourcc;
- tfmt-width = mf-width;
- tfmt-height = mf-height;
- ffmt = fimc_capture_try_format(ctx,
- tfmt-width, tfmt-height,
- NULL, fcc, FIMC_SD_PAD_SOURCE);
- if (ffmt ffmt-mbus_code)
- mf-code = ffmt-mbus_code;
- if (mf-width != tfmt-width ||
- mf-height != tfmt-height)
- continue;
- tfmt-code = mf-code;
- }
- if (csis)
- ret = v4l2_subdev_call(csis, pad, set_fmt, NULL, sfmt);
- if (mf-code == tfmt-code
- mf-width == tfmt-width mf-height == tfmt-height)
- break;
+ if (mf-code != tfmt-code)
+ continue;
+
+ fcc = ffmt-fourcc;
+ tfmt-width = mf-width;
+
[PATCH RFC 2/3] s5p-fimc: add support for sensors with multiple pads
Some sensors can have more than one pad (case of S5C73M3).
In such cases FIMC assumes the last pad of the sensor is the source pad.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/platform/s5p-fimc/fimc-capture.c |6 --
drivers/media/platform/s5p-fimc/fimc-mdevice.c |3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 3d39d97..3acbea3 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -885,14 +885,16 @@ static int fimc_get_sensor_frame_desc(struct v4l2_subdev
*sensor,
{
struct v4l2_mbus_frame_desc fd;
int i, ret;
+ int pad;
for (i = 0; i num_planes; i++)
fd.entry[i].length = plane_fmt[i].sizeimage;
+ pad = sensor-entity.num_pads - 1;
if (try)
- ret = v4l2_subdev_call(sensor, pad, set_frame_desc, 0, fd);
+ ret = v4l2_subdev_call(sensor, pad, set_frame_desc, pad, fd);
else
- ret = v4l2_subdev_call(sensor, pad, get_frame_desc, 0, fd);
+ ret = v4l2_subdev_call(sensor, pad, get_frame_desc, pad, fd);
if (ret 0)
return ret;
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index a69f053..0a6d23c 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -660,7 +660,8 @@ static int fimc_md_create_links(struct fimc_md *fmd)
but s5p-csis module is not loaded!\n))
return -EINVAL;
- ret = media_entity_create_link(sensor-entity, 0,
+ pad = sensor-entity.num_pads - 1;
+ ret = media_entity_create_link(sensor-entity, pad,
csis-entity, CSIS_PAD_SINK,
MEDIA_LNK_FL_IMMUTABLE |
MEDIA_LNK_FL_ENABLED);
--
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 FOR v3.8] OMAP3 ISP patches
Hi Mauro, This time the pull request should be good :-) The following changes since commit 1323024fd3296537dd34da70fe70b4df12a308ec: [media] siano: fix build with allmodconfig (2012-11-23 13:48:39 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp/next Laurent Pinchart (6): omap3isp: Use monotonic timestamps for statistics buffers omap3isp: Remove unneeded module memory address definitions omap3isp: Replace printk with dev_* omap3isp: preview: Add support for 8-bit formats at the sink pad omap3isp: Prepare/unprepare clocks before/after enable/disable omap3isp: Replace cpu_is_omap3630() with ISP revision check Sakari Ailus (4): omap3isp: Add CSI configuration registers from control block to ISP resources omap3isp: Add PHY routing configuration omap3isp: Configure CSI-2 phy based on platform data omap3isp: Find source pad from external entity arch/arm/mach-omap2/devices.c| 10 + drivers/media/platform/omap3isp/isp.c| 83 ++ drivers/media/platform/omap3isp/isp.h|5 +- drivers/media/platform/omap3isp/ispcsi2.c|6 +- drivers/media/platform/omap3isp/ispcsiphy.c | 227 ++--- drivers/media/platform/omap3isp/ispcsiphy.h | 10 - drivers/media/platform/omap3isp/isphist.c|8 +- drivers/media/platform/omap3isp/isppreview.c | 41 +++-- drivers/media/platform/omap3isp/ispreg.h | 99 +++- drivers/media/platform/omap3isp/ispstat.c|5 +- drivers/media/platform/omap3isp/ispstat.h|2 +- drivers/media/platform/omap3isp/ispvideo.c |3 +- 12 files changed, 294 insertions(+), 205 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MAINTAINERS: Taking over saa7146 maintainership from Michael Hunold.
Hi, on 23.11.2012 14:10 Hans Verkuil said the following: From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 80b8f68..76b1c1d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6440,10 +6440,9 @@ F: Documentation/video4linux/saa7134/ F: drivers/media/pci/saa7134/ SAA7146 VIDEO4LINUX-2 DRIVER -M: Michael Hunold mich...@mihu.de +M: Hans Verkuil hverk...@xs4all.nl L: linux-media@vger.kernel.org T: git git://linuxtv.org/media_tree.git -W: http://www.mihu.de/linux/saa7146 S: Maintained F: drivers/media/common/saa7146/ F: drivers/media/pci/saa7146/ Acked-by: Michael Hunold mich...@mihu.de CU Michael. -- 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
Mysterious USB device ID change on Hauppauge HVR-900 (em28xx)
Hi, I've got a Hauppauge HVR-900 (65008/A1C0) today. First, the device showed up as USB device 7640:edc1 (even after several unplug - replug cycles), so I decided to add this VID:PID to the em28xx driver to see what happens. That worked fine, em2882/em2883, tuner xc2028/3028 etc. were detected properly. Later I noticed, that the device now shows up as 2040:6500, which is the expected ID for this device. Since then, the device maintains this ID. I also checked if Windows is involved, but it shows up with the same ID there. Does anyone have an idea what could have happened ??? I wonder if we should add this ID to the em28xx driver... Regards, Frank -- 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] MAINTAINERS: add tda9840, tea6415c and tea6420 entries.
Hi, on 23.11.2012 14:10 Hans Verkuil said the following: From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS | 24 1 file changed, 24 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 76b1c1d..c25ade7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7412,6 +7412,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda8290.* +TDA9840 MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tda9840* + TEA5761 TUNER DRIVER M: Mauro Carvalho Chehab mche...@redhat.com L: linux-media@vger.kernel.org @@ -7428,6 +7436,22 @@ T: git git://linuxtv.org/media_tree.git S: Maintained F: drivers/media/tuners/tea5767.* +TEA6415C MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tea6415c* + +TEA6420 MEDIA DRIVER +M: Hans Verkuil hverk...@xs4all.nl +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Maintained +F: drivers/media/i2c/tea6420* + TEAM DRIVER M: Jiri Pirko jpi...@redhat.com L: net...@vger.kernel.org these drivers belong to the Multimedia eXtension Board which is saa7146 based, so: Acked-by: Michael Hunold mich...@mihu.de CU Michael. -- 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] gspca - ov534: Fix the light frequency filter
On Thu, 22 Nov 2012 12:46:52 +0100
Jean-Francois Moine moin...@free.fr wrote:
(fix lack of signature)
From: Jean-François Moine moin...@free.fr
The exchanges relative to the light frequency filter were adapted
from a description found in a ms-windows driver. It seems that the
registers were the ones of some other sensor.
The PS3 sends the old sequence too AFAIR, for the PS3 Eye.
This patch was done thanks to the documentation of the right
OmniVision sensors.
In the datasheet I have for ov772x, bit[6] of register 0x13 is described
as:
Bit[6]: AEC - Step size limit
0: Step size is limited to vertical blank
1: Unlimited step size
And the patch makes Light Frequency _NOT_ work with the PS3 eye (based
on ov772x).
What does the ov767x datasheet say?
Maybe we should use the new values only when
sd-sensor == SENSOR_OV767x
What sensor does Alexander's webcam use?
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
drivers/media/usb/gspca/ov534.c: In function ‘setlightfreq’:
drivers/media/usb/gspca/ov534.c:1039:13: warning: unused variable ‘sd’
[-Wunused-variable]
But that will go away if we check for the sensor again in a next
version of the patch.
- val = val ? 0x9e : 0x00;
- if (sd-sensor == SENSOR_OV767x) {
- sccb_reg_write(gspca_dev, 0x2a, 0x00);
- if (val)
- val = 0x9d; /* insert dummy to 25fps for 50Hz */
- }
- sccb_reg_write(gspca_dev, 0x2b, val);
+ if (!val)
+ sccb_reg_write(gspca_dev, 0x13, /* off */
+ sccb_reg_read(gspca_dev, 0x13) ~0x20);
+ else
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
}
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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: Mysterious USB device ID change on Hauppauge HVR-900 (em28xx)
On 11/23/2012 07:01 PM, Frank Schäfer wrote: Hi, I've got a Hauppauge HVR-900 (65008/A1C0) today. First, the device showed up as USB device 7640:edc1 (even after several unplug - replug cycles), so I decided to add this VID:PID to the em28xx driver to see what happens. That worked fine, em2882/em2883, tuner xc2028/3028 etc. were detected properly. Later I noticed, that the device now shows up as 2040:6500, which is the expected ID for this device. Since then, the device maintains this ID. I also checked if Windows is involved, but it shows up with the same ID there. Does anyone have an idea what could have happened ??? I wonder if we should add this ID to the em28xx driver... em28xx chip reads USB ID from the external eeprom using I2C just after it was powered. After USB ID is got it connects to the USB bus using that ID. If there is no external eeprom it uses chipset default USB ID, which is 0xeb1a as vendor ID and some other number defined for chip model as device ID. In that case those wrong IDs seems to be total garbage, which indicates there is some hardware problems when communicating towards eeprom. That method is not only Empia USB interface chips but almost all chipset uses just similar method. regard Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: avermedia, new version of avertv volar green hd
Totally new chipset (AV3007) or markings are changed. Did you look
another side of PCB if there is some other chips?
I suspect it is all integrated to that chip unless there is RF-tuner on
the other side of PCB.
Without the lsusb, driver, and any other info we cannot help more.
regards
Antti
On 11/23/2012 03:24 PM, moebius wrote:
Bonjour,
A little in late but here is the pic location :
http://dl.free.fr/n7m8Gfe5q
cordialement,
Le 07/11/2012 16:23, Antti Palosaari a écrit :
Hello
If possible put those pictures somewhere to the net and give link
everyone could take a look. If that's not possible then I am still happy
to get those pics to my that email address.
regards
Antti
On 11/07/2012 03:39 PM, moebius wrote:
Bonjour,
This is not possible anymore : the device has returned to the seller !
But AV3007 is perhaps a compagny chip (AV = avermedia ?)
cordialement,
PS : if you give me an adress, I can post the picture of the opened
device
Le 06/11/2012 22:09, Antti Palosaari a écrit :
Also lsusb -vvd 07ca:3835 could be nice to see.
Antti
On 11/06/2012 10:33 PM, Antti Palosaari wrote:
Any idea about chipset? Those listed didn't sound any familiar. What
are
driver file names?
regards
Antti
On 11/05/2012 02:37 PM, Árvai Zoltán wrote:
Hi,
I asked the local guy from Avermedia about this tuner.
He said it is a new product called AVerTV Volar HD M (A835M). It
has
probably the same hardware like the Volar Green, but it has extended
software bundle (e.g. Mac support).
http://www.avermedia.com/Product/ProductDetail.aspx?Id=517
Regards,
Zoltan
On 11/04/2012 07:43 PM, moebius wrote:
Bonjour,
It's a dvb-t usb dongle
It's the same name than a former device but with new id : 07ca:3835
instead of 07ca:a835 and probably new hardware ; and it doesn't
work...
I've tried to enter a new device in the v4l-dvb web list but nothing
has happened ; the source, can be found at
http://www.linuxtv.org/wiki/index.php?title=DVB-T_USB_Devices_ListData/Helperaction=editsection=1
I've made a photo too but don't know how I can upload it.
Anyway, here is the source :
AVerMedia AVerTV Volar Green HD 07ca:3835
{{DeviceDisplayMedium|AVerMedia AVerTV Volar Green HD 07ca:3835}}
/noincludeincludeonly
{renderwith}}}|src=USB_Device_Data|selatt1={{{selatt1|}}}|selval1={{{selval1|}}}|selatt2={{{selatt2|}}}|selval2={{{selval2|}}}|selatt3={{{selatt3|}}}|selval3={{{selval3|}}}|selatt4={{{selatt4|}}}|selval4={{{selval4|}}}
| did=AVerMedia AVerTV Volar Green HD 07ca:3835
| vendor=[[AVerMedia]]
| device=[[AVerMedia AVerTV Volar Green HD | AVerTV Volar Green HD]]
| standard=DVB-T
| supported={{no}}
| pic=
| pic=
| url=
| url=
| hostinterface=USB2.0
| usbid=07ca:3835
| hw=unknown (see pic)
| tuner=
| demodulator=
| usbbridge=
| fw=
| comment= New version with same name ; main chipset (square, 4x12
pins) named AV3007 SXB1102 ; a little chip with 8 pins named 402R6
K207, another one with 5 pins 215L1(or I instead of 1) AC1H ;
last
small chip with metal on top T120 WtBF.
This device don't work on recent ubuntu kernel
(3.2.0-23-lowlatency),
even with the last (04/11/2012) v4l drivers that I've downloaded and
install today.
}}
cordialement,
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe
linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gspca - ov534: Fix the light frequency filter
On Fri, 23 Nov 2012 18:09:09 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
On Thu, 22 Nov 2012 12:46:52 +0100
[snip]
Jean-Francois Moine moin...@free.fr wrote:
This patch was done thanks to the documentation of the right
OmniVision sensors.
In the datasheet I have for ov772x, bit[6] of register 0x13 is described
as:
Bit[6]: AEC - Step size limit
0: Step size is limited to vertical blank
1: Unlimited step size
Right, but I don't use the bit 6, it is the bit 5:
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
which is described as:
Bit[5]: Banding filter ON/OFF
And the patch makes Light Frequency _NOT_ work with the PS3 eye (based
on ov772x).
What does the ov767x datasheet say?
Quite the same thing:
Bit[5]: Banding filter ON/OFF - In order to turn ON the banding
filter, BD50ST (0x9D) or BD60ST (0x9E) must be set to a
non-zero value.
0: OFF
1: ON
(the registers 9d and 9e are non zero for the ov767x in ov534.c)
Maybe we should use the new values only when
sd-sensor == SENSOR_OV767x
What sensor does Alexander's webcam use?
He has exactly the same webcam as yours: 1415:2000 (ps eye) with
sensor ov772x.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
drivers/media/usb/gspca/ov534.c: In function ‘setlightfreq’:
drivers/media/usb/gspca/ov534.c:1039:13: warning: unused variable ‘sd’
[-Wunused-variable]
Thanks.
Well, here is one of the last message I received from Alexander (in
fact, his first name is Fabian):
Thanks for all your help, it is very kind of you, I used the code below,the
60 Hz filter appear to work even at 100fps, but when I used 125 fps it
didnt work :( , i guess it is something of detection speed. If you have any
other idea I'll be very thankful.
Sincerely Fabian Calderon
So, how may we advance?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mysterious USB device ID change on Hauppauge HVR-900 (em28xx)
Am 23.11.2012 18:20, schrieb Antti Palosaari: On 11/23/2012 07:01 PM, Frank Schäfer wrote: Hi, I've got a Hauppauge HVR-900 (65008/A1C0) today. First, the device showed up as USB device 7640:edc1 (even after several unplug - replug cycles), so I decided to add this VID:PID to the em28xx driver to see what happens. That worked fine, em2882/em2883, tuner xc2028/3028 etc. were detected properly. Later I noticed, that the device now shows up as 2040:6500, which is the expected ID for this device. Since then, the device maintains this ID. I also checked if Windows is involved, but it shows up with the same ID there. Does anyone have an idea what could have happened ??? I wonder if we should add this ID to the em28xx driver... em28xx chip reads USB ID from the external eeprom using I2C just after it was powered. After USB ID is got it connects to the USB bus using that ID. If there is no external eeprom it uses chipset default USB ID, which is 0xeb1a as vendor ID and some other number defined for chip model as device ID. In that case those wrong IDs seems to be total garbage, which indicates there is some hardware problems when communicating towards eeprom. Yeah, hardware problems, sure... but I wonder why the USB ID was/is persistent ? Communication problems caused by circuit defect should lead to a rather random behavior... On power loss, the everything except (ee)prom(s) contents should be reset to a default state. And if the eeprom was corrupted, how could it magically recover ? Also: the USB id is read from the eeprom even without a OS driver beeing involved, but the first usage of the driver seems to have fixed the ID... Regards, Frank That method is not only Empia USB interface chips but almost all chipset uses just similar method. regard Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.8] DMABUF support in Video4Linux
Hi Mauro, This patch series adds DMABUF importer and exporting feature to V4L2 API and to some s5p-* drivers. I'm sending this on behalf of Tomasz Stanislawski. Please pull for v3.8. The following changes since commit 1323024fd3296537dd34da70fe70b4df12a308ec: [media] siano: fix build with allmodconfig (2012-11-23 13:48:39 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/media.git samsung/dmabuf_for_v3.8 Laurent Pinchart (2): v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: reorder functions Marek Szyprowski (4): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (18): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: vb2-vmalloc: add support for dmabuf importing v4l: vivi: support for dmabuf importing v4l: uvc: add support for DMABUF importing v4l: mem2mem_testdev: add support for dmabuf importing v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation: media: description of DMABUF exporting in V4L2 v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2-dma-contig: add support for DMABUF exporting v4l: vb2-dma-contig: add reference counting for a device from allocator context v4l: vb2-dma-contig: align buffer size to PAGE_SIZE v4l: s5p-fimc: support for dmabuf exporting v4l: s5p-tv: mixer: support for dmabuf exporting v4l: s5p-mfc: support for dmabuf exporting Documentation/DocBook/media/v4l/compat.xml |7 + Documentation/DocBook/media/v4l/io.xml | 184 +- Documentation/DocBook/media/v4l/v4l2.xml |1 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 16 +- Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 212 ++ Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 17 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +- drivers/media/platform/mem2mem_testdev.c |4 +- drivers/media/platform/s5p-fimc/fimc-capture.c | 11 +- drivers/media/platform/s5p-fimc/fimc-m2m.c | 14 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 14 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 14 + drivers/media/platform/s5p-tv/mixer_video.c| 12 +- drivers/media/platform/vivi.c |2 +- drivers/media/usb/uvc/uvc_queue.c |2 +- drivers/media/v4l2-core/Kconfig|3 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 + drivers/media/v4l2-core/v4l2-dev.c |1 + drivers/media/v4l2-core/v4l2-ioctl.c | 11 + drivers/media/v4l2-core/v4l2-mem2mem.c | 13 + drivers/media/v4l2-core/videobuf-core.c|4 + drivers/media/v4l2-core/videobuf2-core.c | 300 +- drivers/media/v4l2-core/videobuf2-dma-contig.c | 700 ++-- drivers/media/v4l2-core/videobuf2-memops.c | 40 -- drivers/media/v4l2-core/videobuf2-vmalloc.c| 56 ++ include/media/v4l2-ioctl.h |2 + include/media/v4l2-mem2mem.h |3 + include/media/videobuf2-core.h | 38 ++ include/media/videobuf2-memops.h |5 - include/uapi/linux/videodev2.h | 35 + 30 files changed, 1646 insertions(+), 141 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml --- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display entity is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the display entities 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 other display entities through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display controller and display entity drivers would take a reference to each other. Those circular references would make driver unloading impossible. One possible solution to this problem would be to simulate an unplug event for the display entity, to force the display driver to release the dislay entities it uses. We would need a userspace API for that though. Better solutions would of course be welcome. Maybe I don't understand all of the underlying issues correctly, but a parent/child model would seem like a better solution to me. We discussed this back when designing the DT bindings for Tegra DRM and came to the conclusion that the output resource of the display controller (RGB, HDMI, DSI or TVO) was the most suitable candidate to be the parent of the panel or display attached to it. The reason for that decision was that it keeps the flow of data or addressing of nodes consistent. So the chain would look something like this (on Tegra): CPU +-host1x +-dc +-rgb | +-panel +-hdmi +-monitor In a natural way this makes the output resource the master of the panel or display. From a programming point of view this becomes quite easy to implement and is very similar to how other busses like I2C or SPI are modelled. In device tree these would be represented as subnodes, while with platform data some kind of lookup could be done like for regulators or alternatively a board setup registration mechanism like what's in place for I2C or SPI. Thierry pgpRbeGtDw3N5.pgp Description: PGP signature
Re: Mysterious USB device ID change on Hauppauge HVR-900 (em28xx)
Em Fri, 23 Nov 2012 18:01:14 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Hi, I've got a Hauppauge HVR-900 (65008/A1C0) today. First, the device showed up as USB device 7640:edc1 (even after several unplug - replug cycles), so I decided to add this VID:PID to the em28xx driver to see what happens. That worked fine, em2882/em2883, tuner xc2028/3028 etc. were detected properly. Later I noticed, that the device now shows up as 2040:6500, which is the expected ID for this device. Since then, the device maintains this ID. I also checked if Windows is involved, but it shows up with the same ID there. This is a known hardware bug on some HVR devices. I have this problem with one based on tm6000: sometimes, it is not able to read from the EEPROM. When this happens, it gets the manufacturer's default USB ID. You may force it to use the right em28xx entry using card= modprobe parameter. -- 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
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:Fri Nov 23 19:00:29 CET 2012 git hash:1323024fd3296537dd34da70fe70b4df12a308ec 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: [RFC v2 0/5] Common Display Framework
Hi Laurent, On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com The CDF models this using a Russian doll's model. From the display controller point of view only the first external entity (LVDS to DSI converter) is visible. The display controller thus calls the control operations implemented by the LVDS to DSI transmitter driver (left-most green arrow). The driver is aware of the next entity in the chain, I can't find this in the code. I can see the video operations propagating upstream using the source field of struct display_entity, but how do the control operations propagate downstream? Am I missing something? 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
