Re: [PATCH] media: vb2: add a check for uninitialized buffer
Hi Marek,
I think there is a typo in this patch:
On Wed, Oct 12, 2011 at 09:12, Marek Szyprowski
m.szyprow...@samsung.com wrote:
__buffer_in_use() might be called for empty/uninitialized buffer in the
following scenario: REQBUF(n, USER_PTR), QUERYBUF(). This patch fixes
kernel ops in such case.
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 | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index d8affb8..cdbbab7 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -284,14 +284,14 @@ static bool __buffer_in_use(struct vb2_queue *q, struct
vb2_buffer *vb)
{
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
+ void mem_priv = vb-planes[plane].mem_priv;
Shouldn't this be void * instead of just void?
/*
* If num_users() has not been provided, call_memop
* will return 0, apparently nobody cares about this
* case anyway. If num_users() returns more than 1,
* we are not the only user of the plane's memory.
*/
- if (call_memop(q, plane, num_users,
- vb-planes[plane].mem_priv) 1)
+ if (mem_priv call_memop(q, plane, num_users, mem_priv) 1)
return true;
}
return false;
--
1.7.1.569.g6f426
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: fix incorrect return value
On Mon, Oct 3, 2011 at 00:21, Marek Szyprowski m.szyprow...@samsung.com wrote:
This patch fixes incorrect return value. Errors should be returned
as negative numbers.
Reported-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 6687ac3..3f5c7a3 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -751,7 +751,7 @@ static int __qbuf_userptr(struct vb2_buffer *vb, struct
v4l2_buffer *b)
/* Check if the provided plane buffer is large enough */
if (planes[plane].length q-plane_sizes[plane]) {
- ret = EINVAL;
+ ret = -EINVAL;
goto err;
}
--
1.7.1.569.g6f426
Acked-by: Pawel Osciak pa...@osciak.com
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] media: vb2: add a check for uninitialized buffer
Hello,
On Wednesday, October 19, 2011 8:03 AM Pawel Osciak wrote:
Hi Marek,
I think there is a typo in this patch:
On Wed, Oct 12, 2011 at 09:12, Marek Szyprowski
m.szyprow...@samsung.com wrote:
__buffer_in_use() might be called for empty/uninitialized buffer in the
following scenario: REQBUF(n, USER_PTR), QUERYBUF(). This patch fixes
kernel ops in such case.
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 | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index d8affb8..cdbbab7 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -284,14 +284,14 @@ static bool __buffer_in_use(struct vb2_queue *q,
struct vb2_buffer
*vb)
{
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
+ void mem_priv = vb-planes[plane].mem_priv;
Shouldn't this be void * instead of just void?
Yes, it should be. It looks that I've posted an older version. In the pull
request there is a correct version.
/*
* If num_users() has not been provided, call_memop
* will return 0, apparently nobody cares about this
* case anyway. If num_users() returns more than 1,
* we are not the only user of the plane's memory.
*/
- if (call_memop(q, plane, num_users,
- vb-planes[plane].mem_priv) 1)
+ if (mem_priv call_memop(q, plane, num_users, mem_priv)
1)
return true;
}
return false;
--
1.7.1.569.g6f426
Best regards
--
Marek Szyprowski
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
Re: omap3isp: BT.656 support
On Tue, Oct 18, 2011 at 7:31 PM, Enrico ebut...@users.berlios.de wrote: On Tue, Oct 18, 2011 at 3:33 PM, Boris Todorov boris.st.todo...@gmail.com wrote: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I can see data from TVP5151 but there are no interrupts in ISP. You can try if this: http://www.spinics.net/lists/linux-media/msg37795.html makes it work. Tried it but it's doesn't work for me. When yavta calls VIDIOC_DQBUF I'm stuck here: omap3isp_video_queue_dqbuf() - isp_video_buffer_wait() Wait for a buffer to be ready with O_NONBLOCK Btw my kernel is 2.6.35 but ISP and V4L are taken from omap3isp-omap3isp-yuv and according ISP/TVP register settings everything should be OK... Enrico -- 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/3] soc-camera: mt9t112: modify delay time after initialize
Hi Guennadi, Morimoto-san, Both are needed. These are bug fix patches I tried to capture several frames beginning with the very first one (as much as performance allowed), and I do see several black or wrongly coloured framed in the beginning, but none of those patches, including the proposed 300ms at the end of .s_stream() fixes the problem reliably. So, either this problems, that these patches fix, are specific to the Solution Engine board (is it the one, where the problems have been observed?), or one needs a different testing method. If they are SE-specific - I don't think, getting those fixes in the driver is very important, because mt9t112 data for SE is not in the mainline. If I was testing wrongly, please, tell me how exactly to reproduce those problems and see, how one or another patch fixes them. I guess mt9t112 camera is used in SE (with local circuit ?) and Ecovec. But I forgot detail of this issue (I have no mt9t112 for now). I think Phil is the person who wanted this patch. There are capture issues on the Ecovec board with this camera. iirc, these patches made the situation better but still didn't completely fix all issues. Morimoto-san has made comments previously that the mt9t112 is a little difficult to setup and we don't have the relevant information from the manufacturer. Thanks Phil -- 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 9:01 AM, Boris Todorov boris.st.todo...@gmail.com wrote: On Tue, Oct 18, 2011 at 7:31 PM, Enrico ebut...@users.berlios.de wrote: You can try if this: http://www.spinics.net/lists/linux-media/msg37795.html makes it work. Tried it but it's doesn't work for me. When yavta calls VIDIOC_DQBUF I'm stuck here: omap3isp_video_queue_dqbuf() - isp_video_buffer_wait() Wait for a buffer to be ready with O_NONBLOCK Btw my kernel is 2.6.35 but ISP and V4L are taken from omap3isp-omap3isp-yuv and according ISP/TVP register settings everything should be OK... When you stop yavta you should have in the kernel log something like this (this comes from an old log i'm not 100% sure they are the correct values): [ 655.470581] omap3isp omap3isp: ###CCDC PCR=0x [ 655.475677] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 655.481231] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 655.486816] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 655.492431] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 655.498046] omap3isp omap3isp: ###CCDC VERT_START=0x [ 655.503784] omap3isp omap3isp: ###CCDC VERT_LINES=0x0139 [ 655.509460] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 655.514892] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 655.520507] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 655.525848] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 655.531372] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 655.536651] omap3isp omap3isp: ###CCDC DCSUB=0x0040 [ 655.541900] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 655.547271] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 655.552612] omap3isp omap3isp: ###CCDC FPC=0x [ 655.557708] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 655.563232] omap3isp omap3isp: ###CCDC VDINT=0x013800d1 [ 655.568511] omap3isp omap3isp: ###CCDC ALAW=0x [ 655.573669] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 655.579193] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 655.584289] omap3isp omap3isp: ###CCDC FMTCFG=0xe000 [ 655.589660] omap3isp omap3isp: ###CCDC FMT_HORZ=0x [ 655.595184] omap3isp omap3isp: ###CCDC FMT_VERT=0x [ 655.600769] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 655.606323] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 655.611816] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 655.617279] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 655.622711] omap3isp omap3isp: ###CCDC VP_OUT=0x [ 655.628051] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 655.633758] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 655.639556] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 655.645599] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x Send your values so we can try to see where the problem is. Enrico -- 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 11:28 AM, Enrico ebut...@users.berlios.de wrote: On Wed, Oct 19, 2011 at 9:01 AM, Boris Todorov boris.st.todo...@gmail.com wrote: On Tue, Oct 18, 2011 at 7:31 PM, Enrico ebut...@users.berlios.de wrote: You can try if this: http://www.spinics.net/lists/linux-media/msg37795.html makes it work. Tried it but it's doesn't work for me. When yavta calls VIDIOC_DQBUF I'm stuck here: omap3isp_video_queue_dqbuf() - isp_video_buffer_wait() Wait for a buffer to be ready with O_NONBLOCK Btw my kernel is 2.6.35 but ISP and V4L are taken from omap3isp-omap3isp-yuv and according ISP/TVP register settings everything should be OK... When you stop yavta you should have in the kernel log something like this (this comes from an old log i'm not 100% sure they are the correct values): [ 655.470581] omap3isp omap3isp: ###CCDC PCR=0x [ 655.475677] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 655.481231] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 655.486816] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 655.492431] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 655.498046] omap3isp omap3isp: ###CCDC VERT_START=0x [ 655.503784] omap3isp omap3isp: ###CCDC VERT_LINES=0x0139 [ 655.509460] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 655.514892] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 655.520507] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 655.525848] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 655.531372] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 655.536651] omap3isp omap3isp: ###CCDC DCSUB=0x0040 [ 655.541900] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 655.547271] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 655.552612] omap3isp omap3isp: ###CCDC FPC=0x [ 655.557708] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 655.563232] omap3isp omap3isp: ###CCDC VDINT=0x013800d1 [ 655.568511] omap3isp omap3isp: ###CCDC ALAW=0x [ 655.573669] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 655.579193] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 655.584289] omap3isp omap3isp: ###CCDC FMTCFG=0xe000 [ 655.589660] omap3isp omap3isp: ###CCDC FMT_HORZ=0x [ 655.595184] omap3isp omap3isp: ###CCDC FMT_VERT=0x [ 655.600769] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 655.606323] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 655.611816] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 655.617279] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 655.622711] omap3isp omap3isp: ###CCDC VP_OUT=0x [ 655.628051] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 655.633758] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 655.639556] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 655.645599] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x Send your values so we can try to see where the problem is. Enrico I really appreciate your help. Here is my log: [ 24.683685] omap3isp omap3isp: -CCDC Register dump- [ 24.683685] omap3isp omap3isp: ###CCDC PCR=0x [ 24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x [ 24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105 [ 24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x [ 24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x [ 24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 24.683837] omap3isp omap3isp: ###CCDC FPC=0x [ 24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104 [ 24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d [ 24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 24.684020]
[PATCH] [media] em28xx: implement VIDIOC_ENUM_FRAMESIZES
Pidgin uses gstreamer (and libv4l) to work. Without implementing this ioctl,
it won't detect properly the size range, and driver will fail.
So, this patch is required, in order to use an em27xx webcam, like
Silvercrest.
The pigdin/gstreamer/libv4l needs to be fixed, as it shouldn't assume
that all drivers will implement this optional ioctl, but, at least now,
devices with em28xx have a better chance of working with pidgin.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/em28xx/em28xx-video.c | 41 -
1 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 62182e3..9b4557a 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1802,6 +1802,45 @@ static int vidioc_enum_fmt_vid_cap(struct file *file,
void *priv,
return 0;
}
+static int vidioc_enum_framesizes(struct file *file, void *priv,
+ struct v4l2_frmsizeenum *fsize)
+{
+ struct em28xx_fh *fh = priv;
+ struct em28xx *dev = fh-dev;
+ struct em28xx_fmt *fmt;
+ unsigned int maxw = norm_maxw(dev);
+ unsigned int maxh = norm_maxh(dev);
+
+ fmt = format_by_fourcc(fsize-pixel_format);
+ if (!fmt) {
+ em28xx_videodbg(Fourcc format (%08x) invalid.\n,
+ fsize-pixel_format);
+ return -EINVAL;
+ }
+
+ if (dev-board.is_em2800) {
+ if (fsize-index 1)
+ return -EINVAL;
+ fsize-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ fsize-discrete.width = maxw / (1 + fsize-index);
+ fsize-discrete.height = maxh / (1 + fsize-index);
+ return 0;
+ }
+
+ if (fsize-index != 0)
+ return -EINVAL;
+
+ /* Report a continuous range */
+ fsize-type = V4L2_FRMSIZE_TYPE_STEPWISE;
+ fsize-stepwise.min_width = 48;
+ fsize-stepwise.min_height = 32;
+ fsize-stepwise.max_width = maxw;
+ fsize-stepwise.max_height = maxh;
+ fsize-stepwise.step_width = 1;
+ fsize-stepwise.step_height = 1;
+ return 0;
+}
+
/* Sliced VBI ioctls */
static int vidioc_g_fmt_sliced_vbi_cap(struct file *file, void *priv,
struct v4l2_format *f)
@@ -2356,10 +2395,10 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
.vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
.vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+ .vidioc_enum_framesizes = vidioc_enum_framesizes,
.vidioc_g_audio = vidioc_g_audio,
.vidioc_s_audio = vidioc_s_audio,
.vidioc_cropcap = vidioc_cropcap,
-
.vidioc_g_fmt_sliced_vbi_cap = vidioc_g_fmt_sliced_vbi_cap,
.vidioc_try_fmt_sliced_vbi_cap = vidioc_try_set_sliced_vbi_cap,
.vidioc_s_fmt_sliced_vbi_cap = vidioc_try_set_sliced_vbi_cap,
--
1.7.6.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 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmura chmoor...@poczta.onet.pl wrote: On Tue, 18 Oct 2011 11:52:17 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote: Thanks for comments for all of you. [PATCH 1-12/14] Following your guidelines i exported all changes from hg one by one. This way we will have all history in kernel tree. I moved driver to staging/media and removed Kconfig/Makefile changes in parent directory in first patch. Hello Piotr, Not that I want to create more work for you, but it would appear that your patches stripped off all the Signed-off-by lines for both myself and Pierrick Hascoet (the developer from the hardware vendor). You have replaced them with cc: lines, which breaks the chain of Developer's Certificate of Origin. When you take somebody else's patches, you need to preserve any existing Signed-off-by lines, adding your own at the bottom of the list. In other words, the first patch should be: Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl instead of: Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl Cc: Pierrick Hascoet pierrick.hasc...@abilis.com Cc: Devin Heitmueller dheitmuel...@kernellabs.com Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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 Ok, i'll resend them again. Should I replay to every patch with something like [RESEND PATCH nn/mm]..., right ? Peter Hi Peter, A common convention is to add the version of your patch in the subject like: [PATCH v2 0/14] staging/media/as102: new driver submission That way people can know that is actually a resend of a new patch-set and not a resend of the last one. Anything that is between your Signed-off and the diff get trimmed by Git when applying a patch (that is why Devin and Pierrick Signed-off where stripped in first place). So you can add information about the changes there. Something like: Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl v2: preserve any existing Signed-off-by lines so it doesn't get stripped when applied. diff -Nur linux.clean/drivers/staging/as102/as102_drv.c linux.as102_initial/drivers/staging/as102/as102_drv.c --- linux.clean/drivers/staging/as102/as102_drv.c 1970-01-01 01:00:00.0 +0100 +++ linux.as102_initial/drivers/staging/as102/as102_drv.c 2011-10-14 17:55:02.0 +0200 @@ -0,0 +1,360 @@ +/* + * Abilis Systems Single DVB-T Receiver + * Copyright (C) 2008 Pierrick Hascoetpierrick.hascoet@xx + * Copyright (C) 2010 Devin Heitmuellerdheitmueller@xx Hope it helps, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
Em 19-10-2011 09:41, Javier Martinez Canillas escreveu: On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmura chmoor...@poczta.onet.pl wrote: On Tue, 18 Oct 2011 11:52:17 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote: Thanks for comments for all of you. [PATCH 1-12/14] Following your guidelines i exported all changes from hg one by one. This way we will have all history in kernel tree. I moved driver to staging/media and removed Kconfig/Makefile changes in parent directory in first patch. Hello Piotr, Not that I want to create more work for you, but it would appear that your patches stripped off all the Signed-off-by lines for both myself and Pierrick Hascoet (the developer from the hardware vendor). You have replaced them with cc: lines, which breaks the chain of Developer's Certificate of Origin. When you take somebody else's patches, you need to preserve any existing Signed-off-by lines, adding your own at the bottom of the list. In other words, the first patch should be: Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl instead of: Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl Cc: Pierrick Hascoet pierrick.hasc...@abilis.com Cc: Devin Heitmueller dheitmuel...@kernellabs.com Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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 Ok, i'll resend them again. Should I replay to every patch with something like [RESEND PATCH nn/mm]..., right ? Peter Hi Peter, A common convention is to add the version of your patch in the subject like: [PATCH v2 0/14] staging/media/as102: new driver submission That way people can know that is actually a resend of a new patch-set and not a resend of the last one. Yes. Also, it seems that you've submitted only 12 patches of this 14 patch series. Where are the other two missing patches? Anything that is between your Signed-off and the diff get trimmed by Git when applying a patch (that is why Devin and Pierrick Signed-off where stripped in first place). So you can add information about the changes there. Something like: Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl v2: preserve any existing Signed-off-by lines so it doesn't get stripped when applied. diff -Nur linux.clean/drivers/staging/as102/as102_drv.c linux.as102_initial/drivers/staging/as102/as102_drv.c --- linux.clean/drivers/staging/as102/as102_drv.c 1970-01-01 01:00:00.0 +0100 +++ linux.as102_initial/drivers/staging/as102/as102_drv.c 2011-10-14 17:55:02.0 +0200 @@ -0,0 +1,360 @@ +/* + * Abilis Systems Single DVB-T Receiver + * Copyright (C) 2008 Pierrick Hascoetpierrick.hascoet@xx + * Copyright (C) 2010 Devin Heitmuellerdheitmueller@xx Hope it helps, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.1-rc10] media fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull from: git://linuxtv.org/mchehab/for_linus.git v4l_for_linus For a one line fix at the V4L2 core, causing OOPSes at device release under certain circumstances. Thanks! Mauro. Latest commit at the branch: e58fced201ad6e6cb673f07499919c3b20792d94 [media] videodev: fix a NULL pointer dereference in v4l2_device_release() The following changes since commit 899e3ee404961a90b828ad527573c39f0ab1: Linux 3.1-rc10 (2011-10-17 21:06:23 -0700) are available in the git repository at: git://linuxtv.org/mchehab/for_linus.git v4l_for_linus Antonio Ospite (1): [media] videodev: fix a NULL pointer dereference in v4l2_device_release() drivers/media/video/v4l2-dev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOnrrNAAoJEGO08Bl/PELnIU4P/iiuqUGQnYr5NH/keGd562Cn INrqAJ5SO9nNjgE2Eg9fuxVGriQazEJ8s+qs1wwZrpcRkrZVq2xzy7LtC/TuBdu1 c8lStlSLN2Cmo6kfkNBuNc++6X1SWh+Rdz4l5r3N8IKNQsu6XfW1idgKql3Pwavr Afzb18vDL8rRQC9etbxzBgtOXHj6zJw+ehdKwqx9SglF1DH72afxAv7z3UhygZYp UVJzgjVKgAyOVQfxHKzFrpNiLQpYWJtJaTpTw+t7hOp8kNZ4rXlinmy9UYsZ8Lrr mlcWld1F2dmDuhxj0xU+QDDOhmfXnPWbLi/VWWramBq9ksNXQzxsQriI4ZKmHg5J nnmvkrbKB+nL/51ITfXBTxYdC5zcDfEwD1m6mge3c8r4SJaRXOuHoMtVOpKAENFj hqBRRDnb6LjnMJhdWrgFPHGs1k/T/BoduCphwZIAU2Ii7Tz0AqCnyKL4aaWHqcwp 0ECduB1Iyr1AUVnf5S7wH3m/gukasIEIGhEH2Yqr7mG1odguM5eSdHRYTLejZw+7 I2Nk71DI099Hrnt3GAer0hEzN8Pm96xMCh5kCqD2pz6H9zoijK7K7MFD0Nf2RhZV JKy/UNwDTGAx3989G0nUu5KWmfYvvqgzZUYNgN1IZhde/YEHldIUOxY6yf3gZy9J twUAlsCBnY/6povAvdMH =RCnh -END PGP SIGNATURE- -- 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
Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). So my questions are these: 1. If I move the drx39xx* and associated files into the staging directory (staging/media/dvb/frontends to be exact), do I simply need to point to staging/filename for any #include statements (specifically in the em28xx-dvb.c and em28xx-cards.c files), or do I need to do something else? 2. In the Makefile for the frontends, I have the commands to make the drivers for the drx39xx* files. Do I need to point those to the staging/ directory as well, or do I need to create Makefiles in that directory for these files? I ask this because on my system, I wasn't able to make the files when they were in a subdirectory of frontends. I actually had to move them to the frontends directory and transfer the commands from the Makefile in the subdirectory to the frontends Makefile. 3. If I submit a pull request as is right now (where these files will go into the linux/drivers/media/dvb/frontends directory and the em28xx-* files will point to those files), will they be pulled in, and someone will help me to get them in the right places? Or do I need to move them to staging, reconfigure everything, and then submit the pull request? Thank you for any help and information, and have a great day:) Patrick. On 10/17/2011 05:31 PM, Greg KH wrote: On Sat, Oct 15, 2011 at 10:54:14PM +0200, Piotr Chmura wrote: [PATCH 1/7] pull as102 driver fromhttp://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/ with the only change needed to compile it in git tree[1]: usb_buffer_alloc() to usb_alloc_coherent() and usb_buffer_free() to usb_free_coherent() [PATCH 2/7] as102: add new device nBox DVB-T Dongle adds new device working on this driver Next patches i made basing on Mauro Carvalho Chehab comments from previous pull try [2]. [PATCH 3/7] as102: cleanup - get rid off typedefs [PATCH 4/7] as102: cleanup - formatting code [PATCH 5/7] as102: cleanup - set __attribute__(packed) instead of pragma(pack) [PATCH 6/7] as102: cleanup - delete vim comments [PATCH 7/7] as102: cleanup - get rid of unnecessary defines (WIN32, LINUX) Mauro, care to take these and move them under your newly-created drivers/staging/media/ directory? thanks, greg k-h -- 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov boris.st.todo...@gmail.com wrote: Here is my log: [ 24.683685] omap3isp omap3isp: -CCDC Register dump- [ 24.683685] omap3isp omap3isp: ###CCDC PCR=0x [ 24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x [ 24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105 [ 24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x [ 24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x [ 24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 24.683837] omap3isp omap3isp: ###CCDC FPC=0x [ 24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104 [ 24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d [ 24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 24.684051] omap3isp omap3isp: This is with: .data_lane_shift = 0, .clk_pol = 0, .hs_pol = 0, .vs_pol = 0, .data_pol = 0, .fldmode = 1, .bt656 = 1, and the above mentioned media-ctl settings From a quick look It seems ok (apart ALAW that maybe should be 0). One thing to check: before loading omap3-isp kernel module you must manually load iommu2, if you don't it will automatically load only iommu and it will not work Enrico -- 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: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 3:40 PM, Enrico ebut...@users.berlios.de wrote: On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov boris.st.todo...@gmail.com wrote: Here is my log: [ 24.683685] omap3isp omap3isp: -CCDC Register dump- [ 24.683685] omap3isp omap3isp: ###CCDC PCR=0x [ 24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x [ 24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105 [ 24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x [ 24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x [ 24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 24.683837] omap3isp omap3isp: ###CCDC FPC=0x [ 24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104 [ 24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d [ 24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 24.684051] omap3isp omap3isp: This is with: .data_lane_shift = 0, .clk_pol = 0, .hs_pol = 0, .vs_pol = 0, .data_pol = 0, .fldmode = 1, .bt656 = 1, and the above mentioned media-ctl settings From a quick look It seems ok (apart ALAW that maybe should be 0). One thing to check: before loading omap3-isp kernel module you must manually load iommu2, if you don't it will automatically load only iommu and it will not work Enrico When I started omap3-isp was embedded in kernel and my /dev/media0 was missing. Making it module resolved this issue. iommu2 is still embedded... will try with module now -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
W dniu 19.10.2011 13:44, Mauro Carvalho Chehab pisze: Em 19-10-2011 09:41, Javier Martinez Canillas escreveu: On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmurachmoor...@poczta.onet.pl wrote: On Tue, 18 Oct 2011 11:52:17 -0400 Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmurachmoor...@poczta.onet.pl wrote: Thanks for comments for all of you. [PATCH 1-12/14] Following your guidelines i exported all changes from hg one by one. This way we will have all history in kernel tree. I moved driver to staging/media and removed Kconfig/Makefile changes in parent directory in first patch. Hello Piotr, Not that I want to create more work for you, but it would appear that your patches stripped off all the Signed-off-by lines for both myself and Pierrick Hascoet (the developer from the hardware vendor). You have replaced them with cc: lines, which breaks the chain of Developer's Certificate of Origin. When you take somebody else's patches, you need to preserve any existing Signed-off-by lines, adding your own at the bottom of the list. In other words, the first patch should be: Signed-off-by: Pierrick Hascoetpierrick.hasc...@abilis.com Signed-off-by: Devin Heitmuellerdheitmuel...@kernellabs.com Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl instead of: Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl Cc: Pierrick Hascoetpierrick.hasc...@abilis.com Cc: Devin Heitmuellerdheitmuel...@kernellabs.com Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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 Ok, i'll resend them again. Should I replay to every patch with something like [RESEND PATCH nn/mm]..., right ? Peter Hi Peter, A common convention is to add the version of your patch in the subject like: [PATCH v2 0/14] staging/media/as102: new driver submission That way people can know that is actually a resend of a new patch-set and not a resend of the last one. Thanks, I'll do it this way next time. Yes. Also, it seems that you've submitted only 12 patches of this 14 patch series. Where are the other two missing patches? 13 and 14 were written by me, so they didn't suffer signed-off-by mistake. Do I need resend them too ? Peter -- 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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Hi Patrick, On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey pdickeyb...@gmail.com wrote: I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). You should definitely be looking at the as102 thread that is currently going on this mailing list. Piotr is actually going through the same process as you are (he is working on upstreaming the as102 driver from a kernellabs.com tree). He made some pretty common mistakes (all perfectly understandable), and your reading the thread might help you avoid them (and having to redo your patch series). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). You should definitely ask Mauro how he expects to do a staging driver for a demodulator before you do any further work. The staging tree works well for bridge drivers, but demod drivers such as the drx require code in the bridge driver (the em28xx in this case), so it's not clear how you would do staging for a product where the bridge driver isn't in staging as well. The answer to that question will likely guide you in how to get the driver into staging. If you have specific questions regarding anything you see in the driver, let me know. I don't have much time nowadays but will find the time if you ask concise questions. Good luck. It will be great to finally see this merged upstream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
[RFCv2] Improved handling of presets
RFCv2: Improved handling of presets
===
Changes from RFCv1:
- Removed name[] in v4l2_enum_bt_timings.
- Improved the description of QUERY_DV_TIMINGS.
- Removed v4l2_query_dv_timings, instead reuse v4l2_dv_timings.
The various 'states' of RFCv1 are now returned as error codes.
- Simplified signalling whether root permissions are required when
setting the timings: just add a single flag to v4l2_dv_timings_cap.
- Add a section on EDID handling.
This RFC attempts to resolve the issues raised by this thread a few months ago:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg33981.html
The last post in this thread did a good job of summarizing the discussion:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg34190.html
I think it is time to revisit this problem. It basically boils down to the fact
that the current preset API is too limited and somewhat awkward and I agree
with that.
Now, I really do not like the idea of creating a preset2 API. Instead I think
it is better to extend the current dv_timings API with new ioctls:
VIDIOC_QUERY_DV_TIMINGS
VIDIOC_ENUM_DV_TIMINGS
VIDIOC_DV_TIMINGS_CAP
These form a superset of the preset API and once this is in place we can
deprecate some or all of the preset ioctls and eventually remove them (say
in one or two years).
Here is the current definition of the v4l2_dv_timings struct from videodev2.h:
/* BT.656/BT.1120 timing data */
struct v4l2_bt_timings {
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 interlaced; /* Interlaced or progressive */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz-7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[16];
} __attribute__ ((packed));
/* Interlaced or progressive format */
#define V4L2_DV_PROGRESSIVE 0
#define V4L2_DV_INTERLACED 1
/* Polarities. If bit is not set, it is assumed to be negative polarity */
#define V4L2_DV_VSYNC_POS_POL 0x0001
#define V4L2_DV_HSYNC_POS_POL 0x0002
/* DV timings */
struct v4l2_dv_timings {
__u32 type;
union {
struct v4l2_bt_timings bt;
__u32 reserved[32];
};
} __attribute__ ((packed));
/* Values for the type field */
#define V4L2_DV_BT_656_1120 0 /* BT.656/1120 timing type */
This API allows you to set and get all the timings details. Its current
use is to allow userspace to set non-standard timings and it is used only in
the dm646x davinci drivers at the moment.
I propose the following additions:
1) Add a standards field to v4l2_bt_timings:
__u32 standards;
Currently I have four standards:
#define V4L2_DV_BT_STD_CEA861 (1 0)
#define V4L2_DV_BT_STD_DMT (1 1) /* VESA Discrete Monitor
Timings */
#define V4L2_DV_BT_STD_CVT (1 2) /* VESA Coordinated Video
Timings */
#define V4L2_DV_BT_STD_GTF (1 3) /* VESA Generalized Timings
Formula */
A particular timing can be part of 0 or more standards.
Both CVT and GTF timings have a so-called 'reduced blanking' mode. It would
be
nice to represent this with a flag somewhere. I guess we need a flags field
for that. The 'polarities' field really should have been called a 'flags'
field.
One option is just to rename 'polarities' to 'flags' if Mauro would agree to
that.
The ABI would be preserved, but applications using the polarities field
would no
longer compile.
The standards field is ignored when setting timings.
2) Create a VIDIOC_ENUM_DV_TIMINGS ioctl:
struct v4l2_enum_dv_timings {
__u32 index;
__u32 reserved[3];
struct v4l2_dv_timings timings;
};
#define VIDIOC_ENUM_DV_TIMINGS _IOWR('V', XX, struct
v4l2_enum_dv_timings)
This ioctl enumerates over all discrete supported timings and returns their
timings.
The timings field can be used as an input to
Re: omap3isp: BT.656 support
On Wed, Oct 19, 2011 at 4:06 PM, Boris Todorov boris.st.todo...@gmail.com wrote: On Wed, Oct 19, 2011 at 3:40 PM, Enrico ebut...@users.berlios.de wrote: On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov boris.st.todo...@gmail.com wrote: Here is my log: [ 24.683685] omap3isp omap3isp: -CCDC Register dump- [ 24.683685] omap3isp omap3isp: ###CCDC PCR=0x [ 24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80 [ 24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f [ 24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x [ 24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105 [ 24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0 [ 24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249 [ 24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x [ 24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x [ 24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 24.683837] omap3isp omap3isp: ###CCDC FPC=0x [ 24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104 [ 24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003 [ 24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800 [ 24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0 [ 24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d [ 24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 24.684051] omap3isp omap3isp: This is with: .data_lane_shift = 0, .clk_pol = 0, .hs_pol = 0, .vs_pol = 0, .data_pol = 0, .fldmode = 1, .bt656 = 1, and the above mentioned media-ctl settings From a quick look It seems ok (apart ALAW that maybe should be 0). One thing to check: before loading omap3-isp kernel module you must manually load iommu2, if you don't it will automatically load only iommu and it will not work Enrico When I started omap3-isp was embedded in kernel and my /dev/media0 was missing. Making it module resolved this issue. iommu2 is still embedded... will try with module now I loaded the modules in this order: iommu.ko - iovmm.ko - iommu2.ko - omap_iommu.ko - omap3_isp.ko # lsmod Module Size Used byNot tainted omap3_isp 121471 0 omap_iommu 1276 0 iommu2 5118 0 iovmm 11389 1 omap3_isp iommu 14627 3 omap3_isp,iommu2,iovmm But it didn't solved my problem. I just scoped PCLK and the data lines from TVP and everything looks fine. I can see the BT.656 embedded sync information. But no ISP irqs... -- 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: omap3isp: BT.656 support
Am 18.10.2011 15:33, schrieb Boris Todorov: Hi I'm trying to run OMAP + TVP5151 in BT656 mode. I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git). Plus the following patches: TVP5151: https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150 The latest RFC patches for BT656 support: Enrico Butera (2): omap3isp: ispvideo: export isp_video_mbus_to_pix omap3isp: ispccdc: configure CCDC registers and add BT656 support Javier Martinez Canillas (1): omap3isp: ccdc: Add interlaced field mode to platform data I'm able to configure with media-ctl: media-ctl -v -r -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005c:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x525]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x525]' But ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4 sleeps after ... Buffer 1 mapped at address 0x4021d000. length: 756000 offset: 1515520 Buffer 2 mapped at address 0x402d6000. length: 756000 offset: 2273280 Buffer 3 mapped at address 0x4038f000. Anyone with the same issue??? This happens with every other v4l test app I used. I had the same issue. Make sure that you disable the xclk when you remove your sensor driver. isp-platform_cb.set_xclk(isp, 0, ISP_XCLK_A) Regards, Stefan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Oct 19 19:00:17 CEST 2011 git hash:35a912455ff5640dc410e91279b03e04045265b2 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: 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: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel OOPS when releasing usb webcam (random)
On Tue, 18 Oct 2011, David Rientjes wrote: Guennadi or Mauro, how is this going to Linus? It sounds like 3.1 material since we've received at least a couple of reports of this in the past week. This fix is now in Linus' tree at e58fced201ad ([media] videodev: fix a NULL pointer dereference in v4l2_device_release()) for 3.1. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] subdevice PM: .s_power() deprecation?
On 10/18/2011 11:38 PM, Guennadi Liakhovetski wrote: On Tue, 18 Oct 2011, Sylwester Nawrocki wrote: On 10/18/2011 01:07 AM, Laurent Pinchart wrote: On Monday 17 October 2011 23:26:28 Sylwester Nawrocki wrote: On 10/17/2011 05:23 PM, Guennadi Liakhovetski wrote: On Mon, 17 Oct 2011, Sylwester Nawrocki wrote: [snip] The bridge driver could also choose to keep the sensor powered on, whenever it sees appropriate, to avoid re-enabling the sensor to often. On what basis would the bridge driver make these decisions? How would it know in advance, when it'll have to re-enable the subdev next time? Re-enabling by allowing a subdev driver to entirely control the power state. The sensor might implement lowest power consumption policy, while the user might want highest performance. Exactly, that's a policy decision. Would PM QoS help here ? Thanks for reminding about PM QoS. I didn't pay much attention to it but it indeed appears to be a good fit for this sort of tasks. But you anyway have to decide - who will implement those PM QoS callbacks? The bridge and then decide whether or not to call subdev's .s_power(), or the subdev driver itself? I think, the latter, in which case .s_power() remain unused. Agreed. With some hints on how to handle power supply directly in the subdev driver we should be able to do without s_power() at the edge subdevs. We would possibly just need to think of parameters which could be associated with video, e.g. video_latency, etc. ?... I'm curious whether the whole power handling could be contained within a subdev driver, most likely it could be done for subdevs exposing a devnode. I'm referring only to camera sensor subdevs, as I don't have much experience with other ones. Also there are some devices where you want to model power control explicitly, and it is critical to overall system operation. The s5p-tv driver is one example of these. The host driver knows exactly how the power state of its subdevs should be handled. The host probably knows about how to handle the power state of its internal subdevs, but what about external ones ? In this particular example there is no external subdevs associated with the host. But we don't seem to have separate callbacks for internal and external subdevs.. So removing s_power() puts the above described sort of drivers in trouble. I understand what you're saying, but can you give us a specific example, when a subdev driver (your SoC internal subdev, that is) doesn't have a way to react to an event itself and only the bridge driver gets called into at that time? Something like an interrupt or an internal timer or some other internal event? 1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV Out. For instance the master video clock is during normal operation derived from (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can switch to this clock only when the HDMI-PHY (subdev) power and clocks are enabled. And it should be done before .s_stream(), to do some H/W configuration earlier in the pipeline, before streaming is enabled. Perhaps Tomasz could give some further explanation of what the s_power() op does and why in the driver. 2. In some of our camera pipeline setups - Sensor - MIPI-CSI receiver - host/DMA, the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the MIPI-CSI receiver must always be powered on before the sensor. With the subdevs doing their own magic wrt to power control the situation is getting slightly out of control. I guess we all agree the power requirements of external subdevs are generally unknown to the hosts. For these it might make lot of sense to let the subdev driver handle the device power supplies on basis of requests like, s_ctrl, s_stream, etc. Yes, right, so, most external (sensor, decoder,...) subdev drivers should never need to implement .s_power(), regardless of whether we decide to keep it or not. Well, ok, no, put it differently - in those drivers .s_power() should only really be called during system-wide suspend / resume. Yes, I agree with that. But before we attempt to remove .s_power() or deprecate it on external subdevs, I'd like to get solved the issue with sensor master clock provided by the bridge. As these two are closely related - the sensor controller won't boot if the clock is disabled. And there are always advantages of not keeping the clock always enabled. With PM QoS it could be easier to decide in the driver when a device should be put in a low power state. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix to qt1010 tuner frequency selection (media/dvb)
Jyrki, So after a bit more testing... [...] /* 22 */ if (freq 45000) rd[15].val = 0xd0; /* 450 MHz */ -else if (freq 48200) rd[15].val = 0xd1; /* 482 MHz */ +else if (freq 48200) rd[15].val = 0xd2; /* 482 MHz */ This change isn't so good. With this change, I can no longer tune to channel 21 (474 MHz). If I revert it back to 0xd1, it's fine. [...] else if (freq 51400) rd[15].val = 0xd4; /* 514 MHz */ -else if (freq 54600) rd[15].val = 0xd7; /* 546 MHz */ +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq 57800) rd[15].val = 0xd8; /* 578 MHz */ (This change is still good though, as this does allow me to now tune to the BBC channels in this range). -Carlos -- 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: kernel OOPS when releasing usb webcam (random)
Em 19-10-2011 18:21, David Rientjes escreveu: On Tue, 18 Oct 2011, David Rientjes wrote: Guennadi or Mauro, how is this going to Linus? It sounds like 3.1 material since we've received at least a couple of reports of this in the past week. This fix is now in Linus' tree at e58fced201ad ([media] videodev: fix a NULL pointer dereference in v4l2_device_release()) for 3.1. Yes, I sent it upstream earlier today. Btw, Greg also picked it for stable. It should be there for the next 3.0.x kernel as well. 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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Em 19-10-2011 11:57, Devin Heitmueller escreveu: Hi Patrick, On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey pdickeyb...@gmail.com wrote: I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). You should definitely be looking at the as102 thread that is currently going on this mailing list. Piotr is actually going through the same process as you are (he is working on upstreaming the as102 driver from a kernellabs.com tree). He made some pretty common mistakes (all perfectly understandable), and your reading the thread might help you avoid them (and having to redo your patch series). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). You should definitely ask Mauro how he expects to do a staging driver for a demodulator before you do any further work. The staging tree works well for bridge drivers, but demod drivers such as the drx require code in the bridge driver (the em28xx in this case), so it's not clear how you would do staging for a product where the bridge driver isn't in staging as well. The answer to that question will likely guide you in how to get the driver into staging. Ah yes, good point. Well, just submit it as if it should be added at the right place, but putting the Kconfig changes in separate. If this driver is not that different than the other drx drivers, I may try to find some time to fix it on the same way. You may also take a look at the history for the drx-k merging patches. I basically wrote a few small perl scripts to correct coding style, and a few manual work. If you have specific questions regarding anything you see in the driver, let me know. I don't have much time nowadays but will find the time if you ask concise questions. Good luck. It will be great to finally see this merged upstream. Devin -- 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] Fix to qt1010 tuner frequency selection (media/dvb)
I think my problem frequency has also been at the later spot. It is possible there is something more complicated going on at 474 MHz - so based on your testing, it's best to apply just the latter change, at least for now. Jyrki +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ 20.10.2011 00:06, Carlos Corbacho kirjoitti: Jyrki, So after a bit more testing... [...] /* 22 */ if (freq 45000) rd[15].val = 0xd0; /* 450 MHz */ -else if (freq 48200) rd[15].val = 0xd1; /* 482 MHz */ +else if (freq 48200) rd[15].val = 0xd2; /* 482 MHz */ This change isn't so good. With this change, I can no longer tune to channel 21 (474 MHz). If I revert it back to 0xd1, it's fine. [...] else if (freq 51400) rd[15].val = 0xd4; /* 514 MHz */ -else if (freq 54600) rd[15].val = 0xd7; /* 546 MHz */ +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq 57800) rd[15].val = 0xd8; /* 578 MHz */ (This change is still good though, as this does allow me to now tune to the BBC channels in this range). -Carlos -- 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
