Re: [patch 5/5] saa7121 driver for s6000 data port
This patch adds a driver to support the saa7121 PAL/NTSC video encoder
in combination with the s6000 data port driver.
The chip is configured for embedded BT.656 syncs as this mode should
be supported on all devices.
The driver presents two outputs to applications and while it is true
that the device has these two outputs, both of them are always active.
The only difference on the Y/C output is that it disables the luma
notch filter.
Hi Daniel,
The big problem with this driver and the micron driver is that this
implementation ties it directly to the s6000 data port driver. Thus making
it impossible to reuse in another system.
I've been working on a new framework for devices like this and almost all
i2c v4l drivers are now converted to v4l2_subdev in our v4l-dvb tree. It
will also be merged in 2.6.30. Please take a look at v4l2-framework.txt in
the v4l-dvb repository for more information.
I'm sure you will have questions later, please don't hesitate to ask! It's
a recent development but very much needed. Otherwise we will end up with a
lot of duplicate i2c drivers, each tied to their own platform or
framework. That's clearly something we do not want.
Regards,
Hans
Signed-off-by: Daniel Glöckner d...@emlix.com
---
drivers/media/video/s6dp/Kconfig|7 +
drivers/media/video/s6dp/Makefile |1 +
drivers/media/video/s6dp/s6dp-saa7121.c | 478
+++
3 files changed, 486 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/s6dp/s6dp-saa7121.c
diff --git a/drivers/media/video/s6dp/Kconfig
b/drivers/media/video/s6dp/Kconfig
index 853e6b1..c95904c 100644
--- a/drivers/media/video/s6dp/Kconfig
+++ b/drivers/media/video/s6dp/Kconfig
@@ -20,3 +20,10 @@ config VIDEO_S6DP_MT9D131
default n
help
Enables the MT9D131 camera driver.
+
+config VIDEO_S6DP_SAA7121
+ tristate SAA7121 video encoder
+ depends on VIDEO_S6000
+ default n
+ help
+ Enables the SAA7121 video encoder driver.
diff --git a/drivers/media/video/s6dp/Makefile
b/drivers/media/video/s6dp/Makefile
index af0bc0f..61d86c9 100644
--- a/drivers/media/video/s6dp/Makefile
+++ b/drivers/media/video/s6dp/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_VIDEO_S6000) += s6dp.o
obj-$(CONFIG_VIDEO_S6DP_MT9D131) += s6dp-mt9d131.o
+obj-$(CONFIG_VIDEO_S6DP_SAA7121) += s6dp-saa7121.o
diff --git a/drivers/media/video/s6dp/s6dp-saa7121.c
b/drivers/media/video/s6dp/s6dp-saa7121.c
new file mode 100644
index 000..70799cd
--- /dev/null
+++ b/drivers/media/video/s6dp/s6dp-saa7121.c
@@ -0,0 +1,478 @@
+/*
+ * drivers/media/video/s6dp/s6dp-saa7121.c
+ *
+ * Description: Driver for SAA7121 chips hooked up to a S6000 family data
port
+ * (c) 2009 emlix GmbH i...@emlix.com
+ *
+ * Author: Daniel Gloeckner d...@emlix.com
+ */
+
+#include media/s6dp-link.h
+#include s6dp.h
+#include linux/i2c.h
+
+static const u8 initial_setup[][2] = {
+ {0x3a, 0x13}
+};
+
+static const u8 pal_values[][2] = {
+ {0x28, 33}, {0x29, 29}, {0x5a, 0x00}, {0x5b, 125},
+ {0x5c, 175}, {0x5d, 35}, {0x5e, 53}, {0x5f, 0x40+53},
+ {0x61, 0x06}, {0x62, 47}, {0x63, 0xcb}, {0x64, 0x8a},
+ {0x65, 0x09}, {0x66, 0x2a}, {0x6c, 0x05}, {0x6d, 0x20},
+ {0x6e, 0xa0}
+};
+
+static const u8 pal_nc_values[][2] = {
+ {0x28, 33}, {0x29, 37}, {0x5a, 0x00}, {0x5b, 125},
+ {0x5c, 175}, {0x5d, 35}, {0x5e, 53}, {0x5f, 0xc0+53},
+ {0x61, 0x06}, {0x62, 47}, {0x63, 0x46}, {0x64, 0x94},
+ {0x65, 0xf6}, {0x66, 0x21}, {0x6c, 0x05}, {0x6d, 0x20},
+ {0x6e, 0xa0}
+};
+
+static const u8 pal_m_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x00}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 45}, {0x5e, 49}, {0x5f, 0xc0+59},
+ {0x61, 0x17}, {0x62, 45}, {0x63, 0xe3}, {0x64, 0xef},
+ {0x65, 0xe6}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0xa0}
+};
+
+static const u8 ntsc_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x88}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 42}, {0x5e, 46}, {0x5f, 0xc0+46},
+ {0x61, 0x15}, {0x62, 63}, {0x63, 0x1f}, {0x64, 0x7c},
+ {0x65, 0xf0}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0x80}
+};
+
+static const u8 ntsc_jp_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x88}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 19}, {0x5e, 46}, {0x5f, 0xc0+46},
+ {0x61, 0x05}, {0x62, 62}, {0x63, 0x1f}, {0x64, 0x7c},
+ {0x65, 0xf0}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0x80}
+};
+
+struct saa7121 {
+ int std;
+ int yc;
+ struct v4l2_pix_format fmt;
+ struct v4l2_rect crop;
+ u8 regs[128];
+};
+
+static int saa7121_write_regs(struct i2c_client *client)
+{
+ struct saa7121 *me = i2c_get_clientdata(client);
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(me-regs); i++) {
+ int ret = i2c_smbus_write_byte_data(client, i, me-regs[i]);
+ if
Re: [PATCH] Allow the user to restrict the RC5 address
Hans Verkuil wrote: On Thursday 26 March 2009 03:34:53 Udo A. Steinberg wrote: Mauro, This patch allows users with multiple remotes to specify an RC5 address for a remote from which key codes will be accepted. If no address is specified, the default value of 0 accepts key codes from any remote. This replaces the current hard-coded address checks, which are too restrictive. I think this should be reviewed by Steve Toth first (CC-ed him). One thing that this patch breaks is if you have multiple Hauppauge remotes, some sending 0x1e, some 0x1f. With this patch I can't use both, only one. Hans, thanks for bringing this to my attention. Mauro, This patch is a regression, although a small one. it probably needs a little more work. I too tend to have multiple remotes, I don't think it's that unusual for long standing Hauppauge customers to have many boards with many types of remotes. It might be better to have an option to explicitly allow old Hauppauge remotes that send 0x00. I could live with this. It relegates older remotes but those remotes are no longer made. This feels like a good compromise. - Steve -- 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: Questinons regarding soc_camera / pxa_camera
(moving to the new v4l list) On Thu, 26 Mar 2009, Stefan Herbrechtsmeier wrote: --- a/linux/drivers/media/video/soc_camera.cSun Mar 22 08:53:36 2009 -0300 +++ b/linux/drivers/media/video/soc_camera.cThu Mar 26 15:35:43 2009 +0100 @@ -238,7 +238,7 @@ static int soc_camera_init_user_formats( icd-num_user_formats = fmts; fmts = 0; -dev_dbg(icd-dev, Found %d supported formats.\n, fmts); +dev_dbg(icd-dev, Found %d supported formats.\n, icd-num_user_formats); /* Second pass - actually fill data formats */ for (i = 0; i icd-num_formats; i++) I thing this was wrong or ' fmts = 0;' must be under the output. Right, I'd prefer the latter though - to move the fmts = 0; assignment down. @@ -675,8 +675,8 @@ static int soc_camera_cropcap(struct fil a-bounds.height= icd-height_max; a-defrect.left= icd-x_min; a-defrect.top= icd-y_min; -a-defrect.width= DEFAULT_WIDTH; -a-defrect.height= DEFAULT_HEIGHT; +a-defrect.width= icd-width_max; +a-defrect.height= icd-height_max; a-pixelaspect.numerator= 1; a-pixelaspect.denominator= 1; What was the reason to use fix values? Because of the current implementation of crop, the default value can get bigger than the max value. Yes, you're right again, taking scaling into account. Although, setting default to maximum doesn't seem a very good idea to me either. Maybe we'd have to add an extra parameter to struct soc_camera_device, but I'm somewhat reluctant to change this now, because all those fields from the struct will have to disappear anyway with the v4l2-subdev transition, at which point, I think, all these requests will have to be passed down to drivers. Is there some ongoing work regarding the crop implementation on soc_camera? If I understand the documentation [1] right, the crop vales should represent the area of the capture device before scaling. What was the reason for the current implementation combing crop and fmt values? See this discussion: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/68 besides, my idea was, that the user cannot be bothered with all scalings / croppings that take place in host and client devices (on camera controllers and / or sensors). My understanding was: the user uses S_FMT to request a window of a certain size, say 640x480, the drivers shall try to fit as much into it as possible using scaling. How many hardware pixels are now used to build this VGA window the user has no idea about. Then you can use S_CROP to select sub-windows from _that_ area. If you want a different resolution, you use S_FMT again (after stopping the running capture), etc. Any other solution seemed too complicated and impractical to me. Thanks Guennadi --- Guennadi Liakhovetski -- 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] Allow the user to restrict the RC5 address
On Thu, 26 Mar 2009 12:45:18 -0400 Steven Toth (ST) wrote: ST I too tend to have multiple remotes, I don't think it's that unusual for ST long standing Hauppauge customers to have many boards with many types of ST remotes. ST ST It might be better to have an option to explicitly allow old Hauppauge ST remotes that send 0x00. ST ST I could live with this. It relegates older remotes but those remotes ST are no longer made. This feels like a good compromise. How about changing the parameter such that it is a filter mask? The default value of 0x0 would accept all remotes. For non-zero values, each bit set in the parameter would filter the device address corresponding to that bit, e.g. 0x1 would filter address 0x0, 0x8000 would filter address 0x1f, etc. Cheers, - Udo signature.asc Description: PGP signature
[REVIEW] v4l2 loopback
Hello, please review the new version of v4l2 loopback driver.
I fixed up comments to the previous submission, waiting for the new ones :-),
reposting for patchwork tool
---
This patch introduces v4l2 loopback module
From: Vasily Levin vas...@gmail.com
This is v4l2 loopback driver which can be used to make available any userspace
video as v4l2 device. Initialy it was written to make videoeffects available
to Skype, but in fact it have many more uses.
Priority: normal
Signed-off-by: Vasily Levin vas...@gmail.com
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig
v4l-dvb.my/linux/drivers/media/video/Kconfig
--- v4l-dvb.orig/linux/drivers/media/video/Kconfig 2009-03-21
07:08:06.0 +0200
+++ v4l-dvb.my/linux/drivers/media/video/Kconfig2009-03-25
23:36:13.0 +0200
@@ -465,6 +465,13 @@ config VIDEO_VIVI
Say Y here if you want to test video apps or debug V4L devices.
In doubt, say N.
+config VIDEO_V4L2_LOOPBACK
+ tristate v4l2 loopback driver
+ depends on VIDEO_V4L2 VIDEO_DEV
+ help
+ Say Y if you want to use v4l2 loopback driver.
+ This driver can be compiled as a module, called v4l2loopback.
+
source drivers/media/video/bt8xx/Kconfig
config VIDEO_SAA6588
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile
v4l-dvb.my/linux/drivers/media/video/Makefile
--- v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-03-21
07:08:06.0 +0200
+++ v4l-dvb.my/linux/drivers/media/video/Makefile 2009-03-24
12:54:59.0 +0200
@@ -132,6 +132,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
+obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c
--- v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
03:00:00.0 +0300
+++ v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-03-25
23:01:35.0 +0200
@@ -0,0 +1,725 @@
+/*
+ * v4l2loopback.c -- video 4 linux loopback driver
+ *
+ * Copyright (C) 2005-2009
+ * Vasily Levin (vas...@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.
+ *
+ */
+#include linux/version.h
+#include linux/vmalloc.h
+#include linux/mm.h
+#include linux/time.h
+#include linux/module.h
+#include media/v4l2-ioctl.h
+#include v4l2loopback.h
+
+/* #define DEBUG
+#define DEBUG_RW */
+#define YAVLD_STREAMING
+
+#ifdef DEBUG
+#define dprintk(fmt, args...)\
+ do {\
+ printk(KERN_INFO v4l2-loopback: fmt, ##args);\
+ } while (0)
+#else
+#define dprintk(fmt, args...)
+#endif
+
+#ifdef DEBUG_RW
+#define dprintkrw(fmt, args...)\
+ do {\
+ printk(KERN_INFO v4l2-loopback: fmt, ##args);\
+ } while (0)
+#else
+#define dprintkrw(fmt, args...)
+#endif
+
+/* global module data */
+struct v4l2_loopback_device *dev;
+/* forward declarations */
+static void init_buffers(int buffer_size);
+static const struct v4l2_file_operations v4l2_loopback_fops;
+static const struct v4l2_ioctl_ops v4l2_loopback_ioctl_ops;
+/
+ my queue helpers ***
+/
+/* next functions sets buffer flags and adjusts counters accordingly */
+static void set_done(struct v4l2_buffer *buffer)
+{
+ buffer-flags |= V4L2_BUF_FLAG_DONE;
+ buffer-flags = ~V4L2_BUF_FLAG_QUEUED;
+}
+
+static void set_queued(struct v4l2_buffer *buffer)
+{
+ buffer-flags |= V4L2_BUF_FLAG_QUEUED;
+ buffer-flags = ~V4L2_BUF_FLAG_DONE;
+}
+
+static void unset_all(struct v4l2_buffer *buffer)
+{
+ buffer-flags = ~V4L2_BUF_FLAG_QUEUED;
+ buffer-flags = ~V4L2_BUF_FLAG_DONE;
+}
+/
+ V4L2 ioctl caps and params calls ***
+/
+/**/
+/* returns device capabilities, called on VIDIOC_QUERYCAP ioctl*/
+static int vidioc_querycap(struct file *file,
+ void *priv, struct v4l2_capability *cap)
+{
+ strcpy(cap-driver, v4l2 loopback);
+ strcpy(cap-card, Dummy video device);
+ cap-version = 1;
+ cap-capabilities =
+ V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT |
+ V4L2_CAP_READWRITE
+#ifdef YAVLD_STREAMING
+ | V4L2_CAP_STREAMING
+#endif
+
Re: [ADMIN] linuxtv.org is moving
On Wed, Mar 25, 2009 at 05:25:41PM +0100, Johannes Stezenbach wrote: linuxtv.org will move to a new server machine tomorrow. Expect some downtime during the move and please be patient. Everything on the old machine will be rsynced to the new machine right before the switch so nothing should get lost. The move is done, but the DNS updates are not out there yet, so especially mail won't work yet until the caches are updated, but everything else should. The new IP address is 217.160.6.122. Johannes -- 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] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Mar 26 19:00:03 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11153:56cf0f1772f7 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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/5] CSI camera interface driver for MX1
On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: +/* common v4l buffer stuff -- must be first */ +struct videobuf_buffer vb; Here you have one space + +const struct soc_camera_data_format*fmt; Here you have 8 spaces + +int inwork; Here you have tabs. Please, unify. Please always check your patches with checkpatch.pl. This will point such issues. No, I did check the patch with checkpatch.pl and it didn't complain about this. It checks _indentation_ of lines, that _must_ be done with TABs, but it doesn't check what is used for alignment _inside_ lines, like xxx = 0; y = 1; z = 2; where first and third lines have spaces before =, and the second one has a TAB. This is not checked by checkpatch.pl. Thanks Guennadi --- Guennadi Liakhovetski -- 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/5] CSI camera interface driver for MX1
On Thu, 26 Mar 2009 17:31:35 -0400 Dave Strauss dave.stra...@zoran.com wrote: Guennadi Liakhovetski wrote: On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: + /* common v4l buffer stuff -- must be first */ + struct videobuf_buffer vb; Here you have one space + + const struct soc_camera_data_format*fmt; Here you have 8 spaces + + int inwork; Here you have tabs. Please, unify. Please always check your patches with checkpatch.pl. This will point such issues. No, I did check the patch with checkpatch.pl and it didn't complain about this. It checks _indentation_ of lines, that _must_ be done with TABs, but it doesn't check what is used for alignment _inside_ lines, like xxx = 0; y = 1; z = 2; where first and third lines have spaces before =, and the second one has a TAB. This is not checked by checkpatch.pl. Thanks Guennadi --- Guennadi Liakhovetski Newbie question -- where does one find checkpatch.pl? And are there any other tools we should be running on patches before we submit them? It is at kernel tree, under script directory. You shouldn't copy it from kernel tree, but to use it from there, to get optimum results, since it will read some files a kernel documentation, for checking the usage of legacy functions. Thanks. - Dave Strauss Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] CSI camera interface driver for MX1
Guennadi Liakhovetski wrote: On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: + /* common v4l buffer stuff -- must be first */ + struct videobuf_buffer vb; Here you have one space + + const struct soc_camera_data_format*fmt; Here you have 8 spaces + + int inwork; Here you have tabs. Please, unify. Please always check your patches with checkpatch.pl. This will point such issues. No, I did check the patch with checkpatch.pl and it didn't complain about this. It checks _indentation_ of lines, that _must_ be done with TABs, but it doesn't check what is used for alignment _inside_ lines, like xxx = 0; y = 1; z = 2; where first and third lines have spaces before =, and the second one has a TAB. This is not checked by checkpatch.pl. Thanks Guennadi --- Guennadi Liakhovetski Newbie question -- where does one find checkpatch.pl? And are there any other tools we should be running on patches before we submit them? Thanks. - Dave Strauss -- 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] add documentation for planar YUV 4:4:4 format
On Thu, 2009-03-26 at 16:05 +0100, Daniel Glöckner wrote:
This patch adds the planar YUV 4:4:4 format to the v4l2 specification.
Signed-off-by: Daniel Glöckner d...@emlix.com
diff -r 55df63b82fef -r bd23aedbd597 v4l2-spec/Makefile
--- a/v4l2-spec/Makefile Thu Mar 26 09:13:40 2009 +0100
+++ b/v4l2-spec/Makefile Thu Mar 26 14:06:09 2009 +0100
@@ -48,6 +48,7 @@
pixfmt-yuv411p.sgml \
pixfmt-yuv420.sgml \
pixfmt-yuv422p.sgml \
+ pixfmt-yuv444p.sgml \
pixfmt-yuyv.sgml \
pixfmt-yvyu.sgml \
pixfmt.sgml \
diff -r 55df63b82fef -r bd23aedbd597 v4l2-spec/pixfmt-yuv444p.sgml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/v4l2-spec/pixfmt-yuv444p.sgml Thu Mar 26 14:06:09 2009 +0100
@@ -0,0 +1,171 @@
+refentry id=V4L2-PIX-FMT-YUV444P
+ refmeta
+ refentrytitleV4L2_PIX_FMT_YUV444P ('444P')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_YUV444P/constant/refname
+ refpurposeFormat with full horizontal and vertical chroma resolution,
+also known as YUV 4:4:4. Planar layout/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis format is not commonly used. The three components are
+separated into three sub-images or planes. The Y plane is first. The Cb plane
+immediately follows the Y plane in memory. Following the Cb plane is the Cr
+plane. All planes have on byte per pixel./para
s/on/one/
Regards,
Andy
+ paraIf the Y plane has pad bytes after each row, then the Cr
+and Cb planes have the same number of pad bytes after their rows. In other
+words, one Cx row (including padding) is exactly as long as one Y row
+(including padding)./para
+
+ example
+ titleconstantV4L2_PIX_FMT_YUV444P/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2*
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryCbsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCbsubscript02/subscript/entry
+ entryCbsubscript03/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;20:/entry
+ entryCbsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCbsubscript12/subscript/entry
+ entryCbsubscript13/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;24:/entry
+ entryCbsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCbsubscript22/subscript/entry
+ entryCbsubscript23/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;28:/entry
+ entryCbsubscript30/subscript/entry
+ entryCbsubscript31/subscript/entry
+ entryCbsubscript32/subscript/entry
+ entryCbsubscript33/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;32:/entry
+ entryCrsubscript00/subscript/entry
+ entryCrsubscript01/subscript/entry
+ entryCrsubscript02/subscript/entry
+ entryCrsubscript03/subscript/entry
+
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for mxl5005s: Switch in mxl5005s_set_params should operate on correct values Can you somehow add to the log: Reported-by: Jose Alberto Reguero jaregu...@telefonica.net Tested-by: Jose Alberto Reguero jaregu...@telefonica.net Tested-by: Andy Walls awa...@radix.net Regards, Andy diffstat: mxl5005s.c |7 +++ 1 file changed, 3 insertions(+), 4 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Hi Klaas, Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal: (2nd try, this should be now in plain text instead of HTML) Hi Hermann, Thanks for your howto on making a proper patch. After a make commit in my local v4l-dvb tree, and filling in the template I got the following output. I confess I do not know if this has now ended up somewhere in linuxtv.org or that it is just local. However, here it is: your patches are still local, but they are at least on the proper list now. Without starting with [PATCH] in the subject Mauro's scripts to add them to patchwork automatically likely will still not find them. As said before, as long nobody has the documentation for that tuner and knows better somehow, your attempt to improve it is valid in my eyes and was usual practice in such cases previously. It would of course be fine if Oliver and/or Michael could review it and eventually give an ACK or NACK with some reasons. I came to it, because you initially reported the problem erroneously on the saa7134 driver, but I'm not sure how I can help further with it now, except for eventually remaining checkpatch.pl stuff and such. Cheers, Hermann changeset: 11143:f10e05176a88 tag: tip user:Klaas de Waal klaas.de.w...@gmail.com date:Tue Mar 24 22:59:44 2009 +0100 files: linux/drivers/media/common/tuners/tda827x.c linux/drivers/media/dvb/ttpci/budget-ci.c description: Separate tuning table for DVB-C solves tuning problem at 388MHz. From: Klaas de Waal klaas.de.w...@gmail.com TechnoTrend C-1501 DVB-C card does not lock on 388MHz. I assume that existing frequency table is valid for DVB-T. This is suggested by the name of the table: tda827xa_dvbt. Added a table for DVB-C with the name tda827xa_dvbc. Added runtime selection of the DVB-C table when the tuner is type FE_QAM. This should leave the behaviour of this driver with with DVB_T tuners unchanged. This modification is in file tda827x.c The tda827x.c gives the following warning message when debug=1 : tda827x: tda827x_config not defined, cannot set LNA gain! Solved this by adding a tda827x_config struct in budget-ci.c. Priority: normal Signed-off-by: Klaas de Waal klaas.de.w...@gmail.com I have attached the result of hg diff tda827x_dvb-c_tuning_table.patch. Patch is based on the hg clone done 23 march. Tested again, now with Linux kernel 2.6.28.9. Cheers, Klaas. -- 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
On Fri, 27 Mar 2009 00:51:43 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi Klaas, Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal: (2nd try, this should be now in plain text instead of HTML) Hi Hermann, Thanks for your howto on making a proper patch. After a make commit in my local v4l-dvb tree, and filling in the template I got the following output. I confess I do not know if this has now ended up somewhere in linuxtv.org or that it is just local. However, here it is: your patches are still local, but they are at least on the proper list now. Without starting with [PATCH] in the subject Mauro's scripts to add them to patchwork automatically likely will still not find them. The patchwork scripts are the ones that came with the product. They are not developed by me ;) Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is not inlined and were attached with a wrong mime type. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] [ADMIN] linuxtv.org is moving
On 27 Mar 2009, at 04:57, Johannes Stezenbach wrote: On Wed, Mar 25, 2009 at 05:25:41PM +0100, Johannes Stezenbach wrote: linuxtv.org will move to a new server machine tomorrow. Expect some downtime during the move and please be patient. Everything on the old machine will be rsynced to the new machine right before the switch so nothing should get lost. The move is done, but the DNS updates are not out there yet, so especially mail won't work yet until the caches are updated, but everything else should. The new IP address is 217.160.6.122. So how do I unsubscribe from linux-dvb? It seems that I still gets some mails from this list, but information on how to unsubscribe is lost from the website. -- Torgeir Veimo torg...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l parent for usb device interface or device?
[cc-ing linux-usb] On Thu, Mar 26, 2009 at 01:29:57PM +0100, Hans de Goede wrote: On 03/25/2009 03:58 PM, Hans Verkuil wrote: Hi Hans, On Wednesday 25 March 2009 11:18:31 Hans de Goede wrote: take 2 this time to the new list, hoping it gets some more attention Hi, Today it came to my attention (through a libv4l bugreport) that the uvc driver and the gspca driver handle the setting of the v4l parent for usb webcams differently. The probe function for an usb driver gets passed in a struct usb_interface *intf parameter. uvc sets parent to: vdev-parent =intf-dev; gspca uses: struct usb_device *dev = interface_to_usbdev(intf); vdev.parent =dev-dev; Looking at what for example the usb mass-storage driver does (with my multi function printer/scanner with cardreader), which matches UVC, and thinking about how this is supposed to work with multifunction devices in general, I believe the uvc driver behaviour is correct, but before writing a patch for gspca, I thought it would be good to first discuss this on the list. So what do you think ? I obviously agree with you :-) USB class drivers bind to interfaces instead of devices to support composite (multifunction) devices. While drivers for vendor-specific USB devices can bind to the device, in which case the parent could be a USB device, we need to have some consistency in the sysfs symlinks. Using a USB interface as the video device parent regardless of the device type makes sense. If the parent should indeed become the usb_interface, then we should make all v4l usb drivers consistent. And update v4l2-framework.txt. I've noticed before that it seems to be random what is used as the parent. I'm no USB expert, so I'm relying on your input. I believe that what uvc is doing, is the right thing. USB explicitly allows for multi-function devices, where each function has a seperate interface. So far example a still camera, with a webcam mode, could have 2 interfaces, a mass storage interface for the sdcard which stores the pictures and a foo interface, for the webcam mode. Clearly the right parent for the webcam v4l device then is the foo interface, and not the entire device (just like the mass storage driver will use the other interface as its parent). I think writing some docs about this and making all drivers consistent wrt this, is a good plan. I will write a driver to make gspca the right thing. While I generally agree that setting parent to the usb interface is probably correct for multifunction devices I noticed a problem after changing the hdpvr driver accordingly. With parent set to the usb interface there is no longer easy access to the usb device properties like the serial number through sysfs. I know that a couple of user with more than one device use the serial number to set static device nodes through udev. Regards, Janne -- 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
On Fri, 27 Mar 2009 01:46:50 +0100 hermann pitton hermann-pit...@arcor.de wrote: Am Donnerstag, den 26.03.2009, 21:09 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 00:51:43 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi Klaas, Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal: (2nd try, this should be now in plain text instead of HTML) Hi Hermann, Thanks for your howto on making a proper patch. After a make commit in my local v4l-dvb tree, and filling in the template I got the following output. I confess I do not know if this has now ended up somewhere in linuxtv.org or that it is just local. However, here it is: your patches are still local, but they are at least on the proper list now. Without starting with [PATCH] in the subject Mauro's scripts to add them to patchwork automatically likely will still not find them. The patchwork scripts are the ones that came with the product. They are not developed by me ;) Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is not inlined and were attached with a wrong mime type. Oh well, I still would prefer to have comments from such closest to that driver and related tuners, instead serving that product. There is more drifting around and it can be prepared to fit in to such rules. My concern is that it will arrive there then without much problems, but outstanding discussions are only postponed. If I'm wrong, even better. The point is that sending a broken patch won't work, anyway, since they can't be applied. The advantage of the tool is that it is clear to everyone that the patch is ok (so, patchwork picked), or if it is line-wrapped or is not inlined, creating troubles for people to review and apply. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [PATCH] cx88: Missing failure checks
Forwarded message:
Date: Thu, 26 Mar 2009 20:44:38 +
From: Alan Cox a...@lxorguk.ukuu.org.uk
To: linux-ker...@vger.kernel.org, mche...@infradead.org
Subject: [PATCH] cx88: Missing failure checks
The ioremap one was reported in October 2007 (Bug 9146), the kmalloc one
was blindingly obvious while looking at the ioremap one
The bug suggests some other configuration for lots of I/O memory (32MB per
device is ioremapped) but I'll leave that to the real maintainers
Signed-off-by: Alan Cox a...@lxorguk.ukuu.org.uk
---
drivers/media/video/cx88/cx88-cards.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/cx88/cx88-cards.c
b/drivers/media/video/cx88/cx88-cards.c
index 733ede3..2fa02cf 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -3089,6 +3089,8 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci,
int nr)
int i;
core = kzalloc(sizeof(*core), GFP_KERNEL);
+ if (core == NULL)
+ return NULL;
atomic_inc(core-refcount);
core-pci_bus = pci-bus-number;
@@ -3110,6 +3112,11 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci,
int nr)
core-lmmio = ioremap(pci_resource_start(pci, 0),
pci_resource_len(pci, 0));
core-bmmio = (u8 __iomem *)core-lmmio;
+
+ if (core-lmmio == NULL) {
+ kfree(core);
+ return NULL;
+ }
/* board config */
core-boardnr = UNSET;
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [PATCH] pluto2: silence spew of card hung up messages
Forwarded message:
Date: Thu, 26 Mar 2009 20:47:48 +
From: Alan Cox a...@lxorguk.ukuu.org.uk
To: linux-ker...@vger.kernel.org, mche...@infradead.org
Subject: [PATCH] pluto2: silence spew of card hung up messages
If the card is ejected on some systems you get a spew of messages as other
shared IRQ devices interrupt between the card eject and the card IRQ
disable.
We don't need to spew them all out
Closes #7472
Signed-off-by: Alan Cox a...@lxorguk.ukuu.org.uk
---
drivers/media/dvb/pluto2/pluto2.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/pluto2/pluto2.c
b/drivers/media/dvb/pluto2/pluto2.c
index d101b30..ee89623 100644
--- a/drivers/media/dvb/pluto2/pluto2.c
+++ b/drivers/media/dvb/pluto2/pluto2.c
@@ -116,6 +116,7 @@ struct pluto {
/* irq */
unsigned int overflow;
+ unsigned int dead;
/* dma */
dma_addr_t dma_addr;
@@ -336,8 +337,10 @@ static irqreturn_t pluto_irq(int irq, void *dev_id)
return IRQ_NONE;
if (tscr == 0x) {
- // FIXME: maybe recover somehow
- dev_err(pluto-pdev-dev, card hung up :(\n);
+ if (pluto-dead == 0)
+ dev_err(pluto-pdev-dev, card has hung or been
ejected.\n);
+ /* It's dead Jim */
+ pluto-dead = 1;
return IRQ_HANDLED;
}
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [PATCH] firedtv: wrong types in printk
Forwarded message: Date: Thu, 26 Mar 2009 21:41:15 + From: Alan Cox a...@lxorguk.ukuu.org.uk To: linux-ker...@vger.kernel.org, mche...@infradead.org Subject: [PATCH] firedtv: wrong types in printk size_t is not int... Signed-off-by: Alan Cox a...@lxorguk.ukuu.org.uk --- drivers/media/dvb/firewire/firedtv-avc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/firewire/firedtv-avc.c b/drivers/media/dvb/firewire/firedtv-avc.c index b55d9cc..424ed5d 100644 --- a/drivers/media/dvb/firewire/firedtv-avc.c +++ b/drivers/media/dvb/firewire/firedtv-avc.c @@ -150,7 +150,7 @@ static void debug_fcp(const u8 *data, size_t length) subunit_type = data[1] 3; subunit_id = data[1] 7; op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2]; - printk(KERN_INFO %ssu=%x.%x l=%d: %-8s - %s\n, + printk(KERN_INFO %ssu=%x.%x l=%Zd: %-8s - %s\n, prefix, subunit_type, subunit_id, length, debug_fcp_ctype(data[0]), debug_fcp_opcode(op, data, length)); Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Am Donnerstag, den 26.03.2009, 22:02 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 01:46:50 +0100 hermann pitton hermann-pit...@arcor.de wrote: Am Donnerstag, den 26.03.2009, 21:09 -0300 schrieb Mauro Carvalho Chehab: On Fri, 27 Mar 2009 00:51:43 +0100 hermann pitton hermann-pit...@arcor.de wrote: Hi Klaas, Am Mittwoch, den 25.03.2009, 21:53 +0100 schrieb klaas de waal: (2nd try, this should be now in plain text instead of HTML) Hi Hermann, Thanks for your howto on making a proper patch. After a make commit in my local v4l-dvb tree, and filling in the template I got the following output. I confess I do not know if this has now ended up somewhere in linuxtv.org or that it is just local. However, here it is: your patches are still local, but they are at least on the proper list now. Without starting with [PATCH] in the subject Mauro's scripts to add them to patchwork automatically likely will still not find them. The patchwork scripts are the ones that came with the product. They are not developed by me ;) Anyway, if patchwork didn't catch is because the inlined patch is broken, or it is not inlined and were attached with a wrong mime type. Oh well, I still would prefer to have comments from such closest to that driver and related tuners, instead serving that product. There is more drifting around and it can be prepared to fit in to such rules. My concern is that it will arrive there then without much problems, but outstanding discussions are only postponed. If I'm wrong, even better. The point is that sending a broken patch won't work, anyway, since they can't be applied. The advantage of the tool is that it is clear to everyone that the patch is ok (so, patchwork picked), or if it is line-wrapped or is not inlined, creating troubles for people to review and apply. Mauro, that is acceptable for me. It loads work off from you and others and within the flood of patches we see that is OK. To talk others to that to follow such rules is a great annoyance and I ended up several times without further replies. But my main concern is, if it once arrived at patchwork formally, it is out of sight for most of us and might miss proper review, except you are sure you can always guarantee that. I don't want to start to argue about all what happened in the past. So, at least, if some patch arrived there mysteriously ;), the linux-media list should be informed that it is there now and last time to speak off, in case anything is not fully clear, before vanishing into some black hole until you find it in the next kernel release ... Cheers, Hermann -- 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: Fw: [PATCH] cx88: Missing failure checks
On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: From: Alan Cox a...@lxorguk.ukuu.org.uk To: linux-ker...@vger.kernel.org, mche...@infradead.org Subject: [PATCH] cx88: Missing failure checks The ioremap one was reported in October 2007 (Bug 9146), the kmalloc one was blindingly obvious while looking at the ioremap one The bug suggests some other configuration for lots of I/O memory (32MB per device is ioremapped) but I'll leave that to the real maintainers Each function has a 16 MB window and Linux can use three of the functions. IIRC, all the function's register windows are the same so only one needs to be mapped. -- 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] v4l2-subdev: ADV7343 video encoder driver
On Thursday 26 March 2009 04:39:48 Chaithrika U S wrote:
Analog Devices ADV7343 video encoder driver
Add ADV7343 I2C based video encoder driver. This follows the v4l2-subdev
framework.This driver has been tested on TI DM646x EVM. It has been
tested for Composite and Component outputs.
In this verision of the patch, review comments have been incorporated.
The querystd implementation has been removed. A note regarding the
hardware not supporting SECAM has been added.
Signed-off-by: Chaithrika U S chaithr...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Thanks! This looks very nice.
Regards,
Hans
---
drivers/media/video/Kconfig|9 +
drivers/media/video/Makefile |1 +
drivers/media/video/adv7343.c | 531
drivers/media/video/adv7343_regs.h |
188 +
include/media/adv7343.h| 23 ++
include/media/v4l2-chip-ident.h|3 +
6 files changed, 755 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/adv7343.c
create mode 100644 drivers/media/video/adv7343_regs.h
create mode 100644 include/media/adv7343.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 114bf04..49ff639 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -426,6 +426,15 @@ config VIDEO_ADV7175
To compile this driver as a module, choose M here: the
module will be called adv7175.
+config VIDEO_ADV7343
+tristate ADV7343 video encoder
+depends on I2C
+help
+ Support for Analog Devices I2C bus based ADV7343 encoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7343.
+
comment Video improvement chips
config VIDEO_UPD64031A
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 08765d8..eaa5a49 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
+obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
obj-$(CONFIG_VIDEO_BT856) += bt856.o
diff --git a/drivers/media/video/adv7343.c
b/drivers/media/video/adv7343.c new file mode 100644
index 000..a31aad4
--- /dev/null
+++ b/drivers/media/video/adv7343.c
@@ -0,0 +1,531 @@
+/*
+ * adv7343 - ADV7343 Video Encoder Driver
+ *
+ * The encoder hardware does not support SECAM.
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated -
http://www.ti.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 version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/module.h
+#include linux/videodev2.h
+#include linux/uaccess.h
+#include linux/version.h
+
+#include media/adv7343.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+
+#include adv7343_regs.h
+
+MODULE_DESCRIPTION(ADV7343 video encoder driver);
+MODULE_LICENSE(GPL);
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+struct adv7343_state {
+ struct v4l2_subdev sd;
+ u8 reg00;
+ u8 reg01;
+ u8 reg02;
+ u8 reg35;
+ u8 reg80;
+ u8 reg82;
+ int bright;
+ int hue;
+ int gain;
+ u32 output;
+ v4l2_std_id std;
+};
+
+static inline struct adv7343_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7343_state, sd);
+}
+
+static inline int adv7343_write(struct v4l2_subdev *sd, u8 reg, u8
value) +{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+static const u8 adv7343_init_reg_val[] = {
+ ADV7343_SOFT_RESET, ADV7343_SOFT_RESET_DEFAULT,
+ ADV7343_POWER_MODE_REG, ADV7343_POWER_MODE_REG_DEFAULT,
+
+ ADV7343_HD_MODE_REG1, ADV7343_HD_MODE_REG1_DEFAULT,
+ ADV7343_HD_MODE_REG2, ADV7343_HD_MODE_REG2_DEFAULT,
+ ADV7343_HD_MODE_REG3, ADV7343_HD_MODE_REG3_DEFAULT,
+ ADV7343_HD_MODE_REG4, ADV7343_HD_MODE_REG4_DEFAULT,
+ ADV7343_HD_MODE_REG5, ADV7343_HD_MODE_REG5_DEFAULT,
+ ADV7343_HD_MODE_REG6, ADV7343_HD_MODE_REG6_DEFAULT,
+ ADV7343_HD_MODE_REG7, ADV7343_HD_MODE_REG7_DEFAULT,
+
+
Re: [PATCH 5/5] LDP: Add support for built-in camera
Aguirre Rodriguez, Sergio Alberto wrote: -Original Message- From: stanley.miao [mailto:stanley.m...@windriver.com] Sent: Tuesday, March 10, 2009 3:04 AM To: Aguirre Rodriguez, Sergio Alberto Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Sakari Ailus; Tuukka.O Toivonen; Hiroshi DOYU; DongSoo(Nathaniel) Kim; MiaoStanley; Nagalla, Hari; Hiremath, Vaibhav; Lakhani, Amish; Menon, Nishanth Subject: RE: [PATCH 5/5] LDP: Add support for built-in camera On Mon, 2009-03-09 at 15:24 -0500, Aguirre Rodriguez, Sergio Alberto wrote: snip out when I run my test program. 3CSI2: ComplexIO Error IRQ 80 CSI2: ComplexIO Error IRQ 80 3CSI2: ComplexIO Error IRQ c2 CSI2: ComplexIO Error IRQ c2 3CSI2: ComplexIO Error IRQ c2 CSI2: ComplexIO Error IRQ c2 3CSI2: ComplexIO Error IRQ c6 CSI2: ComplexIO Error IRQ c6 3CSI2: ECC correction failed CSI2: ECC correction failed 3CSI2: ComplexIO Error IRQ 6 CSI2: ComplexIO Error IRQ 6 3CSI2: ComplexIO Error IRQ 6 CSI2: ComplexIO Error IRQ 6 3CSI2: ComplexIO Error IRQ 6 CSI2: ComplexIO Error IRQ 6 3CSI2: ComplexIO Error IRQ 6 CSI2: ComplexIO Error IRQ 6 Oops, my mistake. Missed to add that struct there... Fixed now. About the CSI2 errors you're receiving... Which version of LDP are you using? Which Silicon revision has (ES2.1 or ES3.0)? ZOOM1 board(LDP3430-VG1.0.0-1), omap3430 ES2.1. When I use your old version patch, sometimes the test succeed, sometimes failed(no data was generated and no error). This version, always failed. Stanley, I'm working on some CSI2 fixes that could help you with this.. I'll keep you updated on this. Also, about your board version, it is possible that you'll need a HW modfix because of a redundant resistor in CSI2 datalanes. I'm in talks with some people at TI to prepare a ready to publish document about this rework. Zoom1 with ES3 silicon doesn't need this HW fix. Hi, Sergio, When I used your version in omapzoom tree, the camera worked sometimes. So I think it's not HW's problem. My test program is capture.c that I got from v4l2 spec and did some modifications. This is my test log: r...@localhost:/root ./capture -d /dev/video4 select timeout read_frame: Resource temporarily unavailable select timeout read_frame: Resource temporarily unavailable ^C r...@localhost:/root ./capture -d /dev/video4 Got 20 frames data, success. r...@localhost:/root ./capture -d /dev/video4 CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed CSI2: Short packet receive error CSI2: ECC correction failed select timeout read_frame: Resource temporarily unavailable select timeout read_frame: Resource temporarily unavailable select timeout read_frame: Resource temporarily unavailable select timeout read_frame: Resource temporarily unavailable ^C select timeout means that no data was generated. Stanley. I'll hope to get back to you about this next week. Regards, Sergio Thanks. Stanley. Regards, Sergio Stanley. -- 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: patchwork tool
On Thu, 26 Mar 2009 01:19:08 +0200 vas...@gmail.com wrote: Hello, how should I format my post in order to patchwork tool understand included patch correctly, If patchwork is not adding your patches there, then it means that the patches are broken (for example, line-wrapped), or that you're attaching it, and your emailer are using the wrong mime encoding type for diffs. should I just format it like in v4l-dvb/README.patches described? then how should I add additional comments to the mail which I do not want to be in the patch log? All comments you add on your patch will be part of the commit message (except for the meta-tags, like from:). It seems it is possible without special comment symbols. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patchwork tool
On Thu, Mar 26, 2009 at 10:34 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Thu, 26 Mar 2009 01:19:08 +0200 vas...@gmail.com wrote: Hello, how should I format my post in order to patchwork tool understand included patch correctly, If patchwork is not adding your patches there, then it means that the patches are broken (for example, line-wrapped), or that you're attaching it, and your emailer are using the wrong mime encoding type for diffs. should I just format it like in v4l-dvb/README.patches described? then how should I add additional comments to the mail which I do not want to be in the patch log? All comments you add on your patch will be part of the commit message (except for the meta-tags, like from:). It seems it is possible without special comment symbols. Cheers, Mauro can it be that patch made by $diff -uprN v4l-dvb.orig v4l-dvb.my patch.patch and make commit in .my tree did not complain still broken? does gmail's web interface plain text mail composer has known issues, which can interfere with sending patches? vasaka -- 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: patchwork tool
On Thu, 26 Mar 2009 11:22:26 +0200 vas...@gmail.com wrote: On Thu, Mar 26, 2009 at 10:34 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Thu, 26 Mar 2009 01:19:08 +0200 vas...@gmail.com wrote: Hello, how should I format my post in order to patchwork tool understand included patch correctly, If patchwork is not adding your patches there, then it means that the patches are broken (for example, line-wrapped), or that you're attaching it, and your emailer are using the wrong mime encoding type for diffs. should I just format it like in v4l-dvb/README.patches described? then how should I add additional comments to the mail which I do not want to be in the patch log? All comments you add on your patch will be part of the commit message (except for the meta-tags, like from:). It seems it is possible without special comment symbols. Cheers, Mauro can it be that patch made by $diff -uprN v4l-dvb.orig v4l-dvb.my patch.patch and make commit in .my tree did not complain still broken? does gmail's web interface plain text mail composer has known issues, which can interfere with sending patches? I never used a web interface to send patches. Since patches should be sent inline, and such interfaces do line wrapping, they aren't good for patch submission. Also, probably, they'll encode the attachments with text/plain or application/octet-stream, instead of the proper text/x-patch mime type. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove debug output from stb6100_cfg.h
This patch removes the debug output from stb6100_cfg.h as it is flooding the syslog with tuning data during normal operation. Signed-off-by: Artem Makhutov ar...@makhutov.org --- linux.old/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:28:57.0 +0100 +++ linux/drivers/media/dvb/frontends/stb6100_cfg.h 2009-03-26 10:29:52.0 +0100 @@ -36,7 +36,6 @@ return err; } *frequency = t_state.frequency; - printk(%s: Frequency=%d\n, __func__, t_state.frequency); } return 0; } @@ -59,7 +58,6 @@ return err; } } - printk(%s: Frequency=%d\n, __func__, t_state.frequency); return 0; } @@ -81,7 +79,6 @@ } *bandwidth = t_state.bandwidth; } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; } @@ -103,6 +100,5 @@ return err; } } - printk(%s: Bandwidth=%d\n, __func__, t_state.bandwidth); return 0; }
Re: patchwork tool
On Thu, Mar 26, 2009 at 12:54 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Thu, 26 Mar 2009 11:22:26 +0200 vas...@gmail.com wrote: On Thu, Mar 26, 2009 at 10:34 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Thu, 26 Mar 2009 01:19:08 +0200 vas...@gmail.com wrote: Hello, how should I format my post in order to patchwork tool understand included patch correctly, If patchwork is not adding your patches there, then it means that the patches are broken (for example, line-wrapped), or that you're attaching it, and your emailer are using the wrong mime encoding type for diffs. should I just format it like in v4l-dvb/README.patches described? then how should I add additional comments to the mail which I do not want to be in the patch log? All comments you add on your patch will be part of the commit message (except for the meta-tags, like from:). It seems it is possible without special comment symbols. Cheers, Mauro can it be that patch made by $diff -uprN v4l-dvb.orig v4l-dvb.my patch.patch and make commit in .my tree did not complain still broken? does gmail's web interface plain text mail composer has known issues, which can interfere with sending patches? I never used a web interface to send patches. Since patches should be sent inline, and such interfaces do line wrapping, they aren't good for patch submission. Well, i have never heard of such interface in gmail. If someone knows about it please let me know. Also, probably, they'll encode the attachments with text/plain or application/octet-stream, instead of the proper text/x-patch mime type. Vasily, may be this file can help you with mail clients linux/Documentation/email-clients.txt and instructions how to send patch correctly. For example, mutt and evolution works fine with gmail. -- Best regards, Klimov Alexey -- 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: v4l parent for usb device interface or device?
On 03/25/2009 03:58 PM, Hans Verkuil wrote: Hi Hans, On Wednesday 25 March 2009 11:18:31 Hans de Goede wrote: take 2 this time to the new list, hoping it gets some more attention Hi, Today it came to my attention (through a libv4l bugreport) that the uvc driver and the gspca driver handle the setting of the v4l parent for usb webcams differently. The probe function for an usb driver gets passed in a struct usb_interface *intf parameter. uvc sets parent to: vdev-parent =intf-dev; gspca uses: struct usb_device *dev = interface_to_usbdev(intf); vdev.parent =dev-dev; Looking at what for example the usb mass-storage driver does (with my multi function printer/scanner with cardreader), which matches UVC, and thinking about how this is supposed to work with multifunction devices in general, I believe the uvc driver behaviour is correct, but before writing a patch for gspca, I thought it would be good to first discuss this on the list. So what do you think ? I obviously agree with you :-) USB class drivers bind to interfaces instead of devices to support composite (multifunction) devices. While drivers for vendor-specific USB devices can bind to the device, in which case the parent could be a USB device, we need to have some consistency in the sysfs symlinks. Using a USB interface as the video device parent regardless of the device type makes sense. If the parent should indeed become the usb_interface, then we should make all v4l usb drivers consistent. And update v4l2-framework.txt. I've noticed before that it seems to be random what is used as the parent. I'm no USB expert, so I'm relying on your input. I believe that what uvc is doing, is the right thing. USB explicitly allows for multi-function devices, where each function has a seperate interface. So far example a still camera, with a webcam mode, could have 2 interfaces, a mass storage interface for the sdcard which stores the pictures and a foo interface, for the webcam mode. Clearly the right parent for the webcam v4l device then is the foo interface, and not the entire device (just like the mass storage driver will use the other interface as its parent). I think writing some docs about this and making all drivers consistent wrt this, is a good plan. I will write a driver to make gspca the right thing. 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 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
Display driver for TI DM646x EVM Signed-off-by: Chaithrika U S chaithr...@ti.com This patch set has been updated with the review comments for the RFC sent earlier. These patches add the display driver support for TI DM646x EVM. This patch set has been tested for basic display functionality for Composite and Component outputs. Patch 1: Display device platform and board setup Patch 2: VPIF driver Patch 3: DM646x display driver Patch 4: Makefile and config files modifications for Display Some of the features like the HBI/VBI support are not yet implemented. Also there are some known issues in the code implementation like fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not been tested extensively. These patches are based on the drivers written by: Manjunath Hadli m...@ti.com Brijesh Jadav brijes...@ti.com The files have been renamed as per the discussion. The header files have been moved to the same directory as the driver. Currently, the driver supports SDTV formats only. -Chaithrika -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Platform specific display device setup for DM646x EVM
Add platform device and resource structures. Also define a platform specific
clock setup function that can be accessed by the driver to configure the clock
and CPLD.
This patch is dependent on a patch submitted earlier, that patch adds
Pin Mux and clock definitions for Video on DM646x.
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to DaVinci GIT tree
arch/arm/mach-davinci/board-dm646x-evm.c| 138 +++
arch/arm/mach-davinci/dm646x.c | 63
arch/arm/mach-davinci/include/mach/dm646x.h | 25 +
3 files changed, 226 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index a300d5d..92d20f5 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -39,6 +39,7 @@
#include mach/serial.h
#include mach/i2c.h
#include mach/mmc.h
+#include mach/mux.h
#include linux/platform_device.h
#include linux/i2c.h
@@ -49,6 +50,19 @@
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET(0x6c)
+
+#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
+#define VCH2CLK_SYSCLK8(BIT(9))
+#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
+#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
+#define VCH3CLK_SYSCLK8(BIT(13))
+#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
+
+#define VIDCH2CLK (BIT(10))
+#define VIDCH3CLK (BIT(11))
+
static struct emac_platform_data dm646x_evm_emac_pdata = {
.phy_mask = DM646X_EVM_PHY_MASK,
.mdio_max_freq = DM646X_EVM_MDIO_FREQUENCY,
@@ -103,11 +117,54 @@ int dm646xevm_eeprom_write(void *buf, off_t off, size_t
count)
}
EXPORT_SYMBOL(dm646xevm_eeprom_write);
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { cpld_video, 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = cpld_video,
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO(24c256, 0x50),
.platform_data = eeprom_info,
},
+ {
+ I2C_BOARD_INFO(adv7343, 0x2A),
+ },
+ {
+ I2C_BOARD_INFO(ths7303, 0x2C),
+ },
+ {
+ I2C_BOARD_INFO(cpld_video, 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -115,10 +172,90 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value = ~(VCH2CLK_MASK);
+ value = ~(VCH3CLK_MASK);
+
+ if (hd = 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value = ~(VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ return 0;
+}
+
+static const struct subdev_info dm646x_vpif_subdev[] = {
+ {
+ .addr = 0x2A,
+ .name = adv7343,
+ },
+ {
+ .addr = 0x2C,
+ .name = ths7303,
+ },
+};
+
+static struct vpif_output output[] = {
+ {
+ .id = 0,
+ .name = Composite
+ },
+ {
+ .id = 1,
+ .name
[PATCH 3/4] ARM: DaVinci: DM646x Video: Add VPIF display driver
Display driver for VPIF
Adds the VPIF display driver and the associated header file.
The patch includes the review comments on the RFC sent earlier.
The major updates are:
- change in the name of the file.
- moved the platform related data to the platform specific files.
- changed the subdev calls to subdev_call_until_err
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpif_display.c | 1702
drivers/media/video/davinci/vpif_display.h | 204
2 files changed, 1906 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpif_display.c
create mode 100644 drivers/media/video/davinci/vpif_display.h
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
new file mode 100644
index 000..582c2b1
--- /dev/null
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -0,0 +1,1702 @@
+/*
+ * vpif-display - VPIF display driver
+ * Display driver for TI DaVinci VPIF
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.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 version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/mm.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/string.h
+#include linux/videodev2.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/i2c.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/version.h
+
+#include asm/irq.h
+#include asm/page.h
+
+#include media/adv7343.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#include mach/dm646x.h
+
+#include vpif_display.h
+#include vpif.h
+
+MODULE_DESCRIPTION(TI DaVinci VPIF Display driver);
+MODULE_LICENSE(GPL);
+
+#define DM646X_V4L2_STD (V4L2_STD_PAL | V4L2_STD_NTSC)
+
+static int debug;
+static u32 ch2_numbuffers = 3;
+static u32 ch3_numbuffers = 3;
+static u32 ch2_bufsize = 1920 * 1080 * 2;
+static u32 ch3_bufsize = 720 * 576 * 2;
+
+module_param(debug, int, 0644);
+module_param(ch2_numbuffers, uint, S_IRUGO);
+module_param(ch3_numbuffers, uint, S_IRUGO);
+module_param(ch2_bufsize, uint, S_IRUGO);
+module_param(ch3_bufsize, uint, S_IRUGO);
+
+MODULE_PARM_DESC(debug, Debug level 0-1);
+MODULE_PARM_DESC(ch2_numbuffers, Channel2 buffer count (default:3));
+MODULE_PARM_DESC(ch3_numbuffers, Channel3 buffer count (default:3));
+MODULE_PARM_DESC(ch2_bufsize, Channel2 buffer size (default:1920 x 1080 x
2));
+MODULE_PARM_DESC(ch3_bufsize, Channel3 buffer size (default:720 x 576 x 2));
+
+static struct vpif_config_params config_params = {
+ .min_numbuffers = 3,
+ .numbuffers[0] = 3,
+ .numbuffers[1] = 3,
+ .min_bufsize[0] = 720 * 480 * 2,
+ .min_bufsize[1] = 720 * 480 * 2,
+ .channel_bufsize[0] = 1920 * 1080 * 2,
+ .channel_bufsize[1] = 720 * 576 * 2,
+};
+
+static int vpif_nr[] = {2, 3,};
+static struct vpif_device vpif_obj = { {NULL} };
+static struct device *vpif_dev;
+
+static struct v4l2_capability vpif_videocap = {
+ .driver = vpif display,
+ .bus_info = Platform,
+ .version= VPIF_DISPLAY_VERSION_CODE,
+ .capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING,
+};
+
+/*
+ * vpif_uservirt_to_phys: This inline function is used to convert user
+ * space virtual address to physical address.
+ */
+static inline u32 vpif_uservirt_to_phys(u32 virtp)
+{
+ struct mm_struct *mm = current-mm;
+ unsigned long physp = 0;
+ struct vm_area_struct *vma;
+
+ vma = find_vma(mm, virtp);
+
+ /* For kernel direct-mapped memory, take the easy way */
+ if (virtp = PAGE_OFFSET) {
+ physp = virt_to_phys((void *)virtp);
+ } else if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff)) {
+ /* this will catch, kernel-allocated, mmaped-to-usermode addr */
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-vm_start);
+ } else {
+ /* otherwise, use get_user_pages() for general userland pages */
+ int res, nr_pages = 1;
+ struct page *pages;
+ down_read(current-mm-mmap_sem);
+
+ res = get_user_pages(current, current-mm,
+virtp, nr_pages, 1, 0, pages, NULL);
+ up_read(current-mm-mmap_sem);
+
+ if (res == nr_pages) {
+ physp =
[PATCH 4/4] ARM: DaVinci: DM646x Video: Makefile and config files modifications for Display
Makefile and Kconfig changes Modifies and adds the video Makefiles and Kconfig files to support DM646x Video display device Signed-off-by: Chaithrika U S chaithr...@ti.com --- Applies to v4l-dvb repository drivers/media/video/Kconfig | 22 ++ drivers/media/video/Makefile |2 ++ drivers/media/video/davinci/Makefile |9 + 3 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 49ff639..0da9aa3 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -462,6 +462,28 @@ config VIDEO_UPD64083 endmenu # encoder / decoder chips +config DISPLAY_DAVINCI_DM646X_EVM +tristate DM646x EVM Video Display +depends on VIDEO_DEV MACH_DAVINCI_DM646X_EVM +select VIDEOBUF_DMA_CONTIG +select VIDEO_DAVINCI_VPIF +select VIDEO_ADV7343 +select VIDEO_THS7303 +help + Support for DaVinci based display device. + + To compile this driver as a module, choose M here: the + module will be called davincihd_display. + +config VIDEO_DAVINCI_VPIF +tristate DaVinci VPIF Driver +depends on DISPLAY_DAVINCI_DM646X_EVM +help + Support for DaVinci VPIF Driver. + + To compile this driver as a module, choose M here: the + module will be called vpif. + config VIDEO_VIVI tristate Virtual Video Driver depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index eaa5a49..b56c1e7 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -152,6 +152,8 @@ obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ +obj-$(CONFIG_ARCH_DAVINCI) += davinci/ + EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends EXTRA_CFLAGS += -Idrivers/media/common/tuners diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile new file mode 100644 index 000..7fe9bce --- /dev/null +++ b/drivers/media/video/davinci/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the davinci video device drivers. +# + +# VPIF +obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o + +#DM646x EVM Display driver +obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -- 1.5.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 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
On Thu, 2009-03-26 at 09:21 -0400, Chaithrika U S wrote: Display driver for TI DM646x EVM Signed-off-by: Chaithrika U S chaithr...@ti.com This patch set has been updated with the review comments for the RFC sent earlier. These patches add the display driver support for TI DM646x EVM. This patch set has been tested for basic display functionality for Composite and Component outputs. Patch 1: Display device platform and board setup Patch 2: VPIF driver Patch 3: DM646x display driver Patch 4: Makefile and config files modifications for Display Some of the features like the HBI/VBI support are not yet implemented. Also there are some known issues in the code implementation like fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not been tested extensively. These patches are based on the drivers written by: Manjunath Hadli m...@ti.com Brijesh Jadav brijes...@ti.com Please add authors and significant contributors of the patch in the signed-off list The files have been renamed as per the discussion. The header files have been moved to the same directory as the driver. Currently, the driver supports SDTV formats only. -Chaithrika ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Tue, 24 Mar 2009 23:07:02 -0500 (CDT) Mike Isely is...@isely.net wrote: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a large collection of pvrusb2 changesets (see below). You forgot to add pvrusb2-cs53l32a.o on your Makefile. I'll add it and merge with the correspond patch that added this patch, to avoid bisect breakage. Cheers, Mauro. --- linux-2.6.29.noarch.orig/drivers/media/video/pvrusb2/Makefile +++ linux-2.6.29.noarch/drivers/media/video/pvrusb2/Makefile @@ -10,6 +10,7 @@ pvrusb2-objs := pvrusb2-i2c-core.o \ pvrusb2-ctrl.o pvrusb2-std.o pvrusb2-devattr.o \ pvrusb2-context.o pvrusb2-io.o pvrusb2-ioread.o \ pvrusb2-cx2584x-v4l.o pvrusb2-wm8775.o \ + pvrusb2-cs53l32a.o \ $(obj-pvrusb2-dvb-y) \ $(obj-pvrusb2-sysfs-y) $(obj-pvrusb2-debugifc-y) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: On Tue, 24 Mar 2009 23:07:02 -0500 (CDT) Mike Isely is...@isely.net wrote: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a large collection of pvrusb2 changesets (see below). You forgot to add pvrusb2-cs53l32a.o on your Makefile. I'll add it and merge with the correspond patch that added this patch, to avoid bisect breakage. Damn. Sorry about that. Usually I *do* catch things like that :-( Thanks for spotting and fixing it. There might be another problem - I did test compile and run all this from within v4l-dvb. With that file missing it should not have loaded correctly, which means I must have missed something else too. I will double check this. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
On Thu, 26 Mar 2009 09:16:55 -0500 (CDT) Mike Isely is...@isely.net wrote: On Thu, 26 Mar 2009, Mauro Carvalho Chehab wrote: On Tue, 24 Mar 2009 23:07:02 -0500 (CDT) Mike Isely is...@isely.net wrote: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for a large collection of pvrusb2 changesets (see below). You forgot to add pvrusb2-cs53l32a.o on your Makefile. I'll add it and merge with the correspond patch that added this patch, to avoid bisect breakage. Damn. Sorry about that. Usually I *do* catch things like that :-( Thanks for spotting and fixing it. There might be another problem - I did test compile and run all this from within v4l-dvb. With that file missing it should not have loaded correctly, which means I must have missed something else too. I will double check this. Ok. PS: I couldn't push the patch to linuxtv yet, although it is already on my tree. It seems that the linuxtv machine migration is happening right now (or the file system sync). After it returning back, I'll push the patch there. I'll anyway do the -git fix. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] allow v4l2 drivers to provide a get_unmapped_area handler
Shared memory mappings on nommu machines require a get_unmapped_area
file operation that suggests an address for the mapping. This patch
adds a way for v4l2 drivers to provide this callback.
Signed-off-by: Daniel Glöckner d...@emlix.com
---
drivers/media/video/v4l2-dev.c | 19 +++
include/media/v4l2-dev.h |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 13f87c2..8c84037 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -198,6 +198,23 @@ static long v4l2_unlocked_ioctl(struct file *filp,
return vdev-fops-unlocked_ioctl(filp, cmd, arg);
}
+#ifdef CONFIG_MMU
+#define v4l2_get_unmapped_area NULL
+#else
+static unsigned long v4l2_get_unmapped_area(struct file *filp,
+ unsigned long addr, unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct video_device *vdev = video_devdata(filp);
+
+ if (!vdev-fops-get_unmapped_area)
+ return -ENOSYS;
+ if (video_is_unregistered(vdev))
+ return -ENODEV;
+ return vdev-fops-get_unmapped_area(filp, addr, len, pgoff, flags);
+}
+#endif
+
static int v4l2_mmap(struct file *filp, struct vm_area_struct *vm)
{
struct video_device *vdev = video_devdata(filp);
@@ -250,6 +267,7 @@ static const struct file_operations v4l2_unlocked_fops = {
.read = v4l2_read,
.write = v4l2_write,
.open = v4l2_open,
+ .get_unmapped_area = v4l2_get_unmapped_area,
.mmap = v4l2_mmap,
.unlocked_ioctl = v4l2_unlocked_ioctl,
#ifdef CONFIG_COMPAT
@@ -265,6 +283,7 @@ static const struct file_operations v4l2_fops = {
.read = v4l2_read,
.write = v4l2_write,
.open = v4l2_open,
+ .get_unmapped_area = v4l2_get_unmapped_area,
.mmap = v4l2_mmap,
.ioctl = v4l2_ioctl,
#ifdef CONFIG_COMPAT
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index e36faab..2058dd4 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -40,6 +40,8 @@ struct v4l2_file_operations {
unsigned int (*poll) (struct file *, struct poll_table_struct *);
long (*ioctl) (struct file *, unsigned int, unsigned long);
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
+ unsigned long (*get_unmapped_area) (struct file *, unsigned long,
+ unsigned long, unsigned long, unsigned long);
int (*mmap) (struct file *, struct vm_area_struct *);
int (*open) (struct file *);
int (*release) (struct file *);
--
1.6.2.107.ge47ee
--
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 5/5] saa7121 driver for s6000 data port
This patch adds a driver to support the saa7121 PAL/NTSC video encoder
in combination with the s6000 data port driver.
The chip is configured for embedded BT.656 syncs as this mode should
be supported on all devices.
The driver presents two outputs to applications and while it is true
that the device has these two outputs, both of them are always active.
The only difference on the Y/C output is that it disables the luma
notch filter.
Signed-off-by: Daniel Glöckner d...@emlix.com
---
drivers/media/video/s6dp/Kconfig|7 +
drivers/media/video/s6dp/Makefile |1 +
drivers/media/video/s6dp/s6dp-saa7121.c | 478 +++
3 files changed, 486 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/s6dp/s6dp-saa7121.c
diff --git a/drivers/media/video/s6dp/Kconfig b/drivers/media/video/s6dp/Kconfig
index 853e6b1..c95904c 100644
--- a/drivers/media/video/s6dp/Kconfig
+++ b/drivers/media/video/s6dp/Kconfig
@@ -20,3 +20,10 @@ config VIDEO_S6DP_MT9D131
default n
help
Enables the MT9D131 camera driver.
+
+config VIDEO_S6DP_SAA7121
+ tristate SAA7121 video encoder
+ depends on VIDEO_S6000
+ default n
+ help
+ Enables the SAA7121 video encoder driver.
diff --git a/drivers/media/video/s6dp/Makefile
b/drivers/media/video/s6dp/Makefile
index af0bc0f..61d86c9 100644
--- a/drivers/media/video/s6dp/Makefile
+++ b/drivers/media/video/s6dp/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_VIDEO_S6000) += s6dp.o
obj-$(CONFIG_VIDEO_S6DP_MT9D131) += s6dp-mt9d131.o
+obj-$(CONFIG_VIDEO_S6DP_SAA7121) += s6dp-saa7121.o
diff --git a/drivers/media/video/s6dp/s6dp-saa7121.c
b/drivers/media/video/s6dp/s6dp-saa7121.c
new file mode 100644
index 000..70799cd
--- /dev/null
+++ b/drivers/media/video/s6dp/s6dp-saa7121.c
@@ -0,0 +1,478 @@
+/*
+ * drivers/media/video/s6dp/s6dp-saa7121.c
+ *
+ * Description: Driver for SAA7121 chips hooked up to a S6000 family data port
+ * (c) 2009 emlix GmbH i...@emlix.com
+ *
+ * Author: Daniel Gloeckner d...@emlix.com
+ */
+
+#include media/s6dp-link.h
+#include s6dp.h
+#include linux/i2c.h
+
+static const u8 initial_setup[][2] = {
+ {0x3a, 0x13}
+};
+
+static const u8 pal_values[][2] = {
+ {0x28, 33}, {0x29, 29}, {0x5a, 0x00}, {0x5b, 125},
+ {0x5c, 175}, {0x5d, 35}, {0x5e, 53}, {0x5f, 0x40+53},
+ {0x61, 0x06}, {0x62, 47}, {0x63, 0xcb}, {0x64, 0x8a},
+ {0x65, 0x09}, {0x66, 0x2a}, {0x6c, 0x05}, {0x6d, 0x20},
+ {0x6e, 0xa0}
+};
+
+static const u8 pal_nc_values[][2] = {
+ {0x28, 33}, {0x29, 37}, {0x5a, 0x00}, {0x5b, 125},
+ {0x5c, 175}, {0x5d, 35}, {0x5e, 53}, {0x5f, 0xc0+53},
+ {0x61, 0x06}, {0x62, 47}, {0x63, 0x46}, {0x64, 0x94},
+ {0x65, 0xf6}, {0x66, 0x21}, {0x6c, 0x05}, {0x6d, 0x20},
+ {0x6e, 0xa0}
+};
+
+static const u8 pal_m_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x00}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 45}, {0x5e, 49}, {0x5f, 0xc0+59},
+ {0x61, 0x17}, {0x62, 45}, {0x63, 0xe3}, {0x64, 0xef},
+ {0x65, 0xe6}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0xa0}
+};
+
+static const u8 ntsc_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x88}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 42}, {0x5e, 46}, {0x5f, 0xc0+46},
+ {0x61, 0x15}, {0x62, 63}, {0x63, 0x1f}, {0x64, 0x7c},
+ {0x65, 0xf0}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0x80}
+};
+
+static const u8 ntsc_jp_values[][2] = {
+ {0x28, 25}, {0x29, 29}, {0x5a, 0x88}, {0x5b, 118},
+ {0x5c, 165}, {0x5d, 19}, {0x5e, 46}, {0x5f, 0xc0+46},
+ {0x61, 0x05}, {0x62, 62}, {0x63, 0x1f}, {0x64, 0x7c},
+ {0x65, 0xf0}, {0x66, 0x21}, {0x6c, 0xf9}, {0x6d, 0x00},
+ {0x6e, 0x80}
+};
+
+struct saa7121 {
+ int std;
+ int yc;
+ struct v4l2_pix_format fmt;
+ struct v4l2_rect crop;
+ u8 regs[128];
+};
+
+static int saa7121_write_regs(struct i2c_client *client)
+{
+ struct saa7121 *me = i2c_get_clientdata(client);
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(me-regs); i++) {
+ int ret = i2c_smbus_write_byte_data(client, i, me-regs[i]);
+ if (ret 0)
+ return ret;
+ }
+ return 0;
+}
+
+static void saa7121_change_regs(struct saa7121 *me, const u8 (*regs)[2],
+ int num)
+{
+ int i;
+ for (i = 0; i num; i++)
+ me-regs[regs[i][0]] = regs[i][1];
+}
+
+static const struct {
+ v4l2_std_id mask;
+ const char *name;
+ const u8 (*regs)[2];
+ int num;
+} standards[] = {
+ {
+ V4L2_STD_PAL | V4L2_STD_PAL_N,
+ PAL,
+ pal_values,
+ ARRAY_SIZE(pal_values)
+ },
+ {
+ V4L2_STD_NTSC_M | V4L2_STD_NTSC_M_KR,
+ NTSC,
+ ntsc_values,
+ ARRAY_SIZE(ntsc_values)
+ },
+ {
+
[patch 2/5] s6000 data port: custom video mode support
Extend s6dp driver to support direct MPEG2 and data streaming modes.
Provide ioctl access to select specific modes.
Signed-off-by: Oskar Schirmer o...@emlix.com
---
.../platforms/s6105/include/platform/ioctl.h | 59 +++
drivers/media/video/s6dp/s6dp.c| 393 +--
2 files changed, 410 insertions(+), 42 deletions(-)
diff --git a/arch/xtensa/platforms/s6105/include/platform/ioctl.h
b/arch/xtensa/platforms/s6105/include/platform/ioctl.h
index 0fc6e2c..da88b4c 100644
--- a/arch/xtensa/platforms/s6105/include/platform/ioctl.h
+++ b/arch/xtensa/platforms/s6105/include/platform/ioctl.h
@@ -14,4 +14,63 @@
#define S6IOCTL_ISEF_PRELOAD _IO(56, 1)
#define S6IOCTL_ISEF_INVALIDATE_IO(56, 2)
+#define MODE_CUSTOM_VIDEO 28
+#define ITU_H222_TRANS 29 /* MPEG2 TS, 188 bytes */
+#define ITU_H222_TRANS_RS 30 /* MPEG2 TS, valid RS, 204 bytes */
+#define ITU_H222_TRANS_RS_DUMMY31 /* MPEG2 TS, invalid RS, 204
bytes */
+#define STREAM832
+#define STREAM16 33
+#define STREAM32 34
+
+#define NUM_MODES 35
+#define MODE_LAST_VIDEOMODE_CUSTOM_VIDEO
+
+struct s6dp_ioctl_config {
+ unsigned char mode;
+ unsigned char lane;
+ unsigned char is_10bit;
+ unsigned char micron_mode;
+ unsigned char use_1120_line_and_crc;
+ unsigned char ext_framing;
+ unsigned char vsync_pol;
+ unsigned char hsync_pol;
+ unsigned char blank_pol;
+ unsigned char field_ctrl;
+ unsigned char blank_ctrl;
+ unsigned char relaxed_framing_mode;
+ unsigned int desc_size;
+ struct {
+ unsigned int width;
+ unsigned int height;
+ unsigned char portsperstream;
+ unsigned char greyperchroma;
+ unsigned char progressive;
+ struct {
+ unsigned int pixel_total;
+ unsigned int pixel_offset;
+ unsigned int pixel_padding;
+ unsigned int line_total;
+ unsigned int line_odd_total;
+ unsigned int line_odd_offset;
+ unsigned int line_even_offset;
+ unsigned int odd_vsync_len;
+ unsigned int odd_vsync_offset;
+ unsigned int even_vsync_len;
+ unsigned int even_vsync_offset;
+ unsigned int odd_hsync_len;
+ unsigned int odd_hsync_offset;
+ unsigned int even_hsync_len;
+ unsigned int even_hsync_offset;
+ } reg;
+ } custom;
+ struct {
+ int pix_start;
+ unsigned int line_start;
+ unsigned int line_width;
+ unsigned int num_lines;
+ } anc_placement[2];
+};
+
+#define S6IOCTL_DP_CONFIG _IOW(56, 9, struct s6dp_ioctl_config)
+
#endif /* __XTENSA_S6105_IOCTL_H */
diff --git a/drivers/media/video/s6dp/s6dp.c b/drivers/media/video/s6dp/s6dp.c
index 434cec5..9f349be 100644
--- a/drivers/media/video/s6dp/s6dp.c
+++ b/drivers/media/video/s6dp/s6dp.c
@@ -31,6 +31,7 @@
#include linux/io.h
#include variant/dmac.h
#include variant/hardware.h
+#include platform/ioctl.h
#include s6dp.h
#define DRV_NAME s6dp
@@ -40,6 +41,8 @@
#define DP_NB_PORTS(S6_DPDMA_NB / S6_DP_CHAN_PER_PORT)
+#define REPEAT_IN_STREAM_MODE 1
+
/* device not opened */
#define DP_STATE_UNUSED0
/* after open */
@@ -80,8 +83,10 @@ struct s6dp {
wait_queue_head_t wait;
u32 outstanding;
struct {
+ u8 modenr; /* -- FIXME */
u8 state;
u8 aligned:1;
+ u8 custom:1;
u8 framerepeat:1;
u8 progressive:1;
@@ -121,6 +126,7 @@ struct s6dp {
u8 is_10bit:1;
u8 micron:1;
u8 egress:1;
+ u8 cascade:1;
u8 use_1120_line_and_crc:1;
u8 ext_framing:1;
u8 vsync_pol:1;
@@ -130,6 +136,14 @@ struct s6dp {
u8 blank_ctrl:1;
u8 relaxed_framing_mode:1;
u32 desc_size;
+ struct anc_placement {
+ struct anc_placement_bbox {
+ s32 pix_start;
+ u32 line_start;
+ u32 line_width;
+ u32 num_lines;
+ } field[2];
+ } anc_placement;
} ext;
unsigned int num_io;
};
@@ -303,6 +317,34 @@ static irqreturn_t s6dp_interrupt(int irq, void *dev_id)
return ret;
}
+static inline int s6dp_is_anc_data_on(struct s6dp *pd)
+{
+ /*
+* if any of the fields in the bounding box are zero,
[patch 3/5] s6000 data port: canonical modes
From: Oskar Schirmer o...@emlix.com
Add optional handling of a list of video modes not directly supported by
the on-chip video engine. Makes use of extended dma capabilities to provide
these modes:
YUV420 and grey mode as well as planar YUV422 and YUV444 with non-aligned
planes
Signed-off-by: Oskar Schirmer o...@emlix.com
---
drivers/media/video/s6dp/Kconfig |9 +
drivers/media/video/s6dp/s6dp.c | 382 +-
2 files changed, 388 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/s6dp/Kconfig b/drivers/media/video/s6dp/Kconfig
index 11cc91d..357cfe5 100644
--- a/drivers/media/video/s6dp/Kconfig
+++ b/drivers/media/video/s6dp/Kconfig
@@ -4,3 +4,12 @@ config VIDEO_S6000
default n
help
Enables the s6000 video driver.
+
+config VIDEO_S6000_CANONICAL
+ tristate S6000 video canonical modes
+ depends on VIDEO_S6000
+ default n
+ help
+ Provides canonical video modes in addition
+ to the s6 specific ones. You might want these when
+ standard video software is used with the driver.
diff --git a/drivers/media/video/s6dp/s6dp.c b/drivers/media/video/s6dp/s6dp.c
index 9f349be..68f8e3d 100644
--- a/drivers/media/video/s6dp/s6dp.c
+++ b/drivers/media/video/s6dp/s6dp.c
@@ -60,6 +60,11 @@
#define CURRENT_BUF_TYPE(pd) ((pd)-ext.egress ? V4L2_BUF_TYPE_VIDEO_OUTPUT \
: V4L2_BUF_TYPE_VIDEO_CAPTURE)
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+#define PROCBUFFERS4
+#define PROCSTEPMAX3
+#endif
+
struct s6dp_frame {
void *data;
dma_addr_t dma_handle;
@@ -67,6 +72,9 @@ struct s6dp_frame {
struct list_head list;
u32 sequence;
u32 flags;
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+ unsigned procdidx;
+#endif
};
struct s6dp {
@@ -122,6 +130,26 @@ struct s6dp {
struct s6dp_frame *frames;
unsigned nrframes;
unsigned nrmapped;
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+ struct {
+ u32 dmac;
+ u8 chan;
+ u8 planemask;
+ u8 stepcnt;
+ u8 maxstep;
+ struct list_head queue;
+ void *buffers_vaddr[PROCBUFFERS];
+ dma_addr_t dma_handle[PROCBUFFERS];
+ u32 bufsize;
+ u8 bufget;
+ u8 bufput;
+ u32 bufoff[PROCSTEPMAX];
+ u32 frameoff[PROCSTEPMAX];
+ s32 stepsize[PROCSTEPMAX];
+ u16 stepchunk[PROCSTEPMAX];
+ u16 stepskip[PROCSTEPMAX];
+ } proc;
+#endif
struct {
u8 is_10bit:1;
u8 micron:1;
@@ -164,6 +192,11 @@ static void s6dp_try_fill_dma(struct s6dp *pd)
struct list_head *inq;
if (pd-cur.state != DP_STATE_ACTIVE)
return;
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+ if (pd-ext.egress pd-proc.maxstep)
+ inq = pd-proc.queue;
+ else
+#endif
inq = pd-idleq;
while (!list_empty(inq)) {
unsigned chan = pd-port * S6_DP_CHAN_PER_PORT;
@@ -174,10 +207,24 @@ static void s6dp_try_fill_dma(struct s6dp *pd)
s6dmac_fifo_full(pd-dmac, chan + i))
return;
f = list_first_entry(inq, struct s6dp_frame, list);
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+ if (pd-proc.maxstep) {
+ if (pd-proc.bufget == pd-proc.bufput)
+ return;
+ f-procdidx = (pd-proc.bufput++) % PROCBUFFERS;
+ } else {
+ f-procdidx = 0;
+ }
+#endif
list_del(f-list);
list_add_tail(f-list, pd-busyq);
do if (pd-cur.chansiz[--i]) {
u32 h, b, s, d;
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+ if ((pd-proc.planemask i) 1)
+ b = (u32)pd-proc.dma_handle[f-procdidx];
+ else
+#endif
b = (u32)f-dma_handle;
b += pd-cur.chanoff[i];
h = pd-dataram + S6_DP_CHAN_OFFSET(i);
@@ -195,6 +242,53 @@ static void s6dp_try_fill_dma(struct s6dp *pd)
}
}
+#ifdef CONFIG_VIDEO_S6000_CANONICAL
+static void s6dp_try_fill_lms(struct s6dp *pd)
+{
+ if (!list_empty(pd-proc.queue)) {
+ struct s6dp_frame *f;
+ unsigned n = pd-proc.stepcnt;
+ u32 s;
+ int l;
+ s6dmac_set_stride_skip(pd-proc.dmac, pd-proc.chan,
+ pd-proc.stepchunk[n], pd-proc.stepskip[n], 0);
+ f = list_first_entry(pd-proc.queue, struct s6dp_frame, list);
+ l = pd-proc.stepsize[n];
+ if (l 0) {
+ l = -l;
+ s = (u32)pd-proc.dma_handle[f-procdidx];
+
[patch 4/5] mt9d131 driver for s6000 data port
This patch adds a driver to support the mt9d131 camera in combination with the s6000 data port driver. Signed-off-by: Daniel Glöckner d...@emlix.com --- drivers/media/video/s6dp/Kconfig|7 + drivers/media/video/s6dp/Makefile |1 + drivers/media/video/s6dp/s6dp-mt9d131.c | 1051 +++ 3 files changed, 1059 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s6dp/s6dp-mt9d131.c diff --git a/drivers/media/video/s6dp/Kconfig b/drivers/media/video/s6dp/Kconfig index 357cfe5..853e6b1 100644 --- a/drivers/media/video/s6dp/Kconfig +++ b/drivers/media/video/s6dp/Kconfig @@ -13,3 +13,10 @@ config VIDEO_S6000_CANONICAL Provides canonical video modes in addition to the s6 specific ones. You might want these when standard video software is used with the driver. + +config VIDEO_S6DP_MT9D131 + tristate MT9D131 camera + depends on VIDEO_S6000 + default n + help + Enables the MT9D131 camera driver. diff --git a/drivers/media/video/s6dp/Makefile b/drivers/media/video/s6dp/Makefile index c503d5b..af0bc0f 100644 --- a/drivers/media/video/s6dp/Makefile +++ b/drivers/media/video/s6dp/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_VIDEO_S6000) += s6dp.o +obj-$(CONFIG_VIDEO_S6DP_MT9D131) += s6dp-mt9d131.o diff --git a/drivers/media/video/s6dp/s6dp-mt9d131.c b/drivers/media/video/s6dp/s6dp-mt9d131.c new file mode 100644 index 000..954e8e0 --- /dev/null +++ b/drivers/media/video/s6dp/s6dp-mt9d131.c @@ -0,0 +1,1051 @@ +/* + * Micron Camera driver + * (c)2007 Stretch, Inc. + * (c)2008 emlix GmbH i...@emlix.com + * Authors:Fabian Godehardt f...@emlix.com + * Oskar Schirmer o...@emlix.com + * Daniel Glöckner d...@emlix.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. + */ + +#include linux/module.h +#include linux/init.h +#include linux/version.h +#include linux/time.h +#include linux/i2c.h +#include linux/interrupt.h +#include linux/list.h +#include linux/delay.h +#include linux/stddef.h +#include linux/videodev2.h + +#include media/s6dp-link.h +#include s6dp.h + +#define PFX mt9d131: + +#define MT9D131_REG_SENSOR 0 /* direct access (Table 5) */ +#define MT9D131_REG_IFP1 1 /* direct access (Table 6) */ +#define MT9D131_REG_IFP2 2 /* direct access (Table 7) */ +#define MT9D131_REG_JPEG 3 /* indirect access, IFP2 reg 30/31 (Table 8) */ +#define MT9D131_REG8_UPROC 4 /* indirect access, IFP1 reg 0xc6/0xc8 (8 bits) */ +#define MT9D131_REG8_UPROC_seq 5 /* indirect, IFP1 reg 0xc6/0xc8 (Table 10) */ +#define MT9D131_REG8_UPROC_ae 6 /* indirect, IFP1 reg 0xc6/0xc8 (Table 11) */ +#define MT9D131_REG8_UPROC_wb 7 /* indirect, IFP1 reg 0xc6/0xc8 (Table 11) */ +#define MT9D131_REG8_UPROC_mode 11 /* indirect, IFP1 reg 0xc6/0xc8 (Table 12) */ +#define MT9D131_REG8_UPROC_jpeg 13 /* indirect, IFP1 reg 0xc6/0xc8 (Table 13) */ +#define MT9D131_REG16_UPROC 24 /* indirect, IFP1 reg 0xc6/0xc8 (16 bits) */ +#define MT9D131_REG16_UPROC_seq 25 +#define MT9D131_REG16_UPROC_ae 26 +#define MT9D131_REG16_UPROC_wb 27 +#define MT9D131_REG16_UPROC_mode 31 +#define MT9D131_REG16_UPROC_jpeg 33 + +#define MT9D131_CONTEXT_A 0 +#define MT9D131_CONTEXT_B 1 +#define MT9D131_NB_CONTEXTS2 + +#define MT9D131_CORE_ROWSTART 0x01 +#define MT9D131_CORE_COLSTART 0x02 +#define MT9D131_CORE_ROWWIDTH 0x03 +#define MT9D131_CORE_COLWIDTH 0x04 +#define MT9D131_CORE_HBLANKB 0x05 +#define MT9D131_CORE_VBLANKB 0x06 +#define MT9D131_CORE_HBLANKA 0x07 +#define MT9D131_CORE_VBLANKA 0x08 +#define MT9D131_CORE_SHUTTERWIDTH 0x09 +#define MT9D131_CORE_ROWSPEED 0x0A +#define MT9D131_CORE_READMODEB 0x20 +#define MT9D131_CORE_READMODEA 0x21 +#define MT9D131_CORE_GREEN1GAIN0x2B +#define MT9D131_CORE_BLUEGAIN 0x2C +#define MT9D131_CORE_REDGAIN 0x2D +#define MT9D131_CORE_GREEN2GAIN0x2E +#define MT9D131_CORE_CLKCTRL 0x65 +#define MT9D131_CORE_PLLCTRL1 0x66 +#define MT9D131_CORE_PLLCTRL2 0x67 + +#define MT9D131_IFP1_CROPWINDOWX0 0x11 +#define MT9D131_IFP1_CROPWINDOWX1 0x12 +#define MT9D131_IFP1_CROPWINDOWY0 0x13 +#define MT9D131_IFP1_CROPWINDOWY1 0x14 +#define MT9D131_IFP1_HORZDECIMATIONWGT 0x16 +#define MT9D131_IFP1_VERTDECIMATIONWGT 0x17 +#define MT9D131_IFP1_OUTPUTFMTCONFIG 0x97 +#define MT9D131_IFP1_YUVCTRL 0xBE +#define MT9D131_IFP1_YRGBOFFSET0xBF +#define MT9D131_IFP1_UPROCVARADDR 0xC6 +#define MT9D131_IFP1_UPROCVARADDR_ADDR 0 +#define MT9D131_IFP1_UPROCVARADDR_ADDR_MASK0xFF +#define MT9D131_IFP1_UPROCVARADDR_DRVID8 +#define
[patch 1/5] s6000 data port driver
From: Oskar Schirmer o...@emlix.com
Support for the s6000 on-chip video input/output engine.
Depending on external wiring it supports up to four video devices.
Signed-off-by: Fabian Godehardt f...@emlix.com
Signed-off-by: Oskar Schirmer o...@emlix.com
Signed-off-by: Johannes Weiner j...@emlix.com
Signed-off-by: Daniel Glöckner d...@emlix.com
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |2 +
drivers/media/video/s6dp/Kconfig |6 +
drivers/media/video/s6dp/Makefile |1 +
drivers/media/video/s6dp/s6dp.c | 1664 +
drivers/media/video/s6dp/s6dp.h | 121 +++
include/media/s6dp-link.h | 63 ++
7 files changed, 1859 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/s6dp/Kconfig
create mode 100644 drivers/media/video/s6dp/Makefile
create mode 100644 drivers/media/video/s6dp/s6dp.c
create mode 100644 drivers/media/video/s6dp/s6dp.h
create mode 100644 include/media/s6dp-link.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..a94c20f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -683,6 +683,8 @@ source drivers/media/video/ivtv/Kconfig
source drivers/media/video/cx18/Kconfig
+source drivers/media/video/s6dp/Kconfig
+
config VIDEO_M32R_AR
tristate AR devices
depends on M32R VIDEO_V4L1
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 72f6d03..7109cfe 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -134,6 +134,8 @@ obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
+obj-$(CONFIG_VIDEO_S6000) += s6dp/
+
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
diff --git a/drivers/media/video/s6dp/Kconfig b/drivers/media/video/s6dp/Kconfig
new file mode 100644
index 000..11cc91d
--- /dev/null
+++ b/drivers/media/video/s6dp/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_S6000
+ tristate S6000 video
+ depends on VIDEO_V4L2
+ default n
+ help
+ Enables the s6000 video driver.
diff --git a/drivers/media/video/s6dp/Makefile
b/drivers/media/video/s6dp/Makefile
new file mode 100644
index 000..c503d5b
--- /dev/null
+++ b/drivers/media/video/s6dp/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_S6000) += s6dp.o
diff --git a/drivers/media/video/s6dp/s6dp.c b/drivers/media/video/s6dp/s6dp.c
new file mode 100644
index 000..434cec5
--- /dev/null
+++ b/drivers/media/video/s6dp/s6dp.c
@@ -0,0 +1,1664 @@
+/*
+ * Video driver for S6105 on chip data port device
+ * (c)2007 Stretch, Inc.
+ * (c)2009 emlix GmbH
+ * Authors:Fabian Godehardt f...@emlix.com
+ * Oskar Schirmer o...@emlix.com
+ * Johannes Weiner j...@emlix.com
+ * Daniel Gloeckner d...@emlix.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.
+ */
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/videodev2.h
+#include linux/time.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/wait.h
+#include linux/dma-mapping.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
+#include media/s6dp-link.h
+#include linux/io.h
+#include variant/dmac.h
+#include variant/hardware.h
+#include s6dp.h
+
+#define DRV_NAME s6dp
+#define DRIVER_VERSION_NUM KERNEL_VERSION(0, 0, 1)
+#define DRV_ERR KERN_ERR DRV_NAME :
+#define DRV_INFO KERN_INFO DRV_NAME :
+
+#define DP_NB_PORTS(S6_DPDMA_NB / S6_DP_CHAN_PER_PORT)
+
+/* device not opened */
+#define DP_STATE_UNUSED0
+/* after open */
+#define DP_STATE_IDLE 1
+/* after reqbufs */
+#define DP_STATE_READY 2
+/* after streamon */
+#define DP_STATE_ACTIVE3
+
+#define DP_CB_OFFSET 0
+#define DP_Y_OFFSET1
+#define DP_CR_OFFSET 2
+#define DP_K_OFFSET3
+
+#define CURRENT_BUF_TYPE(pd) ((pd)-ext.egress ? V4L2_BUF_TYPE_VIDEO_OUTPUT \
+ : V4L2_BUF_TYPE_VIDEO_CAPTURE)
+
+struct s6dp_frame {
+ void *data;
+ dma_addr_t dma_handle;
+ struct timeval timestamp;
+ struct list_head list;
+ u32 sequence;
+ u32 flags;
+};
+
+struct s6dp {
+ u8 port;
+ u16 irq;
+ void __iomem *dp;
+ u32 dataram;
+ u32 dmac;
+ struct s6dp_link *link;
+ struct list_head idleq;
+ struct list_head busyq;
+ struct list_head fullq;
+ spinlock_t lock;
+ wait_queue_head_t wait;
+ u32 outstanding;
+ struct {
+
[patch] add documentation for planar YUV 4:4:4 format
This patch adds the planar YUV 4:4:4 format to the v4l2 specification.
Signed-off-by: Daniel Glöckner d...@emlix.com
diff -r 55df63b82fef -r bd23aedbd597 v4l2-spec/Makefile
--- a/v4l2-spec/MakefileThu Mar 26 09:13:40 2009 +0100
+++ b/v4l2-spec/MakefileThu Mar 26 14:06:09 2009 +0100
@@ -48,6 +48,7 @@
pixfmt-yuv411p.sgml \
pixfmt-yuv420.sgml \
pixfmt-yuv422p.sgml \
+ pixfmt-yuv444p.sgml \
pixfmt-yuyv.sgml \
pixfmt-yvyu.sgml \
pixfmt.sgml \
diff -r 55df63b82fef -r bd23aedbd597 v4l2-spec/pixfmt-yuv444p.sgml
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/v4l2-spec/pixfmt-yuv444p.sgml Thu Mar 26 14:06:09 2009 +0100
@@ -0,0 +1,171 @@
+refentry id=V4L2-PIX-FMT-YUV444P
+ refmeta
+ refentrytitleV4L2_PIX_FMT_YUV444P ('444P')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_YUV444P/constant/refname
+ refpurposeFormat with full horizontal and vertical chroma resolution,
+also known as YUV 4:4:4. Planar layout/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis format is not commonly used. The three components are
+separated into three sub-images or planes. The Y plane is first. The Cb plane
+immediately follows the Y plane in memory. Following the Cb plane is the Cr
+plane. All planes have on byte per pixel./para
+
+ paraIf the Y plane has pad bytes after each row, then the Cr
+and Cb planes have the same number of pad bytes after their rows. In other
+words, one Cx row (including padding) is exactly as long as one Y row
+(including padding)./para
+
+ example
+ titleconstantV4L2_PIX_FMT_YUV444P/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2*
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryCbsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCbsubscript02/subscript/entry
+ entryCbsubscript03/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;20:/entry
+ entryCbsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCbsubscript12/subscript/entry
+ entryCbsubscript13/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;24:/entry
+ entryCbsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCbsubscript22/subscript/entry
+ entryCbsubscript23/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;28:/entry
+ entryCbsubscript30/subscript/entry
+ entryCbsubscript31/subscript/entry
+ entryCbsubscript32/subscript/entry
+ entryCbsubscript33/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;32:/entry
+ entryCrsubscript00/subscript/entry
+ entryCrsubscript01/subscript/entry
+ entryCrsubscript02/subscript/entry
+ entryCrsubscript03/subscript/entry
+ /row
+
