Re: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi James, On 12/15/2011 08:14 AM, James wrote: Hi all, I'm using an OMAP3530 board and a monochrome 12-bit grey sensor. Can anyone enlighten me why is the 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output? There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only the VP (video port) truncates data to 10 bits, and it does that because the subdevs it feeds can only handle 10 bits max. I need to read the entire RAW 12-bit grey value from the CCDC to memory and the data does not pass through other OMAP3ISP sub-devices. I intend to use Laurent's yavta to capture the data to file to verify its operation for the moment. Can this 12-bit (Y12) raw capture be done? Yes. If you are writing the 12-bit gray value directly into memory, you will use SOURCE_OF and can write the full 12-bits into memory. You need to set up your media pipeline to do sensor-CCDC-OMAP3 ISP CCDC output. Thank you in adv. -- Regards, James -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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: Hauppauge HVR-930C problems
On 12/14/11 17:33, Mihai Dobrescu wrote:
Hello,
I need to make my tunner working too.
Did you make it work?
Where did you get the firmware (dvb-usb-hauppauge-hvr930c-drxk.fw)?
I have Sabayon 7 64 bit, which is sort of Gentoo, as I've seen you have.
Thank you.
Hi Mihai,
There is a perl script get_dvb_firmware that downloads the firmware and
extract it (from the Windows driver I think). You need a version of
get_dvb_firmware where this has been added:
+sub drxk_hauppauge_hvr930c {
+my $url = http://www.wintvcd.co.uk/drivers/;;
+my $zipfile = HVR-9x0_5_10_325_28153_SIGNED.zip;
+my $hash = 83ab82e7e9480ec8bf1ae0155ca63c88;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
+my $drvfile = HVR-900/emOEM.sys;
+my $fwfile = dvb-usb-hauppauge-hvr930c-drxk.fw;
+
+checkstandard();
+
+wgetfile($zipfile, $url . $zipfile);
+verify($zipfile, $hash);
+unzip($zipfile, $tmpdir);
+extract($tmpdir/$drvfile, 0x117b0, 42692, $fwfile);
+
+$fwfile
+}
+
Do a git checkout of the linux-media tree to get it (I think).
Also, before I found the perl script I did it manually using:
1)
wget http://www.wintvcd.co.uk/drivers/HVR-9x0_5_10_325_28153_SIGNED.zip
2) unzip it
3) extact it with dd [0x117b (hex) = 71600 (dec)]:
dd if=HVR-900/emOEM.sys of=dvb-usb-hauppauge-hvr930c-drxk.fw bs=1
skip=71600 count=42692
4) copy it to the firmware dir
cp dvb-usb-hauppauge-hvr930c-drxk.fw /lib/firmware/'
HTH
/Fredrik
--
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/15] module_param: check type correctness for module_param_array
On 15-12-2011 01:00, Rusty Russell wrote:
module_param_array(), unlike its non-array cousins, didn't check the type
of the variable. Fixing this found two bugs.
Cc: Luca Risolia luca.riso...@studio.unibo.it
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Eric Piel eric.p...@tremplin-utc.net
Cc: linux-media@vger.kernel.org
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/media/video/et61x251/et61x251_core.c |4 ++--
drivers/media/video/sn9c102/sn9c102_core.c |4 ++--
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/mfd/janz-cmodio.c|2 +-
drivers/misc/lis3lv02d/lis3lv02d.c |2 ++
include/linux/moduleparam.h |1 +
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/et61x251/et61x251_core.c
b/drivers/media/video/et61x251/et61x251_core.c
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -76,8 +76,8 @@ MODULE_PARM_DESC(video_nr,
\none and for every other camera.
\n);
-static short force_munmap[] = {[0 ... ET61X251_MAX_DEVICES-1] =
-ET61X251_FORCE_MUNMAP};
+static bool force_munmap[] = {[0 ... ET61X251_MAX_DEVICES-1] =
+ ET61X251_FORCE_MUNMAP};
module_param_array(force_munmap, bool, NULL, 0444);
MODULE_PARM_DESC(force_munmap,
\n0|1[,...] Force the application to unmap previously
diff --git a/drivers/media/video/sn9c102/sn9c102_core.c
b/drivers/media/video/sn9c102/sn9c102_core.c
--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -75,8 +75,8 @@ MODULE_PARM_DESC(video_nr,
\none and for every other camera.
\n);
-static short force_munmap[] = {[0 ... SN9C102_MAX_DEVICES-1] =
-SN9C102_FORCE_MUNMAP};
+static bool force_munmap[] = {[0 ... SN9C102_MAX_DEVICES-1] =
+ SN9C102_FORCE_MUNMAP};
module_param_array(force_munmap, bool, NULL, 0444);
MODULE_PARM_DESC(force_munmap,
0|1[,...]
diff --git a/drivers/mfd/janz-cmodio.c b/drivers/mfd/janz-cmodio.c
--- a/drivers/mfd/janz-cmodio.c
+++ b/drivers/mfd/janz-cmodio.c
@@ -33,7 +33,7 @@
/* Module Parameters */
static unsigned int num_modules = CMODIO_MAX_MODULES;
-static unsigned char *modules[CMODIO_MAX_MODULES] = {
+static char *modules[CMODIO_MAX_MODULES] = {
empty, empty, empty, empty,
};
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c
b/drivers/misc/lis3lv02d/lis3lv02d.c
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -111,6 +111,8 @@ static struct kernel_param_ops param_ops
.get = param_get_int,
};
+#define param_check_axis(name, p) param_check_int(name, p)
+
module_param_array_named(axes, lis3_dev.ac.as_array, axis, NULL, 0644);
MODULE_PARM_DESC(axes, Axis-mapping for x,y,z directions);
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -395,6 +395,7 @@ extern int param_get_invbool(char *buffe
* module_param_named() for why this might be necessary.
*/
#define module_param_array_named(name, array, type, nump, perm)
\
+ param_check_##type(name, (array)[0]); \
static const struct kparam_array __param_arr_##name \
= { .max = ARRAY_SIZE(array), .num = nump, \
.ops = param_ops_##type, \
--
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 -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
On 15-12-2011 04:34, Dan Carpenter wrote:
On a 32bit system the multiplication here could overflow. p-count is
used in some of the V4L drivers.
ULONG_MAX / sizeof(v4l2_ext_control) is too much. This ioctl is used on things
like setting MPEG paramenters, where several parameters need adjustments at
the same time. I risk to say that 64 is probably a reasonably safe upper limit.
Btw, the upstream code also seems to have the same issue:
static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
void * __user *user_ptr, void ***kernel_ptr)
{
...
if (ctrls-count != 0) {
...
*array_size = sizeof(struct v4l2_ext_control)
* ctrls-count;
ret = 1;
...
}
long
video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
v4l2_kioctl func)
{
...
err = check_array_args(cmd, parg, array_size, user_ptr, kernel_ptr);
if (err 0)
goto out;
has_array_args = err;
if (has_array_args) {
mbuf = kmalloc(array_size, GFP_KERNEL);
...
so, if is there any overflow at check_array_args(), instead of returning
an error to userspace, it will allocate the array with less space than
needed.
On both upstream and longterm, I think that it is more reasonable to
state a limit for the maximum number of controls that can be passed at
the same time, and live with that.
A dummy check says:
$ more include/linux/videodev2.h |grep V4L2_CID|wc -l
209
So, an upper limit of 256 is enough to allow userspace to change all existing
controls
at the same time.
The proper way seems to add a define at include/linux/videodev2.h
and enforce it at the usercopy code.
Regards,
Mauro
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a patch against the 2.6.32-longterm kernel. In the stock
kernel, this code was totally rewritten and fixed in 2010 by d14e6d76ebf
[media] v4l: Add multi-planar ioctl handling code.
Hopefully, someone can Ack this and we merge it into the stable tree.
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 265bfb5..7196303 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -414,6 +414,9 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
@@ -1912,6 +1915,9 @@ long video_ioctl2(struct file *file,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
--
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 -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
On Thursday, December 15, 2011 10:21:41 Mauro Carvalho Chehab wrote:
On 15-12-2011 04:34, Dan Carpenter wrote:
On a 32bit system the multiplication here could overflow. p-count is
used in some of the V4L drivers.
ULONG_MAX / sizeof(v4l2_ext_control) is too much. This ioctl is used on things
like setting MPEG paramenters, where several parameters need adjustments at
the same time. I risk to say that 64 is probably a reasonably safe upper
limit.
Let's make it 1024. That gives more than enough room for expansion without
taking
too much memory.
Especially for video encoders a lot of controls are needed, and sensor drivers
are also getting more complex, so 64 is a bit too low for my taste.
I agree that limiting this to some sensible value is a good idea.
Btw, the upstream code also seems to have the same issue:
static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
void * __user *user_ptr, void ***kernel_ptr)
{
...
if (ctrls-count != 0) {
...
*array_size = sizeof(struct v4l2_ext_control)
* ctrls-count;
ret = 1;
...
}
long
video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
v4l2_kioctl func)
{
...
err = check_array_args(cmd, parg, array_size, user_ptr,
kernel_ptr);
if (err 0)
goto out;
has_array_args = err;
if (has_array_args) {
mbuf = kmalloc(array_size, GFP_KERNEL);
...
so, if is there any overflow at check_array_args(), instead of returning
an error to userspace, it will allocate the array with less space than
needed.
On both upstream and longterm, I think that it is more reasonable to
state a limit for the maximum number of controls that can be passed at
the same time, and live with that.
A dummy check says:
$ more include/linux/videodev2.h |grep V4L2_CID|wc -l
209
So, an upper limit of 256 is enough to allow userspace to change all existing
controls
at the same time.
I would like to have this set to at least twice the number of existing controls
(which 1024 certainly is).
It is possible (and valid) to have the same control any number of times in the
control list. The last one will 'win' in that case. I can think of (admittedly
contrived) scenarios where that might be useful. The only thing we want to do
here is to add a sanity check against insane count values.
The proper way seems to add a define at include/linux/videodev2.h
and enforce it at the usercopy code.
I agree.
Regards,
Hans
Regards,
Mauro
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a patch against the 2.6.32-longterm kernel. In the stock
kernel, this code was totally rewritten and fixed in 2010 by d14e6d76ebf
[media] v4l: Add multi-planar ioctl handling code.
Hopefully, someone can Ack this and we merge it into the stable tree.
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 265bfb5..7196303 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -414,6 +414,9 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
@@ -1912,6 +1915,9 @@ long video_ioctl2(struct file *file,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: tvp5150 Fix default input selection.
In page 23 of the datasheet of this chip (SLES098A) it is stated that de default input for this chip is Composite AIP1A which is the same as COMPOSITE0 in the driver. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/tvp5150.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c index e927d25..26cc75b 100644 --- a/drivers/media/video/tvp5150.c +++ b/drivers/media/video/tvp5150.c @@ -993,7 +993,7 @@ static int tvp5150_probe(struct i2c_client *c, } core-norm = V4L2_STD_ALL; /* Default is autodetect */ - core-input = TVP5150_COMPOSITE1; + core-input = TVP5150_COMPOSITE0; core-enable = 1; v4l2_ctrl_handler_init(core-hdl, 4); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] media: tvp5150: Add mbus_fmt callbacks.
These callbacks allow a host video driver
to poll video supported video formats of tvp5150.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/tvp5150.c | 72 +
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..8f01f08 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,75 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder-norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder-norm;
+
+ if ((std == V4L2_STD_NTSC) || (std == V4L2_STD_NTSC_443) ||
+ (std == V4L2_STD_PAL_M)) {
+ f-width = 720;
+ f-height = 480;
+ }
+ if ((std == V4L2_STD_PAL) ||
+ (std == (V4L2_STD_PAL_N | V4L2_STD_PAL_Nc)) ||
+ (std == V4L2_STD_SECAM)) {
+ f-width = 720;
+ f-height = 576;
+ }
+ f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f-field = V4L2_FIELD_SEQ_TB;
+ f-colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, width = %d, height = %d\n, f-width,
+ f-height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +999,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops
= {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv3 PATCH 0/3] Add per-device-node capabilities
Hi Mauro, This patch series adds support for per-device capabilities. All comments from the previous RFC PATCH series: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/40688 have been incorporated and the documentation has been updated. The only file changed since the previous series was vidioc-querycap.xml. As far as I am concerned it is ready to be merged for v3.3. The git request-pull output is below: The following changes since commit bcc072756e4467dc30e502a311b1c3adec96a0e4: [media] STV0900: Query DVB frontend delivery capabilities (2011-12-12 15:04:34 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git capsv3 Hans Verkuil (3): V4L2: Add per-device-node capabilities vivi: set device_caps. ivtv: setup per-device caps. Documentation/DocBook/media/v4l/compat.xml |9 + Documentation/DocBook/media/v4l/v4l2.xml |9 - .../DocBook/media/v4l/vidioc-querycap.xml | 36 ++-- drivers/media/video/cx231xx/cx231xx-417.c |1 - drivers/media/video/ivtv/ivtv-driver.h |1 + drivers/media/video/ivtv/ivtv-ioctl.c |7 +++- drivers/media/video/ivtv/ivtv-streams.c| 14 drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 - drivers/media/video/v4l2-ioctl.c |6 ++- drivers/media/video/vivi.c |5 ++- include/linux/videodev2.h | 29 +++- 11 files changed, 97 insertions(+), 21 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
[RFCv3 PATCH 2/3] vivi: set device_caps.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/vivi.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c index 7d754fb..84ea88d 100644 --- a/drivers/media/video/vivi.c +++ b/drivers/media/video/vivi.c @@ -819,8 +819,9 @@ static int vidioc_querycap(struct file *file, void *priv, strcpy(cap-driver, vivi); strcpy(cap-card, vivi); strlcpy(cap-bus_info, dev-v4l2_dev.name, sizeof(cap-bus_info)); - cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | \ - V4L2_CAP_READWRITE; + cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING | + V4L2_CAP_READWRITE | V4L2_CAP_DEVICE_CAPS; + cap-device_caps = cap-capabilities; return 0; } -- 1.7.7.3 -- 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
[RFCv3 PATCH 3/3] ivtv: setup per-device caps.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-driver.h |1 +
drivers/media/video/ivtv/ivtv-ioctl.c |7 +--
drivers/media/video/ivtv/ivtv-streams.c | 14 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.h
b/drivers/media/video/ivtv/ivtv-driver.h
index 8f9cc17..06b9efd 100644
--- a/drivers/media/video/ivtv/ivtv-driver.h
+++ b/drivers/media/video/ivtv/ivtv-driver.h
@@ -331,6 +331,7 @@ struct ivtv_stream {
struct ivtv *itv; /* for ease of use */
const char *name; /* name of the stream */
int type; /* stream type */
+ u32 caps; /* V4L2 capabilities */
u32 id;
spinlock_t qlock; /* locks access to the queues */
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index ecafa69..6be63e9 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -752,12 +752,15 @@ static int ivtv_s_register(struct file *file, void *fh,
struct v4l2_dbg_register
static int ivtv_querycap(struct file *file, void *fh, struct v4l2_capability
*vcap)
{
- struct ivtv *itv = fh2id(fh)-itv;
+ struct ivtv_open_id *id = fh2id(file-private_data);
+ struct ivtv *itv = id-itv;
+ struct ivtv_stream *s = itv-streams[id-type];
strlcpy(vcap-driver, IVTV_DRIVER_NAME, sizeof(vcap-driver));
strlcpy(vcap-card, itv-card_name, sizeof(vcap-card));
snprintf(vcap-bus_info, sizeof(vcap-bus_info), PCI:%s,
pci_name(itv-pdev));
- vcap-capabilities = itv-v4l2_cap; /* capabilities */
+ vcap-capabilities = itv-v4l2_cap | V4L2_CAP_DEVICE_CAPS;
+ vcap-device_caps = s-caps;
return 0;
}
diff --git a/drivers/media/video/ivtv/ivtv-streams.c
b/drivers/media/video/ivtv/ivtv-streams.c
index e7794dc..4d4ae6e 100644
--- a/drivers/media/video/ivtv/ivtv-streams.c
+++ b/drivers/media/video/ivtv/ivtv-streams.c
@@ -78,60 +78,73 @@ static struct {
int num_offset;
int dma, pio;
enum v4l2_buf_type buf_type;
+ u32 v4l2_caps;
const struct v4l2_file_operations *fops;
} ivtv_stream_info[] = {
{ /* IVTV_ENC_STREAM_TYPE_MPG */
encoder MPG,
VFL_TYPE_GRABBER, 0,
PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
+ V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
ivtv_v4l2_enc_fops
},
{ /* IVTV_ENC_STREAM_TYPE_YUV */
encoder YUV,
VFL_TYPE_GRABBER, IVTV_V4L2_ENC_YUV_OFFSET,
PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_TUNER |
+ V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
ivtv_v4l2_enc_fops
},
{ /* IVTV_ENC_STREAM_TYPE_VBI */
encoder VBI,
VFL_TYPE_VBI, 0,
PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_VBI_CAPTURE,
+ V4L2_CAP_VBI_CAPTURE | V4L2_CAP_SLICED_VBI_CAPTURE |
V4L2_CAP_TUNER |
+ V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
ivtv_v4l2_enc_fops
},
{ /* IVTV_ENC_STREAM_TYPE_PCM */
encoder PCM,
VFL_TYPE_GRABBER, IVTV_V4L2_ENC_PCM_OFFSET,
PCI_DMA_FROMDEVICE, 0, V4L2_BUF_TYPE_PRIVATE,
+ V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
ivtv_v4l2_enc_fops
},
{ /* IVTV_ENC_STREAM_TYPE_RAD */
encoder radio,
VFL_TYPE_RADIO, 0,
PCI_DMA_NONE, 1, V4L2_BUF_TYPE_PRIVATE,
+ V4L2_CAP_RADIO | V4L2_CAP_TUNER,
ivtv_v4l2_enc_fops
},
{ /* IVTV_DEC_STREAM_TYPE_MPG */
decoder MPG,
VFL_TYPE_GRABBER, IVTV_V4L2_DEC_MPG_OFFSET,
PCI_DMA_TODEVICE, 0, V4L2_BUF_TYPE_VIDEO_OUTPUT,
+ V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
ivtv_v4l2_dec_fops
},
{ /* IVTV_DEC_STREAM_TYPE_VBI */
decoder VBI,
VFL_TYPE_VBI, IVTV_V4L2_DEC_VBI_OFFSET,
PCI_DMA_NONE, 1, V4L2_BUF_TYPE_VBI_CAPTURE,
+ V4L2_CAP_SLICED_VBI_CAPTURE | V4L2_CAP_READWRITE,
ivtv_v4l2_enc_fops
},
{ /* IVTV_DEC_STREAM_TYPE_VOUT */
decoder VOUT,
VFL_TYPE_VBI, IVTV_V4L2_DEC_VOUT_OFFSET,
PCI_DMA_NONE, 1, V4L2_BUF_TYPE_VBI_OUTPUT,
+ V4L2_CAP_SLICED_VBI_OUTPUT | V4L2_CAP_AUDIO |
V4L2_CAP_READWRITE,
ivtv_v4l2_dec_fops
},
{ /*
[RFCv3 PATCH 1/3] V4L2: Add per-device-node capabilities
From: Hans Verkuil hans.verk...@cisco.com If V4L2_CAP_DEVICE_CAPS is set, then the new device_caps field is filled with the capabilities of the opened device node. The capabilities field traditionally contains the capabilities of the physical device, being a superset of all capabilities available at the several device nodes. E.g., if you open /dev/video0, then if it contains VBI caps then that means that there is a corresponding vbi node as well. And the capabilities field of both the video and vbi nodes should contain identical caps. However, it would be very useful to also have a capabilities field that contains just the caps for the currently open device, hence the new CAP bit and field. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/compat.xml |9 + Documentation/DocBook/media/v4l/v4l2.xml |9 - .../DocBook/media/v4l/vidioc-querycap.xml | 36 ++-- drivers/media/video/cx231xx/cx231xx-417.c |1 - drivers/media/video/pvrusb2/pvrusb2-v4l2.c |1 - drivers/media/video/v4l2-ioctl.c |6 ++- include/linux/videodev2.h | 29 +++- 7 files changed, 74 insertions(+), 17 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 8b44a43..d122a3e 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2378,6 +2378,15 @@ that used it. It was originally scheduled for removal in 2.6.35. /listitem /orderedlist /section +section + titleV4L2 in Linux 3.3/title + orderedlist +listitem + paraAdded the device_caps field to struct v4l2_capabilities and added the new + V4L2_CAP_DEVICE_CAPS capability./para +/listitem + /orderedlist +/section section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..6b6e584 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.3/revnumber + date2011-11-22/date + authorinitialshv/authorinitials + revremarkAdded device_caps field to struct v4l2_capabilities./revremark + /revision + + revision revnumber3.2/revnumber date2011-08-26/date authorinitialshv/authorinitials @@ -417,7 +424,7 @@ and discussions on the V4L mailing list./revremark /partinfo titleVideo for Linux Two API Specification/title - subtitleRevision 3.2/subtitle + subtitleRevision 3.3/subtitle chapter id=common sub-common; diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index e3664d6..4643505 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -124,12 +124,35 @@ printf (Version: %u.%u.%u\n, row entry__u32/entry entrystructfieldcapabilities/structfield/entry - entryDevice capabilities, see xref - linkend=device-capabilities /./entry + entryAvailable capabilities of the physical device as a whole, see xref + linkend=device-capabilities /. The same physical device can export + multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and /dev/radioZ). + The structfieldcapabilities/structfield field should contain a union + of all capabilities available around the several V4L2 devices exported + to userspace. + For all those devices the structfieldcapabilities/structfield field + returns the same set of capabilities. This allows applications to open + just one of the devices (typically the video device) and discover whether + video, vbi and/or radio are also supported. + /entry /row row entry__u32/entry - entrystructfieldreserved/structfield[4]/entry + entrystructfielddevice_caps/structfield/entry + entryDevice capabilities of the opened device, see xref + linkend=device-capabilities /. Should contain the available capabilities + of that specific device node. So, for example, structfielddevice_caps/structfield + of a radio device will only contain radio related capabilities and + no video or vbi capabilities. This field is only set if the structfieldcapabilities/structfield + field contains the constantV4L2_CAP_DEVICE_CAPS/constant capability. + Only the
v4l: How bridge driver get subdev std?
Hi Hans and Guennadi, I'm wondering how does bridge driver get subdev std (not query)? My case is that bridge needs to get subdev default std. Regards, Scott -- 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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi Michael, On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, On 12/15/2011 08:14 AM, James wrote: Hi all, I'm using an OMAP3530 board and a monochrome 12-bit grey sensor. Can anyone enlighten me why is the 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output? There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only the VP (video port) truncates data to 10 bits, and it does that because the subdevs it feeds can only handle 10 bits max. Thank you for the clarification. I need to read the entire RAW 12-bit grey value from the CCDC to memory and the data does not pass through other OMAP3ISP sub-devices. I intend to use Laurent's yavta to capture the data to file to verify its operation for the moment. Can this 12-bit (Y12) raw capture be done? Yes. If you are writing the 12-bit gray value directly into memory, you will use SOURCE_OF and can write the full 12-bits into memory. You need to set up your media pipeline to do sensor-CCDC-OMAP3 ISP CCDC output. Is there further modification needed to apply to the OMAP3ISP to achieve this? Do you have an application to test the pipeline for this setting to simple display? Many thanks in adv. -- Regards, James -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] OMAP 3 ISP driver improvements
Hi all, This patchset removes two of the three callbacks in the OMAP 3 ISP driver's board code. It is dependent on first and third patch in the [RFC] On controlling sensors patchset: URL:http://www.spinics.net/lists/linux-media/msg40861.html What will be left is the external clock, which should be moved to use the generic clock framework in the future. The dependency indeed is the generic clock framework --- on OMAP 3 the clock is provided by the ISP, so accessing it through the clock framework isn't possible at the moment. Once we have that, the ISP should register the xclk to the clock framework and the sensor driver would use if from there. Then I see no issues in moving to the device tree. Also, controlling the CSI-2 receiver in the OMAP 3630 properly is now possible with this patchset. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
On 15-12-2011 07:33, Hans Verkuil wrote:
On Thursday, December 15, 2011 10:21:41 Mauro Carvalho Chehab wrote:
On 15-12-2011 04:34, Dan Carpenter wrote:
On a 32bit system the multiplication here could overflow. p-count is
used in some of the V4L drivers.
ULONG_MAX / sizeof(v4l2_ext_control) is too much. This ioctl is used on
things
like setting MPEG paramenters, where several parameters need adjustments at
the same time. I risk to say that 64 is probably a reasonably safe upper
limit.
Let's make it 1024. That gives more than enough room for expansion without
taking
too much memory.
Especially for video encoders a lot of controls are needed, and sensor drivers
are also getting more complex, so 64 is a bit too low for my taste.
I agree that limiting this to some sensible value is a good idea.
I'm fine with 1024. Yet, this could easily be changed to whatever upper value
needed,
and still be backward compatible.
Btw, the upstream code also seems to have the same issue:
static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
void * __user *user_ptr, void ***kernel_ptr)
{
...
if (ctrls-count != 0) {
...
*array_size = sizeof(struct v4l2_ext_control)
* ctrls-count;
ret = 1;
...
}
long
video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
v4l2_kioctl func)
{
...
err = check_array_args(cmd, parg, array_size, user_ptr,
kernel_ptr);
if (err 0)
goto out;
has_array_args = err;
if (has_array_args) {
mbuf = kmalloc(array_size, GFP_KERNEL);
...
so, if is there any overflow at check_array_args(), instead of returning
an error to userspace, it will allocate the array with less space than
needed.
On both upstream and longterm, I think that it is more reasonable to
state a limit for the maximum number of controls that can be passed at
the same time, and live with that.
A dummy check says:
$ more include/linux/videodev2.h |grep V4L2_CID|wc -l
209
So, an upper limit of 256 is enough to allow userspace to change all
existing controls
at the same time.
I would like to have this set to at least twice the number of existing
controls
(which 1024 certainly is).
It is possible (and valid) to have the same control any number of times in the
control list. The last one will 'win' in that case. I can think of (admittedly
contrived) scenarios where that might be useful. The only thing we want to do
here is to add a sanity check against insane count values.
The proper way seems to add a define at include/linux/videodev2.h
and enforce it at the usercopy code.
I agree.
Regards,
Hans
Regards,
Mauro
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a patch against the 2.6.32-longterm kernel. In the stock
kernel, this code was totally rewritten and fixed in 2010 by d14e6d76ebf
[media] v4l: Add multi-planar ioctl handling code.
Hopefully, someone can Ack this and we merge it into the stable tree.
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 265bfb5..7196303 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -414,6 +414,9 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
@@ -1912,6 +1915,9 @@ long video_ioctl2(struct file *file,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count ULONG_MAX / sizeof(struct
v4l2_ext_control))
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the
[RFC 1/4] omap3isp: Implement validate_pipeline
Validate pipeline of any external entity connected to the ISP driver.
The validation of the pipeline for the part that involves links inside the
domain of another driver must be done by that very driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index f229057..17bc03c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -355,6 +355,18 @@ static int isp_video_validate_pipeline(struct isp_pipeline
*pipe)
fmt_source.format.height != fmt_sink.format.height)
return -EPIPE;
+ if (subdev-host_priv) {
+ /*
+* host_priv != NULL: this is a sensor. Issue
+* validate_pipeline. We're at our end of the
+* pipeline so we quit now.
+*/
+ ret = v4l2_subdev_call(subdev, pad, validate_pipeline);
+ if (IS_ERR_VALUE(ret))
+ return -EPIPE;
+ break;
+ }
+
if (shifter_link) {
unsigned int parallel_shift = 0;
if (isp-isp_ccdc.input == CCDC_INPUT_PARALLEL) {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/4] omap3isp: Use pixel clock from sensor media bus frameformat
Configure the ISP based on the pixel clock in media bus frame format.
Previously the same was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c |3 +--
drivers/media/video/omap3isp/isp.h |3 ++-
drivers/media/video/omap3isp/ispvideo.c |3 +++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index b818cac..c9bed37 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -344,7 +344,7 @@ void omap3isp_configure_bridge(struct isp_device *isp,
* Set the average pixel clock required by the sensor. The ISP will use the
* lowest possible memory bandwidth settings compatible with the clock.
**/
-static void isp_set_pixel_clock(struct isp_device *isp, unsigned int pixelclk)
+void omap3isp_set_pixel_clock(struct isp_device *isp, unsigned int pixelclk)
{
isp-isp_ccdc.vpcfg.pixelclk = pixelclk;
}
@@ -2072,7 +2072,6 @@ static int isp_probe(struct platform_device *pdev)
isp-autoidle = autoidle;
isp-platform_cb.set_xclk = isp_set_xclk;
- isp-platform_cb.set_pixel_clock = isp_set_pixel_clock;
mutex_init(isp-isp_mutex);
spin_lock_init(isp-stat_lock);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index c5935ae..dd7b303 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,7 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
/*
@@ -219,6 +218,8 @@ struct isp_device {
#define v4l2_dev_to_isp_device(dev) \
container_of(dev, struct isp_device, v4l2_dev)
+void omap3isp_set_pixel_clock(struct isp_device *isp, unsigned int pixelclk);
+
void omap3isp_hist_dma_done(struct isp_device *isp);
void omap3isp_flush(struct isp_device *isp);
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index cdcf1d0..64f29ac 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -372,6 +372,9 @@ static int isp_video_validate_pipeline(struct isp_pipeline
*pipe)
if (IS_ERR_VALUE(ret))
return -EPIPE;
}
+ omap3isp_set_pixel_clock(isp,
+fmt_source.format.pixel_clock
+* 1000);
}
if (subdev-host_priv) {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] omap3isp: Add lane configuration to platform data
Add lane configuration (order of clock and data lane) to platform data on
both CCP2 and CSI-2.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispcsiphy.h | 15 ++-
include/media/omap3isp.h | 15 +++
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
b/drivers/media/video/omap3isp/ispcsiphy.h
index 9596dc6..e93a661 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.h
+++ b/drivers/media/video/omap3isp/ispcsiphy.h
@@ -27,22 +27,11 @@
#ifndef OMAP3_ISP_CSI_PHY_H
#define OMAP3_ISP_CSI_PHY_H
+#include media/omap3isp.h
+
struct isp_csi2_device;
struct regulator;
-struct csiphy_lane {
- u8 pos;
- u8 pol;
-};
-
-#define ISP_CSIPHY2_NUM_DATA_LANES 2
-#define ISP_CSIPHY1_NUM_DATA_LANES 1
-
-struct isp_csiphy_lanes_cfg {
- struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
- struct csiphy_lane clk;
-};
-
struct isp_csiphy_dphy_cfg {
u8 ths_term;
u8 ths_settle;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index e917b1d..8fe0bdf 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -86,6 +86,19 @@ enum {
ISP_CCP2_MODE_CCP2 = 1,
};
+struct csiphy_lane {
+ u8 pos;
+ u8 pol;
+};
+
+#define ISP_CSIPHY2_NUM_DATA_LANES 2
+#define ISP_CSIPHY1_NUM_DATA_LANES 1
+
+struct isp_csiphy_lanes_cfg {
+ struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
+ struct csiphy_lane clk;
+};
+
/**
* struct isp_ccp2_platform_data - CCP2 interface platform data
* @strobe_clk_pol: Strobe/clock polarity
@@ -105,6 +118,7 @@ struct isp_ccp2_platform_data {
unsigned int ccp2_mode:1;
unsigned int phy_layer:1;
unsigned int vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
};
/**
@@ -115,6 +129,7 @@ struct isp_ccp2_platform_data {
struct isp_csi2_platform_data {
unsigned crc:1;
unsigned vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
};
struct isp_subdev_i2c_board_info {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/4] omap3isp: Configure CSI-2 phy based on platform data
Configure CSI-2 phy based on platform data in the ISP driver rather than in
platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.h |3 -
drivers/media/video/omap3isp/ispcsiphy.c | 95 ++---
drivers/media/video/omap3isp/ispcsiphy.h |4 +
drivers/media/video/omap3isp/ispvideo.c | 19 ++
4 files changed, 108 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 705946e..c5935ae 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,9 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c
index 5be37ce..52af308 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,90 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * THS_TERM: Programmed value = ceil(12.5 ns/DDRClk period) - 1.
+ * THS_SETTLE: Programmed value = ceil(90 ns/DDRClk period) + 3.
+ */
+#define THS_TERM_D 200
+#define THS_TERM(ddrclk_khz) \
+( \
+ ((25 * (ddrclk_khz)) % THS_TERM_D) ?\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) :\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) - 1 \
+)
+
+#define THS_SETTLE_D 100
+#define THS_SETTLE(ddrclk_khz) \
+( \
+ ((90 * (ddrclk_khz)) % THS_SETTLE_D) ? \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 4 : \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 3\
+)
+
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev,
+ struct v4l2_subdev *sensor,
+ struct v4l2_mbus_framefmt *sensor_fmt)
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 cam_phy_ctrl;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ if (!lanes) {
+ dev_err(isp-dev, no lane configuration\n);
+ return -EINVAL;
+ }
+
+ cam_phy_ctrl = omap_readl(
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ /*
+* SCM.CONTROL_CAMERA_PHY_CTRL
+* - bit[4]: CSIPHY1 data sent to CSIB
+* - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+* - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+*/
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
+ cam_phy_ctrl |= 1 2;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
+ cam_phy_ctrl = 1 2;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ cam_phy_ctrl |= 1;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
+ cam_phy_ctrl = 1;
+
+ omap_writel(cam_phy_ctrl,
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ csi2_ddrclk_khz = sensor_fmt-pixel_clock
+ / (2 * csi2-phy-num_data_lanes)
+ * omap3isp_video_format_info(sensor_fmt-code)-bpp;
+ csi2phy.ths_term = THS_TERM(csi2_ddrclk_khz);
+ csi2phy.ths_settle = THS_SETTLE(csi2_ddrclk_khz);
+ csi2phy.tclk_term = TCLK_TERM;
+ csi2phy.tclk_miss = TCLK_MISS;
+ csi2phy.tclk_settle = TCLK_SETTLE;
/* Clock and data
Re: Hauppauge HVR-930C problems
On 15-12-2011 06:04, Fredrik Lingvall wrote:
On 12/14/11 17:33, Mihai Dobrescu wrote:
Hello,
I need to make my tunner working too.
Did you make it work?
Where did you get the firmware (dvb-usb-hauppauge-hvr930c-drxk.fw)?
I have Sabayon 7 64 bit, which is sort of Gentoo, as I've seen you have.
Thank you.
Hi Mihai,
There is a perl script get_dvb_firmware that downloads the firmware and
extract it (from the Windows driver I think). You need a version of
get_dvb_firmware where this has been added:
+sub drxk_hauppauge_hvr930c {
+my $url = http://www.wintvcd.co.uk/drivers/;;
+my $zipfile = HVR-9x0_5_10_325_28153_SIGNED.zip;
+my $hash = 83ab82e7e9480ec8bf1ae0155ca63c88;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
+my $drvfile = HVR-900/emOEM.sys;
+my $fwfile = dvb-usb-hauppauge-hvr930c-drxk.fw;
+
+checkstandard();
+
+wgetfile($zipfile, $url . $zipfile);
+verify($zipfile, $hash);
+unzip($zipfile, $tmpdir);
+extract($tmpdir/$drvfile, 0x117b0, 42692, $fwfile);
+
+$fwfile
+}
+
Do a git checkout of the linux-media tree to get it (I think).
Also, before I found the perl script I did it manually using:
1)
wget http://www.wintvcd.co.uk/drivers/HVR-9x0_5_10_325_28153_SIGNED.zip
2) unzip it
3) extact it with dd [0x117b (hex) = 71600 (dec)]:
dd if=HVR-900/emOEM.sys of=dvb-usb-hauppauge-hvr930c-drxk.fw bs=1 skip=71600
count=42692
This is basically what the script does, with one difference:
it will double check if the extracted binary blob is really a firmware,
by comparing it with a known hash value. This way, if the driver there gots
updated, the script will fail, instead of writing some random values to a
.fw file.
4) copy it to the firmware dir
cp dvb-usb-hauppauge-hvr930c-drxk.fw /lib/firmware/'
HTH
/Fredrik
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l: How bridge driver get subdev std?
On Thursday, December 15, 2011 10:48:39 Scott Jiang wrote: Hi Hans and Guennadi, I'm wondering how does bridge driver get subdev std (not query)? My case is that bridge needs to get subdev default std. It can just call the core g_std op. Note that g_std was added only recently (September 9th according to the git log), so if you work with an older kernel, then it may not be there yet. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: tvp5150: Add mbus_fmt callbacks.
On 15-12-2011 07:39, Javier Martin wrote:
These callbacks allow a host video driver
to poll video supported video formats of tvp5150.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/tvp5150.c | 72
+
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..8f01f08 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,75 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder-norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder-norm;
+
+ if ((std == V4L2_STD_NTSC) || (std == V4L2_STD_NTSC_443) ||
+ (std == V4L2_STD_PAL_M)) {
+ f-width = 720;
+ f-height = 480;
+ }
+ if ((std == V4L2_STD_PAL) ||
+ (std == (V4L2_STD_PAL_N | V4L2_STD_PAL_Nc)) ||
+ (std == V4L2_STD_SECAM)) {
+ f-width = 720;
+ f-height = 576;
+ }
The above is wrong, as std is a bitmask. So, userspace can pass more than
one bit set there. It should be, instead:
f-width = 720;
if (std V4L2_STD_525_60)
f-height = 480;
else
f-height = 576;
+ f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f-field = V4L2_FIELD_SEQ_TB;
+ f-colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, width = %d, height = %d\n, f-width,
+ f-height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +999,9 @@ static const struct v4l2_subdev_tuner_ops
tvp5150_tuner_ops = {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
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 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions
Hi, Guennadi
Would you acknowledge these two v3 patches and queue them for 3.3 merge
window? Thanks.
Best Regards,
Josh Wu
On Thursday, December 08, 2011 6:19 PM, Josh Wu wrote:
Signed-off-by: Josh Wu josh...@atmel.com
---
in v2 version, made the label name to be consistent
drivers/media/video/atmel-isi.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c
b/drivers/media/video/atmel-isi.c
index ea4eef4..91ebcfb 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_unprepare(isi-mck);
clk_put(isi-mck);
+ clk_unprepare(isi-pclk);
clk_put(isi-pclk);
kfree(isi);
@@ -955,6 +957,12 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
if (IS_ERR(pclk))
return PTR_ERR(pclk);
+ ret = clk_prepare(pclk);
+ if (ret) {
+ clk_put(pclk);
+ return ret;
+ }
+
isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
if (!isi) {
ret = -ENOMEM;
@@ -978,6 +986,10 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_clk_get;
}
+ ret = clk_prepare(isi-mck);
+ if (ret)
+ goto err_clk_prepare_mck;
+
/* Set ISI_MCK's frequency, it should be faster than pixel clock
*/
ret = clk_set_rate(isi-mck, pdata-mck_hz);
if (ret 0)
@@ -1059,10 +1071,13 @@ err_alloc_ctx:
isi-fb_descriptors_phys);
err_alloc_descriptors:
err_set_mck_rate:
+ clk_unprepare(isi-mck);
+err_clk_prepare_mck:
clk_put(isi-mck);
err_clk_get:
kfree(isi);
err_alloc_isi:
+ clk_unprepare(pclk);
clk_put(pclk);
return ret;
--
1.6.3.3
--
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: How bridge driver get subdev std?
2011/12/15 Hans Verkuil hverk...@xs4all.nl: On Thursday, December 15, 2011 10:48:39 Scott Jiang wrote: Hi Hans and Guennadi, I'm wondering how does bridge driver get subdev std (not query)? My case is that bridge needs to get subdev default std. It can just call the core g_std op. Note that g_std was added only recently (September 9th according to the git log), so if you work with an older kernel, then it may not be there yet. Thanks. I found it in latest kernel. Scott -- 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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi James, On 12/15/2011 10:49 AM, James wrote: Hi Michael, On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, On 12/15/2011 08:14 AM, James wrote: Hi all, I'm using an OMAP3530 board and a monochrome 12-bit grey sensor. Can anyone enlighten me why is the 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output? There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only the VP (video port) truncates data to 10 bits, and it does that because the subdevs it feeds can only handle 10 bits max. Thank you for the clarification. I need to read the entire RAW 12-bit grey value from the CCDC to memory and the data does not pass through other OMAP3ISP sub-devices. I intend to use Laurent's yavta to capture the data to file to verify its operation for the moment. Can this 12-bit (Y12) raw capture be done? Yes. If you are writing the 12-bit gray value directly into memory, you will use SOURCE_OF and can write the full 12-bits into memory. You need to set up your media pipeline to do sensor-CCDC-OMAP3 ISP CCDC output. Is there further modification needed to apply to the OMAP3ISP to achieve this? Do you have an application to test the pipeline for this setting to simple display? Let's establish where you're coming from. Are you familiar with the media controller? Laurent has a program 'media-ctl' to set up the pipeline (see http://git.ideasonboard.org/?p=media-ctl.git). You will find many examples of its usage in the archives of this mailing list. It will look something like: media-ctl -r media-ctl -l 'OMAP3 ISP CCDC:1 - OMAP3 ISP CCDC output:0 [1]' media-ctl -l 'your-sensor-name:0 - OMAP3 ISP CCDC:0 [1]' you will also need to set the formats through the pipeline with 'media-ctl --set-format'. After you use media-ctl to set up the pipeline, you can use yavta to capture the data from the CCDC output (for me, this is /dev/video2). -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
On 15-12-2011 07:39, Javier Martin wrote: In page 23 of the datasheet of this chip (SLES098A) it is stated that de default input for this chip is Composite AIP1A which is the same as COMPOSITE0 in the driver. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- drivers/media/video/tvp5150.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c index e927d25..26cc75b 100644 --- a/drivers/media/video/tvp5150.c +++ b/drivers/media/video/tvp5150.c @@ -993,7 +993,7 @@ static int tvp5150_probe(struct i2c_client *c, } core-norm = V4L2_STD_ALL; /* Default is autodetect */ - core-input = TVP5150_COMPOSITE1; + core-input = TVP5150_COMPOSITE0; core-enable = 1; v4l2_ctrl_handler_init(core-hdl, 4); Changing this could break em28xx that might be expecting it to be set to composite1. On a quick look, the code there seems to be doing the right thing: during the probe procedure, it explicitly calls s_routing, in order to initialize the device input to the first input type found at the cards structure. So, this patch is likely harmless. Yet, why do you need to change it? Any bridge driver that uses it should be doing the same: at initialization, it should set the input to a value that it is compatible with the way the device is wired, and not to assume a particular arrangement. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: tvp5150: Add mbus_fmt callbacks.
Hi Mauro, thank you for your review, I will prepare a new version with those fixes. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv5] v4l: Update subdev drivers to handle framesamples parameter
Update the sub-device drivers having a devnode enabled so they properly
handle the new framesamples field of struct v4l2_mbus_framefmt.
These drivers don't support compressed (entropy encoded) formats so the
framesamples field is simply initialized to 0, altogether with the
reserved field.
There is a few other drivers that expose a devnode (mt9p031, mt9t001,
mt9v032) but they already implicitly initialize the new data structure
field to 0, so they don't need to be touched.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v4:
- in the try format functions use local copies of only width, height, code
rather that caching whole struct v4l2_mbus_framefmt
Changes since v3:
- use local copy of the format data structure to clear all structure
members which are unused by a driver, in way that it don't break
after new fields are added to struct v4l2_mbus_framefmt;
The omap3isp changes are only compile tested. Thus I'd like to ask someone
who has access to the hardware to test the patch and provide Ack or
Tested-by :)
Thanks,
Sylwester
---
drivers/media/video/noon010pc30.c |3 +++
drivers/media/video/omap3isp/ispccdc.c|8 ++--
drivers/media/video/omap3isp/ispccp2.c| 16 +++-
drivers/media/video/omap3isp/ispcsi2.c| 14 +-
drivers/media/video/omap3isp/isppreview.c | 15 ++-
drivers/media/video/omap3isp/ispresizer.c |3 +++
drivers/media/video/s5k6aa.c |2 ++
7 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 50838bf..9a6a7ac 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -519,6 +519,7 @@ static int noon010_get_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
mf = fmt-format;
mutex_lock(info-lock);
+ memset(mf, 0, sizeof(mf));
mf-width = info-curr_win-width;
mf-height = info-curr_win-height;
mf-code = info-curr_fmt-code;
@@ -546,12 +547,14 @@ static const struct noon010_format
*noon010_try_fmt(struct v4l2_subdev *sd,
static int noon010_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_format *fmt)
{
+ const int offset = offsetof(struct v4l2_mbus_framefmt, framesamples);
struct noon010_info *info = to_noon010(sd);
const struct noon010_frmsize *size = NULL;
const struct noon010_format *nf;
struct v4l2_mbus_framefmt *mf;
int ret = 0;
+ memset(fmt-format + offset, 0, sizeof(fmt-format) - offset);
nf = noon010_try_fmt(sd, fmt-format);
noon010_try_frame_size(fmt-format, size);
fmt-format.colorspace = V4L2_COLORSPACE_JPEG;
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index b0b0fa5..9e12548 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1802,6 +1802,7 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
unsigned int pad, struct v4l2_mbus_framefmt *fmt,
enum v4l2_subdev_format_whence which)
{
+ enum v4l2_mbus_pixelcode pixelcode = fmt-code;
struct v4l2_mbus_framefmt *format;
const struct isp_format_info *info;
unsigned int width = fmt-width;
@@ -1810,21 +1811,24 @@ ccdc_try_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
switch (pad) {
case CCDC_PAD_SINK:
+ memset(fmt, 0, sizeof(*fmt));
+
/* TODO: If the CCDC output formatter pad is connected directly
* to the resizer, only YUV formats can be used.
*/
for (i = 0; i ARRAY_SIZE(ccdc_fmts); i++) {
- if (fmt-code == ccdc_fmts[i])
+ if (pixelcode == ccdc_fmts[i])
break;
}
/* If not found, use SGRBG10 as default */
if (i = ARRAY_SIZE(ccdc_fmts))
- fmt-code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ pixelcode = V4L2_MBUS_FMT_SGRBG10_1X10;
/* Clamp the input size. */
fmt-width = clamp_t(u32, width, 32, 4096);
fmt-height = clamp_t(u32, height, 32, 4096);
+ fmt-code = pixelcode;
break;
case CCDC_PAD_SOURCE_OF:
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c
index 904ca8c..864b220 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -673,25 +673,31 @@ static void ccp2_try_format(struct isp_ccp2_device *ccp2,
struct v4l2_mbus_framefmt *fmt,
enum v4l2_subdev_format_whence which)
{
+
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
On 12/14/11 20:14, mar...@neutronstar.dyndns.org wrote:
On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
Hi Martin,
On 12/14/11 03:25, Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-omap3evm-camera.c | 155
+++
arch/arm/mach-omap2/board-omap3evm.c|4 +
3 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V3
* Added missing copyright and attribution.
* switched to gpio_request_array for gpio init.
* removed device_initcall and added call to omap3_evm_camera_init into
omap3_evm_init
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
[...]
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
I don't really care about that, but I don't see any mux
being set in the above function so the name and comments
are misleading.
There's are video muxes on this board that's controlled by various
gpios. It's not a mux in the omap chip if you've expected to see that.
As this is an evaluation board it has a bunch of video connectors that
the user can choose from for different input devices.
I see... Probably a comment explaining that would not hurt here.
[...]
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ ret = gpio_request_array(setup_gpios, ARRAY_SIZE(setup_gpios));
+ if (ret 0) {
+ pr_err(omap3evm-camera: Failed to setup camera signal
routing.\n);
+ return ret;
+ }
It looks like both above calls (gpio_request and mux_init)
can be moved to omap3evm_set_mux() function (or a renamed version of it),
so all the GPIO stuff will be close to each other instead of requesting
in one place and playing with values in another...
I'd like to keep the one time setup and the theoretically run time switchable
parts seperate. It doesn't complicate the code and if a brave soul wants to
connect different camera modules and switch between them it's a more
reviewable
patch from here.
Ok
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
So the plan is to add support for the 3 types,
but hard code to only one?
Can't this be runtime detected somehow?
The mux code came from out of tree drivers. I did want to keep enough
information so someone extending this board code for other setups doesn't
have a
hard time. I can't think of an reliable way to runtime detect what video
source
a specific use case would want. Ideally someone who needs one of the other
video sources should add a more generic solution here.
I'm Ok with it, but usually, stuff that is never used stays out...
I think the way it should be is to have a platform driver that uses
a callback to switch between the muxes on the extension.
[...]
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/4] omap3isp: Implement validate_pipeline
Hi Sakari,
Thanks for the patch.
On Thursday 15 December 2011 10:50:32 Sakari Ailus wrote:
Validate pipeline of any external entity connected to the ISP driver.
The validation of the pipeline for the part that involves links inside the
domain of another driver must be done by that very driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index f229057..17bc03c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -355,6 +355,18 @@ static int isp_video_validate_pipeline(struct
isp_pipeline *pipe) fmt_source.format.height != fmt_sink.format.height)
return -EPIPE;
+ if (subdev-host_priv) {
+ /*
+ * host_priv != NULL: this is a sensor. Issue
+ * validate_pipeline. We're at our end of the
+ * pipeline so we quit now.
+ */
+ ret = v4l2_subdev_call(subdev, pad, validate_pipeline);
+ if (IS_ERR_VALUE(ret))
Is the validate pipeline operation expected to return a value different than 0
on success ? If not if (ret 0) should do.
Although there's another issue. Not all sensors will implement the
validate_pipeline operation, so you shouldn't return an error if ret == -
ENOIOCTLCMD.
I will comment on the validate_pipeline approach itself in the On controlling
sensors mail thread.
+ return -EPIPE;
+ break;
+ }
+
if (shifter_link) {
unsigned int parallel_shift = 0;
if (isp-isp_ccdc.input == CCDC_INPUT_PARALLEL) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
Changing this could break em28xx that might be expecting it to be set to composite1. On a quick look, the code there seems to be doing the right thing: during the probe procedure, it explicitly calls s_routing, in order to initialize the device input to the first input type found at the cards structure. So, this patch is likely harmless. Yet, why do you need to change it? Any bridge driver that uses it should be doing the same: at initialization, it should set the input to a value that it is compatible with the way the device is wired, and not to assume a particular arrangement. What I'm trying to do with these patches and my previous one related to mx2_camera, is to be able to use mx2_camera host driver with tvp5150 video decoder. I'm not sure how mx2_camera could be aware that the sensor or decoder attached to it needs s_routing function to be called with a certain parameter without making it too board specific. The only solution I could think of was assuming that if s_routing function was not called at all, the enabled input in tvp5150 would be the default COMPOSITE0 as it is specified in the datasheet. However, If you or anyone suggests a cleaner approach I'm totally open. But still, changing default value of the selected input in tvp5150 probe function is a bit dirty IMHO. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
Thanks for the patch.
On Thursday 15 December 2011 10:50:34 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver rather than in
platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.h |3 -
drivers/media/video/omap3isp/ispcsiphy.c | 95
++--- drivers/media/video/omap3isp/ispcsiphy.h |
4 +
drivers/media/video/omap3isp/ispvideo.c | 19 ++
4 files changed, 108 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h index 705946e..c5935ae 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,9 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes);
void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..52af308 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,90 @@ static void csiphy_dphy_config(struct isp_csiphy
*phy) isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * THS_TERM: Programmed value = ceil(12.5 ns/DDRClk period) - 1.
+ * THS_SETTLE: Programmed value = ceil(90 ns/DDRClk period) + 3.
+ */
+#define THS_TERM_D 200
+#define THS_TERM(ddrclk_khz) \
+(\
+ ((25 * (ddrclk_khz)) % THS_TERM_D) ?\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) :\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) - 1 \
+)
+
+#define THS_SETTLE_D 100
+#define THS_SETTLE(ddrclk_khz) \
+(\
+ ((90 * (ddrclk_khz)) % THS_SETTLE_D) ? \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 4 : \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 3\
+)
The THS_TERM and THS_SETTLE macros are only used once. I would just put that
code explictly where it gets used. The macros hinder readability.
+
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM0
+#define TCLK_MISS1
+#define TCLK_SETTLE 14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+struct v4l2_subdev *csi2_subdev,
+struct v4l2_subdev *sensor,
+struct v4l2_mbus_framefmt *sensor_fmt)
The number of lanes can depend on the format. Wouldn't it be better to add a
subdev operation to query the sensor for its bus configuration instead of
relying on ISP platform data ?
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 cam_phy_ctrl;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ if (!lanes) {
+ dev_err(isp-dev, no lane configuration\n);
+ return -EINVAL;
+ }
+
+ cam_phy_ctrl = omap_readl(
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4]: CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
+ cam_phy_ctrl |= 1 2;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
+ cam_phy_ctrl = 1 2;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ cam_phy_ctrl |= 1;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
+ cam_phy_ctrl = 1;
+
+ omap_writel(cam_phy_ctrl,
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+
Re: [RFC 4/4] omap3isp: Use pixel clock from sensor media bus frameformat
Hi Sakari,
Thanks for the patch.
On Thursday 15 December 2011 10:50:35 Sakari Ailus wrote:
Configure the ISP based on the pixel clock in media bus frame format.
Previously the same was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c |3 +--
drivers/media/video/omap3isp/isp.h |3 ++-
drivers/media/video/omap3isp/ispvideo.c |3 +++
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c index b818cac..c9bed37 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -344,7 +344,7 @@ void omap3isp_configure_bridge(struct isp_device *isp,
* Set the average pixel clock required by the sensor. The ISP will use
the * lowest possible memory bandwidth settings compatible with the clock.
**/
-static void isp_set_pixel_clock(struct isp_device *isp, unsigned int
pixelclk) +void omap3isp_set_pixel_clock(struct isp_device *isp, unsigned
int pixelclk) {
isp-isp_ccdc.vpcfg.pixelclk = pixelclk;
}
@@ -2072,7 +2072,6 @@ static int isp_probe(struct platform_device *pdev)
isp-autoidle = autoidle;
isp-platform_cb.set_xclk = isp_set_xclk;
- isp-platform_cb.set_pixel_clock = isp_set_pixel_clock;
mutex_init(isp-isp_mutex);
spin_lock_init(isp-stat_lock);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h index c5935ae..dd7b303 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,7 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
/*
@@ -219,6 +218,8 @@ struct isp_device {
#define v4l2_dev_to_isp_device(dev) \
container_of(dev, struct isp_device, v4l2_dev)
+void omap3isp_set_pixel_clock(struct isp_device *isp, unsigned int
pixelclk); +
void omap3isp_hist_dma_done(struct isp_device *isp);
void omap3isp_flush(struct isp_device *isp);
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index cdcf1d0..64f29ac 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -372,6 +372,9 @@ static int isp_video_validate_pipeline(struct
isp_pipeline *pipe) if (IS_ERR_VALUE(ret))
return -EPIPE;
}
+ omap3isp_set_pixel_clock(isp,
+ fmt_source.format.pixel_clock
+ * 1000);
Similarly to 3/4, I think this belongs to isp_pipeline_enable(), or even
possibly the subdev s_stream operation (same for 3/4 actually).
}
if (subdev-host_priv) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.3] Media, OMAP3 ISP AS3645A
Hi Mauro, On Tuesday 13 December 2011 02:43:27 Laurent Pinchart wrote: Hi Mauro, The following changes since commit bcc072756e4467dc30e502a311b1c3adec96a0e4: [media] STV0900: Query DVB frontend delivery capabilities (2011-12-12 15:04:34 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-omap3isp-next There was an issue with comments in patch omap3isp: Mark next captured frame as faulty when an SBL overflow occurs. I've updated my branch, could you please get the new patches if you've already pulled ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problems with mythtv and pvr-350
changing channel stopped working ages ago (5-6 months). i assumed that it was a bug in myth. now i am wondering. as far as i can see, mytht pauses the device when changing channel. but somewhere along the way it chokes when unpausing (poll errors). i notice that hans made some changes in this area back in september. has anyone updated the myth code to support the new ioctls? running myth master and media_build for the drivers. any help gratefully received. -- simon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
On 15-12-2011 08:24, javier Martin wrote: Changing this could break em28xx that might be expecting it to be set to composite1. On a quick look, the code there seems to be doing the right thing: during the probe procedure, it explicitly calls s_routing, in order to initialize the device input to the first input type found at the cards structure. So, this patch is likely harmless. Yet, why do you need to change it? Any bridge driver that uses it should be doing the same: at initialization, it should set the input to a value that it is compatible with the way the device is wired, and not to assume a particular arrangement. What I'm trying to do with these patches and my previous one related to mx2_camera, is to be able to use mx2_camera host driver with tvp5150 video decoder. I'm not sure how mx2_camera could be aware that the sensor or decoder attached to it needs s_routing function to be called with a certain parameter without making it too board specific. The only solution I could think of was assuming that if s_routing function was not called at all, the enabled input in tvp5150 would be the default COMPOSITE0 as it is specified in the datasheet. However, If you or anyone suggests a cleaner approach I'm totally open. But still, changing default value of the selected input in tvp5150 probe function is a bit dirty IMHO. Board-specific information is needed anyway, if someone wants to use any driver. It doesn't matter if the pipelines are set via libv4l, via direct calls or whatever. On em28xx, the board-specific info is stored in Kernel. It would be possible to put that info on userspace, but that would require some code at libv4l. The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to tvp5150, in order to set the pipelines there. The libv4l plugin also needs to know about that. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] omap3isp: Configure CSI-2 phy based on platform data
Hi Laurent,
Thanks for the review!
On Thu, Dec 15, 2011 at 11:28:06AM +0100, Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
On Thursday 15 December 2011 10:50:34 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver rather than in
platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.h |3 -
drivers/media/video/omap3isp/ispcsiphy.c | 95
++--- drivers/media/video/omap3isp/ispcsiphy.h |
4 +
drivers/media/video/omap3isp/ispvideo.c | 19 ++
4 files changed, 108 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h index 705946e..c5935ae 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,9 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..52af308 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,90 @@ static void csiphy_dphy_config(struct isp_csiphy
*phy) isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * THS_TERM: Programmed value = ceil(12.5 ns/DDRClk period) - 1.
+ * THS_SETTLE: Programmed value = ceil(90 ns/DDRClk period) + 3.
+ */
+#define THS_TERM_D 200
+#define THS_TERM(ddrclk_khz) \
+( \
+ ((25 * (ddrclk_khz)) % THS_TERM_D) ?\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) :\
+ ((25 * (ddrclk_khz)) / THS_TERM_D) - 1 \
+)
+
+#define THS_SETTLE_D 100
+#define THS_SETTLE(ddrclk_khz) \
+( \
+ ((90 * (ddrclk_khz)) % THS_SETTLE_D) ? \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 4 : \
+ ((90 * (ddrclk_khz)) / THS_SETTLE_D) + 3\
+)
The THS_TERM and THS_SETTLE macros are only used once. I would just put that
code explictly where it gets used. The macros hinder readability.
I'll do that.
+
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev,
+ struct v4l2_subdev *sensor,
+ struct v4l2_mbus_framefmt *sensor_fmt)
The number of lanes can depend on the format. Wouldn't it be better to add a
subdev operation to query the sensor for its bus configuration instead of
relying on ISP platform data ?
In principle, yes. That's an interesting point; how this kind of information
would best be delivered?
On the other hand I don't see any pressing reason to use less lanes than the
maximum, so this could wait IMHO.
Perhaps around the time we standardise how the CSI-2 configuration is being
done? It's not quite as simple as the mbus_config seems to assume. For
example, the lane mapping and then which lanes do you use if you're using
less than the maximum has to be handled in a way or another.
The number of lanes might be something the user would want to touch, but I'm
not entirely sure. You achieve more functionality by providing that
flexibility to the user but I don't see need for configuring that --- still
getting the number of lanes could be interesting.
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 cam_phy_ctrl;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ if (!lanes) {
+
Re: [RFC 1/4] omap3isp: Implement validate_pipeline
Hi Laurent,
Thanks for the review!!!
On Thu, Dec 15, 2011 at 11:18:53AM +0100, Laurent Pinchart wrote:
Hi Sakari,
Thanks for the patch.
On Thursday 15 December 2011 10:50:32 Sakari Ailus wrote:
Validate pipeline of any external entity connected to the ISP driver.
The validation of the pipeline for the part that involves links inside the
domain of another driver must be done by that very driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index f229057..17bc03c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -355,6 +355,18 @@ static int isp_video_validate_pipeline(struct
isp_pipeline *pipe) fmt_source.format.height != fmt_sink.format.height)
return -EPIPE;
+ if (subdev-host_priv) {
+ /*
+* host_priv != NULL: this is a sensor. Issue
+* validate_pipeline. We're at our end of the
+* pipeline so we quit now.
+*/
+ ret = v4l2_subdev_call(subdev, pad, validate_pipeline);
+ if (IS_ERR_VALUE(ret))
Is the validate pipeline operation expected to return a value different than
0
on success ? If not if (ret 0) should do.
Although there's another issue. Not all sensors will implement the
validate_pipeline operation, so you shouldn't return an error if ret == -
ENOIOCTLCMD.
I will comment on the validate_pipeline approach itself in the On
controlling
sensors mail thread.
Good point. I'll fix this; same for your comment on the third patch.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to tvp5150, in order to set the pipelines there. This sounds like a sensible solution I will work on that soon. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin, On Wednesday 14 December 2011 19:22:29 mar...@neutronstar.dyndns.org wrote: On Wed, Dec 14, 2011 at 02:15:22PM +0100, Laurent Pinchart wrote: On Wednesday 14 December 2011 10:31:35 Igor Grinberg wrote: On 12/14/11 03:25, Martin Hostettler wrote: Adds board support for an MT9M032 based camera to omap3evm. Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org [snip] diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 index 000..bffd5b8 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c @@ -0,0 +1,155 @@ [snip] +#include linux/i2c.h +#include linux/init.h +#include linux/platform_device.h + +#include linux/gpio.h +#include plat/mux.h +#include mux.h + +#include ../../../drivers/media/video/omap3isp/isp.h Laurent, In one of the previous reviews, you stated: I'll probably split it and move the part required by board files to include/media/omap3isp.h. Is there any progress on that? Yes, it has been half-fixed in mainline. Half only because all the structures and macros that should be used by board code are now in media/omap3isp.h, but some boards need to access OMAP3 ISP internals from board code, which still requires drivers/media/video/omap3isp/isp.h. This will eventually be fixed, when the generic struct clk object will be available. After a quick look at this patch it seems that media/omap3isp.h should be enough here. Almost. The code uses ISPCTRL_PAR_BRIDGE_DISABLE which is only available from drivers/media/video/omap3isp/ispreg.h. So i'd say it's better to keep that include than to duplicate this constant in the code. What do you think? You should use ISP_BRIDGE_DISABLE instead. That one is defined in media/omap3isp.h By the way, it seems drivers/media/video/omap3isp/ispvideo.c is missing a #include linux/module.h at the moment. I had to patch that line in to get omap3isp to compile as module. http://patchwork.linuxtv.org/patch/8510/ The fix should get in v3.2. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 01/11] davinci: vpif: remove obsolete header file inclusion
remove inclusion of header files from vpif.h and vpif_dispaly.c and add appropriate header file for building. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: LMML linux-media@vger.kernel.org --- drivers/media/video/davinci/vpif.h |2 +- drivers/media/video/davinci/vpif_display.c |2 -- 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..c96268a 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -19,7 +19,7 @@ #include linux/io.h #include linux/videodev2.h #include mach/hardware.h -#include mach/dm646x.h +#include linux/i2c.h #include media/davinci/vpif_types.h /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include media/v4l2-ioctl.h #include media/v4l2-chip-ident.h -#include mach/dm646x.h - #include vpif_display.h #include vpif.h -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] add dm365 specific media formats
add mediabus formats and pixel formats suported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include - 1. ALAW compressed bayer. 2. UV interleaved without Y( for resizer) 3. NV12 Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 include/linux/v4l2-mediabus.h | 10 -- include/linux/videodev2.h |6 ++ 2 files changed, 14 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] v4l2: add new pixel formats supported on dm365
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0
16x16 macroblocks */
#define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0
2 lines y, 1 line uv interleaved */
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */
+
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */
#define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
@@ -366,6 +369,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG..
GBGB.. */
/* 10bit raw bayer DPCM compressed to 8 bits */
#define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+ /* 10bit raw bayer a-law compressed to 8 bits */
+#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
/*
* 10bit raw bayer, expanded to 16 bits
* rrgg ggbb...
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: add new mediabus format enums for dm365
add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code
to represent A-LAW compressed Bayer format. This corresponds to pixel
format - V4L2_PIX_FMT_SGRBG10ALAW8.
add UV8 and NV12 ( Y and C separate with UV interleaved) which are supported
on dm365.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..d408654 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2014 */
+ /* YUV (including grey) - next is 0x2016 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
@@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
+ V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
+ V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
- /* Bayer - next is 0x3015 */
+ /* Bayer - next is 0x3019 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
@@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+ V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
+ V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
+ V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
+ V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
On 15 December 2011 13:01, javier Martin javier.mar...@vista-silicon.com wrote: The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to tvp5150, in order to set the pipelines there. This sounds like a sensible solution I will work on that soon. Hi Mauro, regarding this subject it seems soc-camera assumes the attached sensor has only one input: input 0. This means I am not able to forward S_INPUT/S_ROUTING as you suggested: http://lxr.linux.no/#linux+v3.1.5/drivers/media/video/soc_camera.c#L213 This trick is clearly a loss of functionality because it restricts sensors to output 0, but it should work since the subsystem can assume a sensor whose inputs have not been configured has input 0 as the one selected. However, this trick in the tvp5150 which selects input 1 (instead of 0) as the default input is breaking that assumption. The solution could be either apply my patch to set input 0 (COMPOSITE0) as default or swap input numbers so that COMPOSITE1 input is input 0. Personally I find my approach more convenient since it matches with the default behavior expected in the datasheet. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
On Thursday 15 December 2011 12:53:03 Sakari Ailus wrote:
On Thu, Dec 15, 2011 at 11:28:06AM +0100, Laurent Pinchart wrote:
On Thursday 15 December 2011 10:50:34 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver rather
than in platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..52af308
100644 --- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
[snip]
+int omap3isp_csiphy_config(struct isp_device *isp,
+struct v4l2_subdev *csi2_subdev,
+struct v4l2_subdev *sensor,
+struct v4l2_mbus_framefmt *sensor_fmt)
The number of lanes can depend on the format. Wouldn't it be better to
add a subdev operation to query the sensor for its bus configuration
instead of relying on ISP platform data ?
In principle, yes. That's an interesting point; how this kind of information
would best be delivered?
There are two separate information that need to be delivered:
- how the lanes are connected on the board
- which lanes are used by the sensor, and for what purpose
The first information must be supplied through platform data, either to the
sensor driver or the OMAP3 ISP driver (or both). As the second information
comes from the sensor, my idea was to provide the first to the sensor, and to
query the sensor in the OMAP3 ISP driver for the full configuration.
On the other hand I don't see any pressing reason to use less lanes than
the maximum, so this could wait IMHO.
Perhaps around the time we standardise how the CSI-2 configuration is being
done? It's not quite as simple as the mbus_config seems to assume. For
example, the lane mapping and then which lanes do you use if you're using
less than the maximum has to be handled in a way or another.
I agree. That's why I don't really like mbus_config, its auto-negotiation
support approach makes it too limited in my opinion.
The number of lanes might be something the user would want to touch, but
I'm not entirely sure. You achieve more functionality by providing that
flexibility to the user but I don't see need for configuring that ---
still getting the number of lanes could be interesting.
If we want to expose such configuration I think we should do it on the sensor,
not the ISP.
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct isp_csiphy_lanes_cfg *lanes;
unsigned int used_lanes = 0;
unsigned int i;
+ u32 cam_phy_ctrl;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes = subdevs-bus.csi2.lanecfg;
+
+ if (!lanes) {
+ dev_err(isp-dev, no lane configuration\n);
+ return -EINVAL;
+ }
+
+ cam_phy_ctrl = omap_readl(
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ /*
+ * SCM.CONTROL_CAMERA_PHY_CTRL
+ * - bit[4]: CSIPHY1 data sent to CSIB
+ * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
+ * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
+ */
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1)
+ cam_phy_ctrl |= 1 2;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2C_PHY1)
+ cam_phy_ctrl = 1 2;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ cam_phy_ctrl |= 1;
+ else if (subdevs-interface == ISP_INTERFACE_CSI2A_PHY2)
+ cam_phy_ctrl = 1;
+
+ omap_writel(cam_phy_ctrl,
+ OMAP343X_CTRL_BASE + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+
+ csi2_ddrclk_khz = sensor_fmt-pixel_clock
+ / (2 * csi2-phy-num_data_lanes)
+ * omap3isp_video_format_info(sensor_fmt-code)-bpp;
+ csi2phy.ths_term = THS_TERM(csi2_ddrclk_khz);
+ csi2phy.ths_settle = THS_SETTLE(csi2_ddrclk_khz);
+ csi2phy.tclk_term = TCLK_TERM;
+ csi2phy.tclk_miss = TCLK_MISS;
+ csi2phy.tclk_settle = TCLK_SETTLE;
/* Clock and data lanes verification */
- for (i = 0; i phy-num_data_lanes; i++) {
+ for (i = 0; i csi2-phy-num_data_lanes; i++) {
if (lanes-data[i].pol 1 || lanes-data[i].pos 3)
return -EINVAL;
@@ -162,10 +239,10 @@ static int csiphy_config(struct isp_csiphy *phy,
if (lanes-clk.pos == 0 || used_lanes (1 lanes-clk.pos))
return -EINVAL;
- mutex_lock(phy-mutex);
- phy-dphy = *dphy;
- phy-lanes = *lanes;
- mutex_unlock(phy-mutex);
+ mutex_lock(csi2-phy-mutex);
+ csi2-phy-dphy = csi2phy;
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hi Manjunath,
Thanks for the patch.
On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Could you please also document these formats in
Documentation/DocBook/media/v4l ?
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV
4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420v4l2_fourcc('M',
'4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV
4:4 */ +
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr
4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /*
12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG..
GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */
#define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+ /* 10bit raw bayer a-law compressed to 8 bits */
+#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
That's not very future-proof, how would you describe SGBRG10ALAW8 for instance
?
Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4
characters, we could start with 'B' to denote Bayer, followed by one character
for the order, one for the compression, and one for the number of bits.
/*
* 10bit raw bayer, expanded to 16 bits
* rrgg ggbb...
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: add new mediabus format enums for dm365
Hi Manhunath,
Thanks for the patch.
On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code
to represent A-LAW compressed Bayer format. This corresponds to pixel
format - V4L2_PIX_FMT_SGRBG10ALAW8.
add UV8 and NV12 ( Y and C separate with UV interleaved) which are
supported on dm365.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
Please also update the documentation in Documentation/DocBook/media/v4l.
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..d408654 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2014 */
+ /* YUV (including grey) - next is 0x2016 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
@@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
+ V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
+ V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
NV12, on the bus ? How does that work ? (The documentation should answer my
question :-))
- /* Bayer - next is 0x3015 */
+ /* Bayer - next is 0x3019 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
@@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+ V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
+ V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
+ V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
+ V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
Please keep the names sorted as described in the comment at the beginning of
the file.
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: tvp5150: Add mbus_fmt callbacks.
These callbacks allow a host video driver
to poll video formats supported by tvp5150.
---
Changes since v1:
Fix standard handling in tvp5150_mbus_fmt()
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/tvp5150.c | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder-norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder-norm;
+
+ f-width = 720;
+ if (std V4L2_STD_525_60)
+ f-height = 480;
+ else
+ f-height = 576;
+
+ f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f-field = V4L2_FIELD_SEQ_TB;
+ f-colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, width = %d, height = %d\n, f-width,
+ f-height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops
= {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv3 PATCH 1/8] v4l2: add VIDIOC_(TRY_)DECODER_CMD.
From: Hans Verkuil hans.verk...@cisco.com
As discussed during the 2011 V4L-DVB workshop, the API in dvb/video.h should
be replaced by a proper V4L2 API. This patch turns the VIDEO_(TRY_)DECODER_CMD
ioctls into proper V4L2 ioctls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-compat-ioctl32.c |2 +
drivers/media/video/v4l2-ioctl.c | 28 +++
include/linux/videodev2.h | 53 +
include/media/v4l2-ioctl.h|4 ++
4 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..ffd9b1e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1003,6 +1003,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_G_ENC_INDEX:
case VIDIOC_ENCODER_CMD:
case VIDIOC_TRY_ENCODER_CMD:
+ case VIDIOC_DECODER_CMD:
+ case VIDIOC_TRY_DECODER_CMD:
case VIDIOC_DBG_S_REGISTER:
case VIDIOC_DBG_G_REGISTER:
case VIDIOC_DBG_G_CHIP_IDENT:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..2355510 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -258,6 +258,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_ENCODER_CMD)] = VIDIOC_ENCODER_CMD,
[_IOC_NR(VIDIOC_TRY_ENCODER_CMD)] = VIDIOC_TRY_ENCODER_CMD,
+ [_IOC_NR(VIDIOC_DECODER_CMD)] = VIDIOC_DECODER_CMD,
+ [_IOC_NR(VIDIOC_TRY_DECODER_CMD)] = VIDIOC_TRY_DECODER_CMD,
[_IOC_NR(VIDIOC_DBG_S_REGISTER)] = VIDIOC_DBG_S_REGISTER,
[_IOC_NR(VIDIOC_DBG_G_REGISTER)] = VIDIOC_DBG_G_REGISTER,
@@ -1658,6 +1660,32 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, cmd=%d, flags=%x\n, p-cmd, p-flags);
break;
}
+ case VIDIOC_DECODER_CMD:
+ {
+ struct v4l2_decoder_cmd *p = arg;
+
+ if (!ops-vidioc_decoder_cmd)
+ break;
+ if (ret_prio) {
+ ret = ret_prio;
+ break;
+ }
+ ret = ops-vidioc_decoder_cmd(file, fh, p);
+ if (!ret)
+ dbgarg(cmd, cmd=%d, flags=%x\n, p-cmd, p-flags);
+ break;
+ }
+ case VIDIOC_TRY_DECODER_CMD:
+ {
+ struct v4l2_decoder_cmd *p = arg;
+
+ if (!ops-vidioc_try_decoder_cmd)
+ break;
+ ret = ops-vidioc_try_decoder_cmd(file, fh, p);
+ if (!ret)
+ dbgarg(cmd, cmd=%d, flags=%x\n, p-cmd, p-flags);
+ break;
+ }
case VIDIOC_G_PARM:
{
struct v4l2_streamparm *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..406f7f7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1849,6 +1849,54 @@ struct v4l2_encoder_cmd {
};
};
+/* Decoder commands */
+#define V4L2_DEC_CMD_START (0)
+#define V4L2_DEC_CMD_STOP(1)
+#define V4L2_DEC_CMD_PAUSE (2)
+#define V4L2_DEC_CMD_RESUME (3)
+
+/* Flags for V4L2_DEC_CMD_START */
+#define V4L2_DEC_CMD_START_MUTE_AUDIO (1 0)
+
+/* Flags for V4L2_DEC_CMD_PAUSE */
+#define V4L2_DEC_CMD_PAUSE_TO_BLACK(1 0)
+
+/* Flags for V4L2_DEC_CMD_STOP */
+#define V4L2_DEC_CMD_STOP_TO_BLACK (1 0)
+#define V4L2_DEC_CMD_STOP_IMMEDIATELY (1 1)
+
+/* Play format requirements (returned by the driver): */
+
+/* The decoder has no special format requirements */
+#define V4L2_DEC_START_FMT_NONE(0)
+/* The decoder requires full GOPs */
+#define V4L2_DEC_START_FMT_GOP (1)
+
+/* The structure must be zeroed before use by the application
+ This ensures it can be extended safely in the future. */
+struct v4l2_decoder_cmd {
+ __u32 cmd;
+ __u32 flags;
+ union {
+ struct {
+ __u64 pts;
+ } stop;
+
+ struct {
+ /* 0 or 1000 specifies normal speed,
+ 1 specifies forward single stepping,
+ -1 specifies backward single stepping,
+ 1: playback at speed/1000 of the normal speed,
+ -1: reverse playback at (-speed/1000) of the normal
speed. */
+ __s32 speed;
+ __u32 format;
+ } start;
+
+ struct {
+ __u32 data[16];
+ } raw;
+ };
+};
#endif
@@ -2255,6 +2303,11 @@ struct v4l2_create_buffers {
#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct v4l2_create_buffers)
#define VIDIOC_PREPARE_BUF _IOWR('V', 93,
[RFCv3 PATCH 2/8] v4l spec: document VIDIOC_(TRY_)DECODER_CMD.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/v4l2.xml |1 + .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 256 .../DocBook/media/v4l/vidioc-encoder-cmd.xml |9 +- 3 files changed, 262 insertions(+), 4 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..7fc11db 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -473,6 +473,7 @@ and discussions on the V4L mailing list./revremark sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; +sub-decoder-cmd; sub-dqevent; sub-encoder-cmd; sub-enumaudio; diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml new file mode 100644 index 000..466fe27 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -0,0 +1,256 @@ +refentry id=vidioc-decoder-cmd + refmeta +refentrytitleioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_DECODER_CMD/refname +refnameVIDIOC_TRY_DECODER_CMD/refname +refpurposeExecute an decoder command/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_decoder_cmd *parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + + paraThis is an link linkend=experimentalexperimental/link +interface and may change in the future./para +/note + +paraThese ioctls control an audio/video (usually MPEG-) decoder. +constantVIDIOC_DECODER_CMD/constant sends a command to the +decoder, constantVIDIOC_TRY_DECODER_CMD/constant can be used to +try a command without actually executing it. To send a command applications +must initialize all fields of a v4l2-decoder-cmd; and call +constantVIDIOC_DECODER_CMD/constant or constantVIDIOC_TRY_DECODER_CMD/constant +with a pointer to this structure./para + +paraThe structfieldcmd/structfield field must contain the +command code. Some commands use the structfieldflags/structfield field for +additional information. +/para + +paraA functionwrite/function() or VIDIOC-STREAMON; call sends an implicit +START command to the decoder if it has not been started yet. +/para + +paraA functionclose/function() or VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP command to the decoder, and all +buffered data is discarded./para + +paraThese ioctls are optional, not all drivers may support +them. They were introduced in Linux 3.3./para + +table pgwide=1 frame=none id=v4l2-decoder-cmd + titlestruct structnamev4l2_decoder_cmd/structname/title + tgroup cols=5 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldcmd/structfield/entry +entry/entry +entry/entry + entryThe decoder command, see xref linkend=decoder-cmds /./entry + /row + row + entry__u32/entry + entrystructfieldflags/structfield/entry +entry/entry +entry/entry + entryFlags to go with the command. If no flags are defined for +this command, drivers and applications must set this field to zero./entry + /row + row + entryunion/entry + entry(anonymous)/entry +entry/entry + entry/entry +entry/entry + /row + row + entry/entry + entrystruct/entry +entrystructfieldstart/structfield/entry +entry/entry +entryStructure containing additional data for the +constantV4L2_DEC_CMD_START/constant command./entry + /row + row +entry/entry +entry/entry + entry__u32/entry + entrystructfieldspeed/structfield/entry +entryPlayback speed
[RFCv3 PATCH 3/8] ivtv: implement new decoder command ioctls.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-driver.c |2 +-
drivers/media/video/ivtv/ivtv-fileops.c |2 +-
drivers/media/video/ivtv/ivtv-ioctl.c | 106 +++---
drivers/media/video/ivtv/ivtv-streams.c |4 +-
4 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 41108a9..7ee7594 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -1378,7 +1378,7 @@ static void ivtv_remove(struct pci_dev *pdev)
else
type = IVTV_DEC_STREAM_TYPE_MPG;
ivtv_stop_v4l2_decode_stream(itv-streams[type],
- VIDEO_CMD_STOP_TO_BLACK |
VIDEO_CMD_STOP_IMMEDIATELY, 0);
+ V4L2_DEC_CMD_STOP_TO_BLACK |
V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
}
ivtv_halt_firmware(itv);
}
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
index 38f0522..66228ee 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -899,7 +899,7 @@ int ivtv_v4l2_close(struct file *filp)
} else if (s-type = IVTV_DEC_STREAM_TYPE_MPG) {
struct ivtv_stream *s_vout =
itv-streams[IVTV_DEC_STREAM_TYPE_VOUT];
- ivtv_stop_decoding(id, VIDEO_CMD_STOP_TO_BLACK |
VIDEO_CMD_STOP_IMMEDIATELY, 0);
+ ivtv_stop_decoding(id, V4L2_DEC_CMD_STOP_TO_BLACK |
V4L2_DEC_CMD_STOP_IMMEDIATELY, 0);
/* If all output streams are closed, and if the user doesn't
have
IVTV_DEC_STREAM_TYPE_VOUT open, then disable CC on TV-out. */
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index ecafa69..c84e325 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -244,34 +244,40 @@ static int ivtv_validate_speed(int cur_speed, int
new_speed)
}
static int ivtv_video_command(struct ivtv *itv, struct ivtv_open_id *id,
- struct video_command *vc, int try)
+ struct v4l2_decoder_cmd *dc, int try)
{
struct ivtv_stream *s = itv-streams[IVTV_DEC_STREAM_TYPE_MPG];
if (!(itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT))
return -EINVAL;
- switch (vc-cmd) {
- case VIDEO_CMD_PLAY: {
- vc-flags = 0;
- vc-play.speed = ivtv_validate_speed(itv-speed,
vc-play.speed);
- if (vc-play.speed 0)
- vc-play.format = VIDEO_PLAY_FMT_GOP;
+ switch (dc-cmd) {
+ case V4L2_DEC_CMD_START: {
+ dc-flags = V4L2_DEC_CMD_START_MUTE_AUDIO;
+ dc-start.speed = ivtv_validate_speed(itv-speed,
dc-start.speed);
+ if (dc-start.speed 0)
+ dc-start.format = V4L2_DEC_START_FMT_GOP;
+ else
+ dc-start.format = V4L2_DEC_START_FMT_NONE;
+ if (dc-start.speed != 500 dc-start.speed != 1500)
+ dc-flags = dc-start.speed == 1000 ? 0 :
+ V4L2_DEC_CMD_START_MUTE_AUDIO;
if (try) break;
+ itv-speed_mute_audio = dc-flags
V4L2_DEC_CMD_START_MUTE_AUDIO;
if (ivtv_set_output_mode(itv, OUT_MPG) != OUT_MPG)
return -EBUSY;
if (test_and_clear_bit(IVTV_F_I_DEC_PAUSED, itv-i_flags)) {
/* forces ivtv_set_speed to be called */
itv-speed = 0;
}
- return ivtv_start_decoding(id, vc-play.speed);
+ return ivtv_start_decoding(id, dc-start.speed);
}
- case VIDEO_CMD_STOP:
- vc-flags = VIDEO_CMD_STOP_IMMEDIATELY|VIDEO_CMD_STOP_TO_BLACK;
- if (vc-flags VIDEO_CMD_STOP_IMMEDIATELY)
- vc-stop.pts = 0;
+ case V4L2_DEC_CMD_STOP:
+ dc-flags = V4L2_DEC_CMD_STOP_IMMEDIATELY |
V4L2_DEC_CMD_STOP_TO_BLACK;
+ if (dc-flags V4L2_DEC_CMD_STOP_IMMEDIATELY)
+ dc-stop.pts = 0;
if (try) break;
if (atomic_read(itv-decoding) == 0)
return 0;
@@ -279,22 +285,22 @@ static int ivtv_video_command(struct ivtv *itv, struct
ivtv_open_id *id,
return -EBUSY;
itv-output_mode = OUT_NONE;
- return ivtv_stop_v4l2_decode_stream(s, vc-flags, vc-stop.pts);
+ return ivtv_stop_v4l2_decode_stream(s, dc-flags, dc-stop.pts);
- case VIDEO_CMD_FREEZE:
- vc-flags = VIDEO_CMD_FREEZE_TO_BLACK;
+ case V4L2_DEC_CMD_PAUSE:
+ dc-flags = V4L2_DEC_CMD_PAUSE_TO_BLACK;
[RFCv3 PATCH 0/8] Add decoder API to V4L2
This is the third version of the new decoder API. The second version is here: http://www.spinics.net/lists/linux-media/msg40474.html The main changes are: - The DVB API is left untouched. So this series only makes changes to the V4L2 subsystem. DVB is just too depressing to propose any changes there. - The V4L2_CID_MPEG_STREAM_DEC_PTS control has been renamed to V4L2_CID_MPEG_VIDEO_DEC_PTS since it is the PTS from the video elementary stream. The documentation of this control has been improved as well. - Note that the 'old' VIDEO_GET_PTS ioctl was also used in ivtv to return the PTS of the encoded video/audio. For an MPEG stream that was unnecessary (since the stream itself already contains those time stamps), but for the YUV and PCM streams that was useful in the past to do A/V synchronization. However, the current firmware seems to sync the YUV and PCM streams correctly (as far as I can remember), so I decided not to create V4L2 counterparts for this. I'm not aware of any application that uses this anyway. 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
[RFCv3 PATCH 5/8] Document decoder controls.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/controls.xml | 59 ++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 9e72f07..400f223 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1273,6 +1273,49 @@ produce a slight hiss, but in the encoder itself, guaranteeing a fixed and reproducible audio bitstream. 0 = unmuted, 1 = muted./entry /row rowentry/entry/row + row id=v4l2-mpeg-audio-dec-playback + entry spanname=idconstantV4L2_CID_MPEG_AUDIO_DEC_PLAYBACK/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_audio_dec_playback/entry + /rowrowentry spanname=descrDetermines how monolingual audio should be played back. +Possible values are:/entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO/constantnbsp;/entry + entryAutomatically determines the best playback mode./entry + /row + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO/constantnbsp;/entry + entryStereo playback./entry + /row + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT/constantnbsp;/entry + entryLeft channel playback./entry + /row + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT/constantnbsp;/entry + entryRight channel playback./entry + /row + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO/constantnbsp;/entry + entryMono playback./entry + /row + row + entryconstantV4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO/constantnbsp;/entry + entryStereo playback with swapped left and right channels./entry + /row + /tbody + /entrytbl + /row + rowentry/entry/row + row id=v4l2-mpeg-audio-dec-multilingual-playback + entry spanname=idconstantV4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_audio_dec_playback/entry + /rowrowentry spanname=descrDetermines how multilingual audio should be played back./entry + /row + rowentry/entry/row row id=v4l2-mpeg-video-encoding entry spanname=idconstantV4L2_CID_MPEG_VIDEO_ENCODING/constantnbsp;/entry entryenumnbsp;v4l2_mpeg_video_encoding/entry @@ -1434,6 +1477,22 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit /tbody /entrytbl /row + rowentry/entry/row + row id=v4l2-mpeg-video-dec-pts + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DEC_PTS/constantnbsp;/entry + entryinteger64/entry + /rowrowentry spanname=descrThis read-only control returns the +33-bit video Presentation Time Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of +the currently displayed frame. This is the same PTS as is used in VIDIOC-DECODER-CMD;./entry + /row + rowentry/entry/row + row id=v4l2-mpeg-video-dec-frame + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DEC_FRAME/constantnbsp;/entry + entryinteger64/entry + /rowrowentry spanname=descrThis read-only control returns the +frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever +the decoder is started./entry + /row rowentry/entry/row -- 1.7.7.3 -- 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
[RFCv3 PATCH 7/8] cx18/ddbridge: remove unused headers.
From: Hans Verkuil hans.verk...@cisco.com The cx18 and ddbridge drivers include linux/dvb/audio.h and video.h without using them. Remove those includes. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/dvb/ddbridge/ddbridge.h |2 -- drivers/media/video/cx18/cx18-driver.h |2 -- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/media/dvb/ddbridge/ddbridge.h b/drivers/media/dvb/ddbridge/ddbridge.h index 6d14893..8b1b41d 100644 --- a/drivers/media/dvb/ddbridge/ddbridge.h +++ b/drivers/media/dvb/ddbridge/ddbridge.h @@ -32,8 +32,6 @@ #include asm/dma.h #include linux/dvb/frontend.h #include linux/dvb/ca.h -#include linux/dvb/video.h -#include linux/dvb/audio.h #include linux/socket.h #include dmxdev.h diff --git a/drivers/media/video/cx18/cx18-driver.h b/drivers/media/video/cx18/cx18-driver.h index b9a94fc..7a37e0e 100644 --- a/drivers/media/video/cx18/cx18-driver.h +++ b/drivers/media/video/cx18/cx18-driver.h @@ -44,8 +44,6 @@ #include linux/slab.h #include asm/byteorder.h -#include linux/dvb/video.h -#include linux/dvb/audio.h #include media/v4l2-common.h #include media/v4l2-ioctl.h #include media/v4l2-device.h -- 1.7.7.3 -- 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
[RFCv3 PATCH 6/8] ivtv: implement new decoder controls.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-controls.c | 62 +++
drivers/media/video/ivtv/ivtv-controls.h |2 +
drivers/media/video/ivtv/ivtv-driver.c | 35 +++-
drivers/media/video/ivtv/ivtv-driver.h | 12 +-
drivers/media/video/ivtv/ivtv-ioctl.c| 67 +
drivers/media/video/ivtv/ivtv-streams.c |5 ++-
6 files changed, 124 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-controls.c
b/drivers/media/video/ivtv/ivtv-controls.c
index b31ee1b..e290118 100644
--- a/drivers/media/video/ivtv/ivtv-controls.c
+++ b/drivers/media/video/ivtv/ivtv-controls.c
@@ -21,6 +21,7 @@
#include ivtv-driver.h
#include ivtv-ioctl.h
#include ivtv-controls.h
+#include ivtv-mailbox.h
static int ivtv_s_stream_vbi_fmt(struct cx2341x_handler *cxhdl, u32 fmt)
{
@@ -99,3 +100,64 @@ struct cx2341x_handler_ops ivtv_cxhdl_ops = {
.s_video_encoding = ivtv_s_video_encoding,
.s_stream_vbi_fmt = ivtv_s_stream_vbi_fmt,
};
+
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame)
+{
+ u32 data[CX2341X_MBOX_MAX_DATA];
+
+ if (test_bit(IVTV_F_I_VALID_DEC_TIMINGS, itv-i_flags)) {
+ *pts = (s64)((u64)itv-last_dec_timing[2] 32) |
+ (u64)itv-last_dec_timing[1];
+ *frame = itv-last_dec_timing[0];
+ return 0;
+ }
+ *pts = 0;
+ *frame = 0;
+ if (atomic_read(itv-decoding)) {
+ if (ivtv_api(itv, CX2341X_DEC_GET_TIMING_INFO, 5, data)) {
+ IVTV_DEBUG_WARN(GET_TIMING: couldn't read clock\n);
+ return -EIO;
+ }
+ memcpy(itv-last_dec_timing, data,
sizeof(itv-last_dec_timing));
+ set_bit(IVTV_F_I_VALID_DEC_TIMINGS, itv-i_flags);
+ *pts = (s64)((u64) data[2] 32) | (u64) data[1];
+ *frame = data[0];
+ /*timing-scr = (u64) (((u64) data[4] 32) | (u64)
(data[3]));*/
+ }
+ return 0;
+}
+
+static int ivtv_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ivtv *itv = container_of(ctrl-handler, struct ivtv, hdl_out);
+
+ switch (ctrl-id) {
+ /* V4L2_CID_MPEG_VIDEO_DEC_PTS and V4L2_CID_MPEG_VIDEO_DEC_FRAME
+ control cluster */
+ case V4L2_CID_MPEG_VIDEO_DEC_PTS:
+ return ivtv_g_pts_frame(itv, itv-ctrl_pts-val64,
+itv-ctrl_frame-val64);
+ }
+ return 0;
+}
+
+static int ivtv_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ivtv *itv = container_of(ctrl-handler, struct ivtv, hdl_out);
+
+ switch (ctrl-id) {
+ /* V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK and MULTILINGUAL_PLAYBACK
+ control cluster */
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ itv-audio_stereo_mode = itv-ctrl_audio_playback-val - 1;
+ itv-audio_bilingual_mode =
itv-ctrl_audio_multilingual_playback-val - 1;
+ ivtv_vapi(itv, CX2341X_DEC_SET_AUDIO_MODE, 2,
itv-audio_bilingual_mode, itv-audio_stereo_mode);
+ break;
+ }
+ return 0;
+}
+
+const struct v4l2_ctrl_ops ivtv_hdl_out_ops = {
+ .s_ctrl = ivtv_s_ctrl,
+ .g_volatile_ctrl = ivtv_g_volatile_ctrl,
+};
diff --git a/drivers/media/video/ivtv/ivtv-controls.h
b/drivers/media/video/ivtv/ivtv-controls.h
index d12893d..3999e63 100644
--- a/drivers/media/video/ivtv/ivtv-controls.h
+++ b/drivers/media/video/ivtv/ivtv-controls.h
@@ -22,5 +22,7 @@
#define IVTV_CONTROLS_H
extern struct cx2341x_handler_ops ivtv_cxhdl_ops;
+extern const struct v4l2_ctrl_ops ivtv_hdl_out_ops;
+int ivtv_g_pts_frame(struct ivtv *itv, s64 *pts, s64 *frame);
#endif
diff --git a/drivers/media/video/ivtv/ivtv-driver.c
b/drivers/media/video/ivtv/ivtv-driver.c
index 7ee7594..ec5a25a 100644
--- a/drivers/media/video/ivtv/ivtv-driver.c
+++ b/drivers/media/video/ivtv/ivtv-driver.c
@@ -747,8 +747,6 @@ static int __devinit ivtv_init_struct1(struct ivtv *itv)
itv-cur_dma_stream = -1;
itv-cur_pio_stream = -1;
- itv-audio_stereo_mode = AUDIO_STEREO;
- itv-audio_bilingual_mode = AUDIO_MONO_LEFT;
/* Ctrls */
itv-speed = 1000;
@@ -1203,6 +1201,32 @@ static int __devinit ivtv_probe(struct pci_dev *pdev,
itv-tuner_std = itv-std;
if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
+ v4l2_ctrl_handler_init(itv-hdl_out, 50);
+ itv-ctrl_pts = v4l2_ctrl_new_std(itv-hdl_out,
ivtv_hdl_out_ops,
+ V4L2_CID_MPEG_VIDEO_DEC_PTS, 0, 0, 1, 0);
+ itv-ctrl_frame = v4l2_ctrl_new_std(itv-hdl_out,
ivtv_hdl_out_ops,
+ V4L2_CID_MPEG_VIDEO_DEC_FRAME, 0, 0x7fff,
1, 0);
+ /* Note: V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO is not supported,
+ mask that menu
[RFCv3 PATCH 4/8] v4l2-ctrls: add new controls for MPEG decoder devices.
From: Hans Verkuil hans.verk...@cisco.com
As discussed during the 2011 V4L-DVB workshop we want to create a proper V4L2
decoder API that replaces the DVBv5 API that has been used until now.
This adds the four controls necessary to be able to switch ivtv over to this
new API.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 23 +++
include/linux/videodev2.h| 13 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..f9469e3 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -175,6 +175,15 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
16-bit CRC,
NULL
};
+ static const char * const mpeg_audio_dec_playback[] = {
+ Auto,
+ Stereo,
+ Left,
+ Right,
+ Mono,
+ Swapped Stereo,
+ NULL
+ };
static const char * const mpeg_video_encoding[] = {
MPEG-1,
MPEG-2,
@@ -374,6 +383,9 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg_audio_emphasis;
case V4L2_CID_MPEG_AUDIO_CRC:
return mpeg_audio_crc;
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
+ return mpeg_audio_dec_playback;
case V4L2_CID_MPEG_VIDEO_ENCODING:
return mpeg_video_encoding;
case V4L2_CID_MPEG_VIDEO_ASPECT:
@@ -491,6 +503,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_AUDIO_MUTE: return Audio Mute;
case V4L2_CID_MPEG_AUDIO_AAC_BITRATE: return Audio AAC Bitrate;
case V4L2_CID_MPEG_AUDIO_AC3_BITRATE: return Audio AC-3 Bitrate;
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK: return Audio Playback;
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK: return Audio
Multilingual Playback;
case V4L2_CID_MPEG_VIDEO_ENCODING: return Video Encoding;
case V4L2_CID_MPEG_VIDEO_ASPECT:return Video Aspect;
case V4L2_CID_MPEG_VIDEO_B_FRAMES: return Video B Frames;
@@ -545,6 +559,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB:return The
Number of MB in a Slice;
case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE: return The
Slice Partitioning Method;
case V4L2_CID_MPEG_VIDEO_VBV_SIZE: return VBV
Buffer Size;
+ case V4L2_CID_MPEG_VIDEO_DEC_PTS: return Video
Decoder PTS;
+ case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return Video
Decoder Frame Count;
/* CAMERA controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -673,6 +689,8 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_AUDIO_MODE_EXTENSION:
case V4L2_CID_MPEG_AUDIO_EMPHASIS:
case V4L2_CID_MPEG_AUDIO_CRC:
+ case V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK:
+ case V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK:
case V4L2_CID_MPEG_VIDEO_ENCODING:
case V4L2_CID_MPEG_VIDEO_ASPECT:
case V4L2_CID_MPEG_VIDEO_BITRATE_MODE:
@@ -723,6 +741,11 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
*type = V4L2_CTRL_TYPE_INTEGER;
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
+ case V4L2_CID_MPEG_VIDEO_DEC_FRAME:
+ case V4L2_CID_MPEG_VIDEO_DEC_PTS:
+ *type = V4L2_CTRL_TYPE_INTEGER64;
+ *flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_VOLATILE;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 406f7f7..225ac29 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1350,6 +1350,16 @@ enum v4l2_mpeg_audio_ac3_bitrate {
V4L2_MPEG_AUDIO_AC3_BITRATE_576K = 17,
V4L2_MPEG_AUDIO_AC3_BITRATE_640K = 18,
};
+#define V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK (V4L2_CID_MPEG_BASE+112)
+enum v4l2_mpeg_audio_dec_playback {
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO = 0,
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO = 1,
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT = 2,
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT = 3,
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO = 4,
+ V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO = 5,
+};
+#define V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK (V4L2_CID_MPEG_BASE+113)
/* MPEG video controls specific to multiplexed streams */
#define V4L2_CID_MPEG_VIDEO_ENCODING (V4L2_CID_MPEG_BASE+200)
@@ -1400,6 +1410,9 @@ enum v4l2_mpeg_video_multi_slice_mode
[RFCv3 PATCH 8/8] ivtv: add IVTV_IOC_PASSTHROUGH_MODE.
From: Hans Verkuil hans.verk...@cisco.com
With this private ioctl it is possible to use the ivtv decoder without
requiring the dvb/video.h and dvb/audio.h headers.
Eventually support for those DVB APIs will be dropped from ivtv.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-ioctl.c |8
include/linux/ivtv.h |6 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index 736ba8e..1cf264f 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -1618,6 +1618,12 @@ static int ivtv_decoder_ioctls(struct file *filp,
unsigned int cmd, void *arg)
return ivtv_yuv_prep_frame(itv, args);
}
+ case IVTV_IOC_PASSTHROUGH_MODE:
+ IVTV_DEBUG_IOCTL(IVTV_IOC_PASSTHROUGH_MODE\n);
+ if (!(itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT))
+ return -EINVAL;
+ return ivtv_passthrough_mode(itv, *(int *)arg != 0);
+
case VIDEO_GET_PTS: {
s64 *pts = arg;
s64 frame;
@@ -1779,6 +1785,7 @@ static long ivtv_default(struct file *file, void *fh,
bool valid_prio,
if (!valid_prio) {
switch (cmd) {
+ case IVTV_IOC_PASSTHROUGH_MODE:
case VIDEO_PLAY:
case VIDEO_STOP:
case VIDEO_FREEZE:
@@ -1804,6 +1811,7 @@ static long ivtv_default(struct file *file, void *fh,
bool valid_prio,
}
case IVTV_IOC_DMA_FRAME:
+ case IVTV_IOC_PASSTHROUGH_MODE:
case VIDEO_GET_PTS:
case VIDEO_GET_FRAME_COUNT:
case VIDEO_GET_EVENT:
diff --git a/include/linux/ivtv.h b/include/linux/ivtv.h
index 062d20f..42bf725 100644
--- a/include/linux/ivtv.h
+++ b/include/linux/ivtv.h
@@ -58,7 +58,11 @@ struct ivtv_dma_frame {
__u32 src_height;
};
-#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0, struct
ivtv_dma_frame)
+#define IVTV_IOC_DMA_FRAME _IOW ('V', BASE_VIDIOC_PRIVATE+0,
struct ivtv_dma_frame)
+
+/* Select the passthrough mode (if the argument is non-zero). In the
passthrough
+ mode the output of the encoder is passed immediately into the decoder. */
+#define IVTV_IOC_PASSTHROUGH_MODE _IOW ('V', BASE_VIDIOC_PRIVATE+1, int)
/* Deprecated defines: applications should use the defines from videodev2.h */
#define IVTV_SLICED_TYPE_TELETEXT_B V4L2_MPEG_VBI_IVTV_TELETEXT_B
--
1.7.7.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.3] Alpha colour control addition
Hello Mauro, The following changes since commit c8c59cb5c459ff71f0592dc0716cdc2e730b20e5: s5p-fimc: Prevent lock up caused by incomplete H/W initialization (2011-12-14 16:02:32 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_rgb_alpha This is a new alpha colour control addition, I've applied it on top of my s5p-fimc bugfix patches, which are already in linuxtv.org/media-next.git GIT, except this one: s5p-fimc: Prevent lock up caused by incomplete H/W initialization Sylwester Nawrocki (2): v4l: Add new alpha component control s5p-fimc: Add support for alpha component configuration Documentation/DocBook/media/v4l/compat.xml | 11 ++ Documentation/DocBook/media/v4l/controls.xml | 25 +++- .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 +- drivers/media/video/s5p-fimc/fimc-capture.c| 11 ++ drivers/media/video/s5p-fimc/fimc-core.c | 128 drivers/media/video/s5p-fimc/fimc-core.h | 30 - drivers/media/video/s5p-fimc/fimc-reg.c| 53 ++-- drivers/media/video/s5p-fimc/regs-fimc.h |5 + drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h |6 +- 10 files changed, 224 insertions(+), 53 deletions(-) Best regards -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: vb2: remove plane argument from call_memop and cleanup mempriv usage
This patch removes unused 'plane' argument from call_memop macro.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index a3a9bf9..9dc887b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -30,7 +30,7 @@ module_param(debug, int, 0644);
printk(KERN_DEBUG vb2: fmt, ## arg); \
} while (0)
-#define call_memop(q, plane, op, args...) \
+#define call_memop(q, op, args...) \
(((q)-mem_ops-op) ? \
((q)-mem_ops-op(args)) : 0)
@@ -52,7 +52,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
/* Allocate memory for all planes in this buffer */
for (plane = 0; plane vb-num_planes; ++plane) {
- mem_priv = call_memop(q, plane, alloc, q-alloc_ctx[plane],
+ mem_priv = call_memop(q, alloc, q-alloc_ctx[plane],
q-plane_sizes[plane]);
if (IS_ERR_OR_NULL(mem_priv))
goto free;
@@ -66,7 +66,7 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
free:
/* Free already allocated memory if one of the allocations failed */
for (; plane 0; --plane)
- call_memop(q, plane, put, vb-planes[plane - 1].mem_priv);
+ call_memop(q, put, vb-planes[plane - 1].mem_priv);
return -ENOMEM;
}
@@ -80,7 +80,7 @@ static void __vb2_buf_mem_free(struct vb2_buffer *vb)
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
- call_memop(q, plane, put, vb-planes[plane].mem_priv);
+ call_memop(q, put, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
dprintk(3, Freed plane %d of buffer %d\n,
plane, vb-v4l2_buf.index);
@@ -100,7 +100,7 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
void *mem_priv = vb-planes[plane].mem_priv;
if (mem_priv) {
- call_memop(q, plane, put_userptr, mem_priv);
+ call_memop(q, put_userptr, mem_priv);
vb-planes[plane].mem_priv = NULL;
}
}
@@ -305,7 +305,7 @@ static bool __buffer_in_use(struct vb2_queue *q, struct
vb2_buffer *vb)
* case anyway. If num_users() returns more than 1,
* we are not the only user of the plane's memory.
*/
- if (mem_priv call_memop(q, plane, num_users, mem_priv) 1)
+ if (mem_priv call_memop(q, num_users, mem_priv) 1)
return true;
}
return false;
@@ -734,7 +734,7 @@ void *vb2_plane_vaddr(struct vb2_buffer *vb, unsigned int
plane_no)
if (plane_no vb-num_planes)
return NULL;
- return call_memop(q, plane_no, vaddr, vb-planes[plane_no].mem_priv);
+ return call_memop(q, vaddr, vb-planes[plane_no].mem_priv);
}
EXPORT_SYMBOL_GPL(vb2_plane_vaddr);
@@ -757,7 +757,7 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int
plane_no)
if (plane_no vb-num_planes)
return NULL;
- return call_memop(q, plane_no, cookie, vb-planes[plane_no].mem_priv);
+ return call_memop(q, cookie, vb-planes[plane_no].mem_priv);
}
EXPORT_SYMBOL_GPL(vb2_plane_cookie);
@@ -899,8 +899,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
/* Release previously acquired memory if present */
if (vb-planes[plane].mem_priv)
- call_memop(q, plane, put_userptr,
- vb-planes[plane].mem_priv);
+ call_memop(q, put_userptr, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
vb-v4l2_planes[plane].m.userptr = 0;
@@ -944,8 +943,7 @@ err:
/* In case of errors, release planes that were already acquired */
for (plane = 0; plane vb-num_planes; ++plane) {
if (vb-planes[plane].mem_priv)
- call_memop(q, plane, put_userptr,
- vb-planes[plane].mem_priv);
+ call_memop(q, put_userptr, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
vb-v4l2_planes[plane].m.userptr = 0;
vb-v4l2_planes[plane].length = 0;
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
[PATCH] media: vb2: review mem_priv usage and fix potential bugs
This patch is a result of review of mem_priv entry usage in videobuf2 core.
It fixes all all potential places where it was not checked against NULL or
zeroed after freeing as well as a few style issues.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c | 44 ++---
1 files changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 9dc887b..26cfbf5 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -65,8 +65,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
return 0;
free:
/* Free already allocated memory if one of the allocations failed */
- for (; plane 0; --plane)
+ for (; plane 0; --plane) {
call_memop(q, put, vb-planes[plane - 1].mem_priv);
+ vb-planes[plane - 1].mem_priv = NULL;
+ }
return -ENOMEM;
}
@@ -82,8 +84,8 @@ static void __vb2_buf_mem_free(struct vb2_buffer *vb)
for (plane = 0; plane vb-num_planes; ++plane) {
call_memop(q, put, vb-planes[plane].mem_priv);
vb-planes[plane].mem_priv = NULL;
- dprintk(3, Freed plane %d of buffer %d\n,
- plane, vb-v4l2_buf.index);
+ dprintk(3, Freed plane %d of buffer %d\n, plane,
+ vb-v4l2_buf.index);
}
}
@@ -97,12 +99,9 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
- void *mem_priv = vb-planes[plane].mem_priv;
-
- if (mem_priv) {
- call_memop(q, put_userptr, mem_priv);
- vb-planes[plane].mem_priv = NULL;
- }
+ if (vb-planes[plane].mem_priv)
+ call_memop(q, put_userptr, vb-planes[plane].mem_priv);
+ vb-planes[plane].mem_priv = NULL;
}
}
@@ -731,7 +730,7 @@ void *vb2_plane_vaddr(struct vb2_buffer *vb, unsigned int
plane_no)
{
struct vb2_queue *q = vb-vb2_queue;
- if (plane_no vb-num_planes)
+ if (plane_no vb-num_planes || !vb-planes[plane_no].mem_priv)
return NULL;
return call_memop(q, vaddr, vb-planes[plane_no].mem_priv);
@@ -754,7 +753,7 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int
plane_no)
{
struct vb2_queue *q = vb-vb2_queue;
- if (plane_no vb-num_planes)
+ if (plane_no vb-num_planes || !vb-planes[plane_no].mem_priv)
return NULL;
return call_memop(q, cookie, vb-planes[plane_no].mem_priv);
@@ -906,19 +905,16 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
vb-v4l2_planes[plane].length = 0;
/* Acquire each plane's memory */
- if (q-mem_ops-get_userptr) {
- mem_priv = q-mem_ops-get_userptr(q-alloc_ctx[plane],
- planes[plane].m.userptr,
- planes[plane].length,
- write);
- if (IS_ERR(mem_priv)) {
- dprintk(1, qbuf: failed acquiring userspace
+ mem_priv = call_memop(q, get_userptr, q-alloc_ctx[plane],
+ planes[plane].m.userptr,
+ planes[plane].length, write);
+ if (IS_ERR_OR_NULL(mem_priv)) {
+ dprintk(1, qbuf: failed acquiring userspace
memory for plane %d\n, plane);
- ret = PTR_ERR(mem_priv);
- goto err;
- }
- vb-planes[plane].mem_priv = mem_priv;
+ ret = mem_priv ? PTR_ERR(mem_priv) : -EINVAL;
+ goto err;
}
+ vb-planes[plane].mem_priv = mem_priv;
}
/*
@@ -1553,7 +1549,6 @@ static int __find_plane_by_offset(struct vb2_queue *q,
unsigned long off,
int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma)
{
unsigned long off = vma-vm_pgoff PAGE_SHIFT;
- struct vb2_plane *vb_plane;
struct vb2_buffer *vb;
unsigned int buffer, plane;
int ret;
@@ -1590,9 +1585,8 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct
*vma)
return ret;
vb = q-bufs[buffer];
- vb_plane = vb-planes[plane];
- ret = q-mem_ops-mmap(vb_plane-mem_priv, vma);
+ ret = call_memop(q, mmap, vb-planes[plane].mem_priv, vma);
if (ret)
return
[PATCH] media: vb2: vmalloc-based allocator user pointer handling
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds support for user pointer memory buffers to vmalloc
videobuf2 allocator.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-vmalloc.c | 90 ++
1 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index a3a8842..4e789a1 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -12,6 +12,7 @@
#include linux/module.h
#include linux/mm.h
+#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
@@ -20,7 +21,10 @@
struct vb2_vmalloc_buf {
void*vaddr;
+ struct page **pages;
+ int write;
unsigned long size;
+ unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -31,7 +35,7 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned long
size)
{
struct vb2_vmalloc_buf *buf;
- buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
return NULL;
@@ -42,15 +46,12 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned
long size)
buf-handler.arg = buf;
if (!buf-vaddr) {
- printk(KERN_ERR vmalloc of size %ld failed\n, buf-size);
+ pr_debug(vmalloc of size %ld failed\n, buf-size);
kfree(buf);
return NULL;
}
atomic_inc(buf-refcount);
- printk(KERN_DEBUG Allocated vmalloc buffer of size %ld at vaddr=%p\n,
- buf-size, buf-vaddr);
-
return buf;
}
@@ -59,21 +60,84 @@ static void vb2_vmalloc_put(void *buf_priv)
struct vb2_vmalloc_buf *buf = buf_priv;
if (atomic_dec_and_test(buf-refcount)) {
- printk(KERN_DEBUG %s: Freeing vmalloc mem at vaddr=%p\n,
- __func__, buf-vaddr);
vfree(buf-vaddr);
kfree(buf);
}
}
-static void *vb2_vmalloc_vaddr(void *buf_priv)
+static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr,
+unsigned long size, int write)
+{
+ struct vb2_vmalloc_buf *buf;
+ unsigned long first, last;
+ int n_pages, offset;
+
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf-write = write;
+ offset = vaddr ~PAGE_MASK;
+ buf-size = size;
+
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
+buf-n_pages, write, 1, /* force */
+buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+
+ buf-vaddr += offset;
+ return buf;
+
+fail_get_user_pages:
+ pr_debug(get_user_pages requested/got: %d/%d]\n, n_pages,
+buf-n_pages);
+ while (--n_pages = 0)
+ put_page(buf-pages[n_pages]);
+ kfree(buf-pages);
+
+fail_pages_array_alloc:
+ kfree(buf);
+
+ return NULL;
+}
+
+static void vb2_vmalloc_put_userptr(void *buf_priv)
{
struct vb2_vmalloc_buf *buf = buf_priv;
+ unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
+ unsigned int i;
+
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ kfree(buf);
+}
- BUG_ON(!buf);
+static void *vb2_vmalloc_vaddr(void *buf_priv)
+{
+ struct vb2_vmalloc_buf *buf = buf_priv;
if (!buf-vaddr) {
- printk(KERN_ERR Address of an unallocated plane requested\n);
+ pr_err(Address of an unallocated plane requested
+ or cannot map user pointer\n);
return NULL;
}
@@ -92,13 +156,13 @@ static int vb2_vmalloc_mmap(void *buf_priv, struct
vm_area_struct *vma)
int ret;
Re: [PATCH] it913x add support for IT9135 9006 devices
W dniu 2011-12-14 07:13, Adeq pisze: Malcolm Priestleytvboxspyat gmail.com writes: Support for IT1935 9006 devices. 9006 have version 2 type chip. 9006 devices should use dvb-usb-it9135-02.fw firmware. On the device tested the tuner id was set to 0 which meant the driver used tuner id 0x38. The device functioned normally. Hello, my device (048d:9006) isn't fully working, here is dmesg log: [code] [ 281.724044] usb 1-3: new high-speed USB device number 10 using ehci_hcd [ 281.860585] usb 1-3: New USB device found, idVendor=048d, idProduct=9006 [ 281.860594] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 281.860601] usb 1-3: Product: DVB-T TV Stick [ 281.860607] usb 1-3: Manufacturer: ITE Technologies, Inc. [ 281.861694] it913x: Chip Version=02 Chip Type=9135 [ 281.863193] it913x: Dual mode=0 Remote=1 Tuner Type=0 [ 281.86] dvb-usb: found a 'ITE 9135(9006) Generic' in cold state, will try to load a firmware [ 281.870053] dvb-usb: downloading firmware from file 'dvb-usb-it9135-02.fw' [ 281.870438] it913x: FRM Starting Firmware Download [ 282.388032] it913x: FRM Firmware Download Failed () [ 282.588116] it913x: Chip Version=79 Chip Type=4af3 [ 283.224203] it913x: DEV it913x Error [ 283.227753] input: ITE Technologies, Inc. DVB-T TV Stick as /devices/pci:00/:00:1d.7/usb1/1-3/1-3:1.1/input/input17 [ 283.228415] generic-usb 0003:048D:9006.0007: input,hidraw0: USB HID v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on usb-:00:1d.7-3/input1 or [ 292.444049] usb 1-3: new high-speed USB device number 11 using ehci_hcd [ 292.580449] usb 1-3: New USB device found, idVendor=048d, idProduct=9006 [ 292.580458] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 292.580465] usb 1-3: Product: DVB-T TV Stick [ 292.580471] usb 1-3: Manufacturer: ITE Technologies, Inc. [ 292.581557] it913x: Chip Version=02 Chip Type=9135 [ 292.583051] it913x: Dual mode=0 Remote=1 Tuner Type=0 [ 292.584284] dvb-usb: found a 'ITE 9135(9006) Generic' in cold state, will try to load a firmware [ 292.589938] dvb-usb: downloading firmware from file 'dvb-usb-it9135-02.fw' [ 292.590302] it913x: FRM Starting Firmware Download [ 292.908023] it913x: FRM Firmware Download Completed - Resetting Device [ 292.908534] it913x: Chip Version=02 Chip Type=9135 [ 292.909032] it913x: Firmware Version 52887808 [ 293.144182] it913x: DEV it913x Error [ 293.147862] input: ITE Technologies, Inc. DVB-T TV Stick as /devices/pci:00/:00:1d.7/usb1/1-3/1-3:1.1/input/input18 [ 293.152345] generic-usb 0003:048D:9006.0008: input,hidraw0: USB HID v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on usb-:00:1d.7-3/input1 [/code] I'm using this device: http://www.runteck.com/products_view.php?Id=24S_Id=2 -- 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 After updating firmware. warmboot: [ 984.370447] dvb-usb: ITE 9135(9006) Generic successfully deinitialized and disconnected. [ 1000.884812] it913x: Chip Version=02 Chip Type=9135 [ 1000.885309] it913x: Firmware Version 52887808 [ 1000.886808] it913x: Dual mode=0 Remote=1 Tuner Type=0 [ 1000.886814] dvb-usb: found a 'ITE 9135(9006) Generic' in warm state. [ 1000.887540] dvb-usb: will use the device's hardware PID filter (table count: 31). [ 1000.887857] DVB: registering new adapter (ITE 9135(9006) Generic) [ 1000.891586] it913x-fe: ADF table value :00 [ 1000.891596] it913x: Message out (d8b401313938) [ 1000.892197] it913x: Message out (d8b50100d8b4) [ 1000.892685] it913x: Message out (d8b30100d8b5) [ 1000.893185] it913x: Message out (f6413800d8b3) [ 1000.893560] it913x: Message out (f5ca0100f641) [ 1001.092205] it913x: Message out (f7150100f5ca) [ 1001.292097] it913x: Message out (00256000) [ 1001.492099] it913x: Message out (f1cda200) [ 1001.692107] it913x: Message out (004501dc4cf5) [ 1001.892111] it913x: Message out (0029) [ 1002.092113] it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 01 [ 1002.092141] dvb-usb: no frontend was attached by 'ITE 9135(9006) Generic' [ 1002.092159] Registered IR keymap rc-msi-digivox-iii [ 1002.092392] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-3/rc/rc1/input15 [ 1002.095747] rc1: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-3/rc/rc1 [ 1002.095757] dvb-usb: schedule remote query interval to 250 msecs. [ 1002.095765] dvb-usb: ITE 9135(9006) Generic successfully initialized and connected. [ 1002.095770] it913x: DEV registering device driver [ 1002.095826] usbcore: registered new interface driver it913x coldboot: [ 1103.536156] it913x: Chip Version=ec Chip Type=5830 [ 1104.336178] it913x: Dual mode=92 Remote=92 Tuner Type=92 [ 1106.248116]
Trying to figure out reasons for lost pictures in UVC driver.
Hi, we are testing a logitech Webcam M/N: V-U0012 in the UVC tree (commit ef7728797039bb6a20f22cc2d96ef72d9338cba0). It is configured at 25fps, VGA. We've observed that the following debugging message appears sometimes Frame complete (FID bit toggled).. Whenever this happens a v4l2 frame is lost (i.e. one sequence number has been skipped). Is this behavior expected? What could we do to avoid frame loss? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
On 15-12-2011 10:33, javier Martin wrote: On 15 December 2011 13:01, javier Martin javier.mar...@vista-silicon.com wrote: The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to tvp5150, in order to set the pipelines there. This sounds like a sensible solution I will work on that soon. Hi Mauro, regarding this subject it seems soc-camera assumes the attached sensor has only one input: input 0. This means I am not able to forward S_INPUT/S_ROUTING as you suggested: http://lxr.linux.no/#linux+v3.1.5/drivers/media/video/soc_camera.c#L213 Then, you need to submit a patch for soc_camera, in order to allow it to work with devices that provide more than one input. This trick is clearly a loss of functionality because it restricts sensors to output 0, but it should work since the subsystem can assume a sensor whose inputs have not been configured has input 0 as the one selected. However, this trick in the tvp5150 which selects input 1 (instead of 0) as the default input is breaking that assumption. The solution could be either apply my patch to set input 0 (COMPOSITE0) as default or swap input numbers so that COMPOSITE1 input is input 0. Personally I find my approach more convenient since it matches with the default behavior expected in the datasheet. Both of your described ways are just hacks. tvp5150 has more than one input. So, the bridge should be supporting the selection between them. Regards, Mauro Regards. -- 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
GrabBeeX - empia 2800 USB 2.0 - problem
Hi, I've got these kind of old usb 2.0 grabbers (GrabBeex) based on some em28xx chipsets that are not correctly identified under linux. Here is the dmesg log. A video device is created but there are no controls in v4l-info and dmesg seems to see that everything is probably not correctly detected. I have a few of the so I can send one for testing if needed - but I would be interested in making it working.Also there is no grab button as the dmesg log suggests ! In Windows 7 - the update system finds and installs an empia 2800 driver - appears as an USB 2800 device in the device list. On Windows the are controls and the device works as expected. Thx Adrian [25966.853726] em28xx: New device @ 480 Mbps (eb1a:2800, interface 0, class 0) [25966.853965] em28xx #0: chip ID is em2800 [25966.957709] em28xx #0: board has no eeprom [25967.017502] em28xx #0: preparing read at i2c address 0x60 failed (error=-19) [25967.053604] em28xx #0: Identified as Unknown EM2800 video grabber (card=0) [25968.190585] em28xx #0: found i2c device @ 0x4a [saa7113h] [25970.884130] em28xx #0: Your board has no unique USB ID. [25970.884136] em28xx #0: A hint were successfully done, based on i2c devicelist hash. [25970.884140] em28xx #0: This method is not 100% failproof. [25970.884143] em28xx #0: If the board were missdetected, please email this log to: [25970.884145] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [25970.884149] em28xx #0: Board detected as EM2860/SAA711X Reference Design [25970.884153] em28xx #0: Registering snapshot button... [25970.884278] input: em28xx snapshot button as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/input/input19 [25970.888795] em28xx #0: Config register raw data: 0xa4 [25970.00] em28xx #0: I2S Audio (3 sample rates) [25970.04] em28xx #0: No AC97 audio processor [25970.939649] em28xx #0: v4l2 driver version 0.1.2 [25971.386698] em28xx #0: V4L2 video device registered as video1 [25971.386705] em28xx-audio.c: probing for em28x1 non standard usbaudio [25971.386708] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger lsusb -v -d eb1a:2800 Bus 002 Device 004: ID eb1a:2800 eMPIA Technology, Inc. Terratec Cinergy 200 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0xeb1a eMPIA Technology, Inc. idProduct 0x2800 Terratec Cinergy 200 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 129 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer
Re: [PATCH] it913x add support for IT9135 9006 devices
[ 1103.536156] it913x: Chip Version=ec Chip Type=5830 [ 1104.336178] it913x: Dual mode=92 Remote=92 Tuner Type=92 [ 1106.248116] dvb-usb: found a 'ITE 9135(9006) Generic' in cold state, will try to load a firmware [ 1106.253773] dvb-usb: downloading firmware from file 'dvb-usb-it9135-02.fw' [ 1106.452123] it913x: FRM Starting Firmware Download [ 1130.756039] it913x: FRM Firmware Download Failed (ff92) [ 1130.956168] it913x: Chip Version=79 Chip Type=5823 [ 1131.592192] it913x: DEV it913x Error [ 1131.592271] usbcore: registered new interface driver it913x No frontend is generated anyway. Looks like the the firmware is not at all compatible with your device. Have you applied the patch cleanly to the latest media_build? These appear to be new version of the 9006. A supplier is sending me one of these devices. As a last resort see if the device works with dvb-usb-it9137-01.fw You will have force to use this firmware dvb-usb-it913x firmware=1 For the moment this patch cannot proceed until the firmware has been checked. Regards Malcolm -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Dec 15 19:00:16 CET 2011 git hash:bcc072756e4467dc30e502a311b1c3adec96a0e4 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support to OmniVision Technologies, Inc. VEHO Filmscanner (omnivision 550)
This path add support to OmniVision Technologies, Inc. VEHO Filmscanner.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -ur linux/drivers/media/video/gspca/ov534_9.c linux.new/drivers/media/video/gspca/ov534_9.c
--- linux/drivers/media/video/gspca/ov534_9.c 2011-09-18 05:45:49.0 +0200
+++ linux.new/drivers/media/video/gspca/ov534_9.c 2011-12-15 19:18:14.26459 +0100
@@ -71,6 +71,7 @@
enum sensors {
SENSOR_OV965x, /* ov9657 */
SENSOR_OV971x, /* ov9712 */
+ SENSOR_OV562x, /* ov5621 */
NSENSORS
};
@@ -207,6 +208,14 @@
}
};
+static const struct v4l2_pix_format ov562x_mode[] = {
+ {2592, 1680, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
+ .bytesperline = 2592,
+ .sizeimage = 2592 * 1680,
+ .colorspace = V4L2_COLORSPACE_SRGB
+ }
+};
+
static const u8 bridge_init[][2] = {
{0x88, 0xf8},
{0x89, 0xff},
@@ -830,6 +839,124 @@
{0xa3, 0x41}, /* bd60 */
};
+static const u8 ov562x_init[][2] = {
+ {0x88, 0x20},
+ {0x89, 0x0a},
+ {0x8a, 0x90},
+ {0x8b, 0x06},
+ {0x8c, 0x01},
+ {0x8d, 0x10},
+ {0x1c, 0x00},
+ {0x1d, 0x48},
+ {0x1d, 0x00},
+ {0x1d, 0xff},
+ {0x1c, 0x0a},
+ {0x1d, 0x2e},
+ {0x1d, 0x1e},
+};
+
+static const u8 ov562x_init_2[][2] = {
+ {0x12, 0x80},
+ {0x11, 0x41},
+ {0x13, 0x00},
+ {0x10, 0x1e},
+ {0x3b, 0x07},
+ {0x5b, 0x40},
+ {0x39, 0x07},
+ {0x53, 0x02},
+ {0x54, 0x60},
+ {0x04, 0x20},
+ {0x27, 0x04},
+ {0x3d, 0x40},
+ {0x36, 0x00},
+ {0xc5, 0x04},
+ {0x4e, 0x00},
+ {0x4f, 0x93},
+ {0x50, 0x7b},
+ {0xca, 0x0c},
+ {0xcb, 0x0f},
+ {0x39, 0x07},
+ {0x4a, 0x10},
+ {0x3e, 0x0a},
+ {0x3d, 0x00},
+ {0x0c, 0x38},
+ {0x38, 0x90},
+ {0x46, 0x30},
+ {0x4f, 0x93},
+ {0x50, 0x7b},
+ {0xab, 0x00},
+ {0xca, 0x0c},
+ {0xcb, 0x0f},
+ {0x37, 0x02},
+ {0x44, 0x48},
+ {0x8d, 0x44},
+ {0x2a, 0x00},
+ {0x2b, 0x00},
+ {0x32, 0x00},
+ {0x38, 0x90},
+ {0x53, 0x02},
+ {0x54, 0x60},
+ {0x12, 0x00},
+ {0x17, 0x12},
+ {0x18, 0xb4},
+ {0x19, 0x0c},
+ {0x1a, 0xf4},
+ {0x03, 0x4a},
+ {0x89, 0x20},
+ {0x83, 0x80},
+ {0xb7, 0x9d},
+ {0xb6, 0x11},
+ {0xb5, 0x55},
+ {0xb4, 0x00},
+ {0xa9, 0xf0},
+ {0xa8, 0x0a},
+ {0xb8, 0xf0},
+ {0xb9, 0xf0},
+ {0xba, 0xf0},
+ {0x81, 0x07},
+ {0x63, 0x44},
+ {0x13, 0xc7},
+ {0x14, 0x60},
+ {0x33, 0x75},
+ {0x2c, 0x00},
+ {0x09, 0x00},
+ {0x35, 0x30},
+ {0x27, 0x04},
+ {0x3c, 0x07},
+ {0x3a, 0x0a},
+ {0x3b, 0x07},
+ {0x01, 0x40},
+ {0x02, 0x40},
+ {0x16, 0x40},
+ {0x52, 0xb0},
+ {0x51, 0x83},
+ {0x21, 0xbb},
+ {0x22, 0x10},
+ {0x23, 0x03},
+ {0x35, 0x38},
+ {0x20, 0x90},
+ {0x28, 0x30},
+ {0x73, 0xe1},
+ {0x6c, 0x00},
+ {0x6d, 0x80},
+ {0x6e, 0x00},
+ {0x70, 0x04},
+ {0x71, 0x00},
+ {0x8d, 0x04},
+ {0x64, 0x00},
+ {0x65, 0x00},
+ {0x66, 0x00},
+ {0x67, 0x00},
+ {0x68, 0x00},
+ {0x69, 0x00},
+ {0x6a, 0x00},
+ {0x6b, 0x00},
+ {0x71, 0x94},
+ {0x74, 0x20},
+ {0x80, 0x09},
+ {0x85, 0xc0},
+};
+
static void reg_w_i(struct gspca_dev *gspca_dev, u16 reg, u8 val)
{
struct usb_device *udev = gspca_dev-dev;
@@ -1210,6 +1337,17 @@
reg_w(gspca_dev, 0x56, 0x1f);
else
reg_w(gspca_dev, 0x56, 0x17);
+ } else if ((sensor_id 0xfff0) == 0x5620) {
+ sd-sensor = SENSOR_OV562x;
+
+ gspca_dev-cam.cam_mode = ov562x_mode;
+ gspca_dev-cam.nmodes = ARRAY_SIZE(ov562x_mode);
+
+ reg_w_array(gspca_dev, ov562x_init,
+ARRAY_SIZE(ov562x_init));
+ sccb_w_array(gspca_dev, ov562x_init_2,
+ARRAY_SIZE(ov562x_init_2));
+ reg_w(gspca_dev, 0xe0, 0x00);
} else {
err(Unknown sensor %04x, sensor_id);
return -EINVAL;
@@ -1222,7 +1360,7 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- if (sd-sensor == SENSOR_OV971x)
+ if (sd-sensor == SENSOR_OV971x || sd-sensor == SENSOR_OV562x)
return gspca_dev-usb_err;
switch (gspca_dev-curr_mode) {
case QVGA_MODE: /* 320x240 */
@@ -1409,6 +1547,7 @@
static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x05a9, 0x8065)},
{USB_DEVICE(0x06f8, 0x3003)},
+ {USB_DEVICE(0x05a9, 0x1550)},
{}
};
Re: [RFC 1/3] v4l: Add pixel clock to struct v4l2_mbus_framefmt
Hi Sakari,
thanks for the patch.
On 12/14/2011 04:22 PM, Sakari Ailus wrote:
Pixel clock is an essential part of the image data parameters. Add this.
Together, the current parameters also define the frame rate.
Sensors do not have a concept of frame rate; pixel clock is much more
meaningful in this context. Also, it is best to combine the pixel clock with
the other format parameters since there are dependencies between them.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/DocBook/media/v4l/subdev-formats.xml |9 -
include/linux/v4l2-mediabus.h |4 +++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..b4591ef 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -35,7 +35,14 @@
/row
row
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldpixel_clock/structfield/entry
+ entryPixel clock in kHz. This clock is the maximum rate at
+ which pixels are transferred on the bus. The pixel_clock
+ field is read-only./entry
I searched a couple of datasheets to find out where I could use this pixel_clock
field but didn't find any so far. I haven't tried too hard though ;)
There seems to be more benefits from having the link frequency control.
It might be easy to confuse pixel_clock with the bus clock. The bus clock is
often referred in datasheets as Pixel Clock (PCLK, AFAIU it's described with
link frequency in your RFC). IMHO your original proposal was better, i.e.
using more explicit pixel_rate. Also why it is in kHz ? Doesn't it make more
sense to use bits or pixels per second ?
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved/structfield[6]/entry
entryReserved for future extensions. Applications and drivers must
set the array to zero./entry
/row
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..76a0df2 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
* @code:data format code (from enum v4l2_mbus_pixelcode)
* @field: used interlacing type (from enum v4l2_field)
* @colorspace: colorspace of the data (from enum v4l2_colorspace)
+ * @pixel_clock: pixel clock, in kHz
*/
struct v4l2_mbus_framefmt {
__u32 width;
@@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
__u32 code;
__u32 field;
__u32 colorspace;
- __u32 reserved[7];
+ __u32 pixel_clock;
I'm wondering, whether it is worth to make it 'pixelclock' for consistency
with other fields? Perhaps it would make more sense to have color_space and
pixel_clock.
+ __u32 reserved[6];
};
#endif
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] omap3isp: Configure CSI-2 phy based on platform data
Hi Laurent,
On Thu, Dec 15, 2011 at 01:54:52PM +0100, Laurent Pinchart wrote:
Hi Sakari,
On Thursday 15 December 2011 12:53:03 Sakari Ailus wrote:
On Thu, Dec 15, 2011 at 11:28:06AM +0100, Laurent Pinchart wrote:
On Thursday 15 December 2011 10:50:34 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver rather
than in platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c index 5be37ce..52af308
100644 --- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
[snip]
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev,
+ struct v4l2_subdev *sensor,
+ struct v4l2_mbus_framefmt *sensor_fmt)
The number of lanes can depend on the format. Wouldn't it be better to
add a subdev operation to query the sensor for its bus configuration
instead of relying on ISP platform data ?
In principle, yes. That's an interesting point; how this kind of information
would best be delivered?
There are two separate information that need to be delivered:
- how the lanes are connected on the board
- which lanes are used by the sensor, and for what purpose
The first information must be supplied through platform data, either to the
sensor driver or the OMAP3 ISP driver (or both). As the second information
Both, and both of them may require configuring it. I don't know sensors that
allow it, but the CSI-2 receiver is flexible in lane mapping.
comes from the sensor, my idea was to provide the first to the sensor, and to
query the sensor in the OMAP3 ISP driver for the full configuration.
In theory, at least, configurations with less lanes need to be specified
separately. There may be limitations on how the lanes can be used, say,
using two out of three lanes may require leaving a aparticular lane unused.
The number of lanes might be something the user would want to touch, but
I'm not entirely sure. You achieve more functionality by providing that
flexibility to the user but I don't see need for configuring that ---
still getting the number of lanes could be interesting.
If we want to expose such configuration I think we should do it on the
sensor,
not the ISP.
I agree.
...
@@ -355,6 +358,22 @@ static int isp_video_validate_pipeline(struct
isp_pipeline *pipe) fmt_source.format.height != fmt_sink.format.height)
return -EPIPE;
+ /* Configure CSI-2 receiver based on sensor format. */
+ if (_subdev == isp-isp_csi2a.subdev
+ || _subdev == isp-isp_csi2c.subdev) {
+ if (cpu_is_omap3630()) {
+ /*
+* FIXME: CSI-2 is supported only on
+* the 3630!
+*/
Is it ? Or do you mean by the driver ? What would it take to support it
on OMAP34xx and OMAP35xx ?
I have no way to test it on the OMAP 3430 since I have no CSI-2 sensor
connected to it. As a matter of fact I've never had one, so I don't really
know.
What about assuming it works on the 34xx and 35xx as well ?
I'll change it so.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] v4l: Add pixel clock to struct v4l2_mbus_framefmt
Hi Sylwester,
Thanks for the comments!
On Thu, Dec 15, 2011 at 10:46:22PM +0100, Sylwester Nawrocki wrote:
Hi Sakari,
thanks for the patch.
On 12/14/2011 04:22 PM, Sakari Ailus wrote:
Pixel clock is an essential part of the image data parameters. Add this.
Together, the current parameters also define the frame rate.
Sensors do not have a concept of frame rate; pixel clock is much more
meaningful in this context. Also, it is best to combine the pixel clock with
the other format parameters since there are dependencies between them.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/DocBook/media/v4l/subdev-formats.xml |9 -
include/linux/v4l2-mediabus.h |4 +++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..b4591ef 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -35,7 +35,14 @@
/row
row
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldpixel_clock/structfield/entry
+ entryPixel clock in kHz. This clock is the maximum rate at
+ which pixels are transferred on the bus. The pixel_clock
+ field is read-only./entry
I searched a couple of datasheets to find out where I could use this
pixel_clock
field but didn't find any so far. I haven't tried too hard though ;)
There seems to be more benefits from having the link frequency control.
There are a few reasons to have the pixel clock available to the user space.
The previously existing reason is that the user may get information on the
pixel rates, including cases where the pixel rate of a subdev isn't enough
for the streaming to be possible. Earlier on it just failed. Such cases are
common on the OMAP 3 ISP, for example.
The second reason is to provide that for timing calculations in the user
space.
It might be easy to confuse pixel_clock with the bus clock. The bus clock is
often referred in datasheets as Pixel Clock (PCLK, AFAIU it's described with
link frequency in your RFC). IMHO your original proposal was better, i.e.
using more explicit pixel_rate. Also why it is in kHz ? Doesn't it make more
sense to use bits or pixels per second ?
Oh, yes, now that you mention it I did call it pixel rate. I'm fine
withrenaming it back to e.g. pixelrate.
I picked kHz since the 32-bit field would allow rates up to 4 GiP/s. Not
sure if that's overkill though. Could be. But in practice it should give
good enough precision this way, too.
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved/structfield[6]/entry
entryReserved for future extensions. Applications and drivers must
set the array to zero./entry
/row
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..76a0df2 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
* @code: data format code (from enum v4l2_mbus_pixelcode)
* @field: used interlacing type (from enum v4l2_field)
* @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ * @pixel_clock: pixel clock, in kHz
*/
struct v4l2_mbus_framefmt {
__u32 width;
@@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
__u32 code;
__u32 field;
__u32 colorspace;
- __u32 reserved[7];
+ __u32 pixel_clock;
I'm wondering, whether it is worth to make it 'pixelclock' for consistency
with other fields? Perhaps it would make more sense to have color_space and
pixel_clock.
pixelrate is fine for me.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] v4l: Add pixel clock to struct v4l2_mbus_framefmt
On 12/15/2011 11:01 PM, Sakari Ailus wrote:
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldpixel_clock/structfield/entry
+ entryPixel clock in kHz. This clock is the maximum rate at
+ which pixels are transferred on the bus. The pixel_clock
+ field is read-only./entry
I searched a couple of datasheets to find out where I could use this
pixel_clock
field but didn't find any so far. I haven't tried too hard though ;)
There seems to be more benefits from having the link frequency control.
There are a few reasons to have the pixel clock available to the user space.
The previously existing reason is that the user may get information on the
pixel rates, including cases where the pixel rate of a subdev isn't enough
for the streaming to be possible. Earlier on it just failed. Such cases are
common on the OMAP 3 ISP, for example.
The second reason is to provide that for timing calculations in the user
space.
Fair enough. Perhaps, if I have worked more with image signal processing
algorithms in user space I would not ask about that in the first place :-)
It might be easy to confuse pixel_clock with the bus clock. The bus clock is
often referred in datasheets as Pixel Clock (PCLK, AFAIU it's described with
link frequency in your RFC). IMHO your original proposal was better, i.e.
using more explicit pixel_rate. Also why it is in kHz ? Doesn't it make more
sense to use bits or pixels per second ?
Oh, yes, now that you mention it I did call it pixel rate. I'm fine
withrenaming it back to e.g. pixelrate.
I'm fine with that too, sounds good!
I picked kHz since the 32-bit field would allow rates up to 4 GiP/s. Not
sure if that's overkill though. Could be. But in practice it should give
good enough precision this way, too.
All right, however I was more concerned by the Hz part, rather than k ;)
It might be good to have the relevant unit defined in the spec, to avoid
misinterpretation and future interoperability issues .
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved/structfield[6]/entry
entryReserved for future extensions. Applications and drivers must
set the array to zero./entry
/row
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..76a0df2 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
* @code: data format code (from enum v4l2_mbus_pixelcode)
* @field: used interlacing type (from enum v4l2_field)
* @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ * @pixel_clock: pixel clock, in kHz
*/
struct v4l2_mbus_framefmt {
__u32 width;
@@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
__u32 code;
__u32 field;
__u32 colorspace;
- __u32 reserved[7];
+ __u32 pixel_clock;
I'm wondering, whether it is worth to make it 'pixelclock' for consistency
with other fields? Perhaps it would make more sense to have color_space and
pixel_clock.
pixelrate is fine for me.
Ack.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] it913x changed firmware loader for chip version 2 types
On Thu, 2011-12-15 at 16:42 +, Malcolm Priestley wrote:
[ 1103.536156] it913x: Chip Version=ec Chip Type=5830
[ 1104.336178] it913x: Dual mode=92 Remote=92 Tuner Type=92
[ 1106.248116] dvb-usb: found a 'ITE 9135(9006) Generic' in cold state,
will try to load a firmware
[ 1106.253773] dvb-usb: downloading firmware from file
'dvb-usb-it9135-02.fw'
[ 1106.452123] it913x: FRM Starting Firmware Download
[ 1130.756039] it913x: FRM Firmware Download Failed (ff92)
[ 1130.956168] it913x: Chip Version=79 Chip Type=5823
[ 1131.592192] it913x: DEV it913x Error
[ 1131.592271] usbcore: registered new interface driver it913x
No frontend is generated anyway.
Looks like the the firmware is not at all compatible with your device.
Have you applied the patch cleanly to the latest media_build?
These appear to be new version of the 9006. A supplier is sending me one
of these devices.
As a last resort see if the device works with dvb-usb-it9137-01.fw
You will have force to use this firmware
dvb-usb-it913x firmware=1
Here is a modified firmware loader for version 2 types.
The firmware must be as in original
./dvb_get_firmware it9135
dd if=dvb-usb-it9135.fw ibs=1 skip=12866 count=5817 of=dvb-usb-it9135-02.fw
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 6f6072b..9290bd8 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -557,7 +557,7 @@ static int it913x_download_firmware(struct usb_device *udev,
const struct firmware *fw)
{
int ret = 0, i = 0, pos = 0;
- u8 packet_size;
+ u8 packet_size, min_pkt;
u8 *fw_data;
ret = it913x_wr_reg(udev, DEV_0, I2C_CLK, I2C_CLK_100);
@@ -569,11 +569,16 @@ static int it913x_download_firmware(struct usb_device
*udev,
/* The firmware must start with 03 XX 00 */
/* and be the extact firmware length */
+ if (it913x_config.chip_ver == 2)
+ min_pkt = 0x11;
+ else
+ min_pkt = 0x19;
+
while (i = fw-size) {
if (((fw-data[i] == 0x3) (fw-data[i + 2] == 0x0))
|| (i == fw-size)) {
packet_size = i - pos;
- if ((packet_size 0x19) || (i == fw-size)) {
+ if ((packet_size min_pkt) || (i == fw-size)) {
fw_data = (u8 *)(fw-data + pos);
pos += packet_size;
if (packet_size 0)
--
1.7.7.3
--
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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi Michael, On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, On 12/15/2011 10:49 AM, James wrote: Hi Michael, On Thu, Dec 15, 2011 at 3:58 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, On 12/15/2011 08:14 AM, James wrote: Hi all, I'm using an OMAP3530 board and a monochrome 12-bit grey sensor. Can anyone enlighten me why is the 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output? There are 2 CCDC outputs: CCDC_PAD_SOURCE_OF and CCDC_PAD_SOURCE_VP. Only the VP (video port) truncates data to 10 bits, and it does that because the subdevs it feeds can only handle 10 bits max. Thank you for the clarification. I need to read the entire RAW 12-bit grey value from the CCDC to memory and the data does not pass through other OMAP3ISP sub-devices. I intend to use Laurent's yavta to capture the data to file to verify its operation for the moment. Can this 12-bit (Y12) raw capture be done? Yes. If you are writing the 12-bit gray value directly into memory, you will use SOURCE_OF and can write the full 12-bits into memory. You need to set up your media pipeline to do sensor-CCDC-OMAP3 ISP CCDC output. Is there further modification needed to apply to the OMAP3ISP to achieve this? Do you have an application to test the pipeline for this setting to simple display? Let's establish where you're coming from. Are you familiar with the media controller? Laurent has a program 'media-ctl' to set up the pipeline (see http://git.ideasonboard.org/?p=media-ctl.git). You will find many examples of its usage in the archives of this mailing list. It will look something like: media-ctl -r media-ctl -l 'OMAP3 ISP CCDC:1 - OMAP3 ISP CCDC output:0 [1]' media-ctl -l 'your-sensor-name:0 - OMAP3 ISP CCDC:0 [1]' you will also need to set the formats through the pipeline with 'media-ctl --set-format'. After you use media-ctl to set up the pipeline, you can use yavta to capture the data from the CCDC output (for me, this is /dev/video2). Yes, I've been using Laurent's media-ctl yavta to test out MT9V032 on the Overo board. He has been helping and guiding me with it as there isn't any success with using MT9V032 on the Overo board then. (^^) What I've been looking for since then is any other application such as GUI MPlayer or gst-launch that can open the device and playback the data to either LCD or DVI display on the board. (i.e. direct 'streaming') Do you know of any? I wish to avoid any further components (e.g. ffmpeg) that modify/convert the raw data as much as possible. sensor-CCDC-application-display Many thanks in adv. -- Regards, James -- 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
LME2510 Sharp 0194A DVB-S
I have a DM04 DVB-S USB box which doesn't seem to be supported with the kernel 3.x dvb-usb-lmedm04 driver although it seems very close. The firmware is loaded the tuner seems to be identified but it fails to attach the tuner? It has a LME2510 chip and the tuner has Sharp F7HZ0194A on it. This is the debug trace: LME2510(C): Firmware Status: 6 (44) LME2510(C): FRM Loading dvb-usb-lme2510-s0194.fw file LME2510(C): FRM Starting Firmware Download LME2510(C): FRM Firmware Download Completed - Resetting Device usbcore: registered new interface driver LME2510C_DVB-S usb 1-2: USB disconnect, device number 3 usb 1-2: new high speed USB device number 7 using ehci_hcd usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x87 has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x3 has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0xA has invalid maxpacket 64usb 1-2: New USB device found, idVendor=3344, idProduct=1122 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=3 usb 1-2: SerialNumber: 䥈児 LME2510(C): Firmware Status: 6 (47) dvb-usb: found a 'DM04_LME2510_DVB-S' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 15). DVB: registering new adapter (DM04_LME2510_DVB-S) LME2510(C): DM04 Not Supported dvb-usb: no frontend was attached by 'DM04_LME2510_DVB-S' Registered IR keymap rc-lme2510 input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0b.1/usb1/1-2/rc/rc2/input11 rc2: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0b.1/usb1/1-2/rc/rc2 dvb-usb: DM04_LME2510_DVB-S successfully initialized and connected. LME2510(C): DEV registering device driver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/8] omap4: introduce fdif(face detect module) hwmod
Hi Benoît
On Wed, 14 Dec 2011, Ming Lei wrote:
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
any comments on this patch? I'd like to queue it if it looks good to you.
- Paul
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6cf21ee..30db754 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -53,6 +53,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
static struct omap_hwmod omap44xx_dss_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
+static struct omap_hwmod omap44xx_fdif_hwmod;
static struct omap_hwmod omap44xx_hsi_hwmod;
static struct omap_hwmod omap44xx_ipu_hwmod;
static struct omap_hwmod omap44xx_iss_hwmod;
@@ -354,6 +355,14 @@ static struct omap_hwmod_ocp_if
omap44xx_dma_system__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* fdif - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_fdif__l3_main_2 = {
+ .master = omap44xx_fdif_hwmod,
+ .slave = omap44xx_l3_main_2_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* hsi - l3_main_2 */
static struct omap_hwmod_ocp_if omap44xx_hsi__l3_main_2 = {
.master = omap44xx_hsi_hwmod,
@@ -5444,6 +5453,75 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
};
+/* 'fdif' class */
+static struct omap_hwmod_class_sysconfig omap44xx_fdif_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO |
+MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_fdif_hwmod_class = {
+ .name = fdif,
+ .sysc = omap44xx_fdif_sysc,
+};
+
+/*fdif*/
+static struct omap_hwmod_addr_space omap44xx_fdif_addrs[] = {
+ {
+ .pa_start = 0x4a10a000,
+ .pa_end = 0x4a10afff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - fdif */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__fdif = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_fdif_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_fdif_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* fdif slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_slaves[] = {
+ omap44xx_l4_cfg__fdif,
+};
+static struct omap_hwmod_irq_info omap44xx_fdif_irqs[] = {
+ { .irq = 69 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+/* fdif master ports */
+static struct omap_hwmod_ocp_if *omap44xx_fdif_masters[] = {
+ omap44xx_fdif__l3_main_2,
+};
+
+static struct omap_hwmod omap44xx_fdif_hwmod = {
+ .name = fdif,
+ .class = omap44xx_fdif_hwmod_class,
+ .clkdm_name = iss_clkdm,
+ .mpu_irqs = omap44xx_fdif_irqs,
+ .main_clk = fdif_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_CAM_FDIF_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_CAM_FDIF_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_fdif_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_fdif_slaves),
+ .masters= omap44xx_fdif_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_fdif_masters),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -5593,6 +5671,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
= {
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+ /* fdif class */
+ omap44xx_fdif_hwmod,
+
NULL,
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
Re: LME2510 Sharp 0194A DVB-S
On Fri, 2011-12-16 at 16:06 +1100, Andrew Congdon wrote: I have a DM04 DVB-S USB box which doesn't seem to be supported with the kernel 3.x dvb-usb-lmedm04 driver although it seems very close. The firmware is loaded the tuner seems to be identified but it fails to attach the tuner? It has a LME2510 chip and the tuner has Sharp F7HZ0194A on it. I have this type of box in use every day. The power adapter must be plugged in for the tuner to attach. Or the power adapter has become faulty. USB power supplies the bridge. PSU supplies the tuner. This is the debug trace: LME2510(C): Firmware Status: 6 (44) LME2510(C): FRM Loading dvb-usb-lme2510-s0194.fw file LME2510(C): FRM Starting Firmware Download LME2510(C): FRM Firmware Download Completed - Resetting Device usbcore: registered new interface driver LME2510C_DVB-S usb 1-2: USB disconnect, device number 3 usb 1-2: new high speed USB device number 7 using ehci_hcd usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x87 has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x3 has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 usb 1-2: config 1 interface 0 altsetting 1 bulk endpoint 0xA has invalid maxpacket 64usb 1-2: New USB device found, idVendor=3344, idProduct=1122 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=3 usb 1-2: SerialNumber: 䥈児 LME2510(C): Firmware Status: 6 (47) dvb-usb: found a 'DM04_LME2510_DVB-S' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 15). DVB: registering new adapter (DM04_LME2510_DVB-S) LME2510(C): DM04 Not Supported dvb-usb: no frontend was attached by 'DM04_LME2510_DVB-S' Registered IR keymap rc-lme2510 input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0b.1/usb1/1-2/rc/rc2/input11 rc2: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:0b.1/usb1/1-2/rc/rc2 dvb-usb: DM04_LME2510_DVB-S successfully initialized and connected. LME2510(C): DEV registering device driver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] v4l: Add pixel clock to struct v4l2_mbus_framefmt
Hi Sylwester, On Thu, Dec 15, 2011 at 11:19:40PM +0100, Sylwester Nawrocki wrote: On 12/15/2011 11:01 PM, Sakari Ailus wrote: entry__u32/entry - entrystructfieldreserved/structfield[7]/entry + entrystructfieldpixel_clock/structfield/entry + entryPixel clock in kHz. This clock is the maximum rate at + which pixels are transferred on the bus. The pixel_clock + field is read-only./entry I searched a couple of datasheets to find out where I could use this pixel_clock field but didn't find any so far. I haven't tried too hard though ;) There seems to be more benefits from having the link frequency control. There are a few reasons to have the pixel clock available to the user space. The previously existing reason is that the user may get information on the pixel rates, including cases where the pixel rate of a subdev isn't enough for the streaming to be possible. Earlier on it just failed. Such cases are common on the OMAP 3 ISP, for example. The second reason is to provide that for timing calculations in the user space. Fair enough. Perhaps, if I have worked more with image signal processing algorithms in user space I would not ask about that in the first place :-) It's not only the algorithms, but it gives you a way to perform low level sensor configuration. It gives the user an easy way to configure the frame rate freely between a range which is easy to obtain, and also taking into account the policy decisions instead of the kernel doing them for the user. There's more in the parent, albeit I forgot to mention the above: URL:http://www.spinics.net/lists/linux-media/msg40861.html It might be easy to confuse pixel_clock with the bus clock. The bus clock is often referred in datasheets as Pixel Clock (PCLK, AFAIU it's described with link frequency in your RFC). IMHO your original proposal was better, i.e. using more explicit pixel_rate. Also why it is in kHz ? Doesn't it make more sense to use bits or pixels per second ? Oh, yes, now that you mention it I did call it pixel rate. I'm fine withrenaming it back to e.g. pixelrate. I'm fine with that too, sounds good! I picked kHz since the 32-bit field would allow rates up to 4 GiP/s. Not sure if that's overkill though. Could be. But in practice it should give good enough precision this way, too. All right, however I was more concerned by the Hz part, rather than k ;) It might be good to have the relevant unit defined in the spec, to avoid misinterpretation and future interoperability issues . Indeed. kp/s then? :-) Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
