Re: Can you review or ack this patch?
On Tue, Aug 23, 2011 at 08:33:25AM +0200, Hans Verkuil wrote: > (and resent again, this time with the correct linux-fsdevel mail address) > (Resent as requested by Andrew Morton since this is still stuck) > > Hi Al, Andrew, > > Can you take a look at this patch and send an Ack or review comments? Not at the moment - I'm half-asleep and tired as hell. Will do in the morning... -- 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
Can you review or ack this patch?
(and resent again, this time with the correct linux-fsdevel mail address)
(Resent as requested by Andrew Morton since this is still stuck)
Hi Al, Andrew,
Can you take a look at this patch and send an Ack or review comments?
It's already been reviewed by Jon Corbet and we really need this functionality
for v3.1. You were in the CC list in earlier postings:
Here: http://www.spinics.net/lists/linux-fsdevel/msg46753.html
and here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg34546.html
The patch also featured on LWN: http://lwn.net/Articles/450658/
Without your ack Mauro can't upstream this and we have a number of other
patches that depend on this and are currently blocked.
We would prefer to upstream this patch through the linux-media git tree
due to these dependencies.
My git branch containing this and the dependent patches is here:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/poll
Your help would be greatly appreciated (and your ack even more :-) )!
Regards,
Hans
[PATCH] poll: add poll_requested_events() function
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil
Reviewed-by: Jonathan Corbet
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(&pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &
+ pt.key = epi->event.events;
+ if (epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
epi->event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event->events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NULL);
/*
* Set the new event interest mask before calling f_op->poll();
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = pt.key = event->events;
epi->event.data = event->data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL);
+ revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt);
/*
* If the item is "hot" and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NU
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Monday, August 22, 2011 19:21:18 Laurent Pinchart wrote: > Hi Hans, > > On Monday 22 August 2011 17:52:12 Hans Verkuil wrote: > > On Monday, August 22, 2011 17:42:36 Laurent Pinchart wrote: > > > On Monday 22 August 2011 15:54:03 Guennadi Liakhovetski wrote: > > > > We discussed a bit more with Hans on IRC, and below is my attempt of a > > > > summary. Hans, please, correct me, if I misunderstood anything. Pawel, > > > > Sakari, Laurent: please, reply, whether you're ok with this. > > > > > > Sakari is on holidays this week. > > > > > > > On Mon, 22 Aug 2011, Hans Verkuil wrote: > > > > > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: > > > > [snip] > > > > > > > > > > It would be good if you also could have a look at my reply to this > > > > > > Pawel's mail: > > > > > > > > > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > > > > > > > > > > infrastructure/36905 > > > > > > > > > > > and, specifically, at the vb2_parse_planes() function in it. That's > > > > > > my understanding of what would be needed, if we preserve > > > > > > .queue_setup() and use your last suggestion to include struct > > > > > > v4l2_format in struct v4l2_create_buffers. > > > > > > > > > > vb2_parse_planes can be useful as a utility function that 'normal' > > > > > drivers can call from the queue_setup. But vb2 should not parse the > > > > > format directly, it should just pass it on to the driver through the > > > > > queue_setup function. > > > > > > > > > > You also mention: "All frame-format fields like fourcc code, width, > > > > > height, colorspace are only input from the user. If the user didn't > > > > > fill them in, they should not be used." > > > > > > > > > > I disagree with that. The user should fill in a full format > > > > > description, just as with S/TRY_FMT. That's the information that the > > > > > driver will use to set up the buffers. It could have weird rules > > > > > like: if the fourcc is this, and the size is less than that, then we > > > > > can allocate in this memory bank. > > > > > > > > > > It is also consistent with REQBUFS: there too the driver uses a full > > > > > format (i.e. the last set format). > > > > > > > > > > I would modify queue_setup to something like this: > > > > > > > > > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > > > > > > > > > > unsigned int *num_buffers, > > > > > unsigned int *num_planes, unsigned int sizes[], > > > > > void *alloc_ctxs[]); > > > > > > > > > > Whether fmt is left to NULL in the reqbufs case, or whether the > > > > > driver has to call g_fmt first before calling vb2 is something that > > > > > could be decided by what is easiest to implement. > > > > > > > > 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user > > > > to > > > > > > > >the kernel, in which struct v4l2_format is embedded. The user _must_ > > > >fill in .type member of struct v4l2_format. For .type == > > > >V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix > > > >is used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or > > > >V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these > > > >cases the user _must_ fill in .width, .height, .pixelformat, .field, > > > >.colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The > > > >user also _may_ optionally fill in any further buffer-size related > > > >fields, if it believes to have any special requirements to them. On > > > >a successful return from the ioctl() .count and .index fields are > > > >filled in by the kernel, .format stays unchanged. The user has to > > > >call VIDIOC_QUERYBUF to retrieve specific buffer information. > > > > > > > > 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, > > > > call > > > > > > > >vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a > > > >second argument. vb2_create_bufs() in turn calls the .queue_setup() > > > > > > > >driver callback, whose prototype is modified as follows: > > > > int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, > > > > > > > > unsigned int *num_buffers, > > > > unsigned int *num_planes, unsigned int sizes[], > > > > void *alloc_ctxs[]); > > > > > > > >with &create->format as a second argument. As pointed out above, > > > >this struct is not modified by V4L, instead, the usual arguments > > > >3-6 are filled in by the driver, which are then used by > > > >vb2_create_bufs() to call __vb2_queue_alloc(). > > > > > > > > 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will > > > > be > > > > > > > >a signal to the driver to use the current format. > > > > > > > > 4. We keep .queue_setup(), because its removal would inevitably push a >
Can you review or ack this patch?
(Resent as requested by Andrew Morton since this is still stuck)
Hi Al, Andrew,
Can you take a look at this patch and send an Ack or review comments?
It's already been reviewed by Jon Corbet and we really need this functionality
for v3.1. You were in the CC list in earlier postings:
Here: http://www.spinics.net/lists/linux-fsdevel/msg46753.html
and here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg34546.html
The patch also featured on LWN: http://lwn.net/Articles/450658/
Without your ack Mauro can't upstream this and we have a number of other
patches that depend on this and are currently blocked.
We would prefer to upstream this patch through the linux-media git tree
due to these dependencies.
My git branch containing this and the dependent patches is here:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/poll
Your help would be greatly appreciated (and your ack even more :-) )!
Regards,
Hans
[PATCH] poll: add poll_requested_events() function
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil
Reviewed-by: Jonathan Corbet
---
fs/eventpoll.c | 19 +++
fs/select.c | 38 +-
include/linux/poll.h |7 ++-
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(&pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi->ffd.file->f_op->poll(epi->ffd.file, NULL) &
+ pt.key = epi->event.events;
+ if (epi->ffd.file->f_op->poll(epi->ffd.file, &pt) &
epi->event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event->events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NULL);
/*
* Set the new event interest mask before calling f_op->poll();
* otherwise we might miss an event that happens between the
* f_op->poll() call and the new event set registering.
*/
- epi->event.events = event->events;
+ epi->event.events = pt.key = event->events;
epi->event.data = event->data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL);
+ revents = epi->ffd.file->f_op->poll(epi->ffd.file, &pt);
/*
* If the item is "hot" and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(&pt, NULL);
/*
* We can loop without lock because we are passe
Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
Hi Laurent and Michael, On 22/08/11 22:15, Michael Jones wrote: I am trying to get the mt9p031 working from nand with a ubifs file system and I am having a few problems. /dev/media0 is not present unless I run: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 #media-ctl -p Enumerating entities media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) With the same rig/files it works fine running from EXT4 on an SD card. Any idea why this does not work on nand with ubifs? Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? Check the kernel log for OMAP3 ISP-related messages. Here is the version running from SD card: # dmesg | grep isp [0.265502] omap-iommu omap-iommu.0: isp registered [2.986541] omap3isp omap3isp: Revision 2.0 found [2.991577] omap-iommu omap-iommu.0: isp: version 1.1 [2.997406] omap3isp omap3isp: hist: DMA channel = 0 [3.006256] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.011932] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz From NAND using UBIFS: # dmesg | grep isp [3.457061] omap3isp omap3isp: Revision 2.0 found [3.462036] omap-iommu omap-iommu.0: isp: version 1.1 [3.467620] omap3isp omap3isp: hist: DMA channel = 0 [3.472564] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 2160 Hz [3.478027] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz Seems to be missing: omap-iommu omap-iommu.0: isp registered Is that the issue? Why would this not work when running from NAND? I'm not sure, either, but I had a similar problem before using Laurent's patch below. IIRC, usually udev would create /dev/media0 from a cached list of /dev/*. Later modutils would come along and load the modules in the proper order (iommu, then omap3-isp) and everybody was happy. Occasionally, udev would fail to use the cached version of /dev/, and look through /sys/devices to re-create the devices in /dev/. When media0 was found, omap3-isp.ko would be loaded, but iommu had not yet been, presumably because it doesn't have an entry in /sys/devices/. So maybe udev is behaving differently for you on NAND than it did on the card? Either way, as I said, using Laurent's patch below did the job for me. -Michael I'm not sure why it doesn't work from NAND, but the iommu2 module needs to be loaded before the omap3-isp module. Alternatively you can compile the iommu2 module in the kernel with diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 49a4c75..3c87644 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -132,7 +132,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + bool config OMAP_IOMMU_DEBUG tristate "Export OMAP IOMMU internals in DebugFS" Thanks for the help! For some reason dmesg does not read early kernel stuff when in UBIFS from NAND. So when I went back and had a look the line I thought was not there is actually included. [0.276977] omap-iommu omap-iommu.0: isp registered So I guess everything is loading fine. I tried the patch and it didn't make a difference. Regarding what Michael said /dev/media0 is not created by udev when boot from NAND. I tried creating it manually with: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 But this does not work - outputs: # media-ctl -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) So is there a problem with udev? Cheers, Chris -- 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: Afatech AF9013
Damn, this patch didn't help so maybe forget this patch. Tuner A is still messed up. -- 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: Afatech AF9013
I might have found one bug so far with the Afa9013 driver. As part of refactoring the code in http://git.linuxtv.org/linux-2.6.git/commitdiff/edb709b61abd3ba475e59d1ad81aab21ad025db6 I think one of the u32->u8 calculations is wrong. The think the second last u32 in the tables has to be changed. Here is the diff. I will try it later as I have run out of time to test it this morning. This may not fix the problems we are having but it might help... So patch the file af9013_priv.h with this in the latest git media_build and see what happens. I'll report back later with my results. af9013_priv.h.diff -- 74c74 < 0x29, 0x03, 0x5d, 0x7a, 0xec, 0x01, 0x45, 0x14, 0x14 } }, --- > 0x29, 0x00, 0xa2, 0x85, 0x14, 0x01, 0x45, 0x14, 0x14 } }, 77c77 < 0xe4, 0x03, 0x71, 0xcb, 0xe8, 0x01, 0x1c, 0x71, 0x32 } }, --- > 0xe4, 0x00, 0x8e, 0x34, 0x72, 0x01, 0x1c, 0x71, 0x32 } }, 80c80 < 0x9e, 0x03, 0x86, 0x1c, 0x31, 0x00, 0xf3, 0xcf, 0x0f } }, --- > 0x9e, 0x00, 0x79, 0xe3, 0xcf, 0x00, 0xf3, 0xcf, 0x0f } }, 84c84 < 0x49, 0x03, 0x1b, 0x74, 0xdb, 0x01, 0xc9, 0x24, 0x25 } }, --- > 0x49, 0x00, 0xe4, 0x8b, 0x25, 0x01, 0xc9, 0x24, 0x25 } }, 87c87 < 0x00, 0x03, 0x38, 0x06, 0x40, 0x01, 0x90, 0x00, 0x00 } }, --- > 0x00, 0x00, 0xc7, 0xf9, 0xc0, 0x01, 0x90, 0x00, 0x00 } }, 90c90 < 0xb7, 0x03, 0x54, 0x97, 0xa4, 0x01, 0x56, 0xdb, 0x1c } }, --- > 0xb7, 0x00, 0xab, 0x68, 0x5c, 0x01, 0x56, 0xdb, 0x1c } }, 94c94 < 0x05, 0x03, 0x58, 0xd6, 0x34, 0x01, 0x4e, 0x5e, 0x03 } }, --- > 0x05, 0x00, 0xa7, 0x29, 0xcc, 0x01, 0x4e, 0x5e, 0x03 } }, 97c97 < 0x25, 0x03, 0x6d, 0xbb, 0x6e, 0x01, 0x24, 0x92, 0x12 } }, --- > 0x25, 0x00, 0x92, 0x44, 0x92, 0x01, 0x24, 0x92, 0x12 } }, 100c100 < 0x44, 0x03, 0x82, 0xa0, 0xa7, 0x00, 0xfa, 0xc6, 0x22 } }, --- > 0x44, 0x00, 0x7d, 0x5f, 0x59, 0x00, 0xfa, 0xc6, 0x22 } }, 104c104 < 0xe7, 0x03, 0x44, 0xc6, 0xf3, 0x01, 0x76, 0x7d, 0x34 } }, --- > 0xe7, 0x00, 0xbb, 0x39, 0x0d, 0x01, 0x76, 0x7d, 0x34 } }, 107c107 < 0x0a, 0x03, 0x5c, 0x2e, 0x14, 0x01, 0x47, 0xae, 0x05 } }, --- > 0x0a, 0x00, 0xa3, 0xd1, 0xec, 0x01, 0x47, 0xae, 0x05 } }, 110c110 < 0x2d, 0x03, 0x73, 0x95, 0x36, 0x01, 0x18, 0xde, 0x17 } }, --- > 0x2d, 0x00, 0x8c, 0x6a, 0xca, 0x01, 0x18, 0xde, 0x17 } }, -- 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] gspca_sn9c20x: device 0c45:62b3: fix status LED
Ping ... what happened to this patch ? ;-)
Am 01.07.2011 12:19, schrieb Frank Schaefer:
gspca_sn9c20x: device 0c45:62b3: fix status LED
Tested with webcam "SilverCrest WC2130".
Signed-off-by: Frank Schaefer
Cc: sta...@kernel.org
---
drivers/media/video/gspca/sn9c20x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/sn9c20x.c
b/drivers/media/video/gspca/sn9c20x.c
index c431900..af9cd50 100644
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -2513,7 +2513,7 @@ static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x0c45, 0x628f), SN9C20X(OV9650, 0x30, 0)},
{USB_DEVICE(0x0c45, 0x62a0), SN9C20X(OV7670, 0x21, 0)},
{USB_DEVICE(0x0c45, 0x62b0), SN9C20X(MT9VPRB, 0x00, 0)},
- {USB_DEVICE(0x0c45, 0x62b3), SN9C20X(OV9655, 0x30, 0)},
+ {USB_DEVICE(0x0c45, 0x62b3), SN9C20X(OV9655, 0x30, LED_REVERSE)},
{USB_DEVICE(0x0c45, 0x62bb), SN9C20X(OV7660, 0x21, LED_REVERSE)},
{USB_DEVICE(0x0c45, 0x62bc), SN9C20X(HV7131R, 0x11, 0)},
{USB_DEVICE(0x045e, 0x00f4), SN9C20X(OV9650, 0x30, 0)},
--
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
Wiki update
So it seemes like MediaWiki-1.14.1 is somewhat broken with PHP-5.3.3 and there have been issues with both the VDR and V4L-DVB Wikis. Thus I've updated MediaWiki to 1.16.5, and full functionality seems to be restored. Please let me know if there are still any issues. Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
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 Aug 22 19:00:32 CEST 2011 git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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
[PATCH] Fix to qt1010 tuner frequency selection (media/dvb), resend as text-only
The patch fixes frequency selection for some UHF frequencies e.g.
channel 32 (562 MHz) on the qt1010 tuner. The tuner is used e.g. in the
MSI Mega Sky dvb-t stick ("MSI Mega Sky 55801 DVB-T USB2.0")
One example of problem reports of the bug this fixes can be read at
http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb
Applies to kernel versions 2.6.38.8, 2.6.39.4, 3.0.3 and 3.1-rc2.
Signed-off-by: Jyrki Kuoppala
diff -upr linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c
linux-source-2.6.38/drivers/media/common/tuners/qt1010.c
--- linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c
2011-03-15 03:20:32.0 +0200
+++ linux-source-2.6.38/drivers/media/common/tuners/qt1010.c 2011-08-21
23:16:38.209580365 +0300
@@ -198,9 +198,10 @@ static int qt1010_set_params(struct dvb_
/* 22 */
if (freq < 45000) rd[15].val = 0xd0; /* 450 MHz */
- else if (freq < 48200) rd[15].val = 0xd1; /* 482 MHz */
+ else if (freq < 48200) rd[15].val = 0xd2; /* 482 MHz */
else if (freq < 51400) rd[15].val = 0xd4; /* 514 MHz */
- else if (freq < 54600) rd[15].val = 0xd7; /* 546 MHz */
+ else if (freq < 54600) rd[15].val = 0xd6; /* 546 MHz */
+ else if (freq < 57800) rd[15].val = 0xd8; /* 578 MHz */
else if (freq < 61000) rd[15].val = 0xda; /* 610 MHz */
else rd[15].val = 0xd0;
--
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 14/14] [media] gspca: Use current logging styles
On Mon, 22 Aug 2011 08:20:28 -0700 Joe Perches wrote: > The primary current advantage is style standardization > both in code and dmesg output. > > Future changes to printk.h will reduce object sizes > by centralizing the prefix to a singleton and > emitting it only in pr_. Hi Joe, OK, I did not see that you started such changes a long time ago! Thanks and good luck! Acked-by: Jean-Francois Moine -- 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
Lockdep warning in ivtv driver in 3.1
Hi All,
We've gotten a report[1] that the ivtv driver is throwing a lockdep
warning when calling ivtv_gpio_init. From what I can tell, it seems
like the lock being held twice is the one allocated for ivtv->cxhdl, but
I can't immediately see where it's locked and not unlocked in the
callstack path.
Does anyone have an idea where this could be happening?
[ 28.556610] =
[ 28.557007] [ INFO: possible recursive locking detected ]
[ 28.557007] 3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[ 28.557007] -
[ 28.557007] modprobe/684 is trying to acquire lock:
[ 28.557007] (&hdl->lock){+.+...}, at: []
find_ref_lock+0x24/0x46 [videodev]
[ 28.557007]
[ 28.557007] but task is already holding lock:
[ 28.557007] (&hdl->lock){+.+...}, at: []
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[ 28.557007]
[ 28.557007] other info that might help us debug this:
[ 28.557007] Possible unsafe locking scenario:
[ 28.557007]
[ 28.557007]CPU0
[ 28.557007]
[ 28.557007] lock(&hdl->lock);
[ 28.557007] lock(&hdl->lock);
[ 28.557007]
[ 28.557007] *** DEADLOCK ***
[ 28.557007]
[ 28.557007] May be due to missing lock nesting notation
[ 28.557007]
[ 28.557007] 3 locks held by modprobe/684:
[ 28.557007] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x3b/0x82
[ 28.557007] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x49/0x82
[ 28.557007] #2: (&hdl->lock){+.+...}, at: []
v4l2_ctrl_add_handler+0x49/0x97 [videodev]
[ 28.557007]
[ 28.557007] stack backtrace:
[ 28.557007] Pid: 684, comm: modprobe Not tainted
3.1.0-0.rc0.git19.1.fc17.x86_64 #1
[ 28.557007] Call Trace:
[ 28.557007] [] __lock_acquire+0x917/0xcf7
[ 28.557007] [] ? sched_clock+0x9/0xd
[ 28.557007] [] ? mark_lock+0x2d/0x220
[ 28.557007] [] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.557007] [] lock_acquire+0xf3/0x13e
[ 28.584886] [] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [] __mutex_lock_common+0x5d/0x39a
[ 28.585146] [] ? find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [] ? mark_held_locks+0x6d/0x95
[ 28.585146] [] ? __mutex_lock_common+0x369/0x39a
[ 28.585146] [] ? trace_hardirqs_on_caller+0x12d/0x164
[ 28.585146] [] mutex_lock_nested+0x40/0x45
[ 28.585146] [] find_ref_lock+0x24/0x46 [videodev]
[ 28.585146] [] handler_new_ref+0x42/0x18a [videodev]
[ 28.585146] [] v4l2_ctrl_add_handler+0x6d/0x97 [videodev]
[ 28.585146] [] v4l2_device_register_subdev+0x16c/0x257
[videodev]
[ 28.585146] [] ivtv_gpio_init+0x14e/0x159 [ivtv]
[ 28.585146] [] ivtv_probe+0xdc4/0x1662 [ivtv]
[ 28.585146] [] ? mark_held_locks+0x55/0x95
[ 28.585146] [] ? _raw_spin_unlock_irqrestore+0x4d/0x61
[ 28.585146] [] local_pci_probe+0x44/0x75
[ 28.585146] [] pci_device_probe+0xd0/0xff
[ 28.585146] [] driver_probe_device+0x131/0x213
[ 28.585146] [] __driver_attach+0x5e/0x82
[ 28.585146] [] ? driver_probe_device+0x213/0x213
[ 28.585146] [] bus_for_each_dev+0x59/0x8f
[ 28.585146] [] driver_attach+0x1e/0x20
[ 28.585146] [] bus_add_driver+0xd4/0x22a
[ 28.585146] [] ? 0xa02fefff
[ 28.585146] [] driver_register+0x98/0x105
[ 28.618302] [] ? 0xa02fefff
[ 28.618302] [] __pci_register_driver+0x66/0xd2
[ 28.618302] [] ? 0xa02fefff
[ 28.618302] [] module_start+0x78/0x1000 [ivtv]
[ 28.618302] [] do_one_initcall+0x7f/0x13a
[ 28.618302] [] ? 0xa02fefff
[ 28.618302] [] sys_init_module+0x114/0x267
[ 28.618302] [] system_call_fastpath+0x16/0x1b
josh
[1] https://bugzilla.redhat.com/show_bug.cgi?id=728316
--
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 to qt1010 tuner frequency selection (media/dvb)
The patch fixes frequency selection for some UHF frequencies e.g.
channel 32 (562 MHz) on the qt1010 tuner. The tuner is used e.g. in the
MSI Mega Sky dvb-t stick ("MSI Mega Sky 55801 DVB-T USB2.0")
One example of problem reports of the bug this fixes can be read at
http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb
Applies to kernel versions 2.6.38.8, 2.6.39.4, 3.0.3 and 3.1-rc2.
Signed-off-by: Jyrki Kuoppala
diff -upr linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c
linux-source-2.6.38/drivers/media/common/tuners/qt1010.c
--- linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c
2011-03-15 03:20:32.0 +0200
+++ linux-source-2.6.38/drivers/media/common/tuners/qt1010.c
2011-08-21 23:16:38.209580365 +0300
@@ -198,9 +198,10 @@ static int qt1010_set_params(struct dvb_
/* 22 */
if (freq < 45000) rd[15].val = 0xd0; /* 450 MHz */
-else if (freq < 48200) rd[15].val = 0xd1; /* 482 MHz */
+else if (freq < 48200) rd[15].val = 0xd2; /* 482 MHz */
else if (freq < 51400) rd[15].val = 0xd4; /* 514 MHz */
-else if (freq < 54600) rd[15].val = 0xd7; /* 546 MHz */
+else if (freq < 54600) rd[15].val = 0xd6; /* 546 MHz */
+else if (freq < 57800) rd[15].val = 0xd8; /* 578 MHz */
else if (freq < 61000) rd[15].val = 0xda; /* 610 MHz */
else rd[15].val = 0xd0;
--
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 v4] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Hans, On Monday 22 August 2011 17:52:12 Hans Verkuil wrote: > On Monday, August 22, 2011 17:42:36 Laurent Pinchart wrote: > > On Monday 22 August 2011 15:54:03 Guennadi Liakhovetski wrote: > > > We discussed a bit more with Hans on IRC, and below is my attempt of a > > > summary. Hans, please, correct me, if I misunderstood anything. Pawel, > > > Sakari, Laurent: please, reply, whether you're ok with this. > > > > Sakari is on holidays this week. > > > > > On Mon, 22 Aug 2011, Hans Verkuil wrote: > > > > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: > > > [snip] > > > > > > > > It would be good if you also could have a look at my reply to this > > > > > Pawel's mail: > > > > > > > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > > > > > > > > infrastructure/36905 > > > > > > > > > and, specifically, at the vb2_parse_planes() function in it. That's > > > > > my understanding of what would be needed, if we preserve > > > > > .queue_setup() and use your last suggestion to include struct > > > > > v4l2_format in struct v4l2_create_buffers. > > > > > > > > vb2_parse_planes can be useful as a utility function that 'normal' > > > > drivers can call from the queue_setup. But vb2 should not parse the > > > > format directly, it should just pass it on to the driver through the > > > > queue_setup function. > > > > > > > > You also mention: "All frame-format fields like fourcc code, width, > > > > height, colorspace are only input from the user. If the user didn't > > > > fill them in, they should not be used." > > > > > > > > I disagree with that. The user should fill in a full format > > > > description, just as with S/TRY_FMT. That's the information that the > > > > driver will use to set up the buffers. It could have weird rules > > > > like: if the fourcc is this, and the size is less than that, then we > > > > can allocate in this memory bank. > > > > > > > > It is also consistent with REQBUFS: there too the driver uses a full > > > > format (i.e. the last set format). > > > > > > > > I would modify queue_setup to something like this: > > > > > > > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > > > > > > > > unsigned int *num_buffers, > > > > unsigned int *num_planes, unsigned int sizes[], > > > > void *alloc_ctxs[]); > > > > > > > > Whether fmt is left to NULL in the reqbufs case, or whether the > > > > driver has to call g_fmt first before calling vb2 is something that > > > > could be decided by what is easiest to implement. > > > > > > 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user > > > to > > > > > >the kernel, in which struct v4l2_format is embedded. The user _must_ > > >fill in .type member of struct v4l2_format. For .type == > > >V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix > > >is used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or > > >V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these > > >cases the user _must_ fill in .width, .height, .pixelformat, .field, > > >.colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The > > >user also _may_ optionally fill in any further buffer-size related > > >fields, if it believes to have any special requirements to them. On > > >a successful return from the ioctl() .count and .index fields are > > >filled in by the kernel, .format stays unchanged. The user has to > > >call VIDIOC_QUERYBUF to retrieve specific buffer information. > > > > > > 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, > > > call > > > > > >vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a > > >second argument. vb2_create_bufs() in turn calls the .queue_setup() > > > > > >driver callback, whose prototype is modified as follows: > > > int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, > > > > > > unsigned int *num_buffers, > > > unsigned int *num_planes, unsigned int sizes[], > > > void *alloc_ctxs[]); > > > > > >with &create->format as a second argument. As pointed out above, > > >this struct is not modified by V4L, instead, the usual arguments > > >3-6 are filled in by the driver, which are then used by > > >vb2_create_bufs() to call __vb2_queue_alloc(). > > > > > > 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will > > > be > > > > > >a signal to the driver to use the current format. > > > > > > 4. We keep .queue_setup(), because its removal would inevitably push a > > > > > >part of the common code from vb2_reqbufs() and vb2_create_bufs() > > >down into drivers, thus creating code redundancy and increasing its > > >complexity. > > > > How much common code would be pushed down to drivers ? I don't think this > > is a real issu
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Monday, August 22, 2011 17:42:36 Laurent Pinchart wrote: > Hi Guennadi, > > On Monday 22 August 2011 15:54:03 Guennadi Liakhovetski wrote: > > We discussed a bit more with Hans on IRC, and below is my attempt of a > > summary. Hans, please, correct me, if I misunderstood anything. Pawel, > > Sakari, Laurent: please, reply, whether you're ok with this. > > Sakari is on holidays this week. > > > On Mon, 22 Aug 2011, Hans Verkuil wrote: > > > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: > > [snip] > > > > > > It would be good if you also could have a look at my reply to this > > > > Pawel's mail: > > > > > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > > > > > > infrastructure/36905 > > > > > > > and, specifically, at the vb2_parse_planes() function in it. That's my > > > > understanding of what would be needed, if we preserve .queue_setup() > > > > and use your last suggestion to include struct v4l2_format in struct > > > > v4l2_create_buffers. > > > > > > vb2_parse_planes can be useful as a utility function that 'normal' > > > drivers can call from the queue_setup. But vb2 should not parse the > > > format directly, it should just pass it on to the driver through the > > > queue_setup function. > > > > > > You also mention: "All frame-format fields like fourcc code, width, > > > height, colorspace are only input from the user. If the user didn't fill > > > them in, they should not be used." > > > > > > I disagree with that. The user should fill in a full format description, > > > just as with S/TRY_FMT. That's the information that the driver will use > > > to set up the buffers. It could have weird rules like: if the fourcc is > > > this, and the size is less than that, then we can allocate in this > > > memory bank. > > > > > > It is also consistent with REQBUFS: there too the driver uses a full > > > format (i.e. the last set format). > > > > > > I would modify queue_setup to something like this: > > > > > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > > > > > > unsigned int *num_buffers, > > > unsigned int *num_planes, unsigned int sizes[], > > > void *alloc_ctxs[]); > > > > > > Whether fmt is left to NULL in the reqbufs case, or whether the driver > > > has to call g_fmt first before calling vb2 is something that could be > > > decided by what is easiest to implement. > > > > 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to > >the kernel, in which struct v4l2_format is embedded. The user _must_ > >fill in .type member of struct v4l2_format. For .type == > >V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is > >used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or > >V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these > >cases the user _must_ fill in .width, .height, .pixelformat, .field, > >.colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The > >user also _may_ optionally fill in any further buffer-size related > >fields, if it believes to have any special requirements to them. On > >a successful return from the ioctl() .count and .index fields are > >filled in by the kernel, .format stays unchanged. The user has to call > >VIDIOC_QUERYBUF to retrieve specific buffer information. > > > > 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call > >vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a > >second argument. vb2_create_bufs() in turn calls the .queue_setup() > >driver callback, whose prototype is modified as follows: > > > > int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, > > unsigned int *num_buffers, > > unsigned int *num_planes, unsigned int sizes[], > > void *alloc_ctxs[]); > > > >with &create->format as a second argument. As pointed out above, this > >struct is not modified by V4L, instead, the usual arguments 3-6 are > >filled in by the driver, which are then used by vb2_create_bufs() to > >call __vb2_queue_alloc(). > > > > 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will be > >a signal to the driver to use the current format. > > > > 4. We keep .queue_setup(), because its removal would inevitably push a > >part of the common code from vb2_reqbufs() and vb2_create_bufs() down > >into drivers, thus creating code redundancy and increasing its > >complexity. > > How much common code would be pushed down to drivers ? I don't think this is > a > real issue. I like Pawel's proposal of removing .queue_setup() better. I still don't see what removing queue_setup will solve or improve. I'd say leave it as it is to keep the diff as small as possible and someone can always attempt to remove it later. Removing queue_setup is independent from multi-s
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Guennadi, On Monday 22 August 2011 15:54:03 Guennadi Liakhovetski wrote: > We discussed a bit more with Hans on IRC, and below is my attempt of a > summary. Hans, please, correct me, if I misunderstood anything. Pawel, > Sakari, Laurent: please, reply, whether you're ok with this. Sakari is on holidays this week. > On Mon, 22 Aug 2011, Hans Verkuil wrote: > > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: > [snip] > > > > It would be good if you also could have a look at my reply to this > > > Pawel's mail: > > > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > > > > infrastructure/36905 > > > > > and, specifically, at the vb2_parse_planes() function in it. That's my > > > understanding of what would be needed, if we preserve .queue_setup() > > > and use your last suggestion to include struct v4l2_format in struct > > > v4l2_create_buffers. > > > > vb2_parse_planes can be useful as a utility function that 'normal' > > drivers can call from the queue_setup. But vb2 should not parse the > > format directly, it should just pass it on to the driver through the > > queue_setup function. > > > > You also mention: "All frame-format fields like fourcc code, width, > > height, colorspace are only input from the user. If the user didn't fill > > them in, they should not be used." > > > > I disagree with that. The user should fill in a full format description, > > just as with S/TRY_FMT. That's the information that the driver will use > > to set up the buffers. It could have weird rules like: if the fourcc is > > this, and the size is less than that, then we can allocate in this > > memory bank. > > > > It is also consistent with REQBUFS: there too the driver uses a full > > format (i.e. the last set format). > > > > I would modify queue_setup to something like this: > > > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > > > > unsigned int *num_buffers, > > unsigned int *num_planes, unsigned int sizes[], > > void *alloc_ctxs[]); > > > > Whether fmt is left to NULL in the reqbufs case, or whether the driver > > has to call g_fmt first before calling vb2 is something that could be > > decided by what is easiest to implement. > > 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to >the kernel, in which struct v4l2_format is embedded. The user _must_ >fill in .type member of struct v4l2_format. For .type == >V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is >used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or >V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these >cases the user _must_ fill in .width, .height, .pixelformat, .field, >.colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The >user also _may_ optionally fill in any further buffer-size related >fields, if it believes to have any special requirements to them. On >a successful return from the ioctl() .count and .index fields are >filled in by the kernel, .format stays unchanged. The user has to call >VIDIOC_QUERYBUF to retrieve specific buffer information. > > 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call >vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a >second argument. vb2_create_bufs() in turn calls the .queue_setup() >driver callback, whose prototype is modified as follows: > > int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, > unsigned int *num_buffers, > unsigned int *num_planes, unsigned int sizes[], > void *alloc_ctxs[]); > >with &create->format as a second argument. As pointed out above, this >struct is not modified by V4L, instead, the usual arguments 3-6 are >filled in by the driver, which are then used by vb2_create_bufs() to >call __vb2_queue_alloc(). > > 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will be >a signal to the driver to use the current format. > > 4. We keep .queue_setup(), because its removal would inevitably push a >part of the common code from vb2_reqbufs() and vb2_create_bufs() down >into drivers, thus creating code redundancy and increasing its >complexity. How much common code would be pushed down to drivers ? I don't think this is a real issue. I like Pawel's proposal of removing .queue_setup() better. > You have 24 hours to object, before I proceed with the next version;-) -- 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] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
On Mon, Aug 22, 2011 at 01:17:16AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Saturday 20 August 2011 07:26:17 Sakari Ailus wrote:
> > Hi Laurent,
> >
> > Thanks for the patch.
>
> And thanks for the comments.
>
> > On Fri, Aug 19, 2011 at 08:14:20AM +0200, Laurent Pinchart wrote:
> > > NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
> > > luma plane followed by an interleaved chroma plane.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > >
> > > Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 128
> > > +++ Documentation/DocBook/media/v4l/pixfmt.xml
> > > |1 +
> > > include/linux/videodev2.h |2 +
> > > 3 files changed, 131 insertions(+), 0 deletions(-)
> > > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> > >
> > > This format will be used by an fbdev driver. I'm already posting the
> > > patch for for review and will send a pull request later.
> > >
> > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> > > b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml new file mode 100644
> > > index 000..e77301d
> > > --- /dev/null
> > > +++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> > > @@ -0,0 +1,128 @@
> > > +
> > > +
> > > + V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42
> > > ('NV42') +&manvol;
> > > +
> > > +
> > > + > > id="V4L2-PIX-FMT-NV24">V4L2_PIX_FMT_NV24
> > > + > > id="V4L2-PIX-FMT-NV42">V4L2_PIX_FMT_NV42
> > > + Formats with full horizontal and vertical
> > > +chroma resolutions, also known as YUV 4:4:4. One luminance and one
> > > +chrominance plane with alternating chroma samples as opposed to
> > > +V4L2_PIX_FMT_YVU420
> > > +
> > > +
> > > + Description
> > > +
> > > + These are two-plane versions of the YUV 4:4:4 format.
> > > +The three components are separated into two sub-images or planes. The
> > > +Y plane is first. The Y plane has one byte per pixel. For
> >
> > Are all 8 bits being used per sample, or is there padding?
>
> All 8 bits are used, as in all YUV planar formats. Do you think that's worth
> mentioning ?
I think this should definitely be mentioned, but if the same issue touches
all the YUV formats, I guess it doesn't need to be in this patch.
E.g. many (if not most) raw bayer formats contain padding.
> > > +V4L2_PIX_FMT_NV24, a combined CbCr plane
> > > +immediately follows the Y plane in memory. The CbCr plane is the same
> > > +width and height, in pixels, as the Y plane (and of the image).
> > > +Each line contains one CbCr pair per pixel.
> >
> > How may bits / bytes per Cb / Cr sample? Perhaps you could mention this
> > once somewhere if all have the same.
>
> All YUV planar formats use 8 bits for each Cb and Cr samples. I will clarify
> this.
Yes, I think the size per sample is important.
--
Sakari Ailus
sakari.ai...@iki.fi
--
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 14/14] [media] gspca: Use current logging styles
On Mon, 2011-08-22 at 10:50 +0200, Jean-Francois Moine wrote: > On Sun, 21 Aug 2011 15:56:57 -0700 > Joe Perches wrote: > > Add pr_fmt. > > Convert usb style logging macros to pr_. > > Remove now unused old usb style logging macros. > Hi Joe, Hello Jean-Francois. > Sorry, but I do not see the advantages of your patch. The primary current advantage is style standardization both in code and dmesg output. Future changes to printk.h will reduce object sizes by centralizing the prefix to a singleton and emitting it only in pr_. > For gspca, the source files are bigger, and the only visible change is > the display of the real module name instead of the name defined by hand > (this change may have been done just in gspca.h). No, not really. gspca.h is not the first #include for all sources. Using #define pr_fmt before any #include avoids possible redefinition of the pr_ prefix. $ grep -rP --include=*.[ch] -l "gspca\.h" drivers/media | \ xargs grep -m1 "#\s*include" > Also, I think that defining 'pr_fmt' in each source file is not a good > idea... That's temporary for another year or so. After changes to printk are introduced, all of the uses of #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt could/should be removed. cheers, Joe -- 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 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Monday, August 22, 2011 15:54:03 Guennadi Liakhovetski wrote: > We discussed a bit more with Hans on IRC, and below is my attempt of a > summary. Hans, please, correct me, if I misunderstood anything. Looks good, that's exactly what I meant. Regards, Hans > Pawel, > Sakari, Laurent: please, reply, whether you're ok with this. > > On Mon, 22 Aug 2011, Hans Verkuil wrote: > > > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: > > [snip] > > > > It would be good if you also could have a look at my reply to this Pawel's > > > mail: > > > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > > infrastructure/36905 > > > > > > and, specifically, at the vb2_parse_planes() function in it. That's my > > > understanding of what would be needed, if we preserve .queue_setup() and > > > use your last suggestion to include struct v4l2_format in struct > > > v4l2_create_buffers. > > > > vb2_parse_planes can be useful as a utility function that 'normal' drivers can > > call from the queue_setup. But vb2 should not parse the format directly, it > > should just pass it on to the driver through the queue_setup function. > > > > You also mention: "All frame-format fields like fourcc code, width, height, > > colorspace are only input from the user. If the user didn't fill them in, they > > should not be used." > > > > I disagree with that. The user should fill in a full format description, just > > as with S/TRY_FMT. That's the information that the driver will use to set up > > the buffers. It could have weird rules like: if the fourcc is this, and the > > size is less than that, then we can allocate in this memory bank. > > > > It is also consistent with REQBUFS: there too the driver uses a full format > > (i.e. the last set format). > > > > I would modify queue_setup to something like this: > > > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > > unsigned int *num_buffers, > > unsigned int *num_planes, unsigned int sizes[], > > void *alloc_ctxs[]); > > > > Whether fmt is left to NULL in the reqbufs case, or whether the driver has to > > call g_fmt first before calling vb2 is something that could be decided by what > > is easiest to implement. > > 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to >the kernel, in which struct v4l2_format is embedded. The user _must_ >fill in .type member of struct v4l2_format. For .type == >V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is >used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or >V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these >cases the user _must_ fill in .width, .height, .pixelformat, .field, >.colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The >user also _may_ optionally fill in any further buffer-size related >fields, if it believes to have any special requirements to them. On >a successful return from the ioctl() .count and .index fields are >filled in by the kernel, .format stays unchanged. The user has to call >VIDIOC_QUERYBUF to retrieve specific buffer information. > > 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call >vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a >second argument. vb2_create_bufs() in turn calls the .queue_setup() >driver callback, whose prototype is modified as follows: > > int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, > unsigned int *num_buffers, > unsigned int *num_planes, unsigned int sizes[], > void *alloc_ctxs[]); > >with &create->format as a second argument. As pointed out above, this >struct is not modified by V4L, instead, the usual arguments 3-6 are >filled in by the driver, which are then used by vb2_create_bufs() to >call __vb2_queue_alloc(). > > 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will be >a signal to the driver to use the current format. > > 4. We keep .queue_setup(), because its removal would inevitably push a >part of the common code from vb2_reqbufs() and vb2_create_bufs() down >into drivers, thus creating code redundancy and increasing its >complexity. > > You have 24 hours to object, before I proceed with the next version;-) > > 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
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
We discussed a bit more with Hans on IRC, and below is my attempt of a summary. Hans, please, correct me, if I misunderstood anything. Pawel, Sakari, Laurent: please, reply, whether you're ok with this. On Mon, 22 Aug 2011, Hans Verkuil wrote: > On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote: [snip] > > It would be good if you also could have a look at my reply to this Pawel's > > mail: > > > > http://article.gmane.org/gmane.linux.drivers.video-input- > infrastructure/36905 > > > > and, specifically, at the vb2_parse_planes() function in it. That's my > > understanding of what would be needed, if we preserve .queue_setup() and > > use your last suggestion to include struct v4l2_format in struct > > v4l2_create_buffers. > > vb2_parse_planes can be useful as a utility function that 'normal' drivers > can > call from the queue_setup. But vb2 should not parse the format directly, it > should just pass it on to the driver through the queue_setup function. > > You also mention: "All frame-format fields like fourcc code, width, height, > colorspace are only input from the user. If the user didn't fill them in, > they > should not be used." > > I disagree with that. The user should fill in a full format description, just > as with S/TRY_FMT. That's the information that the driver will use to set up > the buffers. It could have weird rules like: if the fourcc is this, and the > size is less than that, then we can allocate in this memory bank. > > It is also consistent with REQBUFS: there too the driver uses a full format > (i.e. the last set format). > > I would modify queue_setup to something like this: > > int (*queue_setup)(struct vb2_queue *q, struct v4l2_format *fmt, > unsigned int *num_buffers, > unsigned int *num_planes, unsigned int sizes[], > void *alloc_ctxs[]); > > Whether fmt is left to NULL in the reqbufs case, or whether the driver has to > call g_fmt first before calling vb2 is something that could be decided by > what > is easiest to implement. 1. VIDIOC_CREATE_BUFS passes struct v4l2_create_buffers from the user to the kernel, in which struct v4l2_format is embedded. The user _must_ fill in .type member of struct v4l2_format. For .type == V4L2_BUF_TYPE_VIDEO_CAPTURE or V4L2_BUF_TYPE_VIDEO_OUTPUT .fmt.pix is used, for .type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE .fmt.pix_mp is used. In both these cases the user _must_ fill in .width, .height, .pixelformat, .field, .colorspace by possibly calling VIDIOC_G_FMT or VIDIOC_TRY_FMT. The user also _may_ optionally fill in any further buffer-size related fields, if it believes to have any special requirements to them. On a successful return from the ioctl() .count and .index fields are filled in by the kernel, .format stays unchanged. The user has to call VIDIOC_QUERYBUF to retrieve specific buffer information. 2. Videobuf2 drivers, that implement .vidioc_create_bufs() operation, call vb2_create_bufs() with a pointer to struct v4l2_create_buffers as a second argument. vb2_create_bufs() in turn calls the .queue_setup() driver callback, whose prototype is modified as follows: int (*queue_setup)(struct vb2_queue *q, const struct v4l2_format *fmt, unsigned int *num_buffers, unsigned int *num_planes, unsigned int sizes[], void *alloc_ctxs[]); with &create->format as a second argument. As pointed out above, this struct is not modified by V4L, instead, the usual arguments 3-6 are filled in by the driver, which are then used by vb2_create_bufs() to call __vb2_queue_alloc(). 3. vb2_reqbufs() shall call .queue_setup() with fmt == NULL, which will be a signal to the driver to use the current format. 4. We keep .queue_setup(), because its removal would inevitably push a part of the common code from vb2_reqbufs() and vb2_create_bufs() down into drivers, thus creating code redundancy and increasing its complexity. You have 24 hours to object, before I proceed with the next version;-) 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
Re: Afatech AF9013
2011/8/22 Jason Hecker : > I just tried LiveCDs of Mythbuntu 10.04 and 10.10 but had limited luck > with the former and some joy with the latter. Unfortunately the > default framebuffer slowed things down. Anyway in LiveCD 10.10 I used > mplayer to set up and view Tuner A and Tuner B and Tuner A only showed > some slight errors when Tuner B was being set up. After that for some > strange reason attempt at retuning with mplayer failed utterly so I > suspect there is some problems with the older versions of mplayer. > > These cards have blue LEDs for each tuner and light up when in use. I > did notice in my testing that the LED on tuner A would flicker off > briefly (and presumably issue the errors) when Tuner B was being set > up. I am wondering if there is a general setup problem or even a I2S > timing problem. Could someone contact me off list about sending me > the data sheets for the AF901x chips? > -- > 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 > Hello again, yesterday I try to connect the KWorld USB Dual DVB-T TV Stick (DVB-T 399U) on my HTPC, I start MythTV and both tuners were working great, I could record a channel and watch an other one, both HD. But 2 hours later they start to watch bad, with pixeled images: http://dl.dropbox.com/u/1541853/kworld.3gp I don't know what happens with this tuner. I have two identical ones and both have same issues. I could share a SSH root access to everyone that want to test the tuner. I will install a fresh Debian Squeeze on my laptop and give full access to the machine. Anyone interested? I don't know what else to try with it. Thanks and best regards. -- Josu Lazkano -- 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 v4] V4L: add two new ioctl()s for multi-size videobuffer management
On Monday, August 22, 2011 12:40:25 Guennadi Liakhovetski wrote:
> Hi Hans
>
> On Mon, 22 Aug 2011, Hans Verkuil wrote:
>
> > Sorry for starting this discussion and then disappearing. I've been very
> > busy lately, so my apologies for that.
> >
> > On Tuesday, August 16, 2011 18:14:33 Pawel Osciak wrote:
> > > Hi Guennadi,
> > >
> > > On Tue, Aug 16, 2011 at 06:13, Guennadi Liakhovetski
> > > wrote:
> > > > On Mon, 15 Aug 2011, Guennadi Liakhovetski wrote:
> > > >
> > > >> On Mon, 15 Aug 2011, Hans Verkuil wrote:
> > > >>
> > > >> > On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> > > >> > > Hi Hans
> > > >> > >
> > > >> > > On Mon, 8 Aug 2011, Hans Verkuil wrote:
> > > >
> > > > [snip]
> > > >
> > > >> > > > but I've changed my mind: I think
> > > >> > > > this should use a struct v4l2_format after all.
> > > >>
> > > >> While switching back, I have to change the struct
vb2_ops::queue_setup()
> > > >> operation to take a struct v4l2_create_buffers pointer. An earlier
> > version
> > > >> of this patch just added one more parameter to .queue_setup(), which
is
> > > >> easier - changes to videobuf2-core.c are smaller, but it is then
> > > >> redundant. We could use the create pointer for both input and output.
The
> > > >> video plane configuration in frame format is the same as what is
> > > >> calculated in .queue_setup(), IIUC. So, we could just let the driver
fill
> > > >> that one in. This would require then the videobuf2-core.c to parse
struct
> > > >> v4l2_format to decide which union member we need, depending on the
buffer
> > > >> type. Do we want this or shall drivers duplicate plane sizes in
separate
> > > >> .queue_setup() parameters?
> > > >
> > > > Let me explain my question a bit. The current .queue_setup() method is
> > > >
> > > >int (*queue_setup)(struct vb2_queue *q, unsigned int
*num_buffers,
> > > > unsigned int *num_planes, unsigned int
sizes[],
> > > > void *alloc_ctxs[]);
> > > >
> > > > To support multiple-size buffers we also have to pass a pointer to
struct
> > > > v4l2_create_buffers to this function now. We can either do it like
this:
> > > >
> > > >int (*queue_setup)(struct vb2_queue *q,
> > > > struct v4l2_create_buffers *create,
> > > > unsigned int *num_buffers,
> > > > unsigned int *num_planes, unsigned int
sizes[],
> > > > void *alloc_ctxs[]);
> > > >
> > > > and let all drivers fill in respective fields in *create, e.g., either
do
> > > >
> > > >create->format.fmt.pix_mp.plane_fmt[i].sizeimage = ...;
> > > >create->format.fmt.pix_mp.num_planes = ...;
> > > >
> > > > and also duplicate it in method parameters
> > > >
> > > >*num_planes = create->format.fmt.pix_mp.num_planes;
> > > >sizes[i] = create->format.fmt.pix_mp.plane_fmt[i].sizeimage;
> > > >
> > > > or with
> > > >
> > > >create->format.fmt.pix.sizeimage = ...;
> > > >
> > > > for single-plane. Alternatively we make the prototype
> > > >
> > > >int (*queue_setup)(struct vb2_queue *q,
> > > > struct v4l2_create_buffers *create,
> > > > unsigned int *num_buffers,
> > > > void *alloc_ctxs[]);
> > > >
> > > > then drivers only fill in *create, and the videobuf2-core will have to
> > > > check create->format.type to decide, which of create->format.fmt.* is
> > > > relevant and extract plane sizes from there.
> > >
> > >
> > > Could we try exploring an alternative idea?
> > > The queue_setup callback was added to decouple formats from vb2 (and
> > > add some asynchronousness). But now we are doing the opposite, adding
> > > format awareness to vb2. Does vb2 really need to know about formats? I
> > > really believe it doesn't. It only needs sizes and counts. Also, we
> > > are actually complicating things I think. The proposal, IIUC, would
> > > look like this:
> > >
> > > driver_queue_setup(..., create, num_buffers, [num_planes], ...)
> > > {
> > > if (create != NULL && create->format != NULL) {
> > > /* use create->fmt to fill sizes */
> >
> > Right.
> >
> > > } else if (create != NULL) { /* this assumes we have both format or
> > sizes */
> > > /* use create->sizes to fill sizes */
> >
> > No, create->format should always be set. If the application can fill in
the
> > sizeimage field(s), then there is no need for create->sizes.
> >
> > > } else {
> > > /* use currently selected format to fill sizes */
> >
> > Right.
> >
> > > }
> > > }
> > >
> > > driver_s_fmt(format)
> > > {
> > > /* ... */
> > > driver_fill_format(&create->fmt);
> > > /* ... */
> > > }
> >
> > ???
> >
> > >
> > > driver_create_bufs(create)
> > > {
> > > vb2_create_bufs(create);
> > > }
> > >
> > > vb2_create_bufs(create)
> > > {
> > > driver_queu
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Hans
On Mon, 22 Aug 2011, Hans Verkuil wrote:
> Sorry for starting this discussion and then disappearing. I've been very
> busy lately, so my apologies for that.
>
> On Tuesday, August 16, 2011 18:14:33 Pawel Osciak wrote:
> > Hi Guennadi,
> >
> > On Tue, Aug 16, 2011 at 06:13, Guennadi Liakhovetski
> > wrote:
> > > On Mon, 15 Aug 2011, Guennadi Liakhovetski wrote:
> > >
> > >> On Mon, 15 Aug 2011, Hans Verkuil wrote:
> > >>
> > >> > On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> > >> > > Hi Hans
> > >> > >
> > >> > > On Mon, 8 Aug 2011, Hans Verkuil wrote:
> > >
> > > [snip]
> > >
> > >> > > > but I've changed my mind: I think
> > >> > > > this should use a struct v4l2_format after all.
> > >>
> > >> While switching back, I have to change the struct vb2_ops::queue_setup()
> > >> operation to take a struct v4l2_create_buffers pointer. An earlier
> version
> > >> of this patch just added one more parameter to .queue_setup(), which is
> > >> easier - changes to videobuf2-core.c are smaller, but it is then
> > >> redundant. We could use the create pointer for both input and output. The
> > >> video plane configuration in frame format is the same as what is
> > >> calculated in .queue_setup(), IIUC. So, we could just let the driver fill
> > >> that one in. This would require then the videobuf2-core.c to parse struct
> > >> v4l2_format to decide which union member we need, depending on the buffer
> > >> type. Do we want this or shall drivers duplicate plane sizes in separate
> > >> .queue_setup() parameters?
> > >
> > > Let me explain my question a bit. The current .queue_setup() method is
> > >
> > >int (*queue_setup)(struct vb2_queue *q, unsigned int *num_buffers,
> > > unsigned int *num_planes, unsigned int sizes[],
> > > void *alloc_ctxs[]);
> > >
> > > To support multiple-size buffers we also have to pass a pointer to struct
> > > v4l2_create_buffers to this function now. We can either do it like this:
> > >
> > >int (*queue_setup)(struct vb2_queue *q,
> > > struct v4l2_create_buffers *create,
> > > unsigned int *num_buffers,
> > > unsigned int *num_planes, unsigned int sizes[],
> > > void *alloc_ctxs[]);
> > >
> > > and let all drivers fill in respective fields in *create, e.g., either do
> > >
> > >create->format.fmt.pix_mp.plane_fmt[i].sizeimage = ...;
> > >create->format.fmt.pix_mp.num_planes = ...;
> > >
> > > and also duplicate it in method parameters
> > >
> > >*num_planes = create->format.fmt.pix_mp.num_planes;
> > >sizes[i] = create->format.fmt.pix_mp.plane_fmt[i].sizeimage;
> > >
> > > or with
> > >
> > >create->format.fmt.pix.sizeimage = ...;
> > >
> > > for single-plane. Alternatively we make the prototype
> > >
> > >int (*queue_setup)(struct vb2_queue *q,
> > > struct v4l2_create_buffers *create,
> > > unsigned int *num_buffers,
> > > void *alloc_ctxs[]);
> > >
> > > then drivers only fill in *create, and the videobuf2-core will have to
> > > check create->format.type to decide, which of create->format.fmt.* is
> > > relevant and extract plane sizes from there.
> >
> >
> > Could we try exploring an alternative idea?
> > The queue_setup callback was added to decouple formats from vb2 (and
> > add some asynchronousness). But now we are doing the opposite, adding
> > format awareness to vb2. Does vb2 really need to know about formats? I
> > really believe it doesn't. It only needs sizes and counts. Also, we
> > are actually complicating things I think. The proposal, IIUC, would
> > look like this:
> >
> > driver_queue_setup(..., create, num_buffers, [num_planes], ...)
> > {
> > if (create != NULL && create->format != NULL) {
> > /* use create->fmt to fill sizes */
>
> Right.
>
> > } else if (create != NULL) { /* this assumes we have both format or
> sizes */
> > /* use create->sizes to fill sizes */
>
> No, create->format should always be set. If the application can fill in the
> sizeimage field(s), then there is no need for create->sizes.
>
> > } else {
> > /* use currently selected format to fill sizes */
>
> Right.
>
> > }
> > }
> >
> > driver_s_fmt(format)
> > {
> > /* ... */
> > driver_fill_format(&create->fmt);
> > /* ... */
> > }
>
> ???
>
> >
> > driver_create_bufs(create)
> > {
> > vb2_create_bufs(create);
> > }
> >
> > vb2_create_bufs(create)
> > {
> > driver_queue_setup(..., create, ...);
> > vb2_fill_format(&create->fmt); /* note different from
> > driver_fill_format(), but both needed */
>
> Huh? Why call vb2_fill_format? vb2 should have no knowledge whatsoever about
> formats. The driver needs that information in order to be able to allocate
> buffers correctly since that depends on
Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
Hi Chris, On 08/22/2011 11:41 AM, Laurent Pinchart wrote: > > Hi Chris, > > On Monday 22 August 2011 06:12:41 CJ wrote: >> On 19/08/11 22:12, Laurent Pinchart wrote: I am trying to get the mt9p031 working from nand with a ubifs file system and I am having a few problems. /dev/media0 is not present unless I run: #mknod /dev/media0 c 251 0 #chown root:video /dev/media0 #media-ctl -p Enumerating entities media_open: Unable to enumerate entities for device /dev/media0 (Inappropriate ioctl for device) With the same rig/files it works fine running from EXT4 on an SD card. Any idea why this does not work on nand with ubifs? >>> >>> Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? >>> Check the kernel log for OMAP3 ISP-related messages. >> >> Here is the version running from SD card: >> # dmesg | grep isp >> [0.265502] omap-iommu omap-iommu.0: isp registered >> [2.986541] omap3isp omap3isp: Revision 2.0 found >> [2.991577] omap-iommu omap-iommu.0: isp: version 1.1 >> [2.997406] omap3isp omap3isp: hist: DMA channel = 0 >> [3.006256] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to >> 2160 Hz >> [3.011932] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz >> >> From NAND using UBIFS: >> # dmesg | grep isp >> [3.457061] omap3isp omap3isp: Revision 2.0 found >> [3.462036] omap-iommu omap-iommu.0: isp: version 1.1 >> [3.467620] omap3isp omap3isp: hist: DMA channel = 0 >> [3.472564] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to >> 2160 Hz >> [3.478027] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz >> >> Seems to be missing: >> omap-iommu omap-iommu.0: isp registered >> >> Is that the issue? Why would this not work when running from NAND? I'm not sure, either, but I had a similar problem before using Laurent's patch below. IIRC, usually udev would create /dev/media0 from a cached list of /dev/*. Later modutils would come along and load the modules in the proper order (iommu, then omap3-isp) and everybody was happy. Occasionally, udev would fail to use the cached version of /dev/, and look through /sys/devices to re-create the devices in /dev/. When media0 was found, omap3-isp.ko would be loaded, but iommu had not yet been, presumably because it doesn't have an entry in /sys/devices/. So maybe udev is behaving differently for you on NAND than it did on the card? Either way, as I said, using Laurent's patch below did the job for me. -Michael > > I'm not sure why it doesn't work from NAND, but the iommu2 module needs to be > loaded before the omap3-isp module. Alternatively you can compile the iommu2 > module in the kernel with > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index 49a4c75..3c87644 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -132,7 +132,7 @@ config OMAP_MBOX_KFIFO_SIZE > module parameter). > > config OMAP_IOMMU > - tristate > + bool > > config OMAP_IOMMU_DEBUG > tristate "Export OMAP IOMMU internals in DebugFS" > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v4] V4L: add two new ioctl()s for multi-size videobuffer management
Sorry for starting this discussion and then disappearing. I've been very
busy lately, so my apologies for that.
On Tuesday, August 16, 2011 18:14:33 Pawel Osciak wrote:
> Hi Guennadi,
>
> On Tue, Aug 16, 2011 at 06:13, Guennadi Liakhovetski
> wrote:
> > On Mon, 15 Aug 2011, Guennadi Liakhovetski wrote:
> >
> >> On Mon, 15 Aug 2011, Hans Verkuil wrote:
> >>
> >> > On Monday, August 15, 2011 13:28:23 Guennadi Liakhovetski wrote:
> >> > > Hi Hans
> >> > >
> >> > > On Mon, 8 Aug 2011, Hans Verkuil wrote:
> >
> > [snip]
> >
> >> > > > but I've changed my mind: I think
> >> > > > this should use a struct v4l2_format after all.
> >>
> >> While switching back, I have to change the struct vb2_ops::queue_setup()
> >> operation to take a struct v4l2_create_buffers pointer. An earlier
version
> >> of this patch just added one more parameter to .queue_setup(), which is
> >> easier - changes to videobuf2-core.c are smaller, but it is then
> >> redundant. We could use the create pointer for both input and output. The
> >> video plane configuration in frame format is the same as what is
> >> calculated in .queue_setup(), IIUC. So, we could just let the driver fill
> >> that one in. This would require then the videobuf2-core.c to parse struct
> >> v4l2_format to decide which union member we need, depending on the buffer
> >> type. Do we want this or shall drivers duplicate plane sizes in separate
> >> .queue_setup() parameters?
> >
> > Let me explain my question a bit. The current .queue_setup() method is
> >
> >int (*queue_setup)(struct vb2_queue *q, unsigned int *num_buffers,
> > unsigned int *num_planes, unsigned int sizes[],
> > void *alloc_ctxs[]);
> >
> > To support multiple-size buffers we also have to pass a pointer to struct
> > v4l2_create_buffers to this function now. We can either do it like this:
> >
> >int (*queue_setup)(struct vb2_queue *q,
> > struct v4l2_create_buffers *create,
> > unsigned int *num_buffers,
> > unsigned int *num_planes, unsigned int sizes[],
> > void *alloc_ctxs[]);
> >
> > and let all drivers fill in respective fields in *create, e.g., either do
> >
> >create->format.fmt.pix_mp.plane_fmt[i].sizeimage = ...;
> >create->format.fmt.pix_mp.num_planes = ...;
> >
> > and also duplicate it in method parameters
> >
> >*num_planes = create->format.fmt.pix_mp.num_planes;
> >sizes[i] = create->format.fmt.pix_mp.plane_fmt[i].sizeimage;
> >
> > or with
> >
> >create->format.fmt.pix.sizeimage = ...;
> >
> > for single-plane. Alternatively we make the prototype
> >
> >int (*queue_setup)(struct vb2_queue *q,
> > struct v4l2_create_buffers *create,
> > unsigned int *num_buffers,
> > void *alloc_ctxs[]);
> >
> > then drivers only fill in *create, and the videobuf2-core will have to
> > check create->format.type to decide, which of create->format.fmt.* is
> > relevant and extract plane sizes from there.
>
>
> Could we try exploring an alternative idea?
> The queue_setup callback was added to decouple formats from vb2 (and
> add some asynchronousness). But now we are doing the opposite, adding
> format awareness to vb2. Does vb2 really need to know about formats? I
> really believe it doesn't. It only needs sizes and counts. Also, we
> are actually complicating things I think. The proposal, IIUC, would
> look like this:
>
> driver_queue_setup(..., create, num_buffers, [num_planes], ...)
> {
> if (create != NULL && create->format != NULL) {
> /* use create->fmt to fill sizes */
Right.
> } else if (create != NULL) { /* this assumes we have both format or
sizes */
> /* use create->sizes to fill sizes */
No, create->format should always be set. If the application can fill in the
sizeimage field(s), then there is no need for create->sizes.
> } else {
> /* use currently selected format to fill sizes */
Right.
> }
> }
>
> driver_s_fmt(format)
> {
> /* ... */
> driver_fill_format(&create->fmt);
> /* ... */
> }
???
>
> driver_create_bufs(create)
> {
> vb2_create_bufs(create);
> }
>
> vb2_create_bufs(create)
> {
> driver_queue_setup(..., create, ...);
> vb2_fill_format(&create->fmt); /* note different from
> driver_fill_format(), but both needed */
Huh? Why call vb2_fill_format? vb2 should have no knowledge whatsoever about
formats. The driver needs that information in order to be able to allocate
buffers correctly since that depends on the required format. But vb2 doesn't
need that knowledge.
> }
>
> vb2_reqbufs(reqbufs)
> {
>driver_queue_setup(..., NULL, ...);
> }
>
> The queue_setup not only becomes unnecessarily complicated, but I'm
> starting to question the convenience of it. And we are teaching vb2
> how to interpret format stru
Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
Hi Chris, On Monday 22 August 2011 06:12:41 CJ wrote: > On 19/08/11 22:12, Laurent Pinchart wrote: > >> I am trying to get the mt9p031 working from nand with a ubifs file > >> system and I am having a few problems. > >> > >> /dev/media0 is not present unless I run: > >> #mknod /dev/media0 c 251 0 > >> #chown root:video /dev/media0 > >> > >> #media-ctl -p > >> Enumerating entities > >> media_open: Unable to enumerate entities for device /dev/media0 > >> (Inappropriate ioctl for device) > >> > >> With the same rig/files it works fine running from EXT4 on an SD card. > >> Any idea why this does not work on nand with ubifs? > > > > Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? > > Check the kernel log for OMAP3 ISP-related messages. > > Here is the version running from SD card: > # dmesg | grep isp > [0.265502] omap-iommu omap-iommu.0: isp registered > [2.986541] omap3isp omap3isp: Revision 2.0 found > [2.991577] omap-iommu omap-iommu.0: isp: version 1.1 > [2.997406] omap3isp omap3isp: hist: DMA channel = 0 > [3.006256] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to > 2160 Hz > [3.011932] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz > > From NAND using UBIFS: > # dmesg | grep isp > [3.457061] omap3isp omap3isp: Revision 2.0 found > [3.462036] omap-iommu omap-iommu.0: isp: version 1.1 > [3.467620] omap3isp omap3isp: hist: DMA channel = 0 > [3.472564] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to > 2160 Hz > [3.478027] omap3isp omap3isp: isp_set_xclk(): cam_xclka set to 0 Hz > > Seems to be missing: > omap-iommu omap-iommu.0: isp registered > > Is that the issue? Why would this not work when running from NAND? I'm not sure why it doesn't work from NAND, but the iommu2 module needs to be loaded before the omap3-isp module. Alternatively you can compile the iommu2 module in the kernel with diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 49a4c75..3c87644 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -132,7 +132,7 @@ config OMAP_MBOX_KFIFO_SIZE module parameter). config OMAP_IOMMU - tristate + bool config OMAP_IOMMU_DEBUG tristate "Export OMAP IOMMU internals in DebugFS" -- 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 14/14] [media] gspca: Use current logging styles
On Sun, 21 Aug 2011 15:56:57 -0700 Joe Perches wrote: > Add pr_fmt. > Convert usb style logging macros to pr_. > Remove now unused old usb style logging macros. Hi Joe, Sorry, but I do not see the advantages of your patch. For gspca, the source files are bigger, and the only visible change is the display of the real module name instead of the name defined by hand (this change may have been done just in gspca.h). Also, I think that defining 'pr_fmt' in each source file is not a good idea... -- 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
