Re: [linux-dvb] TechnoTrend S1500 DVBs / CI can not read Irdeto Cam
Le lundi 22 février 2010 06:59:35, Ahmad Issa a écrit : > Hi, > > > > I am testing TechnoTrend DVBS 1500 with CI. Everything is working fine when > i use KeyFly Cam, but when i use Irdeto Cam im getting the below error: > > > > error: cannot write to CAM device (Input/output error) > > error: en50221_Init: couldn't send TPDU on slot 0 > > debug: en50221_Poll: resetting slot 0 > > > > i testing the card using DVBLast and also when i use VLC i get same results > > > > i have installed the latest DVB driver from www.linuxtv.org > > > > #lspci > > 0f:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > > > > > > # lsmod | grep dvb > > dvb_ttpci 125216 0 > > saa7146_vv 59560 1 dvb_ttpci > > saa714622800 4 budget_ci,budget_core,dvb_ttpci,saa7146_vv > > ttpci_eeprom2792 2 budget_core,dvb_ttpci > > dvb_core 120724 5 > stv0299,budget_ci,budget_core,dvb_ttpci,b2c2_flexcop > > > > Any Help? > > > > Thanks Alot > > > > > > Ahmad > See http://www.linuxtv.org/wiki/index.php/TechnoTrend_TT-budget_S-1500 -- Christophe Thommeret -- 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 v5 5/6] V4L: Events: Support event handling in do_ioctl
Hi Hans,
On Monday 22 February 2010 08:53:53 Hans Verkuil wrote:
> On Sunday 21 February 2010 23:31:43 Sakari Ailus wrote:
> > Hans Verkuil wrote:
> > > More comments...
> > >
> > > On Friday 19 February 2010 20:21:59 Sakari Ailus wrote:
> > >> Add support for event handling to do_ioctl.
> > >>
> > >> Signed-off-by: Sakari Ailus
> > >> ---
> > >>
> > >> drivers/media/video/v4l2-ioctl.c | 58
> > >> ++ include/media/v4l2-ioctl.h
> > >> |7
> > >> 2 files changed, 65 insertions(+), 0 deletions(-)
> > >>
> > >> diff --git a/drivers/media/video/v4l2-ioctl.c
> > >> b/drivers/media/video/v4l2-ioctl.c index 34c7d6e..f7d6177 100644
> > >> --- a/drivers/media/video/v4l2-ioctl.c
> > >> +++ b/drivers/media/video/v4l2-ioctl.c
> > >> @@ -25,6 +25,8 @@
> > >>
> > >> #endif
> > >> #include
> > >> #include
> > >>
> > >> +#include
> > >> +#include
> > >>
> > >> #include
> > >>
> > >> #define dbgarg(cmd, fmt, arg...) \
> > >>
> > >> @@ -1944,7 +1946,63 @@ static long __video_do_ioctl(struct file *file,
> > >>
> > >> }
> > >> break;
> > >>
> > >> }
> > >>
> > >> +case VIDIOC_DQEVENT:
> > >> +{
> > >> +struct v4l2_event *ev = arg;
> > >> +struct v4l2_fh *vfh = fh;
> > >> +
> > >> +if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
> > >> +|| vfh->events == NULL)
> > >> +break;
> > >
> > > Change this to:
> > > if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
> > >
> > > break;
> > >
> > > if (vfh->events == NULL)
> > >
> > > return -ENOENT;
> > >
> > > But see also the next comment.
> > >
> > >> +
> > >> +ret = v4l2_event_dequeue(fh, ev);
> > >
> > > There is a crucial piece of functionality missing here: if the
> > > filehandle is in blocking mode, then it should wait until an event
> > > arrives. That also means that if vfh->events == NULL, you should still
> > > call v4l2_event_dequeue, and that function should initialize
> > > vfh->events and wait for an event if the fh is in blocking mode.
> >
> > I originally left this out intentionally. Most applications using events
> > would use select / poll as well by default. For completeness it should
> > be there, I agree.
>
> It has to be there. This is important functionality. For e.g. ivtv I would
> use this to wait until the MPEG decoder flushed all buffers and displayed
> the last frame of the stream. That's something you would often do in
> blocking mode.
Blocking mode can easily be emulated using select().
> > This btw. suggests that we perhaps should put back the struct file
> > argument for the event functions in video_ioctl_ops. The blocking flag
> > is indeed part of the file structure. I'm open to better suggestions,
> > too.
>
> My long term goal is that the file struct is only used inside v4l2-ioctl.c
> and not in drivers. Drivers should not need this struct at all. The easiest
> way to ensure this is by not passing it to the drivers at all :-)
Drivers still need a way to access the blocking flag. The interim solution of
adding a file * member to v4l2_fh would allow that, while still removing most
usage of file * from drivers.
> > >> +if (ret < 0) {
> > >> +dbgarg(cmd, "no pending events?");
> > >> +break;
> > >> +}
> > >> +dbgarg(cmd,
> > >> + "pending=%d, type=0x%8.8x, sequence=%d, "
> > >> + "timestamp=%lu.%9.9lu ",
> > >> + ev->pending, ev->type, ev->sequence,
> > >> + ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
> > >> +break;
> > >> +}
> > >> +case VIDIOC_SUBSCRIBE_EVENT:
> > >> +{
> > >> +struct v4l2_event_subscription *sub = arg;
> > >> +struct v4l2_fh *vfh = fh;
> > >>
> > >> +if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
> > >
> > > Testing for this bit is unnecessarily. Just test for
> > > ops->vidioc_subscribe_event.
> > >
> > >> +|| vfh->events == NULL
> > >
> > > Remove this test. If you allocate the event queue only when you first
> > > subscribe to an event (as ivtv will do), then you have to be able to
> > > call vidioc_subscribe_event even if vfh->events == NULL.
> >
> > How about calling v4l2_event_alloc() with zero events? That allocates
> > and initialises the v4l2_events structure. That's easier to handle in
> > drivers as well since they don't need to consider special cases like
> > fh->events happens to be NULL even if events are supported by the
> > driver. This is how I first thought it'd work.
>
> Proposal: export a v4l2_event_init() call that sets up fh->events. Calling
> v4l2_event_alloc(0)
Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
> Hi Hans,
>
> On Monday 22 February 2010 08:53:53 Hans Verkuil wrote:
>> On Sunday 21 February 2010 23:31:43 Sakari Ailus wrote:
>> > Hans Verkuil wrote:
>> > > More comments...
>> > >
>> > > On Friday 19 February 2010 20:21:59 Sakari Ailus wrote:
>> > >> Add support for event handling to do_ioctl.
>> > >>
>> > >> Signed-off-by: Sakari Ailus
>>
>> > >> ---
>> > >>
>> > >> drivers/media/video/v4l2-ioctl.c | 58
>> > >> ++ include/media/v4l2-ioctl.h
>> > >> |7
>> > >> 2 files changed, 65 insertions(+), 0 deletions(-)
>> > >>
>> > >> diff --git a/drivers/media/video/v4l2-ioctl.c
>> > >> b/drivers/media/video/v4l2-ioctl.c index 34c7d6e..f7d6177 100644
>> > >> --- a/drivers/media/video/v4l2-ioctl.c
>> > >> +++ b/drivers/media/video/v4l2-ioctl.c
>> > >> @@ -25,6 +25,8 @@
>> > >>
>> > >> #endif
>> > >> #include
>> > >> #include
>> > >>
>> > >> +#include
>> > >> +#include
>> > >>
>> > >> #include
>> > >>
>> > >> #define dbgarg(cmd, fmt, arg...) \
>> > >>
>> > >> @@ -1944,7 +1946,63 @@ static long __video_do_ioctl(struct file
>> *file,
>> > >>
>> > >> }
>> > >> break;
>> > >>
>> > >> }
>> > >>
>> > >> + case VIDIOC_DQEVENT:
>> > >> + {
>> > >> + struct v4l2_event *ev = arg;
>> > >> + struct v4l2_fh *vfh = fh;
>> > >> +
>> > >> + if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)
>> > >> + || vfh->events == NULL)
>> > >> + break;
>> > >
>> > > Change this to:
>> > > if (!test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
>> > >
>> > > break;
>> > >
>> > > if (vfh->events == NULL)
>> > >
>> > > return -ENOENT;
>> > >
>> > > But see also the next comment.
>> > >
>> > >> +
>> > >> + ret = v4l2_event_dequeue(fh, ev);
>> > >
>> > > There is a crucial piece of functionality missing here: if the
>> > > filehandle is in blocking mode, then it should wait until an event
>> > > arrives. That also means that if vfh->events == NULL, you should
>> still
>> > > call v4l2_event_dequeue, and that function should initialize
>> > > vfh->events and wait for an event if the fh is in blocking mode.
>> >
>> > I originally left this out intentionally. Most applications using
>> events
>> > would use select / poll as well by default. For completeness it should
>> > be there, I agree.
>>
>> It has to be there. This is important functionality. For e.g. ivtv I
>> would
>> use this to wait until the MPEG decoder flushed all buffers and
>> displayed
>> the last frame of the stream. That's something you would often do in
>> blocking mode.
>
> Blocking mode can easily be emulated using select().
>
>> > This btw. suggests that we perhaps should put back the struct file
>> > argument for the event functions in video_ioctl_ops. The blocking flag
>> > is indeed part of the file structure. I'm open to better suggestions,
>> > too.
>>
>> My long term goal is that the file struct is only used inside
>> v4l2-ioctl.c
>> and not in drivers. Drivers should not need this struct at all. The
>> easiest
>> way to ensure this is by not passing it to the drivers at all :-)
>
> Drivers still need a way to access the blocking flag. The interim solution
> of
> adding a file * member to v4l2_fh would allow that, while still removing
> most
> usage of file * from drivers.
Why not just add a 'blocking' argument to the v4l2_event_dequeue? And let
v4l2-ioctl.c fill in that argument? That's how I would do it.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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] fix some info messages
Hi
Fix some messages for add information about TM6010
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-alsa.c
--- a/linux/drivers/staging/tm6000/tm6000-alsa.cSun Feb 21 21:00:16
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-alsa.cMon Feb 22 07:36:15
2010 -0500
@@ -1,6 +1,6 @@
/*
*
- * Support for audio capture for tm5600/6000
+ * Support for audio capture for tm5600/6000/6010
*(c) 2007-2008 Mauro Carvalho Chehab
*
* Based on cx88-alsa.c
@@ -89,11 +89,12 @@
Module macros
/
-MODULE_DESCRIPTION("ALSA driver module for tm5600/tm6000 based TV cards");
+MODULE_DESCRIPTION("ALSA driver module for tm5600/tm6000/tm6010 based TV
cards");
MODULE_AUTHOR("Mauro Carvalho Chehab ");
MODULE_LICENSE("GPL");
MODULE_SUPPORTED_DEVICE("{{Trident,tm5600},"
- "{{Trident,tm6000}");
+ "{{Trident,tm6000},"
+ "{{Trident,tm6010}");
static unsigned int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "enable debug messages");
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Sun Feb 21 21:00:16
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Mon Feb 22 07:36:15
2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-cards.c - driver for TM5600/TM6000 USB video capture devices
+ tm6000-cards.c - driver for TM5600/TM6000/TM6010 USB video capture devices
Copyright (C) 2006-2007 Mauro Carvalho Chehab
@@ -799,6 +799,6 @@
module_init(tm6000_module_init);
module_exit(tm6000_module_exit);
-MODULE_DESCRIPTION("Trident TVMaster TM5600/TM6000 USB2 adapter");
+MODULE_DESCRIPTION("Trident TVMaster TM5600/TM6000/TM6010 USB2 adapter");
MODULE_AUTHOR("Mauro Carvalho Chehab");
MODULE_LICENSE("GPL");
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-core.c
--- a/linux/drivers/staging/tm6000/tm6000-core.cSun Feb 21 21:00:16
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-core.cMon Feb 22 07:36:15
2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-core.c - driver for TM5600/TM6000 USB video capture devices
+ tm6000-core.c - driver for TM5600/TM6000/TM6010 USB video capture devices
Copyright (C) 2006-2007 Mauro Carvalho Chehab
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-dvb.c
--- a/linux/drivers/staging/tm6000/tm6000-dvb.c Sun Feb 21 21:00:16 2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-dvb.c Mon Feb 22 07:36:15 2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-dvb.c - dvb-t support for TM5600/TM6000 USB video capture devices
+ tm6000-dvb.c - dvb-t support for TM5600/TM6000/TM6010 USB video capture
devices
Copyright (C) 2007 Michel Ludwig
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Sun Feb 21 21:00:16 2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Feb 22 07:36:15 2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-i2c.c - driver for TM5600/TM6000 USB video capture devices
+ tm6000-i2c.c - driver for TM5600/TM6000/TM6010 USB video capture devices
Copyright (C) 2006-2007 Mauro Carvalho Chehab
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-regs.h
--- a/linux/drivers/staging/tm6000/tm6000-regs.hSun Feb 21 21:00:16
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-regs.hMon Feb 22 07:36:15
2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-regs.h - driver for TM5600/TM6000 USB video capture devices
+ tm6000-regs.h - driver for TM5600/TM6000/TM6010 USB video capture devices
Copyright (C) 2006-2007 Mauro Carvalho Chehab
@@ -18,7 +18,7 @@
*/
/*
- * Define TV Master TM5600/TM6000 Request codes
+ * Define TV Master TM5600/TM6000/TM6010 Request codes
*/
#define REQ_00_SET_IR_VALUE0
#define REQ_01_SET_WAKEUP_IRCODE 1
@@ -49,7 +49,7 @@
/* Read : Slave Addr, register, 2, data */
/*
- * Define TV Master TM5600/TM6000 GPIO lines
+ * Define TV Master TM5600/TM6000/TM6010 GPIO lines
*/
#define TM6000_GPIO_CLK0x101
@@ -74,7 +74,7 @@
#define TM6010_GPIO_7 0x0301
#define TM6010_GPIO_9 0x0305
/*
- * Define TV Master TM5600/TM6000 URB message codes and length
+ * Define TV Master TM5600/TM6000/TM6010 URB message codes and length
*/
enum {
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-stds.c
--- a/linux/drivers/staging/tm6000/tm6000-stds.cSun Feb 21 21:00:16
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-stds.cMon Feb 22 07:36:15
2010 -0500
@@ -1,5 +1,5 @@
/*
- tm6000-stds.c - driver for TM5600/TM6000 USB video capture devices
+ tm6000-stds.c - driver for TM5600/TM6000/TM6010 USB video capture devices
Copyright (C) 2007 Mauro Carvalho Chehab
diff -r ac88a0dd8fb7 linux/drivers/staging/tm6000/tm6000-usb-isoc.h
--- a/linux/drivers/staging/tm6000/tm
Re: [PATCH v5 5/6] V4L: Events: Support event handling in do_ioctl
Hans Verkuil wrote: > There is a crucial piece of functionality missing here: if the > filehandle is in blocking mode, then it should wait until an event > arrives. That also means that if vfh->events == NULL, you should >>> still > call v4l2_event_dequeue, and that function should initialize > vfh->events and wait for an event if the fh is in blocking mode. I originally left this out intentionally. Most applications using >>> events would use select / poll as well by default. For completeness it should be there, I agree. >>> >>> It has to be there. This is important functionality. For e.g. ivtv I >>> would >>> use this to wait until the MPEG decoder flushed all buffers and >>> displayed >>> the last frame of the stream. That's something you would often do in >>> blocking mode. >> >> Blocking mode can easily be emulated using select(). It's quite simple to implement still so I'll do that in the VIDIOC_DQEVENT. Easier for applications anyway in use cases that I haven't been thinking about, e.g. ivtv. This btw. suggests that we perhaps should put back the struct file argument for the event functions in video_ioctl_ops. The blocking flag is indeed part of the file structure. I'm open to better suggestions, too. >>> >>> My long term goal is that the file struct is only used inside >>> v4l2-ioctl.c >>> and not in drivers. Drivers should not need this struct at all. The >>> easiest >>> way to ensure this is by not passing it to the drivers at all :-) >> >> Drivers still need a way to access the blocking flag. The interim solution >> of >> adding a file * member to v4l2_fh would allow that, while still removing >> most >> usage of file * from drivers. > > Why not just add a 'blocking' argument to the v4l2_event_dequeue? And let > v4l2-ioctl.c fill in that argument? That's how I would do it. Implemented already before reading your mail... :-) I'll try to repost the patches today. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PATCH] cx88-alsa: prevent out-of-range volume setting
Ensure that volume values are always in the allowed range. Otherwise,
it would be possible to set other bits in the AUD_VOL_CTL register or to
get a wrong sign in the AUD_BAL_CTL register.
Signed-off-by: Clemens Ladisch
--- linux/drivers/media/video/cx88/cx88-alsa.c
+++ linux/drivers/media/video/cx88/cx88-alsa.c
@@ -583,16 +583,18 @@ static int snd_cx88_volume_put(struct sn
{
snd_cx88_card_t *chip = snd_kcontrol_chip(kcontrol);
struct cx88_core *core=chip->core;
- int v, b;
+ int left, right, v, b;
int changed = 0;
u32 old;
- b = value->value.integer.value[1] - value->value.integer.value[0];
+ left = value->value.integer.value[0] & 0x3f;
+ right = value->value.integer.value[1] & 0x3f;
+ b = right - left;
if (b < 0) {
- v = 0x3f - value->value.integer.value[0];
+ v = 0x3f - left;
b = (-b) | 0x40;
} else {
- v = 0x3f - value->value.integer.value[1];
+ v = 0x3f - right;
}
/* Do we really know this will always be called with IRQs on? */
spin_lock_irq(&chip->reg_lock);
--
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: More videobuf and streaming I/O questions
Hi Hans and Laurent, On Mon, 22 Feb 2010 00:12:18 +0100 Laurent Pinchart wrote: > On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote: > > 1) The spec mentions that the memory field should be set for > > VIDIOC_DQBUF. But videobuf doesn't need it and it makes no sense to > > me either unless it is for symmetry with VIDIOC_QBUF. Strictly > > speaking QBUF doesn't need it either, but it is a good sanity check. > > > > Can I remove the statement in the spec that memory should be set > > for DQBUF? The alternative is to add a check against the memory > > field in videobuf, but that's rather scary. > > In that case I would remove it for QBUF as well, and state that the > memory field must be ignored by drivers (but should they fill it when > returning from QBUF/DQBUF ?) Agree. It seems that the memory field is not useful at all in the struct v4l2_buffer if a same process does reqbuf, qbuf, dqbuf and querybuf. BTW, I had a pending question. The spec says that streamoff 'removes all buffers from the incoming and outgoing queues' and return to 'the same state as after calling VIDIOC_REQBUFS'. For output, there is no problem. For capture, does this mean that the buffers previously queued by qbuf are implicitly unqueued (i.e. that qbuf must be done again for all buffers)? In this case, streamoff does not work with two processes. A first process is streaming when a second one does streamoff and then streamon. The first process will stay blocked on polling because no buffer is queued anymore. It cannot know this fact and the second process cannot requeue the buffers... To work correctly, the spec should say that streamoff discards the content of the filled buffers and that it requeues these buffers as empty either in the driver's incoming queue (capture) or outgoing queue (output). Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chroma gain configuration
> I'm asking because it seems a bit strange that someone would introduce > a v4l2 standard control to disable the AGC but not have the ability to > manually set the gain once it was disabled. As the person who introduced V4L2_CID_CHROMA_AGC for cx2388x I can explain that part. The AGC was actually introduced when only a manual gain setting was available and the AGC was disabled. The addition of the V4L2_CID_CHROMA_AGC allowed the AGC to be enabled by default, which is probably what most users want, but still have a way to set chroma gain manually. The cx88 driver allows you to set the UV-gain using the V4L2_CID_SATURATION control when the AGC is disabled. Regards, --Frej -- 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
hauppage 2200 on 2.6.33 kernel : nodename is now devnode
Hi, Sorry if this is a duplicate. My previous post didn't seem to appear. I'm using mythbuntu 9.10. I upgraded to kernel v2.6.33-rc8 because I have a DH55TC mobo (following the advice here https://wiki.ubuntu.com/Intel_DH55TC). This fixed a number of startup and slow video issues. Now I can't rebuild the drivers for my hauppage 2200 as I did for my previous kernel. I've been following the instructions here: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200 I've been using the dev tree but I also get similar errors with the stable tree. Initially I got a message complaining v4l/config-compat.h could not include autoconf.h. I got around that by changing the include to be: #include #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 33) #include #endif Now I get the following error: /home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.c: In function 'init_dvbdev': /home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.c:516: error: 'struct class' has no member named 'nodename' make[3]: *** [/home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.o] Error 1 make[2]: *** [_module_/home/john/local/src/hauppage-2200/saa7164-dev/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.33-020633rc8-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/john/local/src/hauppage-2200/saa7164-dev/v4l' make: *** [all] Error 2 As far as I can tell by googling, 'nodename' is now 'devnode' and has a different signature. I don't think I know enough to edit the driver source to reflect this. Has anyone got a solution? If the 2200 driver is not currently supported on 2.6.33 does anyone know when it might be? Thanks for any help! John. -- 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: Chroma gain configuration
On Sun, 2010-02-21 at 23:07 -0500, Devin Heitmueller wrote: > I am doing some work on the saa711x driver, and ran into a case where > I need to disable the chroma AGC and manually set the chroma gain. Sakari, Hans, or anyone else, On a somewhat related note, what is the status of the media controller and of file handles per v4l2_subdev. Will Sakari's V4L file-handle changes be all we need for the infrastructure or is there more to be done after that? I'd like to implement specific "technician controls", something an average user wouldn't use, for a few subdevs. > I see there is an existing boolean control called V4L2_CID_CHROMA_AGC, > which would be the logical candidate for allowing the user to disable > the chroma AGC. However, once this is done I still need to expose the > ability to set the gain manually (bits 6-0 of register 0x0f). > > Is there some existing control I am just missing? Or do I need to do > this through a private control. > > I'm asking because it seems a bit strange that someone would introduce > a v4l2 standard control to disable the AGC but not have the ability to > manually set the gain once it was disabled. Devin, Well, I can imagine letting hardware do the initial AGC, and then when it is settled manually disabling it to prevent hardware from getting "fooled". Regards, Andy > Suggestions welcome. I obviously would only want to introduce a > private control if absolutely necessary. > > 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: Chroma gain configuration
Andy Walls wrote: > On Sun, 2010-02-21 at 23:07 -0500, Devin Heitmueller wrote: >> I am doing some work on the saa711x driver, and ran into a case where >> I need to disable the chroma AGC and manually set the chroma gain. > > Sakari, Hans, or anyone else, > > On a somewhat related note, what is the status of the media controller > and of file handles per v4l2_subdev. Will Sakari's V4L file-handle > changes be all we need for the infrastructure or is there more to be > done after that? > > I'd like to implement specific "technician controls", something an > average user wouldn't use, for a few subdevs. The exposition of a control to the user or not is a decision of the userspace software developer. We shouldn't be too concerned about it. Eventually, we can group some controls on a "raw hardware level" group. I don't think we need a media controller for it. Also, this won't avoid developers to use the media controller to expose such controls to userspace. >> I see there is an existing boolean control called V4L2_CID_CHROMA_AGC, >> which would be the logical candidate for allowing the user to disable >> the chroma AGC. However, once this is done I still need to expose the >> ability to set the gain manually (bits 6-0 of register 0x0f). >> >> Is there some existing control I am just missing? Or do I need to do >> this through a private control. >> >> I'm asking because it seems a bit strange that someone would introduce >> a v4l2 standard control to disable the AGC but not have the ability to >> manually set the gain once it was disabled. > > Devin, > > Well, I can imagine letting hardware do the initial AGC, and then when > it is settled manually disabling it to prevent hardware from getting > "fooled". I did some tests on it with cx23881/cx23883 chips. At least on cx88, as far as I remember, the AGC doesn't affect the saturation register, so, this trick won't work. The issue with cx88 chips is that, with some video input sources, the AGC over-saturates the color pattern. So, depending on the analog video standard and the quality of the source (TV or Composite/Svideo), it gives more reallistic colors with different AGC/saturation configuration. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chroma gain configuration
Thanks everybody for the feedback. On Mon, Feb 22, 2010 at 7:15 AM, Mauro Carvalho Chehab wrote: > The issue with cx88 chips is that, with some video input sources, the > AGC over-saturates the color pattern. So, depending on the analog video > standard and the quality of the source (TV or Composite/Svideo), it gives > more reallistic colors with different AGC/saturation configuration. I'm actually having the same issue with the saa7113. I have a specific input source where I am getting too much chroma gain via the AGC, and need to disable it and manually turn it down a bit. While I can use the V4L2_CID_CHROMA_AGC to disable the AGC, I still need to then adjust the value of the gain. I guess I *could* reuse the saturation control, this time controlling the chroma gain register instead of the saturation register, it would seem to make more sense to have an explicit control, since the controls correspond to different registers and in theory could be controlled independently. I guess at this point, I have three options: 1. Introduce a new user control 2. Use a private control 3. Reuse the saturation control (hacking the driver such that the saturation control pokes different registers depending on whether the AGC is enabled). On a related note, has anyone noticed that the v4l2-dbg tool appears to always insist on using the "extended controls ioctl" for any attempts to set private controls? This doesn't seem right to me. I believe there probably are cases where extended controls are required, but I believe just a general user control based on V4L2_CID_PRIVATE_BASE should probably be able to work even with the generic VIDIOC_S_CTRL. I'm just asking because it would mean in order for v4l2-dbg to work with my solution i would have to add support for extended controls in general to the saa7115 driver, which shouldn't be necessary. Cheers, 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
Re: Chroma gain configuration
Devin Heitmueller wrote: > Thanks everybody for the feedback. > > On Mon, Feb 22, 2010 at 7:15 AM, Mauro Carvalho Chehab > wrote: >> The issue with cx88 chips is that, with some video input sources, the >> AGC over-saturates the color pattern. So, depending on the analog video >> standard and the quality of the source (TV or Composite/Svideo), it gives >> more reallistic colors with different AGC/saturation configuration. > > I'm actually having the same issue with the saa7113. I have a > specific input source where I am getting too much chroma gain via the > AGC, and need to disable it and manually turn it down a bit. > > While I can use the V4L2_CID_CHROMA_AGC to disable the AGC, I still > need to then adjust the value of the gain. I guess I *could* reuse > the saturation control, this time controlling the chroma gain register > instead of the saturation register, it would seem to make more sense > to have an explicit control, since the controls correspond to > different registers and in theory could be controlled independently. > > I guess at this point, I have three options: > > 1. Introduce a new user control > > 2. Use a private control > > 3. Reuse the saturation control (hacking the driver such that the > saturation control pokes different registers depending on whether the > AGC is enabled). I don't like (2). That's said, we really need to take a closer look on those color gain controls. We have already several controls that change color gain: #define V4L2_CID_SATURATION (V4L2_CID_BASE+2) #define V4L2_CID_AUTOGAIN (V4L2_CID_BASE+18) #define V4L2_CID_GAIN (V4L2_CID_BASE+19) #define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29) #define V4L2_CID_AUTO_WHITE_BALANCE (V4L2_CID_BASE+12) #define V4L2_CID_DO_WHITE_BALANCE (V4L2_CID_BASE+13) #define V4L2_CID_RED_BALANCE(V4L2_CID_BASE+14) #define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) #define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26) The map of the above controls are not uniform along the drivers, and the API is not clear enough about what is expected on each of the above controls. For example, on some drivers (mostly webcam ones), the red/blue balance as used as "red/blue gain", and not as balance. I remember we've started some discussions about this with some DaVinci patches, but we never finished those discussions. I think that the control you want is V4L2_CID_GAIN. > > On a related note, has anyone noticed that the v4l2-dbg tool appears > to always insist on using the "extended controls ioctl" for any > attempts to set private controls? This doesn't seem right to me. I agree. > I believe there probably are cases where extended controls are required, > but I believe just a general user control based on > V4L2_CID_PRIVATE_BASE should probably be able to work even with the > generic VIDIOC_S_CTRL > > I'm just asking because it would mean in order for v4l2-dbg to work > with my solution i would have to add support for extended controls in > general to the saa7115 driver, which shouldn't be necessary. The end objective is to have everybody implementing extended controls and removing the old controls, letting the V4L2 ioctl2 to convert a call to a simple control into an extended control callback. So, I think it would be worthy to implement extended control on saa7115. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chroma gain configuration
On Mon, Feb 22, 2010 at 8:40 AM, Mauro Carvalho Chehab wrote: > I think that the control you want is V4L2_CID_GAIN. I would have guessed the CID_GAIN control would have been responsible for *luma* gain. I could be wrong about that of course (but that is what I believe people typically think of when they think of "gain" in general). >> I believe there probably are cases where extended controls are required, >> but I believe just a general user control based on >> V4L2_CID_PRIVATE_BASE should probably be able to work even with the >> generic VIDIOC_S_CTRL >> >> I'm just asking because it would mean in order for v4l2-dbg to work >> with my solution i would have to add support for extended controls in >> general to the saa7115 driver, which shouldn't be necessary. > > The end objective is to have everybody implementing extended controls and > removing the old controls, letting the V4L2 ioctl2 to convert a call to a > simple control into an extended control callback. So, I think it would > be worthy to implement extended control on saa7115. Ok then. I'll add the 15-20 lines of code which add the extended controls mechanism to the 7115, which just operates as a passthrough for the older control interface. 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
Re: Chroma gain configuration
Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 8:40 AM, Mauro Carvalho Chehab > wrote: >> I think that the control you want is V4L2_CID_GAIN. > > I would have guessed the CID_GAIN control would have been responsible > for *luma* gain. I could be wrong about that of course (but that is > what I believe people typically think of when they think of "gain" in > general). Maybe it is for luma, but I bet that this is also is used for more than one different kind of control. We should revisit those controls and properly specify what they should do. > >>> I believe there probably are cases where extended controls are required, >>> but I believe just a general user control based on >>> V4L2_CID_PRIVATE_BASE should probably be able to work even with the >>> generic VIDIOC_S_CTRL >>> >>> I'm just asking because it would mean in order for v4l2-dbg to work >>> with my solution i would have to add support for extended controls in >>> general to the saa7115 driver, which shouldn't be necessary. >> The end objective is to have everybody implementing extended controls and >> removing the old controls, letting the V4L2 ioctl2 to convert a call to a >> simple control into an extended control callback. So, I think it would >> be worthy to implement extended control on saa7115. > > Ok then. I'll add the 15-20 lines of code which add the extended > controls mechanism to the 7115, which just operates as a passthrough > for the older control interface. The better is to do the opposite: extended being the control interface and the old calls as a passthrough, since the idea is to remove the old interface after having all drivers converted. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-utils
Hans Verkuil wrote: > Hi Mauro, Please address patches to v4l2-apps and other non-upstream stuff directly to Douglas ;) Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hauppage 2200 on 2.6.33 kernel : nodename is now devnode
On Mon, Feb 22, 2010 at 6:28 AM, John Reid wrote: > Hi, > > Sorry if this is a duplicate. My previous post didn't seem to appear. > > I'm using mythbuntu 9.10. > > I upgraded to kernel v2.6.33-rc8 because I have a DH55TC mobo (following the > advice here https://wiki.ubuntu.com/Intel_DH55TC). This fixed a number of > startup and slow video issues. > > Now I can't rebuild the drivers for my hauppage 2200 as I did for my > previous kernel. I've been following the instructions here: > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200 > I've been using the dev tree but I also get similar errors with the stable > tree. > > Initially I got a message complaining v4l/config-compat.h could not include > autoconf.h. I got around that by changing the include to be: > #include > #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 33) > #include > #endif > > Now I get the following error: > /home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.c: In function > 'init_dvbdev': > /home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.c:516: error: > 'struct class' has no member named 'nodename' > make[3]: *** [/home/john/local/src/hauppage-2200/saa7164-dev/v4l/dvbdev.o] > Error 1 > make[2]: *** [_module_/home/john/local/src/hauppage-2200/saa7164-dev/v4l] > Error 2 > make[2]: Leaving directory `/usr/src/linux-headers-2.6.33-020633rc8-generic' > make[1]: *** [default] Error 2 > make[1]: Leaving directory > `/home/john/local/src/hauppage-2200/saa7164-dev/v4l' > make: *** [all] Error 2 > > As far as I can tell by googling, 'nodename' is now 'devnode' and has a > different signature. I don't think I know enough to edit the driver source > to reflect this. Has anyone got a solution? If the 2200 driver is not > currently supported on 2.6.33 does anyone know when it might be? Hello John, There were some changes made in the 2.6.33 mainline kernel which were incompatible with the v4l-dvb tree (and the saa7164 tree on the kernellabs hg is based off of a version of v4l-dvb that is several months old). The issue should have been fixed relatively recently in the v4l-dvb trunk (which *does* contain pretty much all the hvr-2200 fixes). I would recommend you do an "hg clone http://linuxtv.org/hg/v4l-dvb"; and do a compile and see if it works. If it doesn't then post a reply. But to be clear, this has nothing to do with the HVR-2200 support in particular. 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
Re: [PATCH 1/3] tm6000: add send and recv function
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_regs’:
drivers/staging/tm6000/tm6000-i2c.c:58: error: ‘USB_VENDOR_TYPE’ undeclared
(first use in this function)
drivers/staging/tm6000/tm6000-i2c.c:58: error: (Each undeclared identifier is
reported only once
drivers/staging/tm6000/tm6000-i2c.c:58: error: for each function it appears in.)
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_regs16’:
drivers/staging/tm6000/tm6000-i2c.c:69: error: ‘USB_VENDOR_TYPE’ undeclared
(first use in this function)
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_xfer’:
drivers/staging/tm6000/tm6000-i2c.c:107: error: expected ‘)’ before ‘{’ token
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_eeprom’:
drivers/staging/tm6000/tm6000-i2c.c:161: error: implicit declaration of
function ‘tm6000_i2c_revc_regs’
Each patch shouldn't break compilation, or it would call git bisect troubles.
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/staging/tm6000/tm6000-i2c.c | 48 +-
> 1 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/tm6000/tm6000-i2c.c
> b/drivers/staging/tm6000/tm6000-i2c.c
> index 656cd19..b563129 100644
> --- a/drivers/staging/tm6000/tm6000-i2c.c
> +++ b/drivers/staging/tm6000/tm6000-i2c.c
> @@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
> printk(KERN_DEBUG "%s at %s: " fmt, \
> dev->name, __FUNCTION__ , ##args); } while (0)
>
> +int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
> reg, char *buf, int len)
> +{
> + return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> + REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
> +}
> +
> +/* read from a 8bit register */
> +int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
> reg, char *buf, int len)
> +{
> + int rc;
> +
> + rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
> USB_RECIP_DEVICE,
> + REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
> len);
> +
> + return rc;
> +}
> +
> +/* read from a 16bit register
> + * for example xc2028, xc3028 or xc3028L
> + */
> +int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr,
> __u16 reg, char *buf, int len)
> +{
> + return tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
> USB_RECIP_DEVICE,
> + REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
> +}
> +
> static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> struct i2c_msg msgs[], int num)
> {
> @@ -78,13 +104,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> i2c_dprintk(2, "; joined to read %s len=%d:",
> i == num - 2 ? "stop" : "nonstop",
> msgs[i + 1].len);
> - rc = tm6000_read_write_usb (dev,
> - USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> - msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
> - : REQ_14_SET_GET_I2C_WR2_RDN,
> - addr | msgs[i].buf[0] << 8,
> - msgs[i].len == 1 ? 0 : msgs[i].buf[1],
> + if (msgs{i].len == 1) {
> + rc = tm6000_i2c_recv_regs(dev, addr,
> msgs[i].buf[0],
> msgs[i + 1].buf, msgs[i + 1].len);
> + } else {
> + rc = tm6000_i2c_recv_regs(dev, addr,
> msgs[i].buf[0] << 8 | msgs[i].buf[1],
> + msgs[i + 1].buf, msgs[i + 1].len);
> + }
> +
> i++;
>
> if (addr == dev->tuner_addr) {
> @@ -99,10 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> if (i2c_debug >= 2)
> for (byte = 0; byte < msgs[i].len; byte++)
> printk(" %02x", msgs[i].buf[byte]);
> - rc = tm6000_read_write_usb(dev,
> - USB_DIR_OUT | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> - REQ_16_SET_GET_I2C_WR1_RDN,
> - addr | msgs[i].buf[0] << 8, 0,
> + rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
> msgs[i].buf + 1, msgs[i].len - 1);
>
> if (addr == dev->tuner_addr) {
> @@ -134,9 +158,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
> bytes[16] = '\0';
> for (i = 0; i < len; ) {
> *p = i;
> - rc = tm6000_read_write_usb (dev,
> - USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVIC
Re: [PATCH 2/3] tm6000: bugfix reading problems with demodulator zl10353
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
This patch depends on the previous one, so I can't apply it as-is.
Ah, please provide a better description for your patches. None of the patches
you
submitted so far contains a single line but the subject. please read
README.patches.
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/staging/tm6000/tm6000-i2c.c | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/tm6000/tm6000-i2c.c
> b/drivers/staging/tm6000/tm6000-i2c.c
> index b563129..6ae02b8 100644
> --- a/drivers/staging/tm6000/tm6000-i2c.c
> +++ b/drivers/staging/tm6000/tm6000-i2c.c
> @@ -54,9 +54,20 @@ int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
> char addr, __u8 reg,
> int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
> reg, char *buf, int len)
> {
> int rc;
> + u8 b[2];
>
> + if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr) && (reg %
> 2 == 0)) {
> + reg -= 1;
> + len += 1;
> +
> + rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
> USB_RECIP_DEVICE,
> + REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, b, len);
> +
> + *buf = b[1];
> + } else {
> rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
> USB_RECIP_DEVICE,
> REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
> len);
> + }
>
> return rc;
> }
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] tm6000: add send and recv function
Am 22.02.2010 16:16, schrieb Mauro Carvalho Chehab:
> stefan.rin...@arcor.de wrote:
>
>> From: Stefan Ringel
>>
>
> drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_regs’:
> drivers/staging/tm6000/tm6000-i2c.c:58: error: ‘USB_VENDOR_TYPE’ undeclared
> (first use in this function)
> drivers/staging/tm6000/tm6000-i2c.c:58: error: (Each undeclared identifier is
> reported only once
> drivers/staging/tm6000/tm6000-i2c.c:58: error: for each function it appears
> in.)
> drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_recv_regs16’:
> drivers/staging/tm6000/tm6000-i2c.c:69: error: ‘USB_VENDOR_TYPE’ undeclared
> (first use in this function)
> drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_xfer’:
> drivers/staging/tm6000/tm6000-i2c.c:107: error: expected ‘)’ before ‘{’ token
> drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_eeprom’:
> drivers/staging/tm6000/tm6000-i2c.c:161: error: implicit declaration of
> function ‘tm6000_i2c_revc_regs’
>
> Each patch shouldn't break compilation, or it would call git bisect troubles.
>
>
>
>> Signed-off-by: Stefan Ringel
>> ---
>> drivers/staging/tm6000/tm6000-i2c.c | 48
>> +-
>> 1 files changed, 35 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/staging/tm6000/tm6000-i2c.c
>> b/drivers/staging/tm6000/tm6000-i2c.c
>> index 656cd19..b563129 100644
>> --- a/drivers/staging/tm6000/tm6000-i2c.c
>> +++ b/drivers/staging/tm6000/tm6000-i2c.c
>> @@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages
>> [i2c]");
>> printk(KERN_DEBUG "%s at %s: " fmt, \
>> dev->name, __FUNCTION__ , ##args); } while (0)
>>
>> +int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
>> reg, char *buf, int len)
>> +{
>> +return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
>> USB_RECIP_DEVICE,
>> +REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
>> +}
>> +
>> +/* read from a 8bit register */
>> +int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
>> reg, char *buf, int len)
>> +{
>> +int rc;
>> +
>> +rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
>> USB_RECIP_DEVICE,
>> +REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
>> len);
>> +
>> +return rc;
>> +}
>> +
>> +/* read from a 16bit register
>> + * for example xc2028, xc3028 or xc3028L
>> + */
>> +int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr,
>> __u16 reg, char *buf, int len)
>> +{
>> +return tm6000_read_write_usb(dev, USB_DIR_IN | USB_VENDOR_TYPE |
>> USB_RECIP_DEVICE,
>> +REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
>> +}
>> +
>> static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
>> struct i2c_msg msgs[], int num)
>> {
>> @@ -78,13 +104,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
>> i2c_dprintk(2, "; joined to read %s len=%d:",
>> i == num - 2 ? "stop" : "nonstop",
>> msgs[i + 1].len);
>> -rc = tm6000_read_write_usb (dev,
>> -USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
>> -msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
>> - : REQ_14_SET_GET_I2C_WR2_RDN,
>> -addr | msgs[i].buf[0] << 8,
>> -msgs[i].len == 1 ? 0 : msgs[i].buf[1],
>> +if (msgs{i].len == 1) {
>> +rc = tm6000_i2c_recv_regs(dev, addr,
>> msgs[i].buf[0],
>> msgs[i + 1].buf, msgs[i + 1].len);
>> +} else {
>> +rc = tm6000_i2c_recv_regs(dev, addr,
>> msgs[i].buf[0] << 8 | msgs[i].buf[1],
>> +msgs[i + 1].buf, msgs[i + 1].len);
>> +}
>> +
>> i++;
>>
>> if (addr == dev->tuner_addr) {
>> @@ -99,10 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
>> if (i2c_debug >= 2)
>> for (byte = 0; byte < msgs[i].len; byte++)
>> printk(" %02x", msgs[i].buf[byte]);
>> -rc = tm6000_read_write_usb(dev,
>> -USB_DIR_OUT | USB_TYPE_VENDOR |
>> USB_RECIP_DEVICE,
>> -REQ_16_SET_GET_I2C_WR1_RDN,
>> -addr | msgs[i].buf[0] << 8, 0,
>> +rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
>> msgs[i].buf + 1, msgs[i].len - 1);
>>
>> if (addr == dev->tuner_addr) {
>> @@ -134,9 +158,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
>> bytes[16]
[PATCH v6 0/6] V4L2 file handles and event interface
Hi, Here's the eighth version of the V4L2 file handle and event interface patchset. The patchset has been tested with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called event): git://gitorious.org/omap3camera/mainline.git event The patchset I'm posting now is against the v4l-dvb tree instead of linux-omap. The omap3camera tree thus has a slightly different version of these patches due to different baselines. Some more comments from Hans and Laurent. What has changed: - Improved documentation. - V4L2_EVENT_ALL only valid in unsubscribing. - Events are initialised in v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is defined. - Event ioctl handlers are called in __video_do_ioctl() iff video_device->ioctl_ops->vidioc_subscribe_event is defined, no other constraints. - Blocking operation for VIDIOC_DQEVENT. - v4l2_event_subscribe_many() is gone. - Fixed memory leak in v4l2_event_subscribe() Comments are welcome as always. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PATCH 3/6] V4L: Events: Add new ioctls for events
This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:
http://www.spinics.net/lists/linux-media/msg12033.html>
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-compat-ioctl32.c |3 +++
drivers/media/video/v4l2-ioctl.c |3 +++
include/linux/videodev2.h | 26 ++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index f77f84b..9004a5f 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1086,6 +1086,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_PRESET:
case VIDIOC_S_DV_TIMINGS:
case VIDIOC_G_DV_TIMINGS:
+ case VIDIOC_DQEVENT:
+ case VIDIOC_SUBSCRIBE_EVENT:
+ case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..34c7d6e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -290,6 +290,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_QUERY_DV_PRESET)] = "VIDIOC_QUERY_DV_PRESET",
[_IOC_NR(VIDIOC_S_DV_TIMINGS)] = "VIDIOC_S_DV_TIMINGS",
[_IOC_NR(VIDIOC_G_DV_TIMINGS)] = "VIDIOC_G_DV_TIMINGS",
+ [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
+ [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
+ [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..f7237fc 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1622,6 +1622,29 @@ struct v4l2_streamparm {
};
/*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+ __u32 type;
+ union {
+ __u8data[64];
+ } u;
+ __u32 pending;
+ __u32 sequence;
+ struct timespec timestamp;
+ __u32 reserved[9];
+};
+
+struct v4l2_event_subscription {
+ __u32 type;
+ __u32 reserved[7];
+};
+
+#define V4L2_EVENT_ALL 0
+#define V4L2_EVENT_PRIVATE_START 0x0800
+
+/*
* A D V A N C E D D E B U G G I N G
*
* NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1743,6 +1766,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset)
#defineVIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
#defineVIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
+#defineVIDIOC_DQEVENT _IOR('V', 83, struct v4l2_event)
+#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 84, struct
v4l2_event_subscription)
+#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 85, struct
v4l2_event_subscription)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] V4L: Events: Add documentation
Add documentation on how to use V4L2 events, both for V4L2 drivers and for V4L2 applications. Signed-off-by: Sakari Ailus --- Documentation/DocBook/media-entities.tmpl |9 ++ Documentation/DocBook/v4l/dev-event.xml| 34 ++ Documentation/DocBook/v4l/v4l2.xml |3 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 124 .../DocBook/v4l/vidioc-subscribe-event.xml | 103 Documentation/video4linux/v4l2-framework.txt | 58 + 6 files changed, 331 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/dev-event.xml create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c725cb8..770be3c 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -17,6 +17,7 @@ VIDIOC_DBG_G_REGISTER"> VIDIOC_DBG_S_REGISTER"> VIDIOC_DQBUF"> +VIDIOC_DQEVENT"> VIDIOC_ENCODER_CMD"> VIDIOC_ENUMAUDIO"> VIDIOC_ENUMAUDOUT"> @@ -60,6 +61,7 @@ VIDIOC_REQBUFS"> VIDIOC_STREAMOFF"> VIDIOC_STREAMON"> +VIDIOC_SUBSCRIBE_EVENT"> VIDIOC_S_AUDIO"> VIDIOC_S_AUDOUT"> VIDIOC_S_CROP"> @@ -141,6 +143,8 @@ v4l2_enc_idx"> v4l2_enc_idx_entry"> v4l2_encoder_cmd"> +v4l2_event"> +v4l2_event_subscription"> v4l2_ext_control"> v4l2_ext_controls"> v4l2_fmtdesc"> @@ -200,6 +204,7 @@ + @@ -292,6 +297,8 @@ + + @@ -381,3 +388,5 @@ + + diff --git a/Documentation/DocBook/v4l/dev-event.xml b/Documentation/DocBook/v4l/dev-event.xml new file mode 100644 index 000..70a9895 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-event.xml @@ -0,0 +1,34 @@ + Event Interface + + The V4L2 event interface provides means for user to get + immediately notified on certain conditions taking place on a device. + This might include start of frame or loss of signal events, for + example. + + + To receive events, the events the user is interested first + must be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an + event is subscribed, the events of subscribed types are dequeueable + using the &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type + V4L2_EVENT_ALL may be used to subscribe or unsubscribe all the + events the driver supports. + + The event subscriptions and event queues are specific to file + handles. Subscribing an event on one file handle does not affect + other file handles. + + + The information on dequeueable events are obtained by using + select or poll system calls on video devices. The V4L2 events use + POLLPRI events on poll system call and exceptions on select system + call. + + + diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 060105a..9737243 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -401,6 +401,7 @@ and discussions on the V4L mailing list. &sub-dev-teletext; &sub-dev-radio; &sub-dev-rds; + &sub-dev-event; @@ -426,6 +427,7 @@ and discussions on the V4L mailing list. &sub-cropcap; &sub-dbg-g-chip-ident; &sub-dbg-g-register; +&sub-dqevent; &sub-encoder-cmd; &sub-enumaudio; &sub-enumaudioout; @@ -467,6 +469,7 @@ and discussions on the V4L mailing list. &sub-reqbufs; &sub-s-hw-freq-seek; &sub-streamon; +&sub-subscribe-event; &sub-mmap; &sub-munmap; diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml b/Documentation/DocBook/v4l/vidioc-dqevent.xml new file mode 100644 index 000..eb45c16 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml @@ -0,0 +1,124 @@ + + +ioctl VIDIOC_DQEVENT +&manvol; + + + +VIDIOC_DQEVENT +Dequeue event + + + + + + int ioctl + int fd + int request + struct v4l2_event +*argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DQEVENT + + + + argp + + + + + + + + +Description + +Dequeue an event from a video device. No input is required +for this ioctl. All the fields of the &v4l2-event; structure are +filled by the driver. The file handle will also receive exceptions +which the application may get by e.g. using the select system +call. + + + struct v4l2_event + + &cs-str; + + + __u32 + type + + Type of the event. + + + union + u + + + + + + __u8 +data[64] + Event data. Defin
[PATCH 4/6] V4L: Events: Add backend
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.
Signed-off-by: Sakari Ailus
Header from folded patch 'event-dq-block':
V4L: Events: Blocking dqevent
Signed-off-by: Sakari Ailus
---
drivers/media/video/Makefile |3 +-
drivers/media/video/v4l2-event.c | 294 ++
drivers/media/video/v4l2-fh.c|5 +
include/media/v4l2-event.h | 67 +
include/media/v4l2-fh.h |2 +
5 files changed, 370 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/v4l2-event.c
create mode 100644 include/media/v4l2-event.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 14bf69a..b84abfe 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,8 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
+ v4l2-event.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..d65df06
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,294 @@
+/*
+ * drivers/media/video/v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+int v4l2_event_init(struct v4l2_fh *fh)
+{
+ if (fh->events != NULL) {
+ WARN_ON(1);
+ return 0;
+ }
+
+ fh->events = kzalloc(sizeof(*fh->events), GFP_KERNEL);
+ if (fh->events == NULL)
+ return -ENOMEM;
+
+ init_waitqueue_head(&fh->events->wait);
+
+ INIT_LIST_HEAD(&fh->events->free);
+ INIT_LIST_HEAD(&fh->events->available);
+ INIT_LIST_HEAD(&fh->events->subscribed);
+
+ fh->events->sequence = -1;
+
+ return 0;
+}
+
+int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
+{
+ struct v4l2_events *events = fh->events;
+ unsigned long flags;
+
+ if (!events) {
+ WARN_ON(1);
+ return -ENOMEM;
+ }
+
+ while (events->nallocated < n) {
+ struct v4l2_kevent *kev;
+
+ kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+ if (kev == NULL)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_add_tail(&kev->list, &events->free);
+ events->nallocated++;
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_alloc);
+
+#define list_kfree(list, type, member) \
+ while (!list_empty(list)) { \
+ type *hi; \
+ hi = list_first_entry(list, type, member); \
+ list_del(&hi->member); \
+ kfree(hi); \
+ }
+
+void v4l2_event_free(struct v4l2_fh *fh)
+{
+ struct v4l2_events *events = fh->events;
+
+ if (!events)
+ return;
+
+ list_kfree(&events->free, struct v4l2_kevent, list);
+ list_kfree(&events->available, struct v4l2_kevent, list);
+ list_kfree(&events->subscribed, struct v4l2_subscribed_event, list);
+
+ kfree(events);
+ fh->events = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_free);
+
+static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
+{
+ struct v4l2_events *events = fh->events;
+ struct v4l2_kevent *kev;
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+
+ if (list_empty(&events->available)) {
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+ return -ENOENT;
+ }
+
+ WARN_ON(events->navailable == 0);
+
+ kev = list_first_entry(&event
[PATCH 1/6] V4L: File handles
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.
Video device drivers should use the v4l2_fh pointer as their
file->private_data.
Signed-off-by: Sakari Ailus
---
drivers/media/video/Makefile |2 +-
drivers/media/video/v4l2-dev.c |4 ++
drivers/media/video/v4l2-fh.c | 64
include/media/v4l2-dev.h |5 +++
include/media/v4l2-fh.h| 42 ++
5 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/v4l2-fh.c
create mode 100644 include/media/v4l2-fh.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 5163289..14bf69a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..65a7b30 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -421,6 +421,10 @@ static int __video_register_device(struct video_device
*vdev, int type, int nr,
if (!vdev->release)
return -EINVAL;
+ /* v4l2_fh support */
+ spin_lock_init(&vdev->fh_lock);
+ INIT_LIST_HEAD(&vdev->fh_list);
+
/* Part 1: check device type */
switch (type) {
case VFL_TYPE_GRABBER:
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
new file mode 100644
index 000..c707930
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,64 @@
+/*
+ * drivers/media/video/v4l2-fh.c
+ *
+ * V4L2 file handles.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+{
+ fh->vdev = vdev;
+ INIT_LIST_HEAD(&fh->list);
+ set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_init);
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_add(&fh->list, &fh->vdev->fh_list);
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_add);
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_del_init(&fh->list);
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+{
+ if (fh->vdev == NULL)
+ return;
+
+ fh->vdev = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2dee938..bebe44b 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -32,6 +32,7 @@ struct v4l2_device;
Drivers can clear this flag if they want to block all future
device access. It is cleared by video_unregister_device. */
#define V4L2_FL_REGISTERED (0)
+#define V4L2_FL_USES_V4L2_FH (1)
struct v4l2_file_operations {
struct module *owner;
@@ -77,6 +78,10 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
+ /* V4L2 file handles */
+ spinlock_t fh_lock; /* Lock for all v4l2_fhs */
+ struct list_headfh_list; /* List of struct v4l2_fh */
+
int debug; /* Activates debug level*/
/* Video standard vars */
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
new file mode 100644
index 000..6b486aa
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,42 @@
+/*
+ * include/media/v4l2-fh.h
+ *
+ * V4L2 file handle.
+ *
+ * Copyright (C) 2009 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * vers
[PATCH 5/6] V4L: Events: Support event handling in do_ioctl
Add support for event handling to do_ioctl.
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-fh.c|5 +++-
drivers/media/video/v4l2-ioctl.c | 50 ++
include/media/v4l2-ioctl.h |7 +
3 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index 713f5a0..2986a2c 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -33,7 +33,10 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device
*vdev)
fh->vdev = vdev;
INIT_LIST_HEAD(&fh->list);
set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
- v4l2_event_init(fh);
+ if (vdev->ioctl_ops && vdev->ioctl_ops->vidioc_subscribe_event)
+ v4l2_event_init(fh);
+ else
+ fh->events = NULL;
}
EXPORT_SYMBOL_GPL(v4l2_fh_init);
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 34c7d6e..4ba22da 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -25,6 +25,8 @@
#endif
#include
#include
+#include
+#include
#include
#define dbgarg(cmd, fmt, arg...) \
@@ -1944,7 +1946,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+ case VIDIOC_DQEVENT:
+ {
+ struct v4l2_event *ev = arg;
+
+ if (!ops->vidioc_subscribe_event)
+ break;
+
+ ret = v4l2_event_dequeue(fh, ev, file->f_flags & O_NONBLOCK);
+ if (ret < 0) {
+ dbgarg(cmd, "no pending events?");
+ break;
+ }
+ dbgarg(cmd,
+ "pending=%d, type=0x%8.8x, sequence=%d, "
+ "timestamp=%lu.%9.9lu ",
+ ev->pending, ev->type, ev->sequence,
+ ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
+ break;
+ }
+ case VIDIOC_SUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+ if (!ops->vidioc_subscribe_event)
+ break;
+
+ ret = ops->vidioc_subscribe_event(fh, sub);
+ if (ret < 0) {
+ dbgarg(cmd, "failed, ret=%ld", ret);
+ break;
+ }
+ dbgarg(cmd, "type=0x%8.8x", sub->type);
+ break;
+ }
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+
+ if (!ops->vidioc_unsubscribe_event)
+ break;
+
+ ret = ops->vidioc_unsubscribe_event(fh, sub);
+ if (ret < 0) {
+ dbgarg(cmd, "failed, ret=%ld", ret);
+ break;
+ }
+ dbgarg(cmd, "type=0x%8.8x", sub->type);
+ break;
+ }
default:
{
if (!ops->vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..06daa6e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -21,6 +21,8 @@
#include
#endif
+struct v4l2_fh;
+
struct v4l2_ioctl_ops {
/* ioctl callbacks */
@@ -254,6 +256,11 @@ struct v4l2_ioctl_ops {
int (*vidioc_g_dv_timings) (struct file *file, void *fh,
struct v4l2_dv_timings *timings);
+ int (*vidioc_subscribe_event) (struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+ int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] V4L: File handles: Add documentation
Add documentation on using V4L2 file handles (v4l2_fh) in V4L2 drivers. Signed-off-by: Sakari Ailus --- Documentation/video4linux/v4l2-framework.txt | 37 ++ 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 74d677c..bfaf0c5 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -695,3 +695,40 @@ The better way to understand it is to take a look at vivi driver. One of the main reasons for vivi is to be a videobuf usage example. the vivi_thread_tick() does the task that the IRQ callback would do on PCI drivers (or the irq callback on USB). + +struct v4l2_fh +-- + +struct v4l2_fh provides a way to easily keep file handle specific data +that is used by the V4L2 framework. + +struct v4l2_fh is allocated as a part of the driver's own file handle +structure and is set to file->private_data in the driver's open +function by the driver. Drivers can extract their own file handle +structure by using the container_of macro. + +Useful functions: + +- v4l2_fh_init() + + Initialise the file handle. This *MUST* be performed in the driver's + v4l2_file_operations->open() handler. + +- v4l2_fh_add() + + Add a v4l2_fh to video_device file handle list. May be called after + initialising the file handle. + +- v4l2_fh_del() + + Unassociate the file handle from video_device(). The file handle + exit function may now be called. + +- v4l2_fh_exit() + + Uninitialise the file handle. After uninitialisation the v4l2_fh + memory can be freed. + +The users of v4l2_fh know whether a driver uses v4l2_fh as its +file->private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in +video_device->flags. -- 1.5.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] V4L: File handles
Sakari Ailus wrote: > This patch adds a list of v4l2_fh structures to every video_device. > It allows using file handle related information in V4L2. The event interface > is one example of such use. > > Video device drivers should use the v4l2_fh pointer as their > file->private_data. FYI: misspelled Laurent's address. Please change that when replying. Sorry. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: adv7180 as SoC camera device
On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: > On Fri, 19 Feb 2010, Rodolfo Giometti wrote: > > > Hello, > > > > on my pxa27x based board I have a adv7180 connected with the CIF > > interface. Due this fact I'm going to use the pxa_camera.c driver > > which in turn registers a soc_camera_host. > > > > In the latest kernel I found your driver for the ADV7180, but it > > registers the chip as a v4l sub device. > > > > I suppose these two interfaces are not compatible, aren't they? > > Congratulations! Thereby you're in a position to develop the first > v4l2-subdev / soc-camera universal driver;) The answer to this your > question is - they are... kinda. This means - yes, soc-camera is also > using the v4l2-subdev API, but - with a couple of additions. Basically, > there are two things you have to change in the adv7180 driver to make it > compatible with soc-camera - (1) add bus-configuration methods, even if > they don't do much (see .query_bus_param() and .set_bus_param() methods > from struct soc_camera_ops), and (2) migrate the driver to the mediabus > API. The latter one requires some care - in principle, mediabus should be > the future API to negotiate parameters on the video bus between bridges > (in your case PXA CIF) and clients, but for you this means you also have > to migrate any other bridge drivers in the mainline to that API, and, if > they also interface to some other subdevices - those too, and if those can > also work with other bridges - those too...;) But, I think, that chain > will terminate quite soon, in fact, I cannot find any users of that driver > currently in the mainline, Richard? > > > In this situation, should I write a new driver for the > > soc_camera_device? Which is The-Right-Thing(TM) to do? :) > > Please, have a look and try to convert the driver as described above. All > the APIs and a few examples are in the mainline, so, you should have > enough copy-paste sources;) Ask on the list (with me on cc) if anything is > still unclear. Thanks for your quick answer! :) What I still don't understand is if should I move the driver form v4l2-subdev to a soc_camera device or trying to support both API... It seems to me that the driver is not used by any machines into mainline so if soc-camera is also using the v4l2-subdev API but with a couple of additions I suppose I can move it to soc_camera API... Is that right? Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giome...@enneenne.com Linux Device Driver giome...@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it -- 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 v5 4/6] V4L: Events: Add backend
On Sunday 21 February 2010 21:57:47 Sakari Ailus wrote:
> Hans Verkuil wrote:
> > Hi Sakari,
>
> Hi Hans,
>
> And many thanks for the comments again!
>
> > Here are some more comments.
> >
> ...
> >> +
> >> +static void v4l2_event_unsubscribe_all(struct v4l2_fh *fh)
> >> +{
> >> + struct v4l2_events *events = fh->events;
> >> + unsigned long flags;
> >> +
> >> + spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> >> +
> >> + while (!list_empty(&events->subscribed)) {
> >> + struct v4l2_subscribed_event *sev;
> >> +
> >> + sev = list_first_entry(&events->subscribed,
> >> + struct v4l2_subscribed_event, list);
> >> +
> >> + list_del(&sev->list);
> >> + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> >> + kfree(sev);
> >> + spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> >> + }
> >> +
> >> + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> >> +}
> >
> > What about this:
> >
> > static void v4l2_event_unsubscribe_all(struct v4l2_fh *fh)
> > {
> > struct v4l2_events *events = fh->events;
> > struct v4l2_subscribed_event *sev;
> > unsigned long flags;
> >
> > do {
> > sev = NULL;
> >
> > spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> > if (!list_empty(&events->subscribed)) {
> > sev = list_first_entry(&events->subscribed,
> >struct v4l2_subscribed_event, list);
> > list_del(&sev->list);
> > }
> > spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> > kfree(sev);
> > } while (sev);
> > }
> >
> > This avoids the 'interleaved' locking which I never like.
>
> Can do. I don't see anything bad in that kind of locking, though. ;-)
Locking is hard to get right. So it is important to keep the locking code as
straightforward as possible. In the original code you really have to look
closely at the code to check that the locking is correct. In the rewritten
code it is much more obvious because of the simplified control flow.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-utils
On Monday 22 February 2010 16:07:15 Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: > > Hi Mauro, > > Please address patches to v4l2-apps and other non-upstream stuff directly to > Douglas ;) Oops! I've corrected my script :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v1 0/4] Multi-plane video buffer support for V4L2 API and videobuf
Hello, This is a preliminary implementation of multi-planar buffer support for V4L2 and videobuf. It is a rather big change so I wanted to put it up for discussion sooner rather than later, in case we decide to go in a completely different direction. We are proposing backward compatible extensions to the V4L2 API and a redesign of memory handling in videobuf core and its memory type modules. The videobuf redesign should have a minimal impact on current drivers though. No videobuf high-level logic (queuing, etc.) has been changed. Only streaming I/O has been tested, read/write might not work correctly. vivi has been adapted for testing and demonstration purposes, but other drivers will not compile. Tests have been made on vivi and on an another driver for an embedded device (those involved dma-contig and USERPTR as well). I am not attaching that driver, as I expect nobody would be able to compile/test it anyway. The previous discussion concerning V4L2 API changes can be found here: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11212. = Purpose and requirements = Currently, the v4l2_buffer struct supports only contiguous memory buffers, i.e. one video frame has to fit into one, contiguous physical buffer. A driver receives from and passes back to the userspace (e.g. when mmap()ing) only one pointer (offset). Our hardware requires two physically separate buffers for Y and CbCr components, which must be placed in two different memory banks. A similar problem was also expressed by Jun Nie: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/10462. This series adds support for a more general type of video buffers: n-plane buffers. = Contents = This series consists of the following parts: - V4L2 API extensions - videobuf core and memory type modifications - vivi extensions for YCbCr422 2- and 3-planar formats API extensions are standalone and fully backward compatible with the old videobuf, drivers and applications. As for videobuf, it could have probably been possible to retain backward compatibility, but we have chosen to introduce some minimal changes, mostly to avoid duplication. They should require only a little bit of minor and practically automatic modifications in the existing drivers though (details below). We have also broken ABI compatibility in one place (videobuf_queue_ops), in order to make sure those minor changes are taken into account by drivers that use videobuf. Please note that videobuf-dma-sg is not adapted yet and will fail to compile, as will all the other drivers, with the exception of vivi, which is intended for demonstration. I will of course adapt everything else as well, after we have agreed on everything. I hope vmalloc and dma-contig are enough for everybody to be able to test/verify and/or discuss. = I. V4L2 API changes = 1. New memory types: -- V4L2_MEMORY_MULTI_USERPTR V4L2_MEMORY_MULTI_MMAP Basically USERTPTR and MMAP for multiplane buffers. 2. A new v4l2_plane structure. -- v4l2_buffers of type V4L2_MEMORY_MULTI_* now contain an array of v4l2_plane structures under their 'planes' member pointer. The size of the array should be equal to the number of planes in the buffer and should be stored in the 'length' member of the buffer structure (recycled for this purpose). The v4l2_plane structure members retain the meaning of their counterparts in the v4l2_buffer struct, but refer to their respective planes. 3. Ioctl handling -- Automatic v4l2_plane array copying has been added for relevant ioctls: QUERYBUF, QBUF and DQBUF. Copy operations are performed only if 'memory' is set to V4L2_MEMORY_MULTI_* and the 'planes' pointer is not NULL. = II. videobuf API changes = 1. A new videobuf_plane structure -- All the memory-related info, such as baddr, bsize, etc. has been moved there. Mappings and private data for memory-specific code should be per-plane now as well. The videobuf_buffer structure now contains the buffer logic-related parts only (queuing, etc.). From the logical point of view (e.g. queuing, waiting, etc.) a videobuf_buffer is it still one entity (userspace cannot operate on planes separately). The new 'mapped' member is set to 1 when all the planes are mapped. A plane is treated as a separate memory buffer, so now all the memory type-related management operates on planes, even if the buffer is not multiplanar. A non-multiplanar buffer is simply a buffer with one plane (planes start at 0). I could have left baddr, bsize, etc. in videobuf_buffer to retain compatibility, but I think that changing all related code from e.g. vb-
[PATCH v1 4/4] v4l: vivi: add 2- and 3-planar YCbCr422
Add example 2- and 3- planar YCbCr422 formats for multi-plane
format testing.
Signed-off-by: Pawel Osciak
Reviewed-by: Kyungmin Park
---
drivers/media/video/vivi.c | 179 +++-
include/linux/videodev2.h |3 +
2 files changed, 147 insertions(+), 35 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 37632a0..bc1ec0d 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -132,6 +132,9 @@ struct vivi_fmt {
char *name;
u32 fourcc; /* v4l2 format id */
int depth;
+ unsigned int num_planes;
+ unsigned int plane_w_shr;
+ unsigned int plane_h_shr;
};
static struct vivi_fmt formats[] = {
@@ -139,31 +142,53 @@ static struct vivi_fmt formats[] = {
.name = "4:2:2, packed, YUYV",
.fourcc = V4L2_PIX_FMT_YUYV,
.depth= 16,
+ .num_planes = 1,
},
{
.name = "4:2:2, packed, UYVY",
.fourcc = V4L2_PIX_FMT_UYVY,
.depth= 16,
+ .num_planes = 1,
},
{
.name = "RGB565 (LE)",
.fourcc = V4L2_PIX_FMT_RGB565, /* gggb rggg */
.depth= 16,
+ .num_planes = 1,
},
{
.name = "RGB565 (BE)",
.fourcc = V4L2_PIX_FMT_RGB565X, /* rggg gggb */
.depth= 16,
+ .num_planes = 1,
},
{
.name = "RGB555 (LE)",
.fourcc = V4L2_PIX_FMT_RGB555, /* gggb argg */
.depth= 16,
+ .num_planes = 1,
},
{
.name = "RGB555 (BE)",
.fourcc = V4L2_PIX_FMT_RGB555X, /* argg gggb */
.depth= 16,
+ .num_planes = 1,
+ },
+ {
+ .name = "YUV 4:2:2, 3-planar",
+ .fourcc = V4L2_PIX_FMT_YUV422PM,
+ .depth = 16,
+ .num_planes = 3,
+ .plane_w_shr= 1,
+ .plane_h_shr= 0,
+ },
+ {
+ .name = "YUV 4:2:2, 2-planar",
+ .fourcc = V4L2_PIX_FMT_NV16M,
+ .depth = 16,
+ .num_planes = 2,
+ .plane_w_shr= 1,
+ .plane_h_shr= 0,
},
};
@@ -361,6 +386,8 @@ static void precalculate_bars(struct vivi_fh *fh)
switch (fh->fmt->fourcc) {
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YUV422PM:
+ case V4L2_PIX_FMT_NV16M:
is_yuv = 1;
break;
case V4L2_PIX_FMT_RGB565:
@@ -410,6 +437,8 @@ static void gen_twopix(struct vivi_fh *fh, unsigned char
*buf, int colorpos)
switch (fh->fmt->fourcc) {
case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_YUV422PM:
+ case V4L2_PIX_FMT_NV16M:
switch (color) {
case 0:
case 2:
@@ -558,30 +587,58 @@ end:
static void vivi_fillbuff(struct vivi_fh *fh, struct vivi_buffer *buf)
{
struct vivi_dev *dev = fh->dev;
- int h , pos = 0;
+ int i, x, h, curr_plane = 0, pos = 0;
int hmax = buf->vb.height;
int wmax = buf->vb.width;
struct timeval ts;
- char *tmpbuf;
- void *vbuf = videobuf_to_vmalloc(&buf->vb);
+ char *tmpbuf, *p_tmpbuf;
+ char *vbuf[VIDEO_MAX_PLANES];
+
+ for (i = 0; i < fh->fmt->num_planes; ++i) {
+ vbuf[i] = videobuf_plane_to_vmalloc(&buf->vb, i);
+ if (!vbuf[i]) {
+ dprintk(dev, 1, "Failed acquiring vaddr for a plane\n");
+ return;
+ }
+ }
- if (!vbuf)
- return;
+ if (fh->fmt->num_planes > 1) {
+ tmpbuf = kmalloc(wmax * 2, GFP_ATOMIC);
+ if (!tmpbuf)
+ return;
+
+ for (h = 0; h < hmax; h++) {
+ gen_line(fh, tmpbuf, 0, wmax, hmax, h, dev->mv_count,
+dev->timestr);
+ p_tmpbuf = tmpbuf;
+
+ for (x = 0; x < wmax; ++x) {
+ *(vbuf[0]++) = *p_tmpbuf++;
+ *(vbuf[curr_plane + 1]++) = *p_tmpbuf++;
+ if (V4L2_PIX_FMT_YUV422PM == fh->fmt->fourcc)
+ curr_plane = !curr_plane;
+ }
+ }
- tmpbuf = kmalloc(wmax * 2, GFP_ATOMIC);
- if (!tmpbuf)
- return;
+ dev->mv_count++;
- for (h =
[PATCH v1 1/4] v4l: add missing checks for kzalloc returning NULL.
Signed-off-by: Pawel Osciak --- drivers/media/video/videobuf-dma-sg.c |2 ++ drivers/media/video/videobuf-vmalloc.c |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c index fa78555..fcd045e 100644 --- a/drivers/media/video/videobuf-dma-sg.c +++ b/drivers/media/video/videobuf-dma-sg.c @@ -418,6 +418,8 @@ static void *__videobuf_alloc(size_t size) struct videobuf_buffer *vb; vb = kzalloc(size+sizeof(*mem),GFP_KERNEL); + if (!vb) + return vb; mem = vb->priv = ((char *)vb)+size; mem->magic=MAGIC_SG_MEM; diff --git a/drivers/media/video/videobuf-vmalloc.c b/drivers/media/video/videobuf-vmalloc.c index d6e6a28..136e093 100644 --- a/drivers/media/video/videobuf-vmalloc.c +++ b/drivers/media/video/videobuf-vmalloc.c @@ -138,6 +138,8 @@ static void *__videobuf_alloc(size_t size) struct videobuf_buffer *vb; vb = kzalloc(size+sizeof(*mem),GFP_KERNEL); + if (!vb) + return vb; mem = vb->priv = ((char *)vb)+size; mem->magic=MAGIC_VMAL_MEM; -- 1.7.0.31.g1df487 -- 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 v1 2/4] v4l: Add support for multi-plane buffers to V4L2 API.
Current V4L2 API assumes that each video buffer contains exactly one,
contiguous memory buffer for video data. Even in case of planar video
formats, e.g. YCbCr with each component residing in a separate area
of memory, it is specified that each of those planes immediately follows
the previous one in memory.
There exist hardware video devices that handle, or even require, each of
the planes to reside in a separate, arbitrary memory area. Some even
require different planes to be placed in different, physical memory banks.
This patch introduces a backward-compatible extension of V4L2 API, which
allows passing additional, per-plane info in the video buffer structure.
Signed-off-by: Pawel Osciak
Reviewed-by: Marek Szyprowski
Reviewed-by: Kyungmin Park
---
drivers/media/video/v4l2-ioctl.c | 97 ++---
include/linux/videodev2.h| 33 -
2 files changed, 99 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..b89b73f 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -172,6 +172,8 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= "mmap",
[V4L2_MEMORY_USERPTR] = "userptr",
[V4L2_MEMORY_OVERLAY] = "overlay",
+ [V4L2_MEMORY_MULTI_USERPTR] = "multi-userptr",
+ [V4L2_MEMORY_MULTI_MMAP]= "multi-mmap",
};
#define prt_names(a, arr) a) >= 0) && ((a) < ARRAY_SIZE(arr))) ? \
@@ -1975,7 +1977,7 @@ static unsigned long cmd_input_size(unsigned int cmd)
switch (cmd) {
CMDINSIZE(ENUM_FMT, fmtdesc,type);
CMDINSIZE(G_FMT,format, type);
- CMDINSIZE(QUERYBUF, buffer, type);
+ CMDINSIZE(QUERYBUF, buffer, length);
CMDINSIZE(G_PARM, streamparm, type);
CMDINSIZE(ENUMSTD, standard, index);
CMDINSIZE(ENUMINPUT,input, index);
@@ -2000,6 +2002,46 @@ static unsigned long cmd_input_size(unsigned int cmd)
}
}
+static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
+ void * __user *user_ptr, void ***kernel_ptr)
+{
+ int ret = 0;
+
+ switch(cmd) {
+ case VIDIOC_QUERYBUF:
+ case VIDIOC_QBUF:
+ case VIDIOC_DQBUF: {
+ struct v4l2_buffer *buf = parg;
+
+ if ((buf->memory == V4L2_MEMORY_MULTI_USERPTR
+|| buf->memory == V4L2_MEMORY_MULTI_MMAP)) {
+ *user_ptr = (void __user *)buf->m.planes;
+ *kernel_ptr = (void **)&buf->m.planes;
+ *array_size = sizeof(struct v4l2_plane) * buf->length;
+ ret = 1;
+ }
+ break;
+ }
+
+ case VIDIOC_S_EXT_CTRLS:
+ case VIDIOC_G_EXT_CTRLS:
+ case VIDIOC_TRY_EXT_CTRLS: {
+ struct v4l2_ext_controls *ctrls = parg;
+
+ if (ctrls->count != 0) {
+ *user_ptr = (void __user *)ctrls->controls;
+ *kernel_ptr = (void **)&ctrls->controls;
+ *array_size = sizeof(struct v4l2_ext_control)
+ * ctrls->count;
+ ret = 1;
+ }
+ break;
+ }
+ }
+
+ return ret;
+}
+
long video_ioctl2(struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -2007,15 +2049,16 @@ long video_ioctl2(struct file *file,
void*mbuf = NULL;
void*parg = NULL;
longerr = -EINVAL;
- int is_ext_ctrl;
- size_t ctrls_size = 0;
+ int has_array_args;
+ size_t array_size = 0;
void __user *user_ptr = NULL;
+ void**kernel_ptr = NULL;
#ifdef __OLD_VIDIOC_
cmd = video_fix_command(cmd);
#endif
- is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS ||
- cmd == VIDIOC_TRY_EXT_CTRLS);
+ /*is_ext_ctrl = (cmd == VIDIOC_S_EXT_CTRLS || cmd == VIDIOC_G_EXT_CTRLS
||
+ cmd == VIDIOC_TRY_EXT_CTRLS);*/
/* Copy arguments into temp kernel buffer */
if (_IOC_DIR(cmd) != _IOC_NONE) {
@@ -2045,43 +2088,39 @@ long video_ioctl2(struct file *file,
}
}
- if (is_ext_ctrl) {
- struct v4l2_ext_controls *p = parg;
+ has_array_args = check_array_args(cmd, parg, &array_size,
+ &user_ptr, &kernel_ptr);
- /* In case of an error, tell the caller that it wasn't
- a specific control that caused it. */
- p->error_idx = p->count;
- user_ptr = (void __user *)p->controls;
- if (p->count)
[EXAMPLE v1] Test application for multiplane vivi driver.
This is an example application for testing muliplane buffer V4L2 extensions
with the vivi driver.
---
--- /dev/null 2010-02-15 07:42:03.265396000 +0100
+++ vivi-mplane.c 2010-02-22 16:58:19.925762651 +0100
@@ -0,0 +1,582 @@
+/*
+ * Pawel Osciak,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define VIDEO_DEV_NAME "/dev/video"
+#define FB_DEV_NAME"/dev/fb0"
+
+#define NUM_DST_BUFS 4
+
+enum io_method {
+ IO_METHOD_MMAP,
+ IO_METHOD_USERPTR,
+};
+
+#define perror_exit(cond, func)\
+ if (cond) {\
+ fprintf(stderr, "%s:%d: ", __func__, __LINE__);\
+ perror(func);\
+ exit(EXIT_FAILURE);\
+ }
+
+#define error_exit(cond, msg, ...)\
+ if (cond) {\
+ fprintf(stderr, "%s:%d: " msg "\n",\
+ __func__, __LINE__, ##__VA_ARGS__);\
+ exit(EXIT_FAILURE);\
+ }
+
+#define perror_ret(cond, func)\
+ if (cond) {\
+ fprintf(stderr, "%s:%d: ", __func__, __LINE__);\
+ perror(func);\
+ return ret;\
+ }
+
+#define memzero(x)\
+ memset(&(x), 0, sizeof (x));
+
+#define error(msg) fprintf(stderr, "%s:%d: " msg "\n", __func__, __LINE__);
+
+#define _DEBUG
+#ifdef _DEBUG
+#define debug(msg, ...)\
+ fprintf(stderr, "%s: " msg, __func__, ##__VA_ARGS__);
+#else
+#define debug(msg, ...)
+#endif
+
+#define PAGE_ALIGN(addr) (((addr) + page_size - 1) & ~(page_size -1))
+
+enum v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+
+enum format {
+ FMT_422,
+ FMT_565,
+ FMT_422P,
+};
+
+struct buffer {
+ char*addr[VIDEO_MAX_PLANES];
+ unsigned long size[VIDEO_MAX_PLANES];
+ unsigned intnum_planes;
+ unsigned intindex;
+ enum format fmt;
+ unsigned intwidth;
+ unsigned intheight;
+ enum v4l2_buf_type type;
+};
+
+static int vid_fd, fb_fd;
+static void *fb_addr, *fb_alloc_ptr;
+static int width = 200, height = 200;
+static off_t fb_line_w, fb_buf_w, fb_size, fb_pix_dist;
+static struct fb_var_screeninfo fbinfo;
+static int vid_node;
+static int framesize;
+static enum format format;
+static int num_planes;
+static long page_size;
+enum io_method io_method;
+enum v4l2_memory memory;
+
+static void set_fmt(enum format format)
+{
+ struct v4l2_format fmt;
+ int ret;
+
+ memzero(fmt);
+ switch (format) {
+ case FMT_422:
+ fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV;
+ fb_buf_w = 2;
+ break;
+ case FMT_565:
+ fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565X;
+ fb_buf_w = 2;
+ break;
+ case FMT_422P:
+ if (2 == num_planes)
+ fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_NV16M;
+ else if (3 == num_planes)
+ fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUV422PM;
+ else
+ error_exit(1, "Invalid format/planes combination\n");
+ fb_buf_w = 1;
+ break;
+ default:
+ error_exit(1, "Invalid params\n");
+ break;
+ }
+
+ debug("Selected fourcc: %d\n", fmt.fmt.pix.pixelformat);
+
+ /* Set format for capture */
+ fmt.type= V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ fmt.fmt.pix.width = width;
+ fmt.fmt.pix.height = height;
+ fmt.fmt.pix.field = V4L2_FIELD_ANY;
+
+ ret = ioctl(vid_fd, VIDIOC_S_FMT, &fmt);
+ perror_exit(ret != 0, "ioctl");
+
+ width = fmt.fmt.pix.width;
+ height = fmt.fmt.pix.height;
+ fb_buf_w *= width;
+ framesize = PAGE_ALIGN(fmt.fmt.pix.sizeimage);
+ debug("Framesize: %d\n", framesize);
+
+ switch (io_method) {
+ case IO_METHOD_MMAP:
+ if (num_planes == 1)
+ memory = V4L2_MEMORY_MMAP;
+ else
+ memory = V4L2_MEMORY_MULTI_MMAP;
+ break;
+ case IO_METHOD_USERPTR:
+ if (num_planes == 1)
+ memory = V4L2_MEMORY_USERPTR;
+ else
+ memory = V4L2_MEMORY_MULTI_USERPTR;
+ break;
+ default:
+ error_exit(1, "Invalid io method\n");
+ }
+}
+
+
+static void verify_caps(void)
+{
+ struct v4l2_capability cap;
+ int ret;
+
+ memzero(cap);
+ ret = ioctl(vid_fd, VIDIOC_QUERYCAP, &cap);
+ perro
Re: adv7180 as SoC camera device
On Monday 22 February 2010 17:01:39 Rodolfo Giometti wrote: > On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: > > On Fri, 19 Feb 2010, Rodolfo Giometti wrote: > > > > > Hello, > > > > > > on my pxa27x based board I have a adv7180 connected with the CIF > > > interface. Due this fact I'm going to use the pxa_camera.c driver > > > which in turn registers a soc_camera_host. > > > > > > In the latest kernel I found your driver for the ADV7180, but it > > > registers the chip as a v4l sub device. > > > > > > I suppose these two interfaces are not compatible, aren't they? > > > > Congratulations! Thereby you're in a position to develop the first > > v4l2-subdev / soc-camera universal driver;) The answer to this your > > question is - they are... kinda. This means - yes, soc-camera is also > > using the v4l2-subdev API, but - with a couple of additions. Basically, > > there are two things you have to change in the adv7180 driver to make it > > compatible with soc-camera - (1) add bus-configuration methods, even if > > they don't do much (see .query_bus_param() and .set_bus_param() methods > > from struct soc_camera_ops), and (2) migrate the driver to the mediabus > > API. The latter one requires some care - in principle, mediabus should be > > the future API to negotiate parameters on the video bus between bridges > > (in your case PXA CIF) and clients, but for you this means you also have > > to migrate any other bridge drivers in the mainline to that API, and, if > > they also interface to some other subdevices - those too, and if those can > > also work with other bridges - those too...;) But, I think, that chain > > will terminate quite soon, in fact, I cannot find any users of that driver > > currently in the mainline, Richard? > > > > > In this situation, should I write a new driver for the > > > soc_camera_device? Which is The-Right-Thing(TM) to do? :) > > > > Please, have a look and try to convert the driver as described above. All > > the APIs and a few examples are in the mainline, so, you should have > > enough copy-paste sources;) Ask on the list (with me on cc) if anything is > > still unclear. > > Thanks for your quick answer! :) > > What I still don't understand is if should I move the driver form > v4l2-subdev to a soc_camera device or trying to support both API... > > It seems to me that the driver is not used by any machines into > mainline so if soc-camera is also using the v4l2-subdev API but with a > couple of additions I suppose I can move it to soc_camera API... The long-term goal is to remove the last soc-camera API dependencies from the sensor subdev drivers. Subdevice (usually i2c) drivers should be fully reusable and a dependency on soc-camera defeats that goal. I think the only missing piece is low-level bus setup (i.e. sync polarities, rising/falling edge sampling, etc.). Some proposals were made, but basically nobody has had the time to actually implement this. Right now, if you want to use your sensor with soc-camera, then you need to support the soc-camera API (or what is left of it) in your subdev driver as well. Regards, Hans > > Is that right? > > Ciao, > > Rodolfo > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v1 3/4] v4l: videobuf: Add support for multi-plane buffers.
Add support for multiplanar buffers to videobuf core, dma-contig
and vmalloc memory types.
Signed-off-by: Pawel Osciak
Reviewed-by: Kyungmin Park
---
drivers/media/video/videobuf-core.c | 363 +++-
drivers/media/video/videobuf-dma-contig.c | 303 ++--
drivers/media/video/videobuf-vmalloc.c| 195 +---
include/media/videobuf-core.h | 59 +++--
include/media/videobuf-dma-contig.h |3 +
include/media/videobuf-vmalloc.h |2 +
6 files changed, 723 insertions(+), 202 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index bb0a1c8..7a5ed69 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -29,6 +29,10 @@
printk(KERN_ERR "magic mismatch: %x (expected %x)\n", is, should); \
BUG(); } } while (0)
+#define is_multiplane(vb)\
+ (vb->memory == V4L2_MEMORY_MULTI_MMAP\
+|| vb->memory == V4L2_MEMORY_MULTI_USERPTR)
+
static int debug;
module_param(debug, int, 0644);
@@ -45,22 +49,24 @@ MODULE_LICENSE("GPL");
#define CALL(q, f, arg...) \
((q->int_ops->f) ? q->int_ops->f(arg) : 0)
-void *videobuf_alloc(struct videobuf_queue *q)
+void *videobuf_alloc(struct videobuf_queue *q, unsigned int num_planes)
{
struct videobuf_buffer *vb;
BUG_ON(q->msize < sizeof(*vb));
+ BUG_ON(0 == num_planes);
if (!q->int_ops || !q->int_ops->alloc) {
printk(KERN_ERR "No specific ops defined!\n");
BUG();
}
- vb = q->int_ops->alloc(q->msize);
+ vb = q->int_ops->alloc(q->msize, num_planes);
if (NULL != vb) {
init_waitqueue_head(&vb->done);
vb->magic = MAGIC_BUFFER;
+ vb->num_planes = num_planes;
}
return vb;
@@ -106,6 +112,17 @@ void *videobuf_queue_to_vmalloc (struct videobuf_queue *q,
}
EXPORT_SYMBOL_GPL(videobuf_queue_to_vmalloc);
+void *videobuf_queue_plane_to_vmalloc(struct videobuf_queue *q,
+ struct videobuf_buffer *buf,
+ unsigned int plane)
+{
+ if (q->int_ops->plane_vmalloc)
+ return q->int_ops->plane_vmalloc(buf, plane);
+ else
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(videobuf_queue_plane_to_vmalloc);
+
/* - */
@@ -131,7 +148,8 @@ void videobuf_queue_core_init(struct videobuf_queue *q,
q->int_ops = int_ops;
/* All buffer operations are mandatory */
- BUG_ON(!q->ops->buf_setup);
+ BUG_ON(!q->ops->buf_negotiate);
+ BUG_ON(!q->ops->buf_setup_plane);
BUG_ON(!q->ops->buf_prepare);
BUG_ON(!q->ops->buf_queue);
BUG_ON(!q->ops->buf_release);
@@ -169,7 +187,7 @@ int videobuf_queue_is_busy(struct videobuf_queue *q)
for (i = 0; i < VIDEO_MAX_FRAME; i++) {
if (NULL == q->bufs[i])
continue;
- if (q->bufs[i]->map) {
+ if (q->bufs[i]->mapped) {
dprintk(1, "busy: buffer #%d mapped\n", i);
return 1;
}
@@ -242,6 +260,8 @@ enum v4l2_field videobuf_next_field(struct videobuf_queue
*q)
static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b,
struct videobuf_buffer *vb, enum v4l2_buf_type type)
{
+ unsigned int i;
+
MAGIC_CHECK(vb->magic, MAGIC_BUFFER);
MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
@@ -251,20 +271,50 @@ static void videobuf_status(struct videobuf_queue *q,
struct v4l2_buffer *b,
b->memory = vb->memory;
switch (b->memory) {
case V4L2_MEMORY_MMAP:
- b->m.offset = vb->boff;
- b->length= vb->bsize;
+ b->m.offset = vb->planes[0].boff;
+ b->length= vb->planes[0].bsize;
break;
case V4L2_MEMORY_USERPTR:
- b->m.userptr = vb->baddr;
- b->length= vb->bsize;
+ b->m.userptr = vb->planes[0].baddr;
+ b->length= vb->planes[0].bsize;
break;
case V4L2_MEMORY_OVERLAY:
- b->m.offset = vb->boff;
+ b->m.offset = vb->planes[0].boff;
+ break;
+ case V4L2_MEMORY_MULTI_MMAP:
+ if (NULL == b->m.planes) {
+ dprintk(1, "Warning: buffer details not copied back "
+ "as no planes array has been provided\n");
+ break;
+ }
+
+ BUG_ON(b->length < vb->num_planes);
+ b->length= vb->num_planes;
+ for (i = 0; i < vb->num_planes; ++i) {
+ b->m.planes[i].m.o
Re: adv7180 as SoC camera device
On Mon, Feb 22, 2010 at 05:11:18PM +0100, Hans Verkuil wrote: > > The long-term goal is to remove the last soc-camera API dependencies from > the sensor subdev drivers. Subdevice (usually i2c) drivers should be fully > reusable and a dependency on soc-camera defeats that goal. > > I think the only missing piece is low-level bus setup (i.e. sync polarities, > rising/falling edge sampling, etc.). Some proposals were made, but basically > nobody has had the time to actually implement this. > > Right now, if you want to use your sensor with soc-camera, then you need to > support the soc-camera API (or what is left of it) in your subdev driver as > well. But with the goal to remove the last soc-camera API dependencies I suppose is better I try to change the pxa_camera driver in something compatible with the API of the adv7180 driver... I'm sorry but I'm a bit confused. :) Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giome...@enneenne.com Linux Device Driver giome...@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it -- 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: adv7180 as SoC camera device
On Mon, 22 Feb 2010, Rodolfo Giometti wrote: > On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: > > On Fri, 19 Feb 2010, Rodolfo Giometti wrote: > > > > > Hello, > > > > > > on my pxa27x based board I have a adv7180 connected with the CIF > > > interface. Due this fact I'm going to use the pxa_camera.c driver > > > which in turn registers a soc_camera_host. > > > > > > In the latest kernel I found your driver for the ADV7180, but it > > > registers the chip as a v4l sub device. > > > > > > I suppose these two interfaces are not compatible, aren't they? > > > > Congratulations! Thereby you're in a position to develop the first > > v4l2-subdev / soc-camera universal driver;) The answer to this your > > question is - they are... kinda. This means - yes, soc-camera is also > > using the v4l2-subdev API, but - with a couple of additions. Basically, > > there are two things you have to change in the adv7180 driver to make it > > compatible with soc-camera - (1) add bus-configuration methods, even if > > they don't do much (see .query_bus_param() and .set_bus_param() methods > > from struct soc_camera_ops), and (2) migrate the driver to the mediabus > > API. The latter one requires some care - in principle, mediabus should be > > the future API to negotiate parameters on the video bus between bridges > > (in your case PXA CIF) and clients, but for you this means you also have > > to migrate any other bridge drivers in the mainline to that API, and, if > > they also interface to some other subdevices - those too, and if those can > > also work with other bridges - those too...;) But, I think, that chain > > will terminate quite soon, in fact, I cannot find any users of that driver > > currently in the mainline, Richard? > > > > > In this situation, should I write a new driver for the > > > soc_camera_device? Which is The-Right-Thing(TM) to do? :) > > > > Please, have a look and try to convert the driver as described above. All > > the APIs and a few examples are in the mainline, so, you should have > > enough copy-paste sources;) Ask on the list (with me on cc) if anything is > > still unclear. > > Thanks for your quick answer! :) > > What I still don't understand is if should I move the driver form > v4l2-subdev to a soc_camera device or trying to support both API... Both. It is just one (v4l2-subdev) API, but soc-camera is using some extensions to it. > It seems to me that the driver is not used by any machines into > mainline That makes your task even easier - you do not have to convert any bridge drivers to mediabus API. > so if soc-camera is also using the v4l2-subdev API but with a > couple of additions I suppose I can move it to soc_camera API... Not move, extend. But preserve an ability to function without soc-camera additions too. I.e., the use of soc-camera extensions should be optional in your driver. Look here http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11493 for an example. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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/3] tm6000: bugfix reading problems with demodulator zl10353
From: Stefan Ringel
repairs reading problems zl10353.
for example:
regs w/o patch with patch
0x06 0x000x7f
0x07 0x330x30
0x08 0x000x00
0x09 0x580x50
0x0f 0x310x28
0x10 0x000x84
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index b39..89297b0 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -54,9 +54,20 @@ int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
char addr, __u8 reg,
int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
{
int rc;
+ u8 b[2];
+ if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr) && (reg %
2 == 0)) {
+ reg -= 1;
+ len += 1;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, b, len);
+
+ *buf = b[1];
+ } else {
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+ }
return rc;
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] tm6000: bugfix i2c addr
From: Stefan Ringel
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 89297b0..b261094 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -125,7 +125,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i++;
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
@@ -140,7 +140,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tm6000: add send and recv function
From: Stefan Ringel
add separately send and receive function
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 48 +-
1 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 656cd19..b39 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
printk(KERN_DEBUG "%s at %s: " fmt, \
dev->name, __FUNCTION__ , ##args); } while (0)
+int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
+}
+
+/* read from a 8bit register */
+int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ int rc;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+
+ return rc;
+}
+
+/* read from a 16bit register
+ * for example xc2028, xc3028 or xc3028L
+ */
+int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr, __u16
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+}
+
static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
@@ -78,13 +104,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i2c_dprintk(2, "; joined to read %s len=%d:",
i == num - 2 ? "stop" : "nonstop",
msgs[i + 1].len);
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
-: REQ_14_SET_GET_I2C_WR2_RDN,
- addr | msgs[i].buf[0] << 8,
- msgs[i].len == 1 ? 0 : msgs[i].buf[1],
+ if (msgs{i].len == 1) {
+ rc = tm6000_i2c_recv_regs(dev, addr,
msgs[i].buf[0],
msgs[i + 1].buf, msgs[i + 1].len);
+ } else {
+ rc = tm6000_i2c_recv_regs(dev, addr,
msgs[i].buf[0] << 8 | msgs[i].buf[1],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ }
+
i++;
if (addr == dev->tuner_addr) {
@@ -99,10 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
if (i2c_debug >= 2)
for (byte = 0; byte < msgs[i].len; byte++)
printk(" %02x", msgs[i].buf[byte]);
- rc = tm6000_read_write_usb(dev,
- USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN,
- addr | msgs[i].buf[0] << 8, 0,
+ rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
if (addr == dev->tuner_addr) {
@@ -134,9 +158,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
bytes[16] = '\0';
for (i = 0; i < len; ) {
*p = i;
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, 0xa0 | i<<8, 0, p, 1);
+ rc = tm6000_i2c_revc_regs(dev, 0xa0, i, p, 1);
if (rc < 1) {
if (p == eedata)
goto noeeprom;
--
1.6.6.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: linux-next: Tree for February 22 (media/video/tvp7002)
On 02/21/10 22:22, Stephen Rothwell wrote: > Hi all, > > Changes since 20100219: drivers/media/video/tvp7002.c:896: error: 'struct tvp7002' has no member named 'registers' -- ~Randy -- 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: adv7180 as SoC camera device
On Mon, 22 Feb 2010, Rodolfo Giometti wrote: > On Mon, Feb 22, 2010 at 05:11:18PM +0100, Hans Verkuil wrote: > > > > The long-term goal is to remove the last soc-camera API dependencies from > > the sensor subdev drivers. Subdevice (usually i2c) drivers should be fully > > reusable and a dependency on soc-camera defeats that goal. > > > > I think the only missing piece is low-level bus setup (i.e. sync polarities, > > rising/falling edge sampling, etc.). Some proposals were made, but basically > > nobody has had the time to actually implement this. > > > > Right now, if you want to use your sensor with soc-camera, then you need to > > support the soc-camera API (or what is left of it) in your subdev driver as > > well. > > But with the goal to remove the last soc-camera API dependencies I > suppose is better I try to change the pxa_camera driver in something > compatible with the API of the adv7180 driver... No. As Hans said, one of important things, that is present in soc-camera, but absent from v4l2-subdev is bus-parameter configuration. So, to remove those dependencies one would have to develop a generic bus-configuration API for V4L2, and then convert soc-camera core and all soc-camera drivers to it. Feel free to submit patches. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck
Mauro, Please pull change: http://udev.netup.ru/hg/v4l-dvb-aospan-tscheck/rev/0fdeb662c7f6 "Allow to enable TS continuity and TEI check on loaded module". Current dvb_demux_tscheck processing doesn't allow to enable check on loaded module. dvb_demux_tscheck can be enabled only when loading module ( dvb_dmx_init should be called to enable dvb_demux_tscheck ). This patch fix this issue. Thanks. -- Abylai Ospan NetUP Inc. signature.asc Description: This is a digitally signed message part
Re: adv7180 as SoC camera device
On 02/22/10 16:16, Guennadi Liakhovetski wrote: > On Mon, 22 Feb 2010, Rodolfo Giometti wrote: > >> On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: >>> On Fri, 19 Feb 2010, Rodolfo Giometti wrote: >>> Hello, on my pxa27x based board I have a adv7180 connected with the CIF interface. Due this fact I'm going to use the pxa_camera.c driver which in turn registers a soc_camera_host. In the latest kernel I found your driver for the ADV7180, but it registers the chip as a v4l sub device. I suppose these two interfaces are not compatible, aren't they? >>> >>> Congratulations! Thereby you're in a position to develop the first >>> v4l2-subdev / soc-camera universal driver;) The answer to this your >>> question is - they are... kinda. This means - yes, soc-camera is also >>> using the v4l2-subdev API, but - with a couple of additions. Basically, >>> there are two things you have to change in the adv7180 driver to make it >>> compatible with soc-camera - (1) add bus-configuration methods, even if >>> they don't do much (see .query_bus_param() and .set_bus_param() methods >>> from struct soc_camera_ops), and (2) migrate the driver to the mediabus >>> API. The latter one requires some care - in principle, mediabus should be >>> the future API to negotiate parameters on the video bus between bridges >>> (in your case PXA CIF) and clients, but for you this means you also have >>> to migrate any other bridge drivers in the mainline to that API, and, if >>> they also interface to some other subdevices - those too, and if those can >>> also work with other bridges - those too...;) But, I think, that chain >>> will terminate quite soon, in fact, I cannot find any users of that driver >>> currently in the mainline, Richard? >>> In this situation, should I write a new driver for the soc_camera_device? Which is The-Right-Thing(TM) to do? :) >>> >>> Please, have a look and try to convert the driver as described above. All >>> the APIs and a few examples are in the mainline, so, you should have >>> enough copy-paste sources;) Ask on the list (with me on cc) if anything is >>> still unclear. >> >> Thanks for your quick answer! :) >> >> What I still don't understand is if should I move the driver form >> v4l2-subdev to a soc_camera device or trying to support both API... > > Both. It is just one (v4l2-subdev) API, but soc-camera is using some > extensions to it. > >> It seems to me that the driver is not used by any machines into >> mainline > > That makes your task even easier - you do not have to convert any bridge > drivers to mediabus API. Indeed. Having time to do that is what is delaying the ov7670 conversion. (that and having time in general!) For info I did post some untested patches for the ov7670 a while back that show the minimal changes I think are needed under these circumstances. > >> so if soc-camera is also using the v4l2-subdev API but with a >> couple of additions I suppose I can move it to soc_camera API... > > Not move, extend. But preserve an ability to function without soc-camera > additions too. I.e., the use of soc-camera extensions should be optional > in your driver. Look here > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11493 > > for an example. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- > 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: [PATCH 1/3] tm6000: add send and recv function
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
>
> add separately send and receive function
Still broken:
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_xfer’:
drivers/staging/tm6000/tm6000-i2c.c:107: error: expected ‘)’ before ‘{’ token
drivers/staging/tm6000/tm6000-i2c.c: In function ‘tm6000_i2c_eeprom’:
drivers/staging/tm6000/tm6000-i2c.c:161: error: implicit declaration of
function ‘tm6000_i2c_revc_regs’
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/staging/tm6000/tm6000-i2c.c | 48 +-
> 1 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/tm6000/tm6000-i2c.c
> b/drivers/staging/tm6000/tm6000-i2c.c
> index 656cd19..b39 100644
> --- a/drivers/staging/tm6000/tm6000-i2c.c
> +++ b/drivers/staging/tm6000/tm6000-i2c.c
> @@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
> printk(KERN_DEBUG "%s at %s: " fmt, \
> dev->name, __FUNCTION__ , ##args); } while (0)
>
> +int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
> reg, char *buf, int len)
> +{
> + return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> + REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
> +}
> +
> +/* read from a 8bit register */
> +int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
> reg, char *buf, int len)
> +{
> + int rc;
> +
> + rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> + REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
> len);
> +
> + return rc;
> +}
> +
> +/* read from a 16bit register
> + * for example xc2028, xc3028 or xc3028L
> + */
> +int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr,
> __u16 reg, char *buf, int len)
> +{
> + return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> + REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
> +}
> +
> static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> struct i2c_msg msgs[], int num)
> {
> @@ -78,13 +104,14 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> i2c_dprintk(2, "; joined to read %s len=%d:",
> i == num - 2 ? "stop" : "nonstop",
> msgs[i + 1].len);
> - rc = tm6000_read_write_usb (dev,
> - USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> - msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
> - : REQ_14_SET_GET_I2C_WR2_RDN,
> - addr | msgs[i].buf[0] << 8,
> - msgs[i].len == 1 ? 0 : msgs[i].buf[1],
> + if (msgs{i].len == 1) {
> + rc = tm6000_i2c_recv_regs(dev, addr,
> msgs[i].buf[0],
> msgs[i + 1].buf, msgs[i + 1].len);
> + } else {
> + rc = tm6000_i2c_recv_regs(dev, addr,
> msgs[i].buf[0] << 8 | msgs[i].buf[1],
> + msgs[i + 1].buf, msgs[i + 1].len);
> + }
> +
> i++;
>
> if (addr == dev->tuner_addr) {
> @@ -99,10 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
> if (i2c_debug >= 2)
> for (byte = 0; byte < msgs[i].len; byte++)
> printk(" %02x", msgs[i].buf[byte]);
> - rc = tm6000_read_write_usb(dev,
> - USB_DIR_OUT | USB_TYPE_VENDOR |
> USB_RECIP_DEVICE,
> - REQ_16_SET_GET_I2C_WR1_RDN,
> - addr | msgs[i].buf[0] << 8, 0,
> + rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
> msgs[i].buf + 1, msgs[i].len - 1);
>
> if (addr == dev->tuner_addr) {
> @@ -134,9 +158,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
> bytes[16] = '\0';
> for (i = 0; i < len; ) {
> *p = i;
> - rc = tm6000_read_write_usb (dev,
> - USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> - REQ_16_SET_GET_I2C_WR1_RDN, 0xa0 | i<<8, 0, p, 1);
> + rc = tm6000_i2c_revc_regs(dev, 0xa0, i, p, 1);
> if (rc < 1) {
> if (p == eedata)
> goto noeeprom;
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/6] V4L: File handles
Hi Sakari, From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com] ... > Will fix. Seems that you missed to fix this patch comments on your v6 version... :-/ Regards, Sergio > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.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
[PATCH 3/3] tm6000: bugfix i2c addr
From: Stefan Ringel
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 0da40ec..8ae988d 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -126,7 +126,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i++;
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
@@ -141,7 +141,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
- if (addr == dev->tuner_addr) {
+ if (addr == dev->tuner_addr << 1) {
tm6000_set_reg(dev, 0x32, 0,0);
tm6000_set_reg(dev, 0x33, 0,0);
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] tm6000: bugfix reading problems with demodulator zl10353
From: Stefan Ringel
repairs reading problems zl10353.
for example:
regs w/o patch with patch
0x06 0x000x7f
0x07 0x330x30
0x08 0x000x00
0x09 0x580x50
0x0f 0x310x28
0x10 0x000x84
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 2de92f3..0da40ec 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -54,9 +54,20 @@ int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
char addr, __u8 reg,
int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
{
int rc;
+ u8 b[2];
+ if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr) && (reg %
2 == 0)) {
+ reg -= 1;
+ len += 1;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, b, len);
+
+ *buf = b[1];
+ } else {
rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+ }
return rc;
}
--
1.6.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tm6000: add send and recv function
From: Stefan Ringel
add separately send and receive function
Signed-off-by: Stefan Ringel
---
drivers/staging/tm6000/tm6000-i2c.c | 51 +-
1 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 656cd19..2de92f3 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -44,6 +44,32 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
printk(KERN_DEBUG "%s at %s: " fmt, \
dev->name, __FUNCTION__ , ##args); } while (0)
+int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
+}
+
+/* read from a 8bit register */
+int tm6000_i2c_recv_regs(struct tm6000_core *dev, unsigned char addr, __u8
reg, char *buf, int len)
+{
+ int rc;
+
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+
+ return rc;
+}
+
+/* read from a 16bit register
+ * for example xc2028, xc3028 or xc3028L
+ */
+int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr, __u16
reg, char *buf, int len)
+{
+ return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
+ REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+}
+
static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[], int num)
{
@@ -78,13 +104,15 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
i2c_dprintk(2, "; joined to read %s len=%d:",
i == num - 2 ? "stop" : "nonstop",
msgs[i + 1].len);
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- msgs[i].len == 1 ? REQ_16_SET_GET_I2C_WR1_RDN
-: REQ_14_SET_GET_I2C_WR2_RDN,
- addr | msgs[i].buf[0] << 8,
- msgs[i].len == 1 ? 0 : msgs[i].buf[1],
- msgs[i + 1].buf, msgs[i + 1].len);
+
+ if (msgs[i].len == 1) {
+ rc = tm6000_i2c_recv_regs(dev, addr,
msgs[i].buf[0],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ } else {
+ rc = tm6000_i2c_recv_regs16(dev, addr,
msgs[i].buf[0] << 8 | msgs[i].buf[1],
+ msgs[i + 1].buf, msgs[i + 1].len);
+ }
+
i++;
if (addr == dev->tuner_addr) {
@@ -99,10 +127,7 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
if (i2c_debug >= 2)
for (byte = 0; byte < msgs[i].len; byte++)
printk(" %02x", msgs[i].buf[byte]);
- rc = tm6000_read_write_usb(dev,
- USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN,
- addr | msgs[i].buf[0] << 8, 0,
+ rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
msgs[i].buf + 1, msgs[i].len - 1);
if (addr == dev->tuner_addr) {
@@ -134,9 +159,7 @@ static int tm6000_i2c_eeprom(struct tm6000_core *dev,
bytes[16] = '\0';
for (i = 0; i < len; ) {
*p = i;
- rc = tm6000_read_write_usb (dev,
- USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, 0xa0 | i<<8, 0, p, 1);
+ rc = tm6000_i2c_recv_regs(dev, 0xa0, i, p, 1);
if (rc < 1) {
if (p == eedata)
goto noeeprom;
--
1.6.6.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: [PATCH v5 1/6] V4L: File handles
Aguirre, Sergio wrote: > Hi Sakari, > > From: Sakari Ailus [mailto:sakari.ai...@maxwell.research.nokia.com] > > ... > >> Will fix. > > Seems that you missed to fix this patch comments on your v6 version... > > :-/ Um, true! I'll make the changes for the next one then. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 v1 1/4] v4l: add missing checks for kzalloc returning NULL.
Pawel Osciak wrote: > Signed-off-by: Pawel Osciak This one is not dependent on the RFC, and fixes a bug, so I'm applying it. Thanks for catching it! Cheers, Mauro. > --- > drivers/media/video/videobuf-dma-sg.c |2 ++ > drivers/media/video/videobuf-vmalloc.c |2 ++ > 2 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/videobuf-dma-sg.c > b/drivers/media/video/videobuf-dma-sg.c > index fa78555..fcd045e 100644 > --- a/drivers/media/video/videobuf-dma-sg.c > +++ b/drivers/media/video/videobuf-dma-sg.c > @@ -418,6 +418,8 @@ static void *__videobuf_alloc(size_t size) > struct videobuf_buffer *vb; > > vb = kzalloc(size+sizeof(*mem),GFP_KERNEL); > + if (!vb) > + return vb; > > mem = vb->priv = ((char *)vb)+size; > mem->magic=MAGIC_SG_MEM; > diff --git a/drivers/media/video/videobuf-vmalloc.c > b/drivers/media/video/videobuf-vmalloc.c > index d6e6a28..136e093 100644 > --- a/drivers/media/video/videobuf-vmalloc.c > +++ b/drivers/media/video/videobuf-vmalloc.c > @@ -138,6 +138,8 @@ static void *__videobuf_alloc(size_t size) > struct videobuf_buffer *vb; > > vb = kzalloc(size+sizeof(*mem),GFP_KERNEL); > + if (!vb) > + return vb; > > mem = vb->priv = ((char *)vb)+size; > mem->magic=MAGIC_VMAL_MEM; -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/4] Multi-plane video buffer support for V4L2 API and videobuf
Pawel Osciak wrote: > Hello, > > This is a preliminary implementation of multi-planar buffer support for V4L2 > and videobuf. > > It is a rather big change so I wanted to put it up for discussion sooner > rather > than later, in case we decide to go in a completely different direction. > > We are proposing backward compatible extensions to the V4L2 API This seems to be the better way. Of course, tests are needed to be sure that no regression will be introduced by it. > and a redesign > of memory handling in videobuf core and its memory type modules. The videobuf > redesign should have a minimal impact on current drivers though. No videobuf > high-level logic (queuing, etc.) has been changed. Seems reasonable. > Only streaming I/O has been tested, read/write might not work correctly. > vivi has been adapted for testing and demonstration purposes, but other > drivers > will not compile. Tests have been made on vivi and on an another driver for an > embedded device (those involved dma-contig and USERPTR as well). I am not > attaching that driver, as I expect nobody would be able to compile/test it > anyway. It would be interesting if you could add userptr support for videobuf-vmalloc, and test all supported modes with vivi. This helps to test the changes against existing userspace applications before needing to touch on all drivers. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Feb 22 19:01:07 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14233:2e0444bf93a4 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-rc5-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.17-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (v4l-dvb-git): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.7-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: [GIT FIXES FOR 2.6.34] uvcvideo updates
Laurent Pinchart wrote: > Hi Mauro, > > The following changes since commit 8e17df0d68f260e9e722b5f3adfa18f553542f93: > Randy Dunlap (1): > V4L/DVB: dvb: fix sparse warnings > > are available in the git repository at: > > git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo > > Laurent Pinchart (7): > uvcvideo: Increase the streaming control timeout to 5 seconds > uvcvideo: Use %pUl printk format specifier to print GUIDs > uvcvideo: Return -ERANGE when setting a control to an out-of-range menu > index > uvcvideo: Cache control min, max, res and def query results # ERROR: spaces prohibited around that ':' (ctx:WxW) # #213: FILE: drivers/media/video/uvc/uvcvideo.h:248: # + modified : 1, # ^ # # ERROR: spaces prohibited around that ':' (ctx:WxW) # #214: FILE: drivers/media/video/uvc/uvcvideo.h:249: # + cached : 1; # ^ # # total: 2 errors, 0 warnings, 190 lines checked As the other bitmask flags are also with spaces, I'll apply. Please fix them later. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] V4L: Events: Add documentation
Some small corrections: On Monday 22 February 2010 16:51:37 Sakari Ailus wrote: > Add documentation on how to use V4L2 events, both for V4L2 drivers and for > V4L2 applications. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media-entities.tmpl |9 ++ > Documentation/DocBook/v4l/dev-event.xml| 34 ++ > Documentation/DocBook/v4l/v4l2.xml |3 + > Documentation/DocBook/v4l/vidioc-dqevent.xml | 124 > > .../DocBook/v4l/vidioc-subscribe-event.xml | 103 > Documentation/video4linux/v4l2-framework.txt | 58 + > 6 files changed, 331 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/v4l/dev-event.xml > create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml > create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml > > diff --git a/Documentation/DocBook/media-entities.tmpl > b/Documentation/DocBook/media-entities.tmpl > index c725cb8..770be3c 100644 > --- a/Documentation/DocBook/media-entities.tmpl > +++ b/Documentation/DocBook/media-entities.tmpl > @@ -17,6 +17,7 @@ > linkend='vidioc-dbg-g-register'>VIDIOC_DBG_G_REGISTER"> > linkend='vidioc-dbg-g-register'>VIDIOC_DBG_S_REGISTER"> > linkend='vidioc-qbuf'>VIDIOC_DQBUF"> > + linkend='vidioc-dqevent'>VIDIOC_DQEVENT"> > linkend='vidioc-encoder-cmd'>VIDIOC_ENCODER_CMD"> > linkend='vidioc-enumaudio'>VIDIOC_ENUMAUDIO"> > linkend='vidioc-enumaudioout'>VIDIOC_ENUMAUDOUT"> > @@ -60,6 +61,7 @@ > linkend='vidioc-reqbufs'>VIDIOC_REQBUFS"> > linkend='vidioc-streamon'>VIDIOC_STREAMOFF"> > linkend='vidioc-streamon'>VIDIOC_STREAMON"> > + linkend='vidioc-subscribe-event'>VIDIOC_SUBSCRIBE_EVENT"> > linkend='vidioc-g-audio'>VIDIOC_S_AUDIO"> > linkend='vidioc-g-audioout'>VIDIOC_S_AUDOUT"> > linkend='vidioc-g-crop'>VIDIOC_S_CROP"> > @@ -141,6 +143,8 @@ > linkend='v4l2-enc-idx'>v4l2_enc_idx"> > linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry"> > linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd"> > + linkend='v4l2-event'>v4l2_event"> > + linkend='v4l2-event-subscription'>v4l2_event_subscription"> > linkend='v4l2-ext-control'>v4l2_ext_control"> > linkend='v4l2-ext-controls'>v4l2_ext_controls"> > linkend='v4l2-fmtdesc'>v4l2_fmtdesc"> > @@ -200,6 +204,7 @@ > > > > + > > > > @@ -292,6 +297,8 @@ > > > > + > + > > > > @@ -381,3 +388,5 @@ > > > > + > + > diff --git a/Documentation/DocBook/v4l/dev-event.xml > b/Documentation/DocBook/v4l/dev-event.xml > new file mode 100644 > index 000..70a9895 > --- /dev/null > +++ b/Documentation/DocBook/v4l/dev-event.xml > @@ -0,0 +1,34 @@ > + Event Interface > + > + The V4L2 event interface provides means for user to get > + immediately notified on certain conditions taking place on a device. > + This might include start of frame or loss of signal events, for > + example. > + > + > + To receive events, the events the user is interested first > + must be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an > + event is subscribed, the events of subscribed types are dequeueable > + using the &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using > + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type > + V4L2_EVENT_ALL may be used to subscribe or unsubscribe all the ALL may be used only with unsubscribe. > + events the driver supports. > + > + The event subscriptions and event queues are specific to file > + handles. Subscribing an event on one file handle does not affect > + other file handles. > + > + > + The information on dequeueable events are obtained by using > + select or poll system calls on video devices. The V4L2 events use > + POLLPRI events on poll system call and exceptions on select system > + call. > + > + > + > diff --git a/Documentation/DocBook/v4l/v4l2.xml > b/Documentation/DocBook/v4l/v4l2.xml > index 060105a..9737243 100644 > --- a/Documentation/DocBook/v4l/v4l2.xml > +++ b/Documentation/DocBook/v4l/v4l2.xml > @@ -401,6 +401,7 @@ and discussions on the V4L mailing list. > &sub-dev-teletext; > &sub-dev-radio; > &sub-dev-rds; > + &sub-dev-event; > > > > @@ -426,6 +427,7 @@ and discussions on the V4L mailing list. > &sub-cropcap; > &sub-dbg-g-chip-ident; > &sub-dbg-g-register; > +&sub-dqevent; > &sub-encoder-cmd; > &sub-enumaudio; > &sub-enumaudioout; > @@ -467,6 +469,7 @@ and discussions on the V4L mailing list. > &sub-reqbufs; > &sub-s-hw-freq-seek; > &sub-streamon; > +&sub-subscribe-event; > > &sub-mmap; > &sub-munmap; > diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml > b/Documentation/DocBook/v4l/vidioc-dqevent.xml > new file mode 100644 > index 000..eb45c16 > --- /dev/null > +++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml > @@ -0,0 +1,124 @@ > + > + > +ioctl VIDIOC_DQEVENT > +&manvol; > + > + > + > +VIDIOC
Re: [PATCH 1/6] V4L: File handles
Looks good.
Reviewed-by: Hans Verkuil
On Monday 22 February 2010 16:51:32 Sakari Ailus wrote:
> This patch adds a list of v4l2_fh structures to every video_device.
> It allows using file handle related information in V4L2. The event interface
> is one example of such use.
>
> Video device drivers should use the v4l2_fh pointer as their
> file->private_data.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/Makefile |2 +-
> drivers/media/video/v4l2-dev.c |4 ++
> drivers/media/video/v4l2-fh.c | 64
>
> include/media/v4l2-dev.h |5 +++
> include/media/v4l2-fh.h| 42 ++
> 5 files changed, 116 insertions(+), 1 deletions(-)
> create mode 100644 drivers/media/video/v4l2-fh.c
> create mode 100644 include/media/v4l2-fh.h
>
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 5163289..14bf69a 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -10,7 +10,7 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o
>
> omap2cam-objs:= omap24xxcam.o omap24xxcam-dma.o
>
> -videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o
> +videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
>
> # V4L2 core modules
>
> diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
> index 7090699..65a7b30 100644
> --- a/drivers/media/video/v4l2-dev.c
> +++ b/drivers/media/video/v4l2-dev.c
> @@ -421,6 +421,10 @@ static int __video_register_device(struct video_device
> *vdev, int type, int nr,
> if (!vdev->release)
> return -EINVAL;
>
> + /* v4l2_fh support */
> + spin_lock_init(&vdev->fh_lock);
> + INIT_LIST_HEAD(&vdev->fh_list);
> +
> /* Part 1: check device type */
> switch (type) {
> case VFL_TYPE_GRABBER:
> diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
> new file mode 100644
> index 000..c707930
> --- /dev/null
> +++ b/drivers/media/video/v4l2-fh.c
> @@ -0,0 +1,64 @@
> +/*
> + * drivers/media/video/v4l2-fh.c
> + *
> + * V4L2 file handles.
> + *
> + * Copyright (C) 2009 Nokia Corporation.
> + *
> + * Contact: Sakari Ailus
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +
> +void v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
> +{
> + fh->vdev = vdev;
> + INIT_LIST_HEAD(&fh->list);
> + set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fh_init);
> +
> +void v4l2_fh_add(struct v4l2_fh *fh)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> + list_add(&fh->list, &fh->vdev->fh_list);
> + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fh_add);
> +
> +void v4l2_fh_del(struct v4l2_fh *fh)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> + list_del_init(&fh->list);
> + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fh_del);
> +
> +void v4l2_fh_exit(struct v4l2_fh *fh)
> +{
> + if (fh->vdev == NULL)
> + return;
> +
> + fh->vdev = NULL;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fh_exit);
> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
> index 2dee938..bebe44b 100644
> --- a/include/media/v4l2-dev.h
> +++ b/include/media/v4l2-dev.h
> @@ -32,6 +32,7 @@ struct v4l2_device;
> Drivers can clear this flag if they want to block all future
> device access. It is cleared by video_unregister_device. */
> #define V4L2_FL_REGISTERED (0)
> +#define V4L2_FL_USES_V4L2_FH (1)
>
> struct v4l2_file_operations {
> struct module *owner;
> @@ -77,6 +78,10 @@ struct video_device
> /* attribute to differentiate multiple indices on one physical device */
> int index;
>
> + /* V4L2 file handles */
> + spinlock_t fh_lock; /* Lock for all v4l2_fhs */
> + struct list_headfh_list; /* List of struct v4l2_fh */
> +
> int debug; /* Activates debug level*/
>
> /* Video standard vars */
> diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
> new file mode 100644
> index 000..6b486aa
Re: [PATCH 2/6] V4L: File handles: Add documentation
Reviewed-by: Hans Verkuil On Monday 22 February 2010 16:51:33 Sakari Ailus wrote: > Add documentation on using V4L2 file handles (v4l2_fh) in V4L2 drivers. > > Signed-off-by: Sakari Ailus > --- > Documentation/video4linux/v4l2-framework.txt | 37 > ++ > 1 files changed, 37 insertions(+), 0 deletions(-) > > diff --git a/Documentation/video4linux/v4l2-framework.txt > b/Documentation/video4linux/v4l2-framework.txt > index 74d677c..bfaf0c5 100644 > --- a/Documentation/video4linux/v4l2-framework.txt > +++ b/Documentation/video4linux/v4l2-framework.txt > @@ -695,3 +695,40 @@ The better way to understand it is to take a look at > vivi driver. One > of the main reasons for vivi is to be a videobuf usage example. the > vivi_thread_tick() does the task that the IRQ callback would do on PCI > drivers (or the irq callback on USB). > + > +struct v4l2_fh > +-- > + > +struct v4l2_fh provides a way to easily keep file handle specific data > +that is used by the V4L2 framework. > + > +struct v4l2_fh is allocated as a part of the driver's own file handle > +structure and is set to file->private_data in the driver's open > +function by the driver. Drivers can extract their own file handle > +structure by using the container_of macro. > + > +Useful functions: > + > +- v4l2_fh_init() > + > + Initialise the file handle. This *MUST* be performed in the driver's > + v4l2_file_operations->open() handler. > + > +- v4l2_fh_add() > + > + Add a v4l2_fh to video_device file handle list. May be called after > + initialising the file handle. > + > +- v4l2_fh_del() > + > + Unassociate the file handle from video_device(). The file handle > + exit function may now be called. > + > +- v4l2_fh_exit() > + > + Uninitialise the file handle. After uninitialisation the v4l2_fh > + memory can be freed. > + > +The users of v4l2_fh know whether a driver uses v4l2_fh as its > +file->private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in > +video_device->flags. > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] V4L: Events: Add backend
Reviewed-by: Hans Verkuil
On Monday 22 February 2010 16:51:35 Sakari Ailus wrote:
> Add event handling backend to V4L2. The backend handles event subscription
> and delivery to file handles. Event subscriptions are based on file handle.
> Events may be delivered to all subscribed file handles on a device
> independent of where they originate from.
>
> Signed-off-by: Sakari Ailus
>
>
> Header from folded patch 'event-dq-block':
>
> V4L: Events: Blocking dqevent
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/Makefile |3 +-
> drivers/media/video/v4l2-event.c | 294
> ++
> drivers/media/video/v4l2-fh.c|5 +
> include/media/v4l2-event.h | 67 +
> include/media/v4l2-fh.h |2 +
> 5 files changed, 370 insertions(+), 1 deletions(-)
> create mode 100644 drivers/media/video/v4l2-event.c
> create mode 100644 include/media/v4l2-event.h
>
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 14bf69a..b84abfe 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -10,7 +10,8 @@ stkwebcam-objs := stk-webcam.o stk-sensor.o
>
> omap2cam-objs:= omap24xxcam.o omap24xxcam-dma.o
>
> -videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
> +videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
> \
> + v4l2-event.o
>
> # V4L2 core modules
>
> diff --git a/drivers/media/video/v4l2-event.c
> b/drivers/media/video/v4l2-event.c
> new file mode 100644
> index 000..d65df06
> --- /dev/null
> +++ b/drivers/media/video/v4l2-event.c
> @@ -0,0 +1,294 @@
> +/*
> + * drivers/media/video/v4l2-event.c
> + *
> + * V4L2 events.
> + *
> + * Copyright (C) 2009 Nokia Corporation.
> + *
> + * Contact: Sakari Ailus
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +int v4l2_event_init(struct v4l2_fh *fh)
> +{
> + if (fh->events != NULL) {
> + WARN_ON(1);
> + return 0;
> + }
> +
> + fh->events = kzalloc(sizeof(*fh->events), GFP_KERNEL);
> + if (fh->events == NULL)
> + return -ENOMEM;
> +
> + init_waitqueue_head(&fh->events->wait);
> +
> + INIT_LIST_HEAD(&fh->events->free);
> + INIT_LIST_HEAD(&fh->events->available);
> + INIT_LIST_HEAD(&fh->events->subscribed);
> +
> + fh->events->sequence = -1;
> +
> + return 0;
> +}
> +
> +int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
> +{
> + struct v4l2_events *events = fh->events;
> + unsigned long flags;
> +
> + if (!events) {
> + WARN_ON(1);
> + return -ENOMEM;
> + }
> +
> + while (events->nallocated < n) {
> + struct v4l2_kevent *kev;
> +
> + kev = kzalloc(sizeof(*kev), GFP_KERNEL);
> + if (kev == NULL)
> + return -ENOMEM;
> +
> + spin_lock_irqsave(&fh->vdev->fh_lock, flags);
> + list_add_tail(&kev->list, &events->free);
> + events->nallocated++;
> + spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_event_alloc);
> +
> +#define list_kfree(list, type, member) \
> + while (!list_empty(list)) { \
> + type *hi; \
> + hi = list_first_entry(list, type, member); \
> + list_del(&hi->member); \
> + kfree(hi); \
> + }
> +
> +void v4l2_event_free(struct v4l2_fh *fh)
> +{
> + struct v4l2_events *events = fh->events;
> +
> + if (!events)
> + return;
> +
> + list_kfree(&events->free, struct v4l2_kevent, list);
> + list_kfree(&events->available, struct v4l2_kevent, list);
> + list_kfree(&events->subscribed, struct v4l2_subscribed_event, list);
> +
> + kfree(events);
> + fh->events = NULL;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_event_free);
> +
> +static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
> +{
> + struct v4l2_events *events = fh->events;
> + struct v4l2_kevent *kev;
> +
Re: [PATCH 3/6] V4L: Events: Add new ioctls for events
Reviewed-by: Hans Verkuil
On Monday 22 February 2010 16:51:34 Sakari Ailus wrote:
> This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
> V4L2 Events RFC version 2.3:
>
> http://www.spinics.net/lists/linux-media/msg12033.html>
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/v4l2-compat-ioctl32.c |3 +++
> drivers/media/video/v4l2-ioctl.c |3 +++
> include/linux/videodev2.h | 26 ++
> 3 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c
> index f77f84b..9004a5f 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -1086,6 +1086,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
> int cmd, unsigned long arg)
> case VIDIOC_QUERY_DV_PRESET:
> case VIDIOC_S_DV_TIMINGS:
> case VIDIOC_G_DV_TIMINGS:
> + case VIDIOC_DQEVENT:
> + case VIDIOC_SUBSCRIBE_EVENT:
> + case VIDIOC_UNSUBSCRIBE_EVENT:
> ret = do_video_ioctl(file, cmd, arg);
> break;
>
> diff --git a/drivers/media/video/v4l2-ioctl.c
> b/drivers/media/video/v4l2-ioctl.c
> index 4b11257..34c7d6e 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -290,6 +290,9 @@ static const char *v4l2_ioctls[] = {
> [_IOC_NR(VIDIOC_QUERY_DV_PRESET)] = "VIDIOC_QUERY_DV_PRESET",
> [_IOC_NR(VIDIOC_S_DV_TIMINGS)] = "VIDIOC_S_DV_TIMINGS",
> [_IOC_NR(VIDIOC_G_DV_TIMINGS)] = "VIDIOC_G_DV_TIMINGS",
> + [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
> + [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
> + [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
> };
> #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 3c26560..f7237fc 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -1622,6 +1622,29 @@ struct v4l2_streamparm {
> };
>
> /*
> + * E V E N T S
> + */
> +
> +struct v4l2_event {
> + __u32 type;
> + union {
> + __u8data[64];
> + } u;
> + __u32 pending;
> + __u32 sequence;
> + struct timespec timestamp;
> + __u32 reserved[9];
> +};
> +
> +struct v4l2_event_subscription {
> + __u32 type;
> + __u32 reserved[7];
> +};
> +
> +#define V4L2_EVENT_ALL 0
> +#define V4L2_EVENT_PRIVATE_START 0x0800
> +
> +/*
> * A D V A N C E D D E B U G G I N G
> *
> * NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
> @@ -1743,6 +1766,9 @@ struct v4l2_dbg_chip_ident {
> #define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset)
> #define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
> #define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
> +#define VIDIOC_DQEVENT _IOR('V', 83, struct v4l2_event)
> +#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 84, struct
> v4l2_event_subscription)
> +#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 85, struct
> v4l2_event_subscription)
>
> /* Reminder: when adding new ioctls please add support for them to
> drivers/media/video/v4l2-compat-ioctl32.c as well! */
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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 5/6] V4L: Events: Support event handling in do_ioctl
Just one tiny comment: On Monday 22 February 2010 16:51:36 Sakari Ailus wrote: > Add support for event handling to do_ioctl. > > Signed-off-by: Sakari Ailus > --- > drivers/media/video/v4l2-fh.c|5 +++- > drivers/media/video/v4l2-ioctl.c | 50 > ++ > include/media/v4l2-ioctl.h |7 + > 3 files changed, 61 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c > index 713f5a0..2986a2c 100644 > --- a/drivers/media/video/v4l2-fh.c > +++ b/drivers/media/video/v4l2-fh.c > @@ -33,7 +33,10 @@ void v4l2_fh_init(struct v4l2_fh *fh, struct video_device > *vdev) > fh->vdev = vdev; > INIT_LIST_HEAD(&fh->list); > set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags); > - v4l2_event_init(fh); I recommend adding a small comment here along the lines of: /* fh->events only needs to be initialized if the driver supports the VIDIOC_SUBSCRIBE_EVENT ioctl. */ > + if (vdev->ioctl_ops && vdev->ioctl_ops->vidioc_subscribe_event) > + v4l2_event_init(fh); > + else > + fh->events = NULL; > } > EXPORT_SYMBOL_GPL(v4l2_fh_init); > Other than that: Reviewed-by: Hans Verkuil -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] Updated videobuf documentation
On Thu, 18 Feb 2010 14:59:30 -0800 Randy Dunlap wrote: > > +A buffer's state should be set to VIDEOBUF_ACTIVE before being > > What does the do in a plain text file? It verifies that somebody was paying attention :) Obviously, that's a bit of markup which slipped through. I'll post another version shortly with your comments addressed, thanks. jon -- 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] Updated videobuf documentation
On Fri, 19 Feb 2010 04:09:19 -0200 Mauro Carvalho Chehab wrote: > Not anymore: there's a patch that added USERPTR support for > videobuf-dma-contig: > > commit 720b17e759a50635c429ccaa2ec3d01edb4f92d6 > Author: Magnus Damm > Date: Tue Jun 16 15:32:36 2009 -0700 > > videobuf-dma-contig: zero copy USERPTR support Now *that* is a special-purpose hack. But it's worth mentioning, so I've updated the text accordingly. > In terms of memory types, there's a possibility that weren't mentioned: the > OVERLAY mode. > > Maybe a small paragraph may be added just for the completeness of the doc. Yeah, I try to ignore overlay whenever I can. I've added a brief bit. New version of the patch attached; look better? Thanks, jon --- V4L2: Add a document describing the videobuf layer Videobuf is a moderately complex API which most V4L2 drivers should use, but its documentation is...sparse. This document attempts to improve the situation. Signed-off-by: Jonathan Corbet --- Documentation/video4linux/v4l2-framework.txt | 107 +--- Documentation/video4linux/videobuf | 360 ++ 2 files changed, 371 insertions(+), 96 deletions(-) create mode 100644 Documentation/video4linux/videobuf diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index b806eda..fa53ab7 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -587,99 +587,14 @@ struct v4l2_device *v4l2_dev = vdev->v4l2_dev; video buffer helper functions - -The v4l2 core API provides a standard method for dealing with video -buffers. Those methods allow a driver to implement read(), mmap() and -overlay() on a consistent way. - -There are currently methods for using video buffers on devices that -supports DMA with scatter/gather method (videobuf-dma-sg), DMA with -linear access (videobuf-dma-contig), and vmalloced buffers, mostly -used on USB drivers (videobuf-vmalloc). - -Any driver using videobuf should provide operations (callbacks) for -four handlers: - -ops->buf_setup - calculates the size of the video buffers and avoid they - to waste more than some maximum limit of RAM; -ops->buf_prepare - fills the video buffer structs and calls - videobuf_iolock() to alloc and prepare mmaped memory; -ops->buf_queue - advices the driver that another buffer were - requested (by read() or by QBUF); -ops->buf_release - frees any buffer that were allocated. - -In order to use it, the driver need to have a code (generally called at -interrupt context) that will properly handle the buffer request lists, -announcing that a new buffer were filled. - -The irq handling code should handle the videobuf task lists, in order -to advice videobuf that a new frame were filled, in order to honor to a -request. The code is generally like this one: - if (list_empty(&dma_q->active)) - return; - - buf = list_entry(dma_q->active.next, struct vbuffer, vb.queue); - - if (!waitqueue_active(&buf->vb.done)) - return; - - /* Some logic to handle the buf may be needed here */ - - list_del(&buf->vb.queue); - do_gettimeofday(&buf->vb.ts); - wake_up(&buf->vb.done); - -Those are the videobuffer functions used on drivers, implemented on -videobuf-core: - -- Videobuf init functions - videobuf_queue_sg_init() - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on drivers that uses DMA - Scatter/Gather buffers. - - videobuf_queue_dma_contig_init - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on drivers that need DMA - contiguous buffers. - - videobuf_queue_vmalloc_init() - Initializes the videobuf infrastructure. This function should be - called before any other videobuf function on USB (and other drivers) - that need a vmalloced type of videobuf. - -- videobuf_iolock() - Prepares the videobuf memory for the proper method (read, mmap, overlay). - -- videobuf_queue_is_busy() - Checks if a videobuf is streaming. - -- videobuf_queue_cancel() - Stops video handling. - -- videobuf_mmap_free() - frees mmap buffers. - -- videobuf_stop() - Stops video handling, ends mmap and frees mmap and other buffers. - -- V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls: - videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(), - videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff(). - -- V4L1 api function (corresponds to VIDIOCMBUF ioctl): - videobuf_cgmbuf() - This function is used to provide backward compatibility with V4L1 - API. - -- Some help functions for read()/poll() operations: - videobuf_read_stream() - For continuous stream read() - videobuf_read_one() - For snapshot read() - vi
Re: DM1105: could not attach frontend 195d:1105
Hey Igor, I'm getting the same error: dm1105 :04:0b.0: could not attach frontend Did you get your one to work. Thanks Nameer Igor M. Liplianin wrote: On 18 февраля 2010, liplia...@me.by wrote: I also got the unbranded dm1105 card. I tried the four possible i2c addresses, just i case. Noen worked of course. Then I traced the i2c pins on the tuner to pins 100 and 101 on the DM1105. These are GPIO pins, so bit-banging i2c on these pins seems to be the solution. scl = p101 = gpio14 sda = p100 = gpio13 Here is the patch to test. Use option card=4. modprobe dm1105 card=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: Chroma gain configuration
On Mon, Feb 22, 2010 at 8:58 AM, Mauro Carvalho Chehab wrote: >> Ok then. I'll add the 15-20 lines of code which add the extended >> controls mechanism to the 7115, which just operates as a passthrough >> for the older control interface. > > The better is to do the opposite: extended being the control interface and > the old calls as a passthrough, since the idea is to remove the old interface > after having all drivers converted. I gave this a bit of thought, and I'm not sure what you are proposing is actually possible. Because the extended controls provides a superset of the functionality of the older user controls interface, it is possible to create a extended control callback which just passes through the request (since any user control can be converted into a extended control). However, you cannot convert the extended control results into the older user control format, since not all the information could be provided. In fact, I would be in favor of taking the basic logic found in cx18_g_ext_ctrls(), and making that generic to the videodev interface, such that any driver which provides a user control interface but doesn't provide an extended control function will work if the calling application makes an extended control call. This will allow userland applications to always use the extended controls API, even if the driver didn't explicitly add support for it. 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
Re: [PATCH] Updated videobuf documentation
On 02/22/10 12:47, Jonathan Corbet wrote: > On Fri, 19 Feb 2010 04:09:19 -0200 > Mauro Carvalho Chehab wrote: > >> Not anymore: there's a patch that added USERPTR support for >> videobuf-dma-contig: >> >> commit 720b17e759a50635c429ccaa2ec3d01edb4f92d6 >> Author: Magnus Damm >> Date: Tue Jun 16 15:32:36 2009 -0700 >> >> videobuf-dma-contig: zero copy USERPTR support > > Now *that* is a special-purpose hack. But it's worth mentioning, so > I've updated the text accordingly. > >> In terms of memory types, there's a possibility that weren't mentioned: the >> OVERLAY mode. >> >> Maybe a small paragraph may be added just for the completeness of the doc. > > Yeah, I try to ignore overlay whenever I can. I've added a brief bit. > > New version of the patch attached; look better? Looks good to me (other than a few straggling lines that end with whitespace). Reviewed-by: Randy Dunlap thanks. -- ~Randy -- 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
PULL request [for 2.6.34]: http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For 24 changesets, summary: - Add support for the button (as input device) on camera's using: pac207, pac7311, sonixb. sonixj, zc3xx, ov511, ov518, ov519 and stv06xx bridges - Much improved exposure and gain controls for PAS106B and PAS202BCB sensors in the sonixb driver - mr97310a: simplify sensor detection, add support for a new type of vga sensor - sq905c: add a new supported USB-ID 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: Chroma gain configuration
Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 8:58 AM, Mauro Carvalho Chehab > wrote: >>> Ok then. I'll add the 15-20 lines of code which add the extended >>> controls mechanism to the 7115, which just operates as a passthrough >>> for the older control interface. >> The better is to do the opposite: extended being the control interface and >> the old calls as a passthrough, since the idea is to remove the old interface >> after having all drivers converted. > > I gave this a bit of thought, and I'm not sure what you are proposing > is actually possible. Because the extended controls provides a > superset of the functionality of the older user controls interface, it > is possible to create a extended control callback which just passes > through the request (since any user control can be converted into a > extended control). However, you cannot convert the extended control > results into the older user control format, since not all the > information could be provided. > > In fact, I would be in favor of taking the basic logic found in > cx18_g_ext_ctrls(), and making that generic to the videodev interface, > such that any driver which provides a user control interface but > doesn't provide an extended control function will work if the calling > application makes an extended control call. This will allow userland > applications to always use the extended controls API, even if the > driver didn't explicitly add support for it. That's exactly the idea: convert all driverst o use ext_ctrl's and let the V4L2 core to handle the calls to the non-extended interface. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chroma gain configuration
On Mon, Feb 22, 2010 at 4:32 PM, Mauro Carvalho Chehab wrote: > Devin Heitmueller wrote: >> In fact, I would be in favor of taking the basic logic found in >> cx18_g_ext_ctrls(), and making that generic to the videodev interface, >> such that any driver which provides a user control interface but >> doesn't provide an extended control function will work if the calling >> application makes an extended control call. This will allow userland >> applications to always use the extended controls API, even if the >> driver didn't explicitly add support for it. > > That's exactly the idea: convert all driverst o use ext_ctrl's and let the > V4L2 core to handle the calls to the non-extended interface. I think you actually missed the point of what I'm trying to say: You can only do the opposite of what you proposed: You can have the v4l2 core receive extended interface calls and pass those calls through to the older interface in drivers (since the older interface is a *subset* of the newer interface). However, you cannot provide a way for callers of the older interface have those requests passed through to the new interface (since the old interface does not support multiple controls in one call and there are multiple classes of controls in the newer interface). In other words, a caller using the extended interface can automatically call the old interface, but a caller using the old interface cannot automatically call into the extended interface. 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
Re: Chroma gain configuration
On Monday 22 February 2010 22:17:24 Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 8:58 AM, Mauro Carvalho Chehab > wrote: > >> Ok then. I'll add the 15-20 lines of code which add the extended > >> controls mechanism to the 7115, which just operates as a passthrough > >> for the older control interface. > > > > The better is to do the opposite: extended being the control interface and > > the old calls as a passthrough, since the idea is to remove the old > > interface > > after having all drivers converted. > > I gave this a bit of thought, and I'm not sure what you are proposing > is actually possible. Because the extended controls provides a > superset of the functionality of the older user controls interface, it > is possible to create a extended control callback which just passes > through the request (since any user control can be converted into a > extended control). However, you cannot convert the extended control > results into the older user control format, since not all the > information could be provided. > > In fact, I would be in favor of taking the basic logic found in > cx18_g_ext_ctrls(), and making that generic to the videodev interface, > such that any driver which provides a user control interface but > doesn't provide an extended control function will work if the calling > application makes an extended control call. This will allow userland > applications to always use the extended controls API, even if the > driver didn't explicitly add support for it. I am still planning to continue my work for a general control handling framework. I know how to do it and it's just time that I lack. Converting all drivers to support the extended control API is quite complicated since the API is fairly complex (esp. with regard to atomicity). In this case my advice would be to support extended controls only where needed and wait for this framework before converting all the other drivers. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Chroma gain configuration
On Mon, Feb 22, 2010 at 4:41 PM, Hans Verkuil wrote: > I am still planning to continue my work for a general control handling > framework. I know how to do it and it's just time that I lack. > > Converting all drivers to support the extended control API is quite > complicated > since the API is fairly complex (esp. with regard to atomicity). In this case > my advice would be to support extended controls only where needed and wait for > this framework before converting all the other drivers. Hans, I have no objection to holding off if that's what you recommend. The only reason we got onto this thread was because the v4l2-dbg application seems to implicitly assume that *all* private controls using V4L2_CID_PRIVATE_BASE can only be accessed via the extended control interface, meaning you cannot use the utility in conjunction with a driver that has a private control defined in the the VIDIOC_G_CTRL function. 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
Re: [HG PULL] http://linuxtv.org/hg/~awalls/ivtv-changes
Andy Walls wrote: > Mauro, > > Please pull from http://linuxtv.org/hg/~awalls/ivtv-changes > > for the following 4 changesets: > > 01/04: ivtv: Fix ivtv_api_get_data() to avoid unneeded IO during IRQ handling > http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=4090ec224ef2 Hmm: WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt #89: FILE: drivers/media/video/ivtv/ivtv-mailbox.c:375: + volatile u32 __iomem *p = mbdata->mbox[mb].data; Is the driver missing some locks? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chroma gain configuration
On Monday 22 February 2010 22:38:56 Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 4:32 PM, Mauro Carvalho Chehab > wrote: > > Devin Heitmueller wrote: > >> In fact, I would be in favor of taking the basic logic found in > >> cx18_g_ext_ctrls(), and making that generic to the videodev interface, > >> such that any driver which provides a user control interface but > >> doesn't provide an extended control function will work if the calling > >> application makes an extended control call. This will allow userland > >> applications to always use the extended controls API, even if the > >> driver didn't explicitly add support for it. > > > > That's exactly the idea: convert all driverst o use ext_ctrl's and let the > > V4L2 core to handle the calls to the non-extended interface. > > I think you actually missed the point of what I'm trying to say: You > can only do the opposite of what you proposed: You can have the v4l2 > core receive extended interface calls and pass those calls through to > the older interface in drivers (since the older interface is a > *subset* of the newer interface). However, you cannot provide a way > for callers of the older interface have those requests passed through > to the new interface (since the old interface does not support > multiple controls in one call and there are multiple classes of > controls in the newer interface). > > In other words, a caller using the extended interface can > automatically call the old interface, but a caller using the old > interface cannot automatically call into the extended interface. Sure you can. See v4l2-ioctl.c, VIDIOC_G/S_CTRL. That's exactly what is being done there. It's the other way around that is not in general possible. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Chroma gain configuration
On Monday 22 February 2010 22:43:58 Devin Heitmueller wrote: > On Mon, Feb 22, 2010 at 4:41 PM, Hans Verkuil wrote: > > I am still planning to continue my work for a general control handling > > framework. I know how to do it and it's just time that I lack. > > > > Converting all drivers to support the extended control API is quite > > complicated > > since the API is fairly complex (esp. with regard to atomicity). In this > > case > > my advice would be to support extended controls only where needed and wait > > for > > this framework before converting all the other drivers. > > Hans, > > I have no objection to holding off if that's what you recommend. The > only reason we got onto this thread was because the v4l2-dbg > application seems to implicitly assume that *all* private controls > using V4L2_CID_PRIVATE_BASE can only be accessed via the extended > control interface, meaning you cannot use the utility in conjunction > with a driver that has a private control defined in the the > VIDIOC_G_CTRL function. Ah, that's another matter. The original approach for handling private controls is seriously flawed. Drivers that want to use private controls are strongly encouraged to use the extended control mechanism for them, and to document those controls in the spec. Actually, it is not so much the extended control API that is relevant here, but the use of V4L2_CTRL_FLAG_NEXT_CTRL in VIDIOC_QUERYCTRL to enumerate the controls. Unfortunately, the current support functions in v4l2-common.c to help with this are pretty crappy, for which I apologize. Regards, Hans > > Devin > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Chroma gain configuration
On Mon, Feb 22, 2010 at 4:54 PM, Hans Verkuil wrote: > Ah, that's another matter. The original approach for handling private > controls is seriously flawed. Drivers that want to use private controls > are strongly encouraged to use the extended control mechanism for them, > and to document those controls in the spec. Yeah, it's just annoying that what should have been a change for something like six lines of code in the g_ctrl/s_ctrl functions in saa7115 is actually resulting in me having to extend saa7115 to add support for the extended control interface. Yeah, I can do that, but it's still annoying that it should be necessary. > Actually, it is not so much the extended control API that is relevant > here, but the use of V4L2_CTRL_FLAG_NEXT_CTRL in VIDIOC_QUERYCTRL to > enumerate the controls. Control enumeration is actually working fine. The queryctrl does properly return all of the controls, including my new private control. > Unfortunately, the current support functions in v4l2-common.c to help > with this are pretty crappy, for which I apologize. Of course, if you and Mauro wanted to sign off on the creation of a new non-private user control called V4L2_CID_CHROMA_GAIN, that would also resolve my problem. :-) 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
Re: [PATCH] Updated videobuf documentation
Randy Dunlap wrote: > On 02/22/10 12:47, Jonathan Corbet wrote: >> On Fri, 19 Feb 2010 04:09:19 -0200 >> Mauro Carvalho Chehab wrote: >> >>> Not anymore: there's a patch that added USERPTR support for >>> videobuf-dma-contig: >>> >>> commit 720b17e759a50635c429ccaa2ec3d01edb4f92d6 >>> Author: Magnus Damm >>> Date: Tue Jun 16 15:32:36 2009 -0700 >>> >>> videobuf-dma-contig: zero copy USERPTR support >> Now *that* is a special-purpose hack. But it's worth mentioning, so >> I've updated the text accordingly. >> >>> In terms of memory types, there's a possibility that weren't mentioned: the >>> OVERLAY mode. >>> >>> Maybe a small paragraph may be added just for the completeness of the doc. >> Yeah, I try to ignore overlay whenever I can. I've added a brief bit. >> >> New version of the patch attached; look better? > > Looks good to me (other than a few straggling lines that end with whitespace). > > Reviewed-by: Randy Dunlap Seems OK to me also. I'll apply it (running a script to remove trailing whitespaces ;) ) -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] V4L: Events: Add documentation
Hans Verkuil wrote: >> + To receive events, the events the user is interested first >> + must be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an >> + event is subscribed, the events of subscribed types are dequeueable >> + using the &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using >> + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type >> + V4L2_EVENT_ALL may be used to subscribe or unsubscribe all the > > ALL may be used only with unsubscribe. Missed that one. Thanks. ... >> + >> + >> +__u32 >> +type >> +Type of the event. >> + >> + >> +__u32 >> +reserved[7] >> +Reserved for future extensions. Drivers must set > > Drivers and applications must zero this array. Fixed. >> +the array to zero. >> + >> + >> + >> + >> + >> + >> + Event Types >> + >> +&cs-def; >> + >> + >> +V4L2_EVENT_ALL >> +0 >> +All events. V4L2_EVENT_ALL is valid only for >> +VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once. >> + >> + >> + >> +V4L2_EVENT_PRIVATE_START >> +0x0800 > > This needs a short description. E.g.: 'Base event number for driver-private > events.' Added. ... >> +Drivers do not initialise events directly. The events are initialised >> +through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is >> +non-NULL. This *MUST* be performed in the driver's >> +v4l2_file_operations->open() handler. >> + >> +Events are delivered to user space through the poll system call. The driver >> +can use v4l2_fh->events->wait wait_queue_head_t as the argument for >> +poll_wait(). >> + >> +There are standard and private events. New standard events must use the >> +smallest available event type. The drivers must allocate their events >> +starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) while individual >> +events start from base + 1. > > What do you mean with 'while individual events start from base + 1'? I still > don't understand that phrase. Will be "There are standard and private events. New standard events must use the smallest available event type. The drivers must allocate their events starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) + 1." in the next one. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: eb1a:2860 eMPIA em28xx device to usb1 ??? usb hub problem?
On Mon, Feb 22, 2010 at 5:38 PM, j wrote: > Hi I get trouble with my Kworld em28xx device, anyone can help any kernel > issue found somewhere about that? Hi J, Is this device plugged directly into the USB port on the motherboard? Or do you have a USB hub that the device is connected to. Sometimes low quality USB hubs will not work properly with high speed isoc devices. Also, I would suggest that you leave the device unplugged when powering up the system. Then once it is up, plug it in and send the full dmesg output. This will make it easier to analyze the dmesg output because the driver will not be initializing at the same time as all the other USB devices. Also, please provide the *full* dmesg output, so we have more context information about the system (things such as the kernel version, etc). Cheers, 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
Re: [ANNOUNCE] git tree repositories & libv4l
On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: > >lib/ > > libv4l1/ > > libv4l2/ > > libv4lconvert/ > >utils/ > > v4l2-dbg > > v4l2-ctl > > cx18-ctl > > ivtv-ctl > >contrib/ > > test/ > > everything else > > git clone git://ifup.org/philips/create-v4l-utils.git cd create-v4l-utils/ ./convert.sh You should now have v4l-utils.git which should have this directory struture. If we need to move other things around let me know and I can tweak name-filter.sh Thoughts? Let me know how we should proceed with dropping v4l2-apps from v4l-dvb. Re: code style cleanup. I think we should do that once we drop v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Cheers, Brandon -- 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 v7 0/6] V4L2 file handles and event interface
Hi, Here's the ninth version of the V4L2 file handle and event interface patchset. The patchset has been tested with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called event): git://gitorious.org/omap3camera/mainline.git event The patchset I'm posting now is against the v4l-dvb tree instead of linux-omap. The omap3camera tree thus has a slightly different version of these patches due to different baselines. Some more comments from Hans and Sergio. What has changed: - Proper ioctl numbers! - v4l2_fh_init() may now fail as v4l2_event_init() may also. - Fixed copyright years. - Fixed file names in file headings. - Removed WARN_ON() in v4l2_event_init(). This function is only called from v4l2_fh_init() and it also initialises the field related to WARN_ON(). - Documentation fixes suggested by Hans. Comments are welcome as always. Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[PATCH v7 1/6] V4L: File handles
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.
Video device drivers should use the v4l2_fh pointer as their
file->private_data.
Signed-off-by: Sakari Ailus
---
drivers/media/video/Makefile |2 +-
drivers/media/video/v4l2-dev.c |4 ++
drivers/media/video/v4l2-fh.c | 66
include/media/v4l2-dev.h |5 +++
include/media/v4l2-fh.h| 42 +
5 files changed, 118 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/v4l2-fh.c
create mode 100644 include/media/v4l2-fh.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 5163289..14bf69a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..65a7b30 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -421,6 +421,10 @@ static int __video_register_device(struct video_device
*vdev, int type, int nr,
if (!vdev->release)
return -EINVAL;
+ /* v4l2_fh support */
+ spin_lock_init(&vdev->fh_lock);
+ INIT_LIST_HEAD(&vdev->fh_list);
+
/* Part 1: check device type */
switch (type) {
case VFL_TYPE_GRABBER:
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
new file mode 100644
index 000..93ea0af
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,66 @@
+/*
+ * v4l2-fh.c
+ *
+ * V4L2 file handles.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+{
+ fh->vdev = vdev;
+ INIT_LIST_HEAD(&fh->list);
+ set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_init);
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_add(&fh->list, &fh->vdev->fh_list);
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_add);
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_del_init(&fh->list);
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+{
+ if (fh->vdev == NULL)
+ return;
+
+ fh->vdev = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2dee938..bebe44b 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -32,6 +32,7 @@ struct v4l2_device;
Drivers can clear this flag if they want to block all future
device access. It is cleared by video_unregister_device. */
#define V4L2_FL_REGISTERED (0)
+#define V4L2_FL_USES_V4L2_FH (1)
struct v4l2_file_operations {
struct module *owner;
@@ -77,6 +78,10 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
+ /* V4L2 file handles */
+ spinlock_t fh_lock; /* Lock for all v4l2_fhs */
+ struct list_headfh_list; /* List of struct v4l2_fh */
+
int debug; /* Activates debug level*/
/* Video standard vars */
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
new file mode 100644
index 000..410e86c
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,42 @@
+/*
+ * v4l2-fh.h
+ *
+ * V4L2 file handle.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version
[PATCH v7 2/6] V4L: File handles: Add documentation
Add documentation on using V4L2 file handles (v4l2_fh) in V4L2 drivers. Signed-off-by: Sakari Ailus --- Documentation/video4linux/v4l2-framework.txt | 37 ++ 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 74d677c..bfaf0c5 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -695,3 +695,40 @@ The better way to understand it is to take a look at vivi driver. One of the main reasons for vivi is to be a videobuf usage example. the vivi_thread_tick() does the task that the IRQ callback would do on PCI drivers (or the irq callback on USB). + +struct v4l2_fh +-- + +struct v4l2_fh provides a way to easily keep file handle specific data +that is used by the V4L2 framework. + +struct v4l2_fh is allocated as a part of the driver's own file handle +structure and is set to file->private_data in the driver's open +function by the driver. Drivers can extract their own file handle +structure by using the container_of macro. + +Useful functions: + +- v4l2_fh_init() + + Initialise the file handle. This *MUST* be performed in the driver's + v4l2_file_operations->open() handler. + +- v4l2_fh_add() + + Add a v4l2_fh to video_device file handle list. May be called after + initialising the file handle. + +- v4l2_fh_del() + + Unassociate the file handle from video_device(). The file handle + exit function may now be called. + +- v4l2_fh_exit() + + Uninitialise the file handle. After uninitialisation the v4l2_fh + memory can be freed. + +The users of v4l2_fh know whether a driver uses v4l2_fh as its +file->private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in +video_device->flags. -- 1.5.6.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/6] V4L: Events: Add new ioctls for events
This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:
http://www.spinics.net/lists/linux-media/msg12033.html>
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-compat-ioctl32.c |3 +++
drivers/media/video/v4l2-ioctl.c |3 +++
include/linux/videodev2.h | 26 ++
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index f77f84b..9004a5f 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1086,6 +1086,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_PRESET:
case VIDIOC_S_DV_TIMINGS:
case VIDIOC_G_DV_TIMINGS:
+ case VIDIOC_DQEVENT:
+ case VIDIOC_SUBSCRIBE_EVENT:
+ case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..34c7d6e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -290,6 +290,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_QUERY_DV_PRESET)] = "VIDIOC_QUERY_DV_PRESET",
[_IOC_NR(VIDIOC_S_DV_TIMINGS)] = "VIDIOC_S_DV_TIMINGS",
[_IOC_NR(VIDIOC_G_DV_TIMINGS)] = "VIDIOC_G_DV_TIMINGS",
+ [_IOC_NR(VIDIOC_DQEVENT)] = "VIDIOC_DQEVENT",
+ [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)] = "VIDIOC_SUBSCRIBE_EVENT",
+ [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..d3b1446 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1622,6 +1622,29 @@ struct v4l2_streamparm {
};
/*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+ __u32 type;
+ union {
+ __u8data[64];
+ } u;
+ __u32 pending;
+ __u32 sequence;
+ struct timespec timestamp;
+ __u32 reserved[9];
+};
+
+struct v4l2_event_subscription {
+ __u32 type;
+ __u32 reserved[7];
+};
+
+#define V4L2_EVENT_ALL 0
+#define V4L2_EVENT_PRIVATE_START 0x0800
+
+/*
* A D V A N C E D D E B U G G I N G
*
* NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1743,6 +1766,9 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset)
#defineVIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
#defineVIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
+#defineVIDIOC_DQEVENT _IOR('V', 89, struct v4l2_event)
+#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription)
+#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct
v4l2_event_subscription)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/6] V4L: Events: Support event handling in do_ioctl
Add support for event handling to do_ioctl.
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-fh.c| 11 +++-
drivers/media/video/v4l2-ioctl.c | 50 ++
include/media/v4l2-ioctl.h |7 +
3 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index aab2fb6..1423c44 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -34,7 +34,16 @@ int v4l2_fh_init(struct v4l2_fh *fh, struct video_device
*vdev)
INIT_LIST_HEAD(&fh->list);
set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
- return v4l2_event_init(fh);
+ /*
+* fh->events only needs to be initialized if the driver
+* supports the VIDIOC_SUBSCRIBE_EVENT ioctl.
+*/
+ if (vdev->ioctl_ops && vdev->ioctl_ops->vidioc_subscribe_event)
+ return v4l2_event_init(fh);
+ else
+ fh->events = NULL;
+
+ return 0;
}
EXPORT_SYMBOL_GPL(v4l2_fh_init);
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 34c7d6e..4ba22da 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -25,6 +25,8 @@
#endif
#include
#include
+#include
+#include
#include
#define dbgarg(cmd, fmt, arg...) \
@@ -1944,7 +1946,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+ case VIDIOC_DQEVENT:
+ {
+ struct v4l2_event *ev = arg;
+
+ if (!ops->vidioc_subscribe_event)
+ break;
+
+ ret = v4l2_event_dequeue(fh, ev, file->f_flags & O_NONBLOCK);
+ if (ret < 0) {
+ dbgarg(cmd, "no pending events?");
+ break;
+ }
+ dbgarg(cmd,
+ "pending=%d, type=0x%8.8x, sequence=%d, "
+ "timestamp=%lu.%9.9lu ",
+ ev->pending, ev->type, ev->sequence,
+ ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
+ break;
+ }
+ case VIDIOC_SUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+ if (!ops->vidioc_subscribe_event)
+ break;
+
+ ret = ops->vidioc_subscribe_event(fh, sub);
+ if (ret < 0) {
+ dbgarg(cmd, "failed, ret=%ld", ret);
+ break;
+ }
+ dbgarg(cmd, "type=0x%8.8x", sub->type);
+ break;
+ }
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ {
+ struct v4l2_event_subscription *sub = arg;
+
+ if (!ops->vidioc_unsubscribe_event)
+ break;
+
+ ret = ops->vidioc_unsubscribe_event(fh, sub);
+ if (ret < 0) {
+ dbgarg(cmd, "failed, ret=%ld", ret);
+ break;
+ }
+ dbgarg(cmd, "type=0x%8.8x", sub->type);
+ break;
+ }
default:
{
if (!ops->vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..06daa6e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -21,6 +21,8 @@
#include
#endif
+struct v4l2_fh;
+
struct v4l2_ioctl_ops {
/* ioctl callbacks */
@@ -254,6 +256,11 @@ struct v4l2_ioctl_ops {
int (*vidioc_g_dv_timings) (struct file *file, void *fh,
struct v4l2_dv_timings *timings);
+ int (*vidioc_subscribe_event) (struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+ int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
+ struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 6/6] V4L: Events: Add documentation
Add documentation on how to use V4L2 events, both for V4L2 drivers and for V4L2 applications. Signed-off-by: Sakari Ailus --- Documentation/DocBook/media-entities.tmpl |9 ++ Documentation/DocBook/v4l/dev-event.xml| 33 + Documentation/DocBook/v4l/v4l2.xml |3 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 124 .../DocBook/v4l/vidioc-subscribe-event.xml | 104 Documentation/video4linux/v4l2-framework.txt | 57 + 6 files changed, 330 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/dev-event.xml create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c725cb8..770be3c 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -17,6 +17,7 @@ VIDIOC_DBG_G_REGISTER"> VIDIOC_DBG_S_REGISTER"> VIDIOC_DQBUF"> +VIDIOC_DQEVENT"> VIDIOC_ENCODER_CMD"> VIDIOC_ENUMAUDIO"> VIDIOC_ENUMAUDOUT"> @@ -60,6 +61,7 @@ VIDIOC_REQBUFS"> VIDIOC_STREAMOFF"> VIDIOC_STREAMON"> +VIDIOC_SUBSCRIBE_EVENT"> VIDIOC_S_AUDIO"> VIDIOC_S_AUDOUT"> VIDIOC_S_CROP"> @@ -141,6 +143,8 @@ v4l2_enc_idx"> v4l2_enc_idx_entry"> v4l2_encoder_cmd"> +v4l2_event"> +v4l2_event_subscription"> v4l2_ext_control"> v4l2_ext_controls"> v4l2_fmtdesc"> @@ -200,6 +204,7 @@ + @@ -292,6 +297,8 @@ + + @@ -381,3 +388,5 @@ + + diff --git a/Documentation/DocBook/v4l/dev-event.xml b/Documentation/DocBook/v4l/dev-event.xml new file mode 100644 index 000..ecee64d --- /dev/null +++ b/Documentation/DocBook/v4l/dev-event.xml @@ -0,0 +1,33 @@ + Event Interface + + The V4L2 event interface provides means for user to get + immediately notified on certain conditions taking place on a device. + This might include start of frame or loss of signal events, for + example. + + + To receive events, the events the user is interested first must be + subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is + subscribed, the events of subscribed types are dequeueable using the + &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type V4L2_EVENT_ALL may + be used to unsubscribe all the events the driver supports. + + The event subscriptions and event queues are specific to file + handles. Subscribing an event on one file handle does not affect + other file handles. + + + The information on dequeueable events are obtained by using + select or poll system calls on video devices. The V4L2 events use + POLLPRI events on poll system call and exceptions on select system + call. + + + diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 060105a..9737243 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -401,6 +401,7 @@ and discussions on the V4L mailing list. &sub-dev-teletext; &sub-dev-radio; &sub-dev-rds; + &sub-dev-event; @@ -426,6 +427,7 @@ and discussions on the V4L mailing list. &sub-cropcap; &sub-dbg-g-chip-ident; &sub-dbg-g-register; +&sub-dqevent; &sub-encoder-cmd; &sub-enumaudio; &sub-enumaudioout; @@ -467,6 +469,7 @@ and discussions on the V4L mailing list. &sub-reqbufs; &sub-s-hw-freq-seek; &sub-streamon; +&sub-subscribe-event; &sub-mmap; &sub-munmap; diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml b/Documentation/DocBook/v4l/vidioc-dqevent.xml new file mode 100644 index 000..eb45c16 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml @@ -0,0 +1,124 @@ + + +ioctl VIDIOC_DQEVENT +&manvol; + + + +VIDIOC_DQEVENT +Dequeue event + + + + + + int ioctl + int fd + int request + struct v4l2_event +*argp + + + + + +Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DQEVENT + + + + argp + + + + + + + + +Description + +Dequeue an event from a video device. No input is required +for this ioctl. All the fields of the &v4l2-event; structure are +filled by the driver. The file handle will also receive exceptions +which the application may get by e.g. using the select system +call. + + + struct v4l2_event + + &cs-str; + + + __u32 + type + + Type of the event. + + + union + u + + + + + + __u8 +data[64] + Event data. Defined by the event t
[PATCH v7 4/6] V4L: Events: Add backend
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.
Signed-off-by: Sakari Ailus
---
drivers/media/video/Makefile |3 +-
drivers/media/video/v4l2-event.c | 289 ++
drivers/media/video/v4l2-fh.c|6 +-
include/media/v4l2-event.h | 67 +
include/media/v4l2-fh.h |2 +
5 files changed, 365 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/v4l2-event.c
create mode 100644 include/media/v4l2-event.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 14bf69a..b84abfe 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,8 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
-videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
+videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
+ v4l2-event.o
# V4L2 core modules
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..aea4332
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,289 @@
+/*
+ * v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+int v4l2_event_init(struct v4l2_fh *fh)
+{
+ fh->events = kzalloc(sizeof(*fh->events), GFP_KERNEL);
+ if (fh->events == NULL)
+ return -ENOMEM;
+
+ init_waitqueue_head(&fh->events->wait);
+
+ INIT_LIST_HEAD(&fh->events->free);
+ INIT_LIST_HEAD(&fh->events->available);
+ INIT_LIST_HEAD(&fh->events->subscribed);
+
+ fh->events->sequence = -1;
+
+ return 0;
+}
+
+int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
+{
+ struct v4l2_events *events = fh->events;
+ unsigned long flags;
+
+ if (!events) {
+ WARN_ON(1);
+ return -ENOMEM;
+ }
+
+ while (events->nallocated < n) {
+ struct v4l2_kevent *kev;
+
+ kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+ if (kev == NULL)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+ list_add_tail(&kev->list, &events->free);
+ events->nallocated++;
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_alloc);
+
+#define list_kfree(list, type, member) \
+ while (!list_empty(list)) { \
+ type *hi; \
+ hi = list_first_entry(list, type, member); \
+ list_del(&hi->member); \
+ kfree(hi); \
+ }
+
+void v4l2_event_free(struct v4l2_fh *fh)
+{
+ struct v4l2_events *events = fh->events;
+
+ if (!events)
+ return;
+
+ list_kfree(&events->free, struct v4l2_kevent, list);
+ list_kfree(&events->available, struct v4l2_kevent, list);
+ list_kfree(&events->subscribed, struct v4l2_subscribed_event, list);
+
+ kfree(events);
+ fh->events = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_free);
+
+static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
+{
+ struct v4l2_events *events = fh->events;
+ struct v4l2_kevent *kev;
+ unsigned long flags;
+
+ spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+
+ if (list_empty(&events->available)) {
+ spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+ return -ENOENT;
+ }
+
+ WARN_ON(events->navailable == 0);
+
+ kev = list_first_entry(&events->available, struct v4l2_kevent, list);
+ list_move(&kev->list, &events->free);
+ events->navailable--;
+
+ kev->event.pending = events->navailable;
+ *event = kev->event;
+
+ spin_unlock_
Re: [git:v4l-dvb/master] V4L/DVB: uvcvideo: Clamp control values to the minimum and maximum values
Hi Mauro,
On Monday 22 February 2010 22:14:19 Patch from Laurent Pinchart wrote:
> From: Laurent Pinchart
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
There's a problem somewhere.
> When setting a control, the V4L2 specification requires drivers to
> either clamp the control value to the [minimum, maximum] range or return
> the -ERANGE error.
>
> Fix the driver to clamp control values to the valid range in
> uvc_ctrl_set() and make sure the value differs from the minimum by an
> integer multiple of step.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Márton Németh
> Signed-off-by: Mauro Carvalho Chehab
>
> drivers/media/video/uvc/uvc_ctrl.c | 47
> --- drivers/media/video/uvc/uvc_v4l2.c |
> 2 +
> 2 files changed, 45 insertions(+), 4 deletions(-)
>
> ---
>
> http://git.linuxtv.org/v4l-dvb.git?a=commitdiff;h=a8677cd5589be9e35ef5117f7
> 5e4b996724102fb
>
> diff --git a/drivers/media/video/uvc/uvc_ctrl.c
> b/drivers/media/video/uvc/uvc_ctrl.c index 5ff5013..f38bc6b 100644
> --- a/drivers/media/video/uvc/uvc_ctrl.c
> +++ b/drivers/media/video/uvc/uvc_ctrl.c
> @@ -1021,19 +1021,57 @@ int uvc_ctrl_set(struct uvc_video_chain *chain,
> {
> struct uvc_control *ctrl;
> struct uvc_control_mapping *mapping;
> - s32 value = xctrl->value;
> + s32 value;
> + u32 step;
> + s32 min;
> + s32 max;
> int ret;
>
> ctrl = uvc_find_control(chain, xctrl->id, &mapping);
> if (ctrl == NULL || (ctrl->info->flags & UVC_CONTROL_SET_CUR) == 0)
> return -EINVAL;
>
> - if (mapping->v4l2_type == V4L2_CTRL_TYPE_MENU) {
> - if (value < 0 || value >= mapping->menu_count)
> + /* Clamp out of range values. */
> + switch (mapping->v4l2_type) {
> + case V4L2_CTRL_TYPE_INTEGER:
> + if (!ctrl->cached) {
> + ret = uvc_ctrl_populate_cache(chain, ctrl);
> + if (ret < 0)
> + return ret;
> + }
> +
> + min = mapping->get(mapping, UVC_GET_MIN,
> +uvc_ctrl_data(ctrl, UVC_CTRL_DATA_MIN));
> + max = mapping->get(mapping, UVC_GET_MAX,
> +uvc_ctrl_data(ctrl, UVC_CTRL_DATA_MAX));
> + step = mapping->get(mapping, UVC_GET_RES,
> + uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES));
> +
> + xctrl->value = min + (xctrl->value - min + step/2) / step *
> step;
> + xctrl->value = clamp(xctrl->value, min, max);
> + value = xctrl->value;
> + break;
> +
> + case V4L2_CTRL_TYPE_BOOLEAN:
> + xctrl->value = clamp(xctrl->value, 0, 1);
> + value = xctrl->value;
> + break;
> +
> + case V4L2_CTRL_TYPE_MENU:
> + if (xctrl->value < 0 || xctrl->value >= mapping->menu_count)
> return -ERANGE;
> - value = mapping->menu_info[value].value;
> + value = mapping->menu_info[xctrl->value].value;
> + break;
> +
> + default:
> + value = xctrl->value;
> + break;
> }
>
> + /* If the mapping doesn't span the whole UVC control, the current value
> + * needs to be loaded from the device to perform the read-modify-write
> + * operation.
> + */
> if (!ctrl->loaded && (ctrl->info->size * 8) != mapping->size) {
> if ((ctrl->info->flags & UVC_CONTROL_GET_CUR) == 0) {
> memset(uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
> @@ -1051,6 +1089,7 @@ int uvc_ctrl_set(struct uvc_video_chain *chain,
> ctrl->loaded = 1;
> }
>
> + /* Backup the current value in case we need to rollback later. */
> if (!ctrl->dirty) {
> memcpy(uvc_ctrl_data(ctrl, UVC_CTRL_DATA_BACKUP),
> uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
> diff --git a/drivers/media/video/uvc/uvc_v4l2.c
> b/drivers/media/video/uvc/uvc_v4l2.c index 23239a4..bf1fc7f 100644
> --- a/drivers/media/video/uvc/uvc_v4l2.c
> +++ b/drivers/media/video/uvc/uvc_v4l2.c
> @@ -549,6 +549,8 @@ static long uvc_v4l2_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) return ret;
> }
> ret = uvc_ctrl_commit(chain);
> + if (ret == 0)
> + ctrl->value = xctrl.value;
> break;
> }
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] V4L: Events: Add documentation
On Monday 22 February 2010 23:47:49 Sakari Ailus wrote: > >> +Drivers do not initialise events directly. The events are initialised > >> +through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event > >> is > >> +non-NULL. This *MUST* be performed in the driver's > >> +v4l2_file_operations->open() handler. > >> + > >> +Events are delivered to user space through the poll system call. The > >> driver > >> +can use v4l2_fh->events->wait wait_queue_head_t as the argument for > >> +poll_wait(). > >> + > >> +There are standard and private events. New standard events must use the > >> +smallest available event type. The drivers must allocate their events > >> +starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) while individual > >> +events start from base + 1. > > > > What do you mean with 'while individual events start from base + 1'? I still > > don't understand that phrase. > > Will be "There are standard and private events. New standard events must > use the smallest available event type. The drivers must allocate their > events starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) + 1." in > the next one. Ah, OK. But why '+ 1'? I don't really see a reason for that to be honest. Am I missing something? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: adv7180 as SoC camera device
On 2/22/10 5:01 PM, Rodolfo Giometti wrote: > On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote: >> On Fri, 19 Feb 2010, Rodolfo Giometti wrote: >> >>> Hello, >>> >>> on my pxa27x based board I have a adv7180 connected with the CIF >>> interface. Due this fact I'm going to use the pxa_camera.c driver >>> which in turn registers a soc_camera_host. >>> >>> In the latest kernel I found your driver for the ADV7180, but it >>> registers the chip as a v4l sub device. >>> >>> I suppose these two interfaces are not compatible, aren't they? >> >> Congratulations! Thereby you're in a position to develop the first >> v4l2-subdev / soc-camera universal driver;) The answer to this your >> question is - they are... kinda. This means - yes, soc-camera is also >> using the v4l2-subdev API, but - with a couple of additions. Basically, >> there are two things you have to change in the adv7180 driver to make it >> compatible with soc-camera - (1) add bus-configuration methods, even if >> they don't do much (see .query_bus_param() and .set_bus_param() methods >> from struct soc_camera_ops), and (2) migrate the driver to the mediabus >> API. The latter one requires some care - in principle, mediabus should be >> the future API to negotiate parameters on the video bus between bridges >> (in your case PXA CIF) and clients, but for you this means you also have >> to migrate any other bridge drivers in the mainline to that API, and, if >> they also interface to some other subdevices - those too, and if those can >> also work with other bridges - those too...;) But, I think, that chain >> will terminate quite soon, in fact, I cannot find any users of that driver >> currently in the mainline, Richard? >> >>> In this situation, should I write a new driver for the >>> soc_camera_device? Which is The-Right-Thing(TM) to do? :) >> >> Please, have a look and try to convert the driver as described above. All >> the APIs and a few examples are in the mainline, so, you should have >> enough copy-paste sources;) Ask on the list (with me on cc) if anything is >> still unclear. > > Thanks for your quick answer! :) > > What I still don't understand is if should I move the driver form > v4l2-subdev to a soc_camera device or trying to support both API... > > It seems to me that the driver is not used by any machines into > mainline so if soc-camera is also using the v4l2-subdev API but with a > couple of additions I suppose I can move it to soc_camera API... > > Is that right? We use it as a subdev to a driver not yet committed from us. So I think you should extend it, not move it. --Richard -- 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: [ANNOUNCE] git tree repositories & libv4l
On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: > On Monday 22 February 2010 23:54:26 Brandon Philips wrote: > > On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: > > > >lib/ > > > > libv4l1/ > > > > libv4l2/ > > > > libv4lconvert/ > > > >utils/ > > > > v4l2-dbg > > > > v4l2-ctl > > > > cx18-ctl > > > > ivtv-ctl > > > >contrib/ > > > > test/ > > > > everything else > > > > > > > > git clone git://ifup.org/philips/create-v4l-utils.git > > cd create-v4l-utils/ > > ./convert.sh > > > > You should now have v4l-utils.git which should have this directory > > struture. If we need to move other things around let me know and I can > > tweak name-filter.sh > > > > Thoughts? Let me know how we should proceed with dropping v4l2-apps > > from v4l-dvb. > > > > Re: code style cleanup. I think we should do that once we drop > > v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. > > Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was > merged into dvb-apps, but while that tool supports dvb, it also supports > v4l2. Just like we merged dvb and v4l in a single repository, so I think we > should also merge the tools to a media-utils repository. > > It remains a fact of life that dvb and v4l are connected and trying to > artificially keep them apart does not make much sense to me. Easy to do but who should be the maintainer of the dvb things? According to the wiki[1] these tools are without a maintainer. So, if no one cares about them enough to make releases why merge them and clutter up the git tree with dead code? Cheers, Brandon [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps -- 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 v7 6/6] V4L: Events: Add documentation
On 02/22/10 15:01, Sakari Ailus wrote: > Add documentation on how to use V4L2 events, both for V4L2 drivers and for > V4L2 applications. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media-entities.tmpl |9 ++ > Documentation/DocBook/v4l/dev-event.xml| 33 + > Documentation/DocBook/v4l/v4l2.xml |3 + > Documentation/DocBook/v4l/vidioc-dqevent.xml | 124 > > .../DocBook/v4l/vidioc-subscribe-event.xml | 104 > Documentation/video4linux/v4l2-framework.txt | 57 + > 6 files changed, 330 insertions(+), 0 deletions(-) > create mode 100644 Documentation/DocBook/v4l/dev-event.xml > create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml > create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml > > diff --git a/Documentation/DocBook/v4l/dev-event.xml > b/Documentation/DocBook/v4l/dev-event.xml > new file mode 100644 > index 000..ecee64d > --- /dev/null > +++ b/Documentation/DocBook/v4l/dev-event.xml > @@ -0,0 +1,33 @@ > + Event Interface > + > + The V4L2 event interface provides means for user to get > + immediately notified on certain conditions taking place on a device. > + This might include start of frame or loss of signal events, for > + example. > + > + > + To receive events, the events the user is interested first must be is interested in > + subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is > + subscribed, the events of subscribed types are dequeueable using the > + &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using > + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type V4L2_EVENT_ALL may > + be used to unsubscribe all the events the driver supports. > + > + The event subscriptions and event queues are specific to file > + handles. Subscribing an event on one file handle does not affect > + other file handles. > + > + > + The information on dequeueable events are obtained by using is obtained > + select or poll system calls on video devices. The V4L2 events use > + POLLPRI events on poll system call and exceptions on select system > + call. > + > + > + > diff --git a/Documentation/video4linux/v4l2-framework.txt > b/Documentation/video4linux/v4l2-framework.txt > index bfaf0c5..d6deb35 100644 > --- a/Documentation/video4linux/v4l2-framework.txt > +++ b/Documentation/video4linux/v4l2-framework.txt > @@ -732,3 +732,60 @@ Useful functions: > The users of v4l2_fh know whether a driver uses v4l2_fh as its > file->private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in > video_device->flags. > + > +V4L2 events > +--- > + > +The V4L2 events provide a generic way to pass events to user space. > +The driver must use v4l2_fh to be able to support V4L2 events. > + > +Useful functions: > + > +- v4l2_event_alloc() > + > + To use events, the driver must allocate events for the file handle. By > + calling the function more than once, the driver may assure that at least n > + events in total has been allocated. The function may not be called in have been > + atomic context. > + > +- v4l2_event_queue() > + > + Queue events to video device. The driver's only responsibility is to fill > + in the type and the data fields. The other fields will be filled in by > + V4L2. > + > +- v4l2_event_subscribe() > + > + The video_device->ioctl_ops->vidioc_subscribe_event must check the driver > + is able to produce events with specified event id. Then it calls > + v4l2_event_subscribe() to subscribe the event. > + > +- v4l2_event_unsubscribe() > + > + vidioc_unsubscribe_event in struct v4l2_ioctl_ops. A driver may use > + v4l2_event_unsubscribe() directly unless it wants to be involved in > + unsubscription process. > + > + The special type V4L2_EVENT_ALL may be used to unsubscribe all events. The > + drivers may want to handle this in a special way. > + > +- v4l2_event_pending() > + > + Returns the number of pending events. Useful when implementing poll. > + > +Drivers do not initialise events directly. The events are initialised > +through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is > +non-NULL. This *MUST* be performed in the driver's > +v4l2_file_operations->open() handler. > + > +Events are delivered to user space through the poll system call. The driver > +can use v4l2_fh->events->wait wait_queue_head_t as the argument for > +poll_wait(). > + > +There are standard and private events. New standard events must use the > +smallest available event type. The drivers must allocate their events > +starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) + 1. > + > +An example on how the V4L2 events may be used can be found in the OMAP > +3 ISP driver available at http://gitorious.org/omap3camera> as of > +writing this. -- ~Rand
Re: Chroma gain configuration
Andy Walls wrote: > On Sun, 2010-02-21 at 23:07 -0500, Devin Heitmueller wrote: >> I am doing some work on the saa711x driver, and ran into a case where >> I need to disable the chroma AGC and manually set the chroma gain. > > Sakari, Hans, or anyone else, Hi Andy, > On a somewhat related note, what is the status of the media controller > and of file handles per v4l2_subdev. Will Sakari's V4L file-handle > changes be all we need for the infrastructure or is there more to be > done after that? There are three things: - V4L2 file handles (and events) - V4L2 subdev device nodes - Media controller The file handles and events appear to be fairly ready. > I'd like to implement specific "technician controls", something an > average user wouldn't use, for a few subdevs. For that you'd need at least V4L2 subdev device nodes, preferrably also Media controller e.g. for the user space to know the two devices indeed are connected to the same higher level device. File handles do not matter here; it's just a generic way to store file handle specific data, required by events, for example. Subdev device nodes and Media controller patches live in Laurent's tree at linuxtv.org at the moment. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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 6/6] V4L: Events: Add documentation
Hans Verkuil wrote: > On Monday 22 February 2010 23:47:49 Sakari Ailus wrote: +Drivers do not initialise events directly. The events are initialised +through v4l2_fh_init() if video_device->ioctl_ops->vidioc_subscribe_event is +non-NULL. This *MUST* be performed in the driver's +v4l2_file_operations->open() handler. + +Events are delivered to user space through the poll system call. The driver +can use v4l2_fh->events->wait wait_queue_head_t as the argument for +poll_wait(). + +There are standard and private events. New standard events must use the +smallest available event type. The drivers must allocate their events +starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) while individual +events start from base + 1. >>> >>> What do you mean with 'while individual events start from base + 1'? I still >>> don't understand that phrase. >> >> Will be "There are standard and private events. New standard events must >> use the smallest available event type. The drivers must allocate their >> events starting from base (V4L2_EVENT_PRIVATE_START + n * 1024) + 1." in >> the next one. > > Ah, OK. But why '+ 1'? I don't really see a reason for that to be honest. > Am I missing something? Many V4L2 control classes do that. No other reason really. :-) Can be removed on my behalf. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
eb1a:2860 eMPIA em28xx device to usb1 ??? usb hub problem?
Hi I get trouble with my Kworld em28xx device, anyone can help any kernel issue found somewhere about that? Bus 001 Device 005: ID eb1a:2860 eMPIA Technology, Inc. The device seems to go to usb1 hub and its usb2 Using kernel : 2.6.27-7-generic LSUSB Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID eb1a:2860 eMPIA Technology, Inc. Bus 001 Device 004: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 001 Device 003: ID 04d9:1603 Holtek Semiconductor, Inc. Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub DMESG [2.429146] usbcore: registered new interface driver usbfs [2.429164] usbcore: registered new interface driver hub [2.429216] usbcore: registered new device driver usb [2.518153] usb usb1: configuration #1 chosen from 1 choice [2.900018] usb 1-1: new low speed USB device using ohci_hcd and address 2 [2.912659] usb usb2: configuration #1 chosen from 1 choice [3.576015] usb 2-3: new high speed USB device using ehci_hcd and address 4 [4.096019] usb 2-3: device not accepting address 4, error -71 [4.208015] usb 2-3: new high speed USB device using ehci_hcd and address 5 [4.340706] usb 2-3: configuration #1 chosen from 1 choice [4.644571] usb 1-1: new low speed USB device using ohci_hcd and address 3 [4.876163] usb 1-1: configuration #1 chosen from 1 choice [5.180015] usb 1-2: new low speed USB device using ohci_hcd and address 4 [5.393407] usb 1-2: configuration #1 chosen from 1 choice [5.396625] usb 2-3: USB disconnect, address 5 [5.636017] usb 2-3: new high speed USB device using ehci_hcd and address 6 [5.768459] usb 2-3: configuration #1 chosen from 1 choice [5.768794] usbcore: registered new interface driver hiddev [5.772486] usb 2-3: USB disconnect, address 6 [5.781319] input: USB Keyboard as /devices/pci:00/:00:02.0/usb1/1-1/1-1:1.0/input/input1 [5.784136] input,hidraw0: USB HID v1.10 Keyboard [ USB Keyboard] on usb-:00:02.0-1 [5.807105] input: USB Keyboard as /devices/pci:00/:00:02.0/usb1/1-1/1-1:1.1/input/input2 [5.807351] input,hidraw1: USB HID v1.10 Device [ USB Keyboard] on usb-:00:02.0-1 [5.814365] input: Logitech Trackball as /devices/pci:00/:00:02.0/usb1/1-2/1-2:1.0/input/input3 [5.814594] input,hidraw2: USB HID v1.10 Mouse [Logitech Trackball] on usb-:00:02.0-2 [5.814611] usbcore: registered new interface driver usbhid [5.814614] usbhid: v2.6:USB HID core driver [6.048518] usb 2-3: new high speed USB device using ehci_hcd and address 7 [6.568017] usb 2-3: device not accepting address 7, error -71 [6.680026] usb 2-3: new high speed USB device using ehci_hcd and address 8 [7.192521] usb 1-3: new full speed USB device using ohci_hcd and address 5 [7.393043] usb 1-3: not running at top speed; connect to a high speed hub [7.399169] usb 1-3: configuration #1 chosen from 1 choice [ 13.927208] em28xx Doesn't have usb audio class [ 14.934118] input: em28xx snapshot button as /devices/pci:00/:00:02.0/usb1/1-3/input/input7 [ 16.785083] usbcore: registered new interface driver em28xx [ 16.909506] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 18.609828] usbcore: usbfs: unrecognised mount option "default" or missing value [ 18.609834] usbcore: usbfs: mount parameter error: LSPCI 00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) 00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) 00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1) 00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2) 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) 00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) 00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) 00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) 00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) 00:0d.0 VGA compatible controller: nVidia Corporation GeForce 6150SE nForce 430 (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:07.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] (rev 86) -- This message has been verified by LastSpam (http://www.lastspam.com) eMail security service,
Re: [ANNOUNCE] git tree repositories & libv4l
On Monday 22 February 2010 23:54:26 Brandon Philips wrote: > On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: > > >lib/ > > > libv4l1/ > > > libv4l2/ > > > libv4lconvert/ > > >utils/ > > > v4l2-dbg > > > v4l2-ctl > > > cx18-ctl > > > ivtv-ctl > > >contrib/ > > > test/ > > > everything else > > > > > git clone git://ifup.org/philips/create-v4l-utils.git > cd create-v4l-utils/ > ./convert.sh > > You should now have v4l-utils.git which should have this directory > struture. If we need to move other things around let me know and I can > tweak name-filter.sh > > Thoughts? Let me know how we should proceed with dropping v4l2-apps > from v4l-dvb. > > Re: code style cleanup. I think we should do that once we drop > v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was merged into dvb-apps, but while that tool supports dvb, it also supports v4l2. Just like we merged dvb and v4l in a single repository, so I think we should also merge the tools to a media-utils repository. It remains a fact of life that dvb and v4l are connected and trying to artificially keep them apart does not make much sense to me. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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:v4l-dvb/master] V4L/DVB: uvcvideo: Clamp control values to the minimum and maximum values
Laurent Pinchart wrote: > Hi Mauro, > > On Monday 22 February 2010 22:14:19 Patch from Laurent Pinchart wrote: >> From: Laurent Pinchart >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=utf-8 >> Content-Transfer-Encoding: 8bit > > There's a problem somewhere. It seems to be only at the git post-update script I wrote, since the commit is sane: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=a8677cd5589be9e35ef5117f75e4b996724102fb What's weird is that the script doesn't add any mime/utf stuff. It just fills the usual from/to/date/subject/cc fields, and calls sendmail. Maybe sendmail didn't like having a non-7-bits CC. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories & libv4l
Brandon Philips wrote: > On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote: >> On Monday 22 February 2010 23:54:26 Brandon Philips wrote: >>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote: > lib/ > libv4l1/ > libv4l2/ > libv4lconvert/ > utils/ > v4l2-dbg > v4l2-ctl > cx18-ctl > ivtv-ctl > contrib/ > test/ > everything else > >>> git clone git://ifup.org/philips/create-v4l-utils.git >>> cd create-v4l-utils/ >>> ./convert.sh >>> >>> You should now have v4l-utils.git which should have this directory >>> struture. If we need to move other things around let me know and I can >>> tweak name-filter.sh >>> >>> Thoughts? Let me know how we should proceed with dropping v4l2-apps >>> from v4l-dvb. >>> >>> Re: code style cleanup. I think we should do that once we drop >>> v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream. >> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was >> merged into dvb-apps, but while that tool supports dvb, it also supports >> v4l2. Just like we merged dvb and v4l in a single repository, so I think we >> should also merge the tools to a media-utils repository. >> >> It remains a fact of life that dvb and v4l are connected and trying to >> artificially keep them apart does not make much sense to me. > > Easy to do but who should be the maintainer of the dvb things? > > According to the wiki[1] these tools are without a maintainer. So, if > no one cares about them enough to make releases why merge them and > clutter up the git tree with dead code? > > Cheers, > > Brandon > > [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps That's weird. I've recently added support for ISDB-T on it: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ and we've got some comments at the mailing list. Btw, the patches I added there also adds DVB-S2 support to szap/scan, but tests are needed, since I don't have any satellite dish nowadays. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories & libv4l
Mauro Carvalho Chehab wrote: >> According to the wiki[1] these tools are without a maintainer. So, if >> no one cares about them enough to make releases why merge them and >> clutter up the git tree with dead code? >> >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps > > That's weird. I've recently added support for ISDB-T on it: > http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ > > and we've got some comments at the mailing list. Btw, the patches > I added there also adds DVB-S2 support to szap/scan, but tests > are needed, since I don't have any satellite dish nowadays. > Hmm... this got changed on Jun, 2009: http://www.linuxtv.org/wiki/index.php?title=LinuxTV_dvb-apps&diff=prev&oldid=23404 Let me comment the "TODO" list: * Start numbering the versions. Yes, with a repo every commit is a kind of version, but in the real world of distros and end users you need to define version numbers as easy reference points. * Tag versioned releases and make src tarballs for the distros. By merging with v4l2-apps, those to will be easily handled. * Add ChangeLog and TODO files (and keep them up to date of course). ChangeLog? Git history is better than it. A TODO file is useful only when there are missing features. * Review the names of the apps and change where necessary. Perhaps scan is too ambiguous a name in a general-purpose system where all sorts of things can be scanned (with scanners, fax machines, barcode readers, etc.). I agree. All distros I know renamed scan to dvbscan. This is a trivial patch through. * Implement API version 5 scanning and zapping for DVB-S2 channels. See S2API, scan-s2 and szap-s2. It is done on my tree: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/ I still need to review Manu's comments on it. My intention is to do it after the next merge window. Also, there are some DVB-S2 parameters that aren't present at the channels.conf format. Nothing more complex than adding printf/scanf lines on some files. * Improve the channels.conf file format so that one file can represent all the channels. Need to o (a) identify the source (S13.0E, S19.2E, Terrestrial, etc) o (b) identify the delivery system (DVB-S, DVB-S2, DVB-T etc) o (c) be able to represent all the parameters required for all the delivery systems in a unified way. For example DVB-S2 has some new paramters (e.g. rolloff). The "VDR" format was expanded for this, but in a messy way. * Make sure there is one true format -- no "zap" versus "VDR" format confusion. * Merge all the *zap programs. You unified the channels.conf file so this is next. Changing the channels.conf format is easy. I had to do it for ISDB-T. The hard part is that channels.conf is used on several DTV applications (mplayer, VDR, kaffeine, ...). So, any format change will require changes on all applications that use channels.conf. This will be needed anyway, in order to add all features that are present on DVB-S2, and to add ISDB-T format to the players. So, maybe someone can propose a "version 3" format (assuming that VDR and ZAP are versions 1 and 2) that will be used by all applications. That's said, if all the issues are the ones listed above, I can try to address them on the next months, to put it into a better shape. That's said, I don't think we should have a single maintainer for it: there are too many DTV standards already, and probably nobody with enough time has access to all of those (DVB-T, DVB-T2, DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...). So, I think we need a team of volunteers that will try to help with the standards they have access. For the channels/transponders list, Christopher (kaffeine maintainer) is doing a really great job. Maybe he could help with the last TODO items (e. g. helping to define the better format for the channels.conf output). That's said, I'm starting to agree with Hans: maybe the better seems to merge it with v4l2-apps, to get synergy in terms, at least in terms of packet management. Comments? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
