Re: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t
On 11/29/2012 09:45 PM, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com Turns out a few drivers have strayed away from using the spinlock_t typedef and decided to use struct spinlock directly. This series converts these drivers to use spinlock_t. Each change has been compile tested with allmodconfig and sparse checked. Driver developers may want to look at the compile error output / sparse error report supplied in each commit log, in particular brcmfmac and i915, there are quite a few things that are not related to this change that the developers can clean up / fix. So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle (chapter 5 Typedefs) is spending a number of lines explaining why. So is spinlock_t an exception to this rule simply because the kernel uses spinlock_t all over the place. Using Greg's favorite final email remark: Confused. Gr. AvS Luis R. Rodriguez (6): ux500: convert struct spinlock to spinlock_t i915: convert struct spinlock to spinlock_t s5p-fimc: convert struct spinlock to spinlock_t s5p-jpeg: convert struct spinlock to spinlock_t brcmfmac: convert struct spinlock to spinlock_t ie6xx_wdt: convert struct spinlock to spinlock_t drivers/crypto/ux500/cryp/cryp.h |4 ++-- drivers/crypto/ux500/hash/hash_alg.h |4 ++-- drivers/gpu/drm/i915/i915_drv.h|4 ++-- drivers/media/platform/s5p-fimc/mipi-csis.c|2 +- drivers/media/platform/s5p-jpeg/jpeg-core.h|2 +- drivers/net/wireless/brcm80211/brcmfmac/fweh.h |2 +- drivers/watchdog/ie6xx_wdt.c |2 +- 7 files changed, 10 insertions(+), 10 deletions(-) -- 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 2/5] video: panel: Add DPI panel support
Hi Laurent,
Am Donnerstag, den 22.11.2012, 22:45 +0100 schrieb Laurent Pinchart:
From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig | 13 +++
drivers/video/display/Makefile|1 +
drivers/video/display/panel-dpi.c | 147
+
include/video/panel-dpi.h | 24 ++
4 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 include/video/panel-dpi.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..0f9b990 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,16 @@ menuconfig DISPLAY_CORE
tristate Display Core
---help---
Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_PANEL_DPI
+ tristate DPI (Parallel) Display Panels
+ ---help---
+ Support for simple digital (parallel) pixel interface panels. Those
+ panels receive pixel data through a parallel bus and have no control
+ bus.
I have tried this driver together with the imx parallel-display with the
added patch below for device tree support.
+ If you are in doubt, say N.
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index bd93496..47978d4 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DISPLAY_CORE) += display-core.o
+obj-$(CONFIG_DISPLAY_PANEL_DPI) += panel-dpi.o
diff --git a/drivers/video/display/panel-dpi.c
b/drivers/video/display/panel-dpi.c
new file mode 100644
index 000..c56197a
--- /dev/null
+++ b/drivers/video/display/panel-dpi.c
@@ -0,0 +1,147 @@
+/*
+ * DPI Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include video/display.h
+#include video/panel-dpi.h
+
+struct panel_dpi {
+ struct display_entity entity;
+ const struct panel_dpi_platform_data *pdata;
+};
+
+#define to_panel_dpi(p) container_of(p, struct panel_dpi,
entity)
+
+static const struct display_entity_interface_params panel_dpi_params = {
+ .type = DISPLAY_ENTITY_INTERFACE_DPI,
+};
+
+static int panel_dpi_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+ switch (state) {
+ case DISPLAY_ENTITY_STATE_OFF:
+ case DISPLAY_ENTITY_STATE_STANDBY:
+ display_entity_set_stream(entity-source,
+ DISPLAY_ENTITY_STREAM_STOPPED);
+ break;
+
+ case DISPLAY_ENTITY_STATE_ON:
+ display_entity_set_stream(entity-source,
+ DISPLAY_ENTITY_STREAM_CONTINUOUS);
+ break;
+ }
+
+ return 0;
+}
+
+static int panel_dpi_get_modes(struct display_entity *entity,
+const struct videomode **modes)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ *modes = panel-pdata-mode;
+ return 1;
+}
+
+static int panel_dpi_get_size(struct display_entity *entity,
+ unsigned int *width, unsigned int *height)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ *width = panel-pdata-width;
+ *height = panel-pdata-height;
+ return 0;
+}
+
+static int panel_dpi_get_params(struct display_entity *entity,
+ struct display_entity_interface_params *params)
+{
+ *params = panel_dpi_params;
+ return 0;
+}
+
+static const struct display_entity_control_ops panel_dpi_control_ops = {
+ .set_state = panel_dpi_set_state,
+ .get_modes = panel_dpi_get_modes,
+ .get_size = panel_dpi_get_size,
+ .get_params = panel_dpi_get_params,
+};
+
+static void panel_dpi_release(struct display_entity *entity)
+{
+ struct panel_dpi *panel = to_panel_dpi(entity);
+
+ kfree(panel);
+}
+
+static int panel_dpi_remove(struct platform_device *pdev)
+{
+ struct panel_dpi *panel = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ display_entity_unregister(panel-entity);
+
+ return 0;
+}
+
+static int __devinit panel_dpi_probe(struct platform_device *pdev)
+{
+ const struct panel_dpi_platform_data *pdata = pdev-dev.platform_data;
+ struct panel_dpi *panel;
+ int ret;
+
+ if (pdata ==
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
On Wed, Nov 28, 2012 at 04:12:00PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com Mauro/Greg, The below series of patches have gone through good amount of reviews, and agreed by Laurent, Hans and Sakari to be part of the staging tree. I am combining the patchs with the pull request so we can get them into the 3.8 kernel. Please pull these patches.If you want a seperate pull request, please let me know. This patch set adds media controller based capture driver for DM365. For the whole set --- granted that the TODO item to add support for regular V4L2 applications through user space libraries is added: Acked-by: Sakari Ailus sakari.ai...@iki.fi -- 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 v3 0/9] Media Controller capture driver for DM365
On Fri November 30 2012 10:47:39 Sakari Ailus wrote: On Wed, Nov 28, 2012 at 04:12:00PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com Mauro/Greg, The below series of patches have gone through good amount of reviews, and agreed by Laurent, Hans and Sakari to be part of the staging tree. I am combining the patchs with the pull request so we can get them into the 3.8 kernel. Please pull these patches.If you want a seperate pull request, please let me know. This patch set adds media controller based capture driver for DM365. For the whole set --- granted that the TODO item to add support for regular V4L2 applications through user space libraries is added: Acked-by: Sakari Ailus sakari.ai...@iki.fi Ditto for the TODO item. Acked-by: Hans Verkuil hans.verk...@cisco.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.8] Update MAINTAINERS file
Hi Mauro, This updates the MAINTAINERS file with all the drivers I'm supporting/maintaining or do odd fixes for. Regards, Hans The following changes since commit d8658bca2e5696df2b6c69bc5538f8fe54e4a01e: [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check (2012-11-28 10:54:46 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git maintainers for you to fetch changes up to 2541f79d3d149e0a520e98285c4062216348e121: MAINTAINERS: add si470x-usb+common and si470x-i2c entries. (2012-11-30 11:15:18 +0100) Hans Verkuil (18): MAINTAINERS: add adv7604/ad9389b entries. MAINTAINERS: add cx2341x entry. MAINTAINERS: add entry for the quickcam parallel port webcams. MAINTAINERS: add radio-keene entry. MAINTAINERS: add radio-cadet entry. MAINTAINERS: add radio-isa entry. MAINTAINERS: add radio-aztech entry. MAINTAINERS: add radio-aimslab entry. MAINTAINERS: add radio-gemtek entry. MAINTAINERS: add radio-maxiradio entry. MAINTAINERS: add radio-miropcm20 entry. MAINTAINERS: add pms entry. MAINTAINERS: add saa6588 entry. MAINTAINERS: add usbvision entry. MAINTAINERS: add vivi entry. MAINTAINERS: Taking over saa7146 maintainership from Michael Hunold. MAINTAINERS: add tda9840, tea6415c and tea6420 entries. MAINTAINERS: add si470x-usb+common and si470x-i2c entries. MAINTAINERS | 170 +++-- 1 file changed, 168 insertions(+), 2 deletions(-) -- 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 v6] [media] vivi: Teach it to tune FPS
On Mon, Nov 19, 2012 at 09:52:36AM +0400, Kirill Smelkov wrote:
On Sun, Nov 18, 2012 at 07:25:38AM -0200, Mauro Carvalho Chehab wrote:
Em 18-11-2012 07:24, Mauro Carvalho Chehab escreveu:
Em 17-11-2012 08:45, Kirill Smelkov escreveu:
On Fri, Nov 16, 2012 at 01:46:58PM -0200, Mauro Carvalho Chehab wrote:
Em 16-11-2012 11:38, Hans Verkuil escreveu:
On Wed November 7 2012 12:30:01 Kirill Smelkov wrote:
[...]
diff --git a/drivers/media/platform/vivi.c
b/drivers/media/platform/vivi.c
index 37d0af8..5d1b374 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -65,8 +65,11 @@ MODULE_PARM_DESC(vid_limit, capture memory limit
in megabytes);
/* Global font descriptor */
static const u8 *font8x16;
-/* default to NTSC timeperframe */
-static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
.denominator = 3};
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+tpf_min = {.numerator = 1,.denominator = UINT_MAX},
/* 1/infty */
+tpf_max = {.numerator = UINT_MAX,.denominator = 1},
/* infty */
I understand your reasoning here, but I wouldn't go with UINT_MAX here.
Something like
1/1000 tpf (or 1 ms) up to 86400/1 tpf (or once a day). With UINT_MAX I
am afraid we
might hit application errors when they manipulate these values. The
shortest time
between frames is 1 ms anyway.
It's the only comment I have, it looks good otherwise.
As those will be a arbitrary values, I suggest to declare a macro for it
at the
beginning of vivi.c file, with some comment explaining the rationale of
the choose,
and what else needs to be changed, if this changes (e. g. less than 1ms
would require
changing the image generation logic, to avoid producing frames with
equal content).
Maybe something like this? (please note, I'm not a good text writer. If
this needs adjustment please help me shape the text up)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 5d1b374..45b8a81 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -36,6 +36,18 @@
#define VIVI_MODULE_NAME vivi
+/* Maximum allowed frame rate
+ *
+ * Vivi will allow setting timeperframe in [1/FPS_MAX - FPS_MAX/1] range.
+ *
+ * Ideally FPS_MAX should be infinity, i.e. practically UINT_MAX, but
that
+ * might hit application errors when they manipulate these values.
+ *
+ * Besides, for tpf 1ms image-generation logic should be changed, to
avoid
+ * producing frames with equal content.
+ */
+#define FPS_MAX 1000
+
#define MAX_WIDTH 1920
#define MAX_HEIGHT 1200
@@ -67,8 +79,8 @@ static const u8 *font8x16;
/* timeperframe: min/max and default */
static const struct v4l2_fract
-tpf_min = {.numerator = 1,.denominator = UINT_MAX}, /*
1/infty */
-tpf_max = {.numerator = UINT_MAX,.denominator = 1},
/* infty */
+tpf_min = {.numerator = 1,.denominator = FPS_MAX}, /*
~1/infty */
+tpf_max = {.numerator = FPS_MAX,.denominator = 1},
/* ~infty */
Was too fast answering it... The comments there should also be dropped, as
it doesn't
range anymore to infty.
Ok, agree, let's drop those ~infty comments and be done with it.
8
From: Kirill Smelkov k...@mns.spb.ru
Date: Tue, 23 Oct 2012 16:56:59 +0400
Subject: [PATCH v6] [media] vivi: Teach it to tune FPS
I was testing my video-over-ethernet subsystem recently, and vivi
seemed to be perfect video source for testing when one don't have lots
of capture boards and cameras. Only its framerate was hardcoded to
NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
needed that to precisely simulate bandwidth.
That's why here is this patch with -enum_frameintervals() and
-{g,s}_parm() implemented as suggested by Hans Verkuil which passes
v4l2-compliance and manual testing through v4l2-ctl -P / -p fps.
Regarding newly introduced __get_format(u32 pixelformat) I decided not
to convert original get_format() to operate on fourcc codes, since = 3
places in driver need to deal with v4l2_format and otherwise it won't be
handy.
Thanks.
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
drivers/media/platform/vivi.c | 102
++
1 file changed, 94 insertions(+), 8 deletions(-)
V6:
- Moved TPF/FPS limit to beginning of vivi.c and added comment there
why that limit is used, to avoid overlows, as suggested by Mauro
Carvalho Chehab.
V5:
- changed 1/infty - infty/1 limits to 1/1000 - 1000/1, to avoid
hitting aplication errors when they try to manipulato those
values, as suggested by Hans Verkuil.
V4:
- corrected fival-stepwise setting and added its check to s_parm();
also
Re: [PATCH v6] [media] vivi: Teach it to tune FPS
On Fri November 30 2012 12:02:14 Kirill Smelkov wrote:
On Mon, Nov 19, 2012 at 09:52:36AM +0400, Kirill Smelkov wrote:
On Sun, Nov 18, 2012 at 07:25:38AM -0200, Mauro Carvalho Chehab wrote:
Em 18-11-2012 07:24, Mauro Carvalho Chehab escreveu:
Em 17-11-2012 08:45, Kirill Smelkov escreveu:
On Fri, Nov 16, 2012 at 01:46:58PM -0200, Mauro Carvalho Chehab wrote:
Em 16-11-2012 11:38, Hans Verkuil escreveu:
On Wed November 7 2012 12:30:01 Kirill Smelkov wrote:
[...]
diff --git a/drivers/media/platform/vivi.c
b/drivers/media/platform/vivi.c
index 37d0af8..5d1b374 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -65,8 +65,11 @@ MODULE_PARM_DESC(vid_limit, capture memory limit
in megabytes);
/* Global font descriptor */
static const u8 *font8x16;
-/* default to NTSC timeperframe */
-static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
.denominator = 3};
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+tpf_min = {.numerator = 1,.denominator = UINT_MAX},
/* 1/infty */
+tpf_max = {.numerator = UINT_MAX,.denominator = 1},
/* infty */
I understand your reasoning here, but I wouldn't go with UINT_MAX
here. Something like
1/1000 tpf (or 1 ms) up to 86400/1 tpf (or once a day). With UINT_MAX
I am afraid we
might hit application errors when they manipulate these values. The
shortest time
between frames is 1 ms anyway.
It's the only comment I have, it looks good otherwise.
As those will be a arbitrary values, I suggest to declare a macro for
it at the
beginning of vivi.c file, with some comment explaining the rationale
of the choose,
and what else needs to be changed, if this changes (e. g. less than
1ms would require
changing the image generation logic, to avoid producing frames with
equal content).
Maybe something like this? (please note, I'm not a good text writer. If
this needs adjustment please help me shape the text up)
diff --git a/drivers/media/platform/vivi.c
b/drivers/media/platform/vivi.c
index 5d1b374..45b8a81 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -36,6 +36,18 @@
#define VIVI_MODULE_NAME vivi
+/* Maximum allowed frame rate
+ *
+ * Vivi will allow setting timeperframe in [1/FPS_MAX - FPS_MAX/1]
range.
+ *
+ * Ideally FPS_MAX should be infinity, i.e. practically UINT_MAX, but
that
+ * might hit application errors when they manipulate these values.
+ *
+ * Besides, for tpf 1ms image-generation logic should be changed, to
avoid
+ * producing frames with equal content.
+ */
+#define FPS_MAX 1000
+
#define MAX_WIDTH 1920
#define MAX_HEIGHT 1200
@@ -67,8 +79,8 @@ static const u8 *font8x16;
/* timeperframe: min/max and default */
static const struct v4l2_fract
-tpf_min = {.numerator = 1,.denominator = UINT_MAX},
/* 1/infty */
-tpf_max = {.numerator = UINT_MAX,.denominator = 1},
/* infty */
+tpf_min = {.numerator = 1,.denominator = FPS_MAX},
/* ~1/infty */
+tpf_max = {.numerator = FPS_MAX,.denominator = 1},
/* ~infty */
Was too fast answering it... The comments there should also be dropped,
as it doesn't
range anymore to infty.
Ok, agree, let's drop those ~infty comments and be done with it.
8
From: Kirill Smelkov k...@mns.spb.ru
Date: Tue, 23 Oct 2012 16:56:59 +0400
Subject: [PATCH v6] [media] vivi: Teach it to tune FPS
I was testing my video-over-ethernet subsystem recently, and vivi
seemed to be perfect video source for testing when one don't have lots
of capture boards and cameras. Only its framerate was hardcoded to
NTSC's 30fps, while in my country we usually use PAL (25 fps) and I
needed that to precisely simulate bandwidth.
That's why here is this patch with -enum_frameintervals() and
-{g,s}_parm() implemented as suggested by Hans Verkuil which passes
v4l2-compliance and manual testing through v4l2-ctl -P / -p fps.
Regarding newly introduced __get_format(u32 pixelformat) I decided not
to convert original get_format() to operate on fourcc codes, since = 3
places in driver need to deal with v4l2_format and otherwise it won't be
handy.
Thanks.
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
drivers/media/platform/vivi.c | 102
++
1 file changed, 94 insertions(+), 8 deletions(-)
V6:
- Moved TPF/FPS limit to beginning of vivi.c and added comment there
why that limit is used, to avoid overlows, as suggested by Mauro
Carvalho Chehab.
V5:
- changed 1/infty - infty/1 limits to 1/1000 - 1000/1, to avoid
Re: stv090x: possible bug with 8psk,fec=5/6
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
[PATCH v4 0/3] Davinci VPSS helper functions for VPFE
From: Lad, Prabhakar prabhakar@ti.com This patch series adds helper functions and enables the VPSS and ISP registers required for VPFE to work. Changes for v4: 1: Fixed review comment from Sakari. Manjunath Hadli (3): 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 drivers/media/platform/davinci/vpss.c | 70 - include/media/davinci/vpss.h | 16 +++ 2 files changed, 85 insertions(+), 1 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 v4 1/3] davinci: vpss: dm365: enable ISP registers
From: Manjunath Hadli manjunath.ha...@ti.com enable the clocks required for VPFE to work in PCCR register, and enbale ISIF out on BCR to get the correct operation from ISIF. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com --- drivers/media/platform/davinci/vpss.c | 23 ++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/drivers/media/platform/davinci/vpss.c b/drivers/media/platform/davinci/vpss.c index 146e4b0..1c96ce8 100644 --- a/drivers/media/platform/davinci/vpss.c +++ b/drivers/media/platform/davinci/vpss.c @@ -51,7 +51,18 @@ MODULE_AUTHOR(Texas Instruments); /* VENCINT - vpss_int8 */ #define DM355_VPSSBL_EVTSEL_DEFAULT0x4 -#define DM365_ISP5_PCCR0x04 +#define DM365_ISP5_PCCR0x04 +#define DM365_ISP5_PCCR_BL_CLK_ENABLE BIT(0) +#define DM365_ISP5_PCCR_ISIF_CLK_ENABLEBIT(1) +#define DM365_ISP5_PCCR_H3A_CLK_ENABLE BIT(2) +#define DM365_ISP5_PCCR_RSZ_CLK_ENABLE BIT(3) +#define DM365_ISP5_PCCR_IPIPE_CLK_ENABLE BIT(4) +#define DM365_ISP5_PCCR_IPIPEIF_CLK_ENABLE BIT(5) +#define DM365_ISP5_PCCR_RSVBIT(6) + +#define DM365_ISP5_BCR 0x08 +#define DM365_ISP5_BCR_ISIF_OUT_ENABLE BIT(1) + #define DM365_ISP5_INTSEL1 0x10 #define DM365_ISP5_INTSEL2 0x14 #define DM365_ISP5_INTSEL3 0x18 @@ -426,6 +437,16 @@ static int __devinit vpss_probe(struct platform_device *pdev) oper_cfg.hw_ops.enable_clock = dm365_enable_clock; oper_cfg.hw_ops.select_ccdc_source = dm365_select_ccdc_source; /* Setup vpss interrupts */ + isp5_write((isp5_read(DM365_ISP5_PCCR) | + DM365_ISP5_PCCR_BL_CLK_ENABLE | + DM365_ISP5_PCCR_ISIF_CLK_ENABLE | + DM365_ISP5_PCCR_H3A_CLK_ENABLE | + DM365_ISP5_PCCR_RSZ_CLK_ENABLE | + DM365_ISP5_PCCR_IPIPE_CLK_ENABLE | + DM365_ISP5_PCCR_IPIPEIF_CLK_ENABLE | + DM365_ISP5_PCCR_RSV), DM365_ISP5_PCCR); + isp5_write((isp5_read(DM365_ISP5_BCR) | + DM365_ISP5_BCR_ISIF_OUT_ENABLE), DM365_ISP5_BCR); isp5_write(DM365_ISP5_INTSEL1_DEFAULT, DM365_ISP5_INTSEL1); isp5_write(DM365_ISP5_INTSEL2_DEFAULT, DM365_ISP5_INTSEL2); isp5_write(DM365_ISP5_INTSEL3_DEFAULT, DM365_ISP5_INTSEL3); -- 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 v4 2/3] davinci: vpss: dm365: set vpss clk ctrl
From: Manjunath Hadli manjunath.ha...@ti.com
request_mem_region for VPSS_CLK_CTRL register and ioremap.
and enable clocks appropriately.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/platform/davinci/vpss.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpss.c
b/drivers/media/platform/davinci/vpss.c
index 1c96ce8..e4ad63d 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -69,6 +69,11 @@ MODULE_AUTHOR(Texas Instruments);
#define DM365_ISP5_CCDCMUX 0x20
#define DM365_ISP5_PG_FRAME_SIZE 0x28
#define DM365_VPBE_CLK_CTRL0x00
+
+#define VPSS_CLK_CTRL 0x01c40044
+#define VPSS_CLK_CTRL_VENCCLKENBIT(3)
+#define VPSS_CLK_CTRL_DACCLKEN BIT(4)
+
/*
* vpss interrupts. VDINT0 - vpss_int0, VDINT1 - vpss_int1,
* AF - vpss_int3
@@ -112,6 +117,7 @@ struct vpss_hw_ops {
struct vpss_oper_config {
__iomem void *vpss_regs_base0;
__iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
enum vpss_platform_type platform;
spinlock_t vpss_lock;
struct vpss_hw_ops hw_ops;
@@ -492,11 +498,20 @@ static struct platform_driver vpss_driver = {
static void vpss_exit(void)
{
+ iounmap(oper_cfg.vpss_regs_base2);
+ release_mem_region(VPSS_CLK_CTRL, 4);
platform_driver_unregister(vpss_driver);
}
static int __init vpss_init(void)
{
+ if (!request_mem_region(VPSS_CLK_CTRL, 4, vpss_clock_control))
+ return -EBUSY;
+
+ oper_cfg.vpss_regs_base2 = ioremap(VPSS_CLK_CTRL, 4);
+ writel(VPSS_CLK_CTRL_VENCCLKEN |
+VPSS_CLK_CTRL_DACCLKEN, oper_cfg.vpss_regs_base2);
+
return platform_driver_register(vpss_driver);
}
subsys_initcall(vpss_init);
--
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 v4 3/3] davinci: vpss: dm365: add vpss helper functions to be used in the main driver for setting hardware parameters
From: Manjunath Hadli manjunath.ha...@ti.com
add interface functions to set sync polarity, interrupt
completion and pageframe size in vpss to be used by the main driver.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/platform/davinci/vpss.c | 32
include/media/davinci/vpss.h | 16
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpss.c
b/drivers/media/platform/davinci/vpss.c
index e4ad63d..d945f94 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -111,6 +111,12 @@ struct vpss_hw_ops {
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
/* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /* set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /* set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
+ /* check and clear interrupt if occured */
+ int (*dma_complete_interrupt)(void);
};
/* vpss configuration */
@@ -175,6 +181,14 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+int vpss_dma_complete_interrupt(void)
+{
+ if (!oper_cfg.hw_ops.dma_complete_interrupt)
+ return 2;
+ return oper_cfg.hw_ops.dma_complete_interrupt();
+}
+EXPORT_SYMBOL(vpss_dma_complete_interrupt);
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
@@ -200,6 +214,15 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
return 0;
}
+void vpss_set_sync_pol(struct vpss_sync_pol sync)
+{
+ if (!oper_cfg.hw_ops.set_sync_pol)
+ return;
+
+ oper_cfg.hw_ops.set_sync_pol(sync);
+}
+EXPORT_SYMBOL(vpss_set_sync_pol);
+
int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
{
if (!oper_cfg.hw_ops.clear_wbl_overflow)
@@ -365,6 +388,15 @@ void dm365_vpss_set_sync_pol(struct vpss_sync_pol sync)
}
EXPORT_SYMBOL(dm365_vpss_set_sync_pol);
+void vpss_set_pg_frame_size(struct vpss_pg_frame_size frame_size)
+{
+ if (!oper_cfg.hw_ops.set_pg_frame_size)
+ return;
+
+ oper_cfg.hw_ops.set_pg_frame_size(frame_size);
+}
+EXPORT_SYMBOL(vpss_set_pg_frame_size);
+
void dm365_vpss_set_pg_frame_size(struct vpss_pg_frame_size frame_size)
{
int current_reg = ((frame_size.hlpfr 1) - 1) 16;
diff --git a/include/media/davinci/vpss.h b/include/media/davinci/vpss.h
index b586495..153473d 100644
--- a/include/media/davinci/vpss.h
+++ b/include/media/davinci/vpss.h
@@ -105,4 +105,20 @@ enum vpss_wbl_sel {
};
/* clear wbl overflow flag for DM6446 */
int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel);
+
+/* set sync polarity*/
+void vpss_set_sync_pol(struct vpss_sync_pol sync);
+/* set the PG_FRAME_SIZE register */
+void vpss_set_pg_frame_size(struct vpss_pg_frame_size frame_size);
+/*
+ * vpss_check_and_clear_interrupt - check and clear interrupt
+ * @irq - common enumerator for IRQ
+ *
+ * Following return values used:-
+ * 0 - interrupt occurred and cleared
+ * 1 - interrupt not occurred
+ * 2 - interrupt status not available
+ */
+int vpss_dma_complete_interrupt(void);
+
#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
[PATCH v4 0/9] Media Controller capture driver for DM365
From: Lad, Prabhakar prabhakar@ti.com The below series of patches have gone through good amount of reviews, and agreed by Laurent, Hans and Sakari to be part of the staging tree. 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 v4: 1: Added a entry in TODO, to have a compatibility layer while replacing the older driver. 2: Included the ACK's in commit message. Changes for v3: 1: Rebased on staging. 2: Seprated out patches which would go into staging. 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 (9): 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: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation and TODO drivers/staging/media/Kconfig |2 + drivers/staging/media/Makefile |1 + drivers/staging/media/davinci_vpfe/Kconfig |9 + drivers/staging/media/davinci_vpfe/Makefile|3 + drivers/staging/media/davinci_vpfe/TODO| 37 + .../staging/media/davinci_vpfe/davinci-vpfe-mc.txt | 154 ++ .../staging/media/davinci_vpfe/davinci_vpfe_user.h | 1290 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 1863 + drivers/staging/media/davinci_vpfe/dm365_ipipe.h | 179 ++ .../staging/media/davinci_vpfe/dm365_ipipe_hw.c| 1048 ++ .../staging/media/davinci_vpfe/dm365_ipipe_hw.h| 559 ++ drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1071 ++ drivers/staging/media/davinci_vpfe/dm365_ipipeif.h | 233 +++ .../media/davinci_vpfe/dm365_ipipeif_user.h| 93 + drivers/staging/media/davinci_vpfe/dm365_isif.c| 2104 drivers/staging/media/davinci_vpfe/dm365_isif.h| 203 ++ .../staging/media/davinci_vpfe/dm365_isif_regs.h | 294 +++ drivers/staging/media/davinci_vpfe/dm365_resizer.c | 1999 +++ drivers/staging/media/davinci_vpfe/dm365_resizer.h | 244 +++ drivers/staging/media/davinci_vpfe/vpfe.h | 86 + .../staging/media/davinci_vpfe/vpfe_mc_capture.c | 740 +++ .../staging/media/davinci_vpfe/vpfe_mc_capture.h | 97 + drivers/staging/media/davinci_vpfe/vpfe_video.c| 1620 +++ drivers/staging/media/davinci_vpfe/vpfe_video.h| 155 ++ 24 files changed, 14084 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/davinci_vpfe/Kconfig create mode 100644 drivers/staging/media/davinci_vpfe/Makefile create mode 100644 drivers/staging/media/davinci_vpfe/TODO create mode 100644 drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt create mode 100644 drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif_user.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif_regs.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.h create mode 100644 drivers/staging/media/davinci_vpfe/vpfe.h create mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c create mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.h create mode 100644
Re: [RFC v2 3/5] video: display: Add MIPI DBI bus support
Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/video/display/Kconfig|4 + drivers/video/display/Makefile |1 + drivers/video/display/mipi-dbi-bus.c | 228 ++ include/video/display.h |5 + include/video/mipi-dbi-bus.h | 125 +++ 5 files changed, 363 insertions(+), 0 deletions(-) create mode 100644 drivers/video/display/mipi-dbi-bus.c create mode 100644 include/video/mipi-dbi-bus.h I've been doing some omapdss testing with CDF and DSI, and I have some thoughts about the bus stuff. I already told these to Laurent, but I'll write them to the mailing list also for discussion. So with the current CDF model we have separate control and video buses. The control bus is represented as proper Linux bus, and video bus is represented via custom display_entity. This sounds good on paper, and I also agreed to this approach when we were planning CDF. However, now I doubt that approach. First, I want to list some examples of devices with different bus configurations: 1) Panel without any control, only video bus 2) Panel with separate control and video buses, e.g. i2c for control, DPI for video 3) Panel with the same control and video buses, like DSI or DBI. The first one is simple, it's just a platform device. No questions there. The second one can be a bit tricky. Say, if we have a panel controlled via i2c, and DSI/DBI used for video. The problem here is that with the current model, DSI/DBI would be represented as a real bus, for control. But in this case there's only the video path. So if all the DSI/DBI bus configuration is handled on the DSI/DBI control bus side, how can it be handled with only the video bus? And if we add the same bus configuration to the video bus side as we have on control bus side, then we have duplicated the API, and it's also somewhat confusing. I don't have any good suggestion for this. Third one is kinda clear, but I feel slightly uneasy about it. In theory we can have separate control and video buses, which use the same HW transport. However, I feel that we'll have some trouble with the implementation, as we'll then have two more or less independent users for the HW transport. I can't really point out why this would not be possible to implement, but I have a gut feeling that it will be difficult, at least for DSI. So I think my question is: what does it give us to have separate control and video buses, and what does the Linux bus give us with the control bus? I don't see us ever having a case where a device would use one of the display buses only for control. So either the display bus is only used for video, or it's used for both control and video. And the display bus is always 1-to-1, so we're talking about really simple bus here. I believe things would be much simpler if we just have one entity for the display buses, which support both video and (when available) control. What would be the downsides of this approach versus the current CDF proposal? Tomi signature.asc Description: OpenPGP digital signature
[PATCH v4 2/9] davinci: vpfe: add v4l2 video driver support
From: Manjunath Hadli manjunath.ha...@ti.com
Add a generic video driver functionality to be used by all the vpfe
drivers for davinci SoCs. The functionality includes all the
standard v4l2 interfaces including streaming. The video node
interface can be used both as an input and output node for both
continuous and single shot modes. Also supports dv_presets to include
HD modes, wth support for both user pointer IO and mmap. The buffering
mechanism is based on videobuf2 interface.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/staging/media/davinci_vpfe/vpfe_video.c | 1620 +++
drivers/staging/media/davinci_vpfe/vpfe_video.h | 155 +++
2 files changed, 1775 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.c
create mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.h
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
new file mode 100644
index 000..99ccbeb
--- /dev/null
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -0,0 +1,1620 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Inc
+ *
+ * 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 version 2.
+ *
+ * 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
+ *
+ * Contributors:
+ * Manjunath Hadli manjunath.ha...@ti.com
+ * Prabhakar Lad prabhakar@ti.com
+ */
+
+#include linux/module.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include vpfe.h
+#include vpfe_mc_capture.h
+
+/* minimum number of buffers needed in cont-mode */
+#define MIN_NUM_BUFFERS3
+
+static int debug;
+
+/* get v4l2 subdev pointer to external subdev which is active */
+static struct media_entity *vpfe_get_input_entity
+ (struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video-vpfe_dev;
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(vpfe_dev-vpfe_isif.pads[0]);
+ if (remote == NULL) {
+ pr_err(Invalid media connection to isif/ccdc\n);
+ return NULL;
+ }
+ return remote-entity;
+}
+
+/* updates external subdev(sensor/decoder) which is active */
+static int vpfe_update_current_ext_subdev(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video-vpfe_dev;
+ struct vpfe_config *vpfe_cfg;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ int i;
+
+ remote = media_entity_remote_source(vpfe_dev-vpfe_isif.pads[0]);
+ if (remote == NULL) {
+ pr_err(Invalid media connection to isif/ccdc\n);
+ return -EINVAL;
+ }
+
+ subdev = media_entity_to_v4l2_subdev(remote-entity);
+ vpfe_cfg = vpfe_dev-pdev-platform_data;
+ for (i = 0; i vpfe_cfg-num_subdevs; i++) {
+ if (!strcmp(vpfe_cfg-sub_devs[i].module_name, subdev-name)) {
+ video-current_ext_subdev = vpfe_cfg-sub_devs[i];
+ break;
+ }
+ }
+
+ /* if user not linked decoder/sensor to isif/ccdc */
+ if (i == vpfe_cfg-num_subdevs) {
+ pr_err(Invalid media chain connection to isif/ccdc\n);
+ return -EINVAL;
+ }
+ /* find the v4l2 subdev pointer */
+ for (i = 0; i vpfe_dev-num_ext_subdevs; i++) {
+ if (!strcmp(video-current_ext_subdev-module_name,
+ vpfe_dev-sd[i]-name))
+ video-current_ext_subdev-subdev = vpfe_dev-sd[i];
+ }
+ return 0;
+}
+
+/* get the subdev which is connected to the output video node */
+static struct v4l2_subdev *
+vpfe_video_remote_subdev(struct vpfe_video_device *video, u32 *pad)
+{
+ struct media_pad *remote = media_entity_remote_source(video-pad);
+
+ if (remote == NULL || remote-entity-type != MEDIA_ENT_T_V4L2_SUBDEV)
+ return NULL;
+ if (pad)
+ *pad = remote-index;
+ return media_entity_to_v4l2_subdev(remote-entity);
+}
+
+/* get the format set at output pad of the adjacent subdev */
+static int
+__vpfe_video_get_format(struct vpfe_video_device *video,
+ struct v4l2_format
[PATCH v4 3/9] davinci: vpfe: dm365: add IPIPEIF driver based on media framework
From: Manjunath Hadli manjunath.ha...@ti.com
add support for dm365 IPIPEIF driver based on media framework.
The IPIPEIF is exposed as a subdev, and it supports features
like fault pixel correction, dark frame subtraction and other
necessary hardware setup.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1071
drivers/staging/media/davinci_vpfe/dm365_ipipeif.h | 233 +
.../media/davinci_vpfe/dm365_ipipeif_user.h| 93 ++
3 files changed, 1397 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.h
create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif_user.h
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
new file mode 100644
index 000..c8cae51
--- /dev/null
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
@@ -0,0 +1,1071 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Inc
+ *
+ * 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 version 2.
+ *
+ * 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
+ *
+ * Contributors:
+ * Manjunath Hadli manjunath.ha...@ti.com
+ * Prabhakar Lad prabhakar@ti.com
+ */
+
+#include dm365_ipipeif.h
+#include vpfe_mc_capture.h
+
+static const unsigned int ipipeif_input_fmts[] = {
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_SGRBG12_1X12,
+ V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_UV8_1X8,
+ V4L2_MBUS_FMT_YDYUYDYV8_1X16,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+};
+
+static const unsigned int ipipeif_output_fmts[] = {
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_SGRBG12_1X12,
+ V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_UV8_1X8,
+ V4L2_MBUS_FMT_YDYUYDYV8_1X16,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
+ V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
+};
+
+static int
+ipipeif_get_pack_mode(enum v4l2_mbus_pixelcode in_pix_fmt)
+{
+ switch (in_pix_fmt) {
+ case V4L2_MBUS_FMT_SBGGR8_1X8:
+ case V4L2_MBUS_FMT_Y8_1X8:
+ case V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8:
+ case V4L2_MBUS_FMT_UV8_1X8:
+ return IPIPEIF_5_1_PACK_8_BIT;
+
+ case V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8:
+ return IPIPEIF_5_1_PACK_8_BIT_A_LAW;
+
+ case V4L2_MBUS_FMT_SGRBG12_1X12:
+ return IPIPEIF_5_1_PACK_16_BIT;
+
+ case V4L2_MBUS_FMT_SBGGR12_1X12:
+ return IPIPEIF_5_1_PACK_12_BIT;
+
+ default:
+ return IPIPEIF_5_1_PACK_16_BIT;
+ }
+}
+
+static inline u32 ipipeif_read(void *addr, u32 offset)
+{
+ return readl(addr + offset);
+}
+
+static inline void ipipeif_write(u32 val, void *addr, u32 offset)
+{
+ writel(val, addr + offset);
+}
+
+static void ipipeif_config_dpc(void *addr, struct ipipeif_dpc *dpc)
+{
+ u32 val = 0;
+
+ if (dpc-en) {
+ val = (dpc-en 1) IPIPEIF_DPC2_EN_SHIFT;
+ val |= dpc-thr IPIPEIF_DPC2_THR_MASK;
+ }
+ ipipeif_write(val, addr, IPIPEIF_DPC2);
+}
+
+#define IPIPEIF_MODE_CONTINUOUS0
+#define IPIPEIF_MODE_ONE_SHOT 1
+
+static int get_oneshot_mode(enum ipipeif_input_entity input)
+{
+ if (input == IPIPEIF_INPUT_MEMORY)
+ return IPIPEIF_MODE_ONE_SHOT;
+ else if (input == IPIPEIF_INPUT_ISIF)
+ return IPIPEIF_MODE_CONTINUOUS;
+
+ return -EINVAL;
+}
+
+static int
+ipipeif_get_cfg_src1(struct vpfe_ipipeif_device *ipipeif)
+{
+ struct v4l2_mbus_framefmt *informat;
+
+ informat = ipipeif-formats[IPIPEIF_PAD_SINK];
+ if (ipipeif-input == IPIPEIF_INPUT_MEMORY
+ (informat-code == V4L2_MBUS_FMT_Y8_1X8 ||
+ informat-code == V4L2_MBUS_FMT_UV8_1X8))
+ return IPIPEIF_CCDC;
+
+ return IPIPEIF_SRC1_PARALLEL_PORT;
+}
+
+static int
+ipipeif_get_data_shift(struct vpfe_ipipeif_device *ipipeif)
+{
+ struct v4l2_mbus_framefmt *informat;
+
+ informat = ipipeif-formats[IPIPEIF_PAD_SINK];
+
+ switch (informat-code) {
+ case V4L2_MBUS_FMT_SGRBG12_1X12:
+
[PATCH v4 6/9] davinci: vpfe: dm365: add IPIPE hardware layer support
From: Manjunath Hadli manjunath.ha...@ti.com
IPIPE is the hardware IP which implements the functionality
required for resizer, ipipe(colorspace converter) and
the associated hardware support. This patch implements hardware
setup including coefficient programming for various hardware
filters, gamma, cfa and clock enabling.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
.../staging/media/davinci_vpfe/dm365_ipipe_hw.c| 1048
.../staging/media/davinci_vpfe/dm365_ipipe_hw.h| 559 +++
2 files changed, 1607 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
new file mode 100644
index 000..e027b92
--- /dev/null
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -0,0 +1,1048 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Inc
+ *
+ * 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 version 2.
+ *
+ * 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
+ *
+ * Contributors:
+ * Manjunath Hadli manjunath.ha...@ti.com
+ * Prabhakar Lad prabhakar@ti.com
+ */
+
+#include dm365_ipipe_hw.h
+
+#define IPIPE_MODE_CONTINUOUS 0
+#define IPIPE_MODE_SINGLE_SHOT 1
+
+static void ipipe_clock_enable(void *__iomem base_addr)
+{
+ /* enable IPIPE MMR for register write access */
+ regw_ip(base_addr, IPIPE_GCK_MMR_DEFAULT, IPIPE_GCK_MMR);
+
+ /* enable the clock wb,cfa,dfc,d2f,pre modules */
+ regw_ip(base_addr, IPIPE_GCK_PIX_DEFAULT, IPIPE_GCK_PIX);
+}
+
+static void
+rsz_set_common_params(void *__iomem rsz_base, struct resizer_params *params)
+{
+ struct rsz_common_params *rsz_common = params-rsz_common;
+ u32 val;
+
+ /* Set mode */
+ regw_rsz(rsz_base, params-oper_mode, RSZ_SRC_MODE);
+
+ /* data source selection and bypass */
+ val = (rsz_common-passthrough RSZ_BYPASS_SHIFT) |
+ rsz_common-source;
+ regw_rsz(rsz_base, val, RSZ_SRC_FMT0);
+
+ /* src image selection */
+ val = (rsz_common-raw_flip 1) |
+ (rsz_common-src_img_fmt RSZ_SRC_IMG_FMT_SHIFT) |
+ ((rsz_common-y_c 1) RSZ_SRC_Y_C_SEL_SHIFT);
+ regw_rsz(rsz_base, val, RSZ_SRC_FMT1);
+
+ regw_rsz(rsz_base, rsz_common-vps IPIPE_RSZ_VPS_MASK, RSZ_SRC_VPS);
+ regw_rsz(rsz_base, rsz_common-hps IPIPE_RSZ_HPS_MASK, RSZ_SRC_HPS);
+ regw_rsz(rsz_base, rsz_common-vsz IPIPE_RSZ_VSZ_MASK, RSZ_SRC_VSZ);
+ regw_rsz(rsz_base, rsz_common-hsz IPIPE_RSZ_HSZ_MASK, RSZ_SRC_HSZ);
+ regw_rsz(rsz_base, rsz_common-yuv_y_min, RSZ_YUV_Y_MIN);
+ regw_rsz(rsz_base, rsz_common-yuv_y_max, RSZ_YUV_Y_MAX);
+ regw_rsz(rsz_base, rsz_common-yuv_c_min, RSZ_YUV_C_MIN);
+ regw_rsz(rsz_base, rsz_common-yuv_c_max, RSZ_YUV_C_MAX);
+ /* chromatic position */
+ regw_rsz(rsz_base, rsz_common-out_chr_pos, RSZ_YUV_PHS);
+}
+
+static void
+rsz_set_rsz_regs(void *__iomem rsz_base, unsigned int rsz_id,
+struct resizer_params *params)
+{
+ struct resizer_scale_param *rsc_params;
+ struct rsz_ext_mem_param *ext_mem;
+ struct resizer_rgb *rgb;
+ u32 reg_base;
+ u32 val;
+
+ rsc_params = params-rsz_rsc_param[rsz_id];
+ rgb = params-rsz2rgb[rsz_id];
+ ext_mem = params-ext_mem_param[rsz_id];
+
+ if (rsz_id == RSZ_A) {
+ val = rsc_params-h_flip RSZA_H_FLIP_SHIFT;
+ val |= rsc_params-v_flip RSZA_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_A;
+ } else {
+ val = rsc_params-h_flip RSZB_H_FLIP_SHIFT;
+ val |= rsc_params-v_flip RSZB_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_B;
+ }
+ /* update flip settings */
+ regw_rsz(rsz_base, val, RSZ_SEQ);
+
+ regw_rsz(rsz_base, params-oper_mode, reg_base + RSZ_MODE);
+
+ val = (rsc_params-cen RSZ_CEN_SHIFT) | rsc_params-yen;
+ regw_rsz(rsz_base, val, reg_base + RSZ_420);
+
+ regw_rsz(rsz_base, rsc_params-i_vps RSZ_VPS_MASK,
+reg_base + RSZ_I_VPS);
+
[PATCH v4 8/9] davinci: vpfe: dm365: add build infrastructure for capture driver
From: Manjunath Hadli manjunath.ha...@ti.com add build infrastructure for dm365 specific modules for VPFE capture driver. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/staging/media/Kconfig |2 ++ drivers/staging/media/Makefile |1 + drivers/staging/media/davinci_vpfe/Kconfig |9 + drivers/staging/media/davinci_vpfe/Makefile |3 +++ 4 files changed, 15 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/davinci_vpfe/Kconfig create mode 100644 drivers/staging/media/davinci_vpfe/Makefile diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index 427218b..ae0abc3 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -23,6 +23,8 @@ source drivers/staging/media/as102/Kconfig source drivers/staging/media/cxd2099/Kconfig +source drivers/staging/media/davinci_vpfe/Kconfig + source drivers/staging/media/dt3155v4l/Kconfig source drivers/staging/media/go7007/Kconfig diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index aec6eb9..2b97cae 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -4,3 +4,4 @@ obj-$(CONFIG_LIRC_STAGING) += lirc/ obj-$(CONFIG_SOLO6X10) += solo6x10/ obj-$(CONFIG_VIDEO_DT3155) += dt3155v4l/ obj-$(CONFIG_VIDEO_GO7007) += go7007/ +obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/ diff --git a/drivers/staging/media/davinci_vpfe/Kconfig b/drivers/staging/media/davinci_vpfe/Kconfig new file mode 100644 index 000..2e4a28b --- /dev/null +++ b/drivers/staging/media/davinci_vpfe/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_DM365_VPFE + tristate DM365 VPFE Media Controller Capture Driver + depends on VIDEO_V4L2 ARCH_DAVINCI_DM365 !VIDEO_VPFE_CAPTURE + select VIDEOBUF2_DMA_CONTIG + help + Support for DM365 VPFE based Media Controller Capture driver. + + To compile this driver as a module, choose M here: the + module will be called vpfe-mc-capture. diff --git a/drivers/staging/media/davinci_vpfe/Makefile b/drivers/staging/media/davinci_vpfe/Makefile new file mode 100644 index 000..c64515c --- /dev/null +++ b/drivers/staging/media/davinci_vpfe/Makefile @@ -0,0 +1,3 @@ +obj-$(CONFIG_VIDEO_DM365_VPFE) += \ + dm365_isif.o dm365_ipipe_hw.o dm365_ipipe.o \ + dm365_resizer.o dm365_ipipeif.o vpfe_mc_capture.o vpfe_video.o -- 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 v4 9/9] davinci: vpfe: Add documentation and TODO
From: Manjunath Hadli manjunath.ha...@ti.com Add documentation on the Davinci VPFE driver. Document the subdevs, and private IOTCLs the driver implements. This patch also includes the TODO's to fit into drivers/media/ folder. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/staging/media/davinci_vpfe/TODO| 37 + .../staging/media/davinci_vpfe/davinci-vpfe-mc.txt | 154 2 files changed, 191 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/davinci_vpfe/TODO create mode 100644 drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt diff --git a/drivers/staging/media/davinci_vpfe/TODO b/drivers/staging/media/davinci_vpfe/TODO new file mode 100644 index 000..7015ab3 --- /dev/null +++ b/drivers/staging/media/davinci_vpfe/TODO @@ -0,0 +1,37 @@ +TODO (general): +== + +- 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) +- While replacing the older driver in media folder, provide a compatibility + layer and compatibility tests that warrants (using the libv4l's LD_PRELOAD + approach) there is no regression for the users using the older driver. + +Building of uImage and Applications: +== + +As of now since the interface will undergo few changes all the include +files are present in staging itself, to build for dm365 follow below steps, + +- copy vpfe.h from drivers/staging/media/davinci_vpfe/ to + include/media/davinci/ folder for building the uImage. +- copy davinci_vpfe_user.h from drivers/staging/media/davinci_vpfe/ to + include/uapi/linux/davinci_vpfe.h, and add a entry in Kbuild (required + for building application). +- copy dm365_ipipeif_user.h from drivers/staging/media/davinci_vpfe/ to + include/uapi/linux/dm365_ipipeif.h and a entry in Kbuild (required + for building application). diff --git a/drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt b/drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt new file mode 100644 index 000..1dbd564 --- /dev/null +++ b/drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt @@ -0,0 +1,154 @@ +Davinci Video processing Front End (VPFE) driver + +Copyright (C) 2012 Texas Instruments Inc + +Contacts: Manjunath Hadli manjunath.ha...@ti.com + Prabhakar Lad prabhakar@ti.com + + +Introduction + + +This file documents the Texas Instruments Davinci Video processing Front End +(VPFE) driver located under drivers/media/platform/davinci. The original driver +exists for Davinci VPFE, which is now being changed to Media Controller +Framework. + +Currently the driver has been successfully used on the following +version of Davinci: + + DM365/DM368 + +The driver implements V4L2, Media controller and v4l2_subdev interfaces. Sensor, +lens and flash drivers using the v4l2_subdev interface in the kernel are +supported. + + +Split to subdevs + + +The Davinci VPFE is split into V4L2 subdevs, each of the blocks inside the VPFE +having one subdev to represent it. Each of the subdevs provide a V4L2 subdev +interface to userspace. + + DAVINCI ISIF + DAVINCI IPIPEIF + DAVINCI IPIPE + DAVINCI CROP RESIZER + DAVINCI RESIZER A + DAVINCI RESIZER B + +Each possible link in the VPFE is modeled by a link in the Media controller +interface. For an example program see [1]. + + +ISIF, IPIPE, and RESIZER block IOCTLs +== + +The Davinci Video processing Front End (VPFE) driver supports standard V4L2 +IOCTLs and controls where possible and practical. Much of the functions provided +by the VPFE, however, does not fall under the standard IOCTL's. + +In general, there is a private ioctl for configuring each of the blocks +containing hardware-dependent functions. + +The following private IOCTLs are supported: + + VIDIOC_VPFE_ISIF_[S/G]_RAW_PARAMS + VIDIOC_VPFE_IPIPE_[S/G]_CONFIG + VIDIOC_VPFE_RSZ_[S/G]_CONFIG + +The parameter structures used by these ioctl's are described in
Re: [PATCH v6] [media] vivi: Teach it to tune FPS
On Fri, Nov 30, 2012 at 12:10:59PM +0100, Hans Verkuil wrote: On Fri November 30 2012 12:02:14 Kirill Smelkov wrote: [...] P.S. Hans, if this is ok for you, would you please add your ack? Looks good to me! Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l: Add mt9v034 sensor driver
Hi Enric, May i ask about mt9v034_probe() and mt9v034_remove()? On Fri, Oct 5, 2012 at 2:34 PM, Enric Balletbo i Serra eballe...@gmail.com wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com The MT9V034 is a parallel wide VGA sensor from Aptina (formerly Micron) controlled through I2C. The driver creates a V4L2 subdevice. It currently supports binning and cropping, and the gain, auto gain, exposure, auto exposure and test pattern controls. The following patch is based on the MT9V032 driver from Laurent Pinchart and was tested on IGEP tech based boards with custom expansion board with MT9V034 sensor. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- drivers/media/i2c/Kconfig | 10 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v034.c | 834 +++ include/media/mt9v034.h | 15 + 4 files changed, 860 insertions(+), 0 deletions(-) create mode 100644 drivers/media/i2c/mt9v034.c create mode 100644 include/media/mt9v034.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 0e0793a..c35efda 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -475,6 +475,16 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V034 + tristate Micron MT9V034 sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the Micron + MT9V034 752x480 CMOS sensor. The MT9V034 is a 1/3-inch + wide-VGA format CMOS active-pixel digital image sensor with + TrueSNAP gobal shutter and high dynamic range (HDR) operation. + config VIDEO_TCM825X tristate TCM825x camera sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 4a270f7..9d4c417 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V034) += mt9v034.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o diff --git a/drivers/media/i2c/mt9v034.c b/drivers/media/i2c/mt9v034.c new file mode 100644 index 000..7bbfeb6 --- /dev/null +++ b/drivers/media/i2c/mt9v034.c @@ -0,0 +1,834 @@ +/* + * Driver for MT9V034 CMOS Image Sensor from Micron + * + * Copyright (C) 2012, Enric Balletbo eballe...@iseebcn.com + * + * Based on the MT9V032 driver, + * + * Copyright (C) 2010, Laurent Pinchart laurent.pinch...@ideasonboard.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/i2c.h +#include linux/log2.h +#include linux/mutex.h +#include linux/slab.h +#include linux/videodev2.h +#include linux/v4l2-mediabus.h +#include linux/module.h + +#include media/mt9v034.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9V034_PIXEL_ARRAY_HEIGHT 499 +#define MT9V034_PIXEL_ARRAY_WIDTH 809 + +#define MT9V034_SYSCLK_FREQ_DEF2660 + +#define MT9V034_CHIP_VERSION 0x00 +#defineMT9V034_CHIP_ID_REV10x1324 +#define MT9V034_COLUMN_START 0x01 +#defineMT9V034_COLUMN_START_MIN1 +#defineMT9V034_COLUMN_START_DEF1 +#defineMT9V034_COLUMN_START_MAX752 +#define MT9V034_ROW_START 0x02 +#defineMT9V034_ROW_START_MIN 4 +#defineMT9V034_ROW_START_DEF 4 +#defineMT9V034_ROW_START_MAX 482 +#define MT9V034_WINDOW_HEIGHT 0x03 +#defineMT9V034_WINDOW_HEIGHT_MIN 1 +#defineMT9V034_WINDOW_HEIGHT_DEF 480 +#defineMT9V034_WINDOW_HEIGHT_MAX 480 +#define MT9V034_WINDOW_WIDTH 0x04 +#defineMT9V034_WINDOW_WIDTH_MIN1 +#defineMT9V034_WINDOW_WIDTH_DEF752 +#defineMT9V034_WINDOW_WIDTH_MAX752 +#define MT9V034_HORIZONTAL_BLANKING0x05 +#defineMT9V034_HORIZONTAL_BLANKING_MIN 61
[PATCH] [media] mx2_camera: Convert it to platform driver
Converting it to platform code can make the code smaller.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 791cd1d..36b4ee0 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1912,22 +1912,11 @@ static struct platform_driver mx2_camera_driver = {
.name = MX2_CAM_DRV_NAME,
},
.id_table = mx2_camera_devtype,
+ .probe = mx2_camera_probe,
.remove = __devexit_p(mx2_camera_remove),
};
-
-static int __init mx2_camera_init(void)
-{
- return platform_driver_probe(mx2_camera_driver, mx2_camera_probe);
-}
-
-static void __exit mx2_camera_exit(void)
-{
- return platform_driver_unregister(mx2_camera_driver);
-}
-
-module_init(mx2_camera_init);
-module_exit(mx2_camera_exit);
+module_platform_driver(mx2_camera_driver);
MODULE_DESCRIPTION(i.MX27/i.MX25 SoC Camera Host driver);
MODULE_AUTHOR(Sascha Hauer s...@pengutronix.de);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t
On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel ar...@broadcom.com wrote: So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle (chapter 5 Typedefs) is spending a number of lines explaining why. So is spinlock_t an exception to this rule simply because the kernel uses spinlock_t all over the place. Yes. Luis -- 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 0/6] drivers: convert struct spinlock to spinlock_t
On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel ar...@broadcom.com wrote: So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle (chapter 5 Typedefs) is spending a number of lines explaining why. So is spinlock_t an exception to this rule simply because the kernel uses spinlock_t all over the place. Yes. Let me provide a better explanation. In practice drivers should not be creating their own typedefs given that generally the reasons to create them do not exist for drivers. The kernel may provide their own though for reasons explained in CodingStyle and in such cases the drivers should use these supplied typedefs. Luis -- 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: ERRORS
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 30 19:00:20 CET 2012 git hash:d8658bca2e5696df2b6c69bc5538f8fe54e4a01e 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: OK 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: ERRORS linux-3.5-i686: ERRORS 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: ERRORS linux-3.5-x86_64: ERRORS 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: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t
On 11/30/2012 09:25 PM, Luis R. Rodriguez wrote: On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel ar...@broadcom.com wrote: So what is the rationale here. During mainlining our drivers we had to remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle (chapter 5 Typedefs) is spending a number of lines explaining why. So is spinlock_t an exception to this rule simply because the kernel uses spinlock_t all over the place. Yes. Let me provide a better explanation. In practice drivers should not be creating their own typedefs given that generally the reasons to create them do not exist for drivers. The kernel may provide their own though for reasons explained in CodingStyle and in such cases the drivers should use these supplied typedefs. Ok. Fine by me. It just looked like a case of saying a and doing b. Thanks for taking time giving the better explanation :-) Gr. AvS -- 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
