RE: vpif_display.c bug
On Mon, Aug 10, 2009 at 20:39:05, Karicheri, Muralidharan wrote:
Chaithrika,
No need to change this since this is already corrected as part of my vpif
capture patch set that I had submitted for review. I had mentioned this to
Hans as well.
Murali,
Thank you for correcting this bug in your patch set.
Regards,
Chaithrika
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Subrahmanya, Chaithrika
Sent: Monday, August 10, 2009 8:51 AM
To: 'Hans Verkuil'
Cc: linux-media@vger.kernel.org
Subject: RE: vpif_display.c bug
On Mon, Aug 10, 2009 at 11:37:23, Hans Verkuil wrote:
Hi Chaithrika,
This code in vpif_display.c is not correct:
for (i = 0; i subdev_count; i++) {
vpif_obj.sd[i] =
v4l2_i2c_new_probed_subdev(vpif_obj.v4l2_dev,
i2c_adap,
subdevdata[i].name,
subdevdata[i].name,
subdevdata[i].addr);
if (!vpif_obj.sd[i]) {
vpif_err(Error registering v4l2 subdevice\n);
goto probe_subdev_out;
}
if (vpif_obj.sd[i])
vpif_obj.sd[i]-grp_id = 1 i;
}
This: 'subdevdata[i].addr' should be: I2C_ADDRS(subdevdata[i].addr).
The list of probe addresses must be terminated by I2C_CLIENT_END (= -1)
and
that isn't the case here.
An alternative solution is to use v4l2_i2c_new_subdev, but then no
probing
will take place. But I think that you don't want probing at all since
this
address information comes from the platform data, so one can assume that
that data is correct.
Even better is to copy the implementation from vpfe_capture.c and to use
v4l2_i2c_new_subdev_board().
Hans,
Thank you for the suggestions.
I will look into this and submit a patch to correct this bug.
Regards,
Chaithrika
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
--
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: How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
On Thu, 2009-08-06 at 22:59 -0700, David Xiao wrote: The V7 speculative prefetching will then probably apply to DMA coherency issue in general, both kernel and user space DMAs. Could this be addressed by inside the dma_unmap_sg/single() calling dma_cache_maint() when the direction is DMA_FROM_DEVICE/DMA_BIDIRECTIONAL, to basically invalidate the related cache lines in case any filled by prefetching? Assuming dma_unmap_sg/single() is called after each DMA operation is completed. Theoretically, with speculative prefetching on ARMv7 and the FROM_DEVICE case we need to invalidate the corresponding D-cache lines both before and after the DMA transfer, i.e. in both dma_map_sg and dma_unmap_sg, otherwise there is a risk of stale data in the cache. -- Catalin -- 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: vpif_display.c bug
On Monday 10 August 2009 17:07:51 Karicheri, Muralidharan wrote:
Hans,
I have already changed v4l2_i2c_new_probed_subdev() to
v4l2_i2c_new_subdev_board() in my latest patch set for adding vpif capture
driver for DM6467 that you had reviewed. I think this change is not needed
once that patch is applied.
You are right. Hmm, I really have a bad memory for these things, I reviewed
it only last Friday :-(
Regards,
Hans
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Monday, August 10, 2009 2:07 AM
To: Subrahmanya, Chaithrika
Cc: linux-media@vger.kernel.org
Subject: vpif_display.c bug
Hi Chaithrika,
This code in vpif_display.c is not correct:
for (i = 0; i subdev_count; i++) {
vpif_obj.sd[i] =
v4l2_i2c_new_probed_subdev(vpif_obj.v4l2_dev,
i2c_adap,
subdevdata[i].name,
subdevdata[i].name,
subdevdata[i].addr);
if (!vpif_obj.sd[i]) {
vpif_err(Error registering v4l2 subdevice\n);
goto probe_subdev_out;
}
if (vpif_obj.sd[i])
vpif_obj.sd[i]-grp_id = 1 i;
}
This: 'subdevdata[i].addr' should be: I2C_ADDRS(subdevdata[i].addr).
The list of probe addresses must be terminated by I2C_CLIENT_END (= -1) and
that isn't the case here.
An alternative solution is to use v4l2_i2c_new_subdev, but then no probing
will take place. But I think that you don't want probing at all since this
address information comes from the platform data, so one can assume that
that data is correct.
Even better is to copy the implementation from vpfe_capture.c and to use
v4l2_i2c_new_subdev_board().
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
--
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-core2 for the following: - v4l: simplify v4l2_i2c_new_subdev and friends - v4l: remove video_register_device_index The first patch simplifies v4l2_i2c_new_subdev and removes v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This was initially proposed for inclusion in 2.6.31 but that was considered too soon. I think it is now a good time to merge this so this will go into 2.6.32. The second patch removes the unused video_register_device_index function. This patch is part of a larger series of patches I'm working on to improve v4l2-dev.c. But since this patch is pretty straightforward I like to get this one in first. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 33 + drivers/media/video/au0828/au0828-cards.c |4 drivers/media/video/bt8xx/bttv-cards.c| 44 +++ drivers/media/video/cafe_ccic.c |2 drivers/media/video/cx18/cx18-i2c.c | 14 +- drivers/media/video/cx231xx/cx231xx-cards.c |4 drivers/media/video/cx23885/cx23885-cards.c |2 drivers/media/video/cx23885/cx23885-video.c |6 drivers/media/video/cx88/cx88-cards.c | 14 +- drivers/media/video/cx88/cx88-video.c |6 drivers/media/video/davinci/vpif_display.c|4 drivers/media/video/em28xx/em28xx-cards.c | 34 ++--- drivers/media/video/ivtv/ivtv-i2c.c | 18 +- drivers/media/video/mxb.c | 14 +- drivers/media/video/pvrusb2/pvrusb2-hdw.c | 10 - drivers/media/video/saa7134/saa7134-cards.c | 12 - drivers/media/video/saa7134/saa7134-core.c|6 drivers/media/video/usbvision/usbvision-i2c.c | 12 - drivers/media/video/v4l2-common.c | 157 -- drivers/media/video/v4l2-dev.c| 55 ++--- drivers/media/video/vino.c|8 - drivers/media/video/w9968cf.c |4 drivers/media/video/zoran/zoran_card.c|8 - include/media/v4l2-common.h | 30 +--- include/media/v4l2-dev.h |2 25 files changed, 151 insertions(+), 352 deletions(-) -- 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
Re: [PATCH] V4L: videobuf-core.c VIDIOC_QBUF should return video buffer flags
On Monday 10 August 2009 19:37:40 Tuukka.O Toivonen wrote: When user space queues a buffer using VIDIOC_QBUF, the kernel should set flags to V4L2_BUF_FLAG_QUEUED in struct v4l2_buffer. videobuf_qbuf() was missing a call to videobuf_status() which does that. This patch adds the proper function call. Signed-off-by: Tuukka Toivonen tuukka.o.toivo...@nokia.com I was a bit surprised, as I didn't think VIDIOC_QBUF was supposed to update the buffer structure, but according to the v4l2 spec it is. However, I don't think calling videobuf_status() is the right thing to do. It will update fields that don't make sense at this point, such as v4l2_buffer::timestamp. Thanks Tuukka for finding this, I'll update the UVC video driver accordingly :-) --- drivers/media/video/videobuf-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf-core.c b/drivers/media/video/videobuf-core.c index b7b0584..d212710 100644 --- a/drivers/media/video/videobuf-core.c +++ b/drivers/media/video/videobuf-core.c @@ -565,6 +565,8 @@ int videobuf_qbuf(struct videobuf_queue *q, spin_unlock_irqrestore(q-irqlock, flags); } dprintk(1, qbuf: succeded\n); + memset(b, 0, sizeof(*b)); + videobuf_status(q, b, buf, q-type); retval = 0; wake_up_interruptible_sync(q-wait); -- 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: [PULL] http://linuxtv.org/hg/~dougsland/video4linux
Em Wed, 5 Aug 2009 13:09:47 -0300 Douglas Schilling Landgraf dougsl...@gmail.com escreveu: Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/video4linux for the following: - cxusb, d680 dmbth use unified lgs8gxx code instead of lgs8gl5 - media/zr364xx: fix build errors - drivers/media/video/gspca: introduce missing kfree - saa7134: fix the radio on Avermedia GO 007 FM - Fix incorrect type of tuner for the BeholdTV H6 card Patches cherry-picked to avoid conflicts with Tobias tree. - radio-si470x: add i2c driver for si470x - radio-si470x: add disconnect check function - radio-si470x: change to dev_* macro from printk - radio-si470x: separate common and usb code Those were got from Tobias tree 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] soc-camera: fix recursive cpin-lock (2.6.31)
Hi Guennadi, Em Thu, 6 Aug 2009 01:28:17 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro, I posted this fix and haven't got any objections (apart from unused variables, which are removed in this version), but - please have a look at it before pulling. In mx3_camera.c::mx3_videobuf_queue(), which is the driver's .buf_queue() method I temporarily drop the spinlock and reenable interrupts to call a possible sleeping function, and then re-lock. Is this acceptable? If not - the IPU IDMAC DMA driver would have to be changed. If it is - please, pull. This depends on how your driver works. The spinlock is important to put a memory barrier protecting videobuf queue data that can be used inside the IRQ routine and via videobuf ioctls. provided that the routines you're calling at videobuf_queue don't touch at the videobuf queue, I don't see any trouble with this strategy. Your code seems to work. Also notice, this is a fix for 2.6.31, and I forgot to put the Priority tag in it, sorry. Ok, I'll re-tag it on my queue. 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
Hi Mauro,
Em Thu, 6 Aug 2009 22:04:13 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l: introduce string control support.
- v4l2-spec: document the new string control type.
- v4l2-ctl: modulator bug fixes
- v4l2-ctl: add support for string controls
It's the same as the previous version, except for reverting the variable
renaming and for improving the comments above the ctrl_is_value64 and
ctrl_is_pointer functions. I've decided to keep the ctrl_is_value64()
function because I want to keep the correct value64 conversion code in
compat32 rather than having to do that work again at some point in the
future.
I agree with Trent, this really sucks:
static inline int ctrl_is_value64(u32 id)
{
- return 0;
+ switch (id) {
+ case V4L2_CID_RDS_TX_PS_NAME:
+ case V4L2_CID_RDS_TX_RADIO_TEXT:
+ return 1;
+ default:
+ return 0;
+ }
}
Yet, by looking on how the struct is defined:
struct v4l2_ext_control {
__u32 id;
__u32 reserved2[2];
union {
__s32 value;
__s64 value64;
void *reserved;
};
} __attribute__ ((packed));
Except on the strings case, I don't see why we need a compat stuff for
this
routine at the first place, copying field by field. Correct me if I'm
wrong,
but, on both 32 and 64 bit cases, the fields will be at the same position
on
both 32 and 64 bits. So, the code could be just:
copy_in_user(kcontrols, ucontrols, sizeof(ucontrols));
if (ctrl_is_pointer(id)) {
/* get_user/compat_ptr magic */
}
OK, makes sense.
I also agree with Trent that, instead of having to maintain some sort of
list
or code to identify string controls, the better would be to reserve one
bit to
indicate pointer controls (like bit 31). People tend to forget about
v4l2-compat32 layer, and I bet that, if we do some sort of list, people
will
forget to update it when adding a new control, and compat32 layer will
break.
So, ctrl_is_pointer() can be just:
#define ctrl_is_pointer(id) (id (1 31))
Now THAT is ugly. Anyway, you can't do it like that. Control IDs are not
random but are grouped in control classes so that similar controls are
together when you enumerate them. Adding flags to mark it as a specific
type is 1) an ugly hack to work around an infrastructure problem, and 2)
will make it impossible to group string controls together with controls
that have a similar purpose.
Anyway, I've started working on a proper control handling framework that
will make it possible for the compat module to query the type. That will
solve this. But that probably won't be ready for the upcoming 2.6.32,
while the si4713 is ready right now.
What should have happened is that we could test whether the size field is
non-zero. Unfortunately, some apps do not set that field (currently a
reserved field) to 0 and we never checked that in the kernel. So sadly we
have to do it another way.
Also note that it is very likely that these two functions will disappear
again in a few months: once the v4l framework has proper control support
these functions should no longer be needed since this information can
then be obtained directly from the framework.
This don't change the fact that you'll need a sort of list or code that
associates a control id with a type, called by the compat layer. Testing
for a
bit costs less than any table seek method.
O(log N) where N is the number of registered controls. It's implemented as
a binary search. It is generic and will work with whatever types we might
create in the future.
I will prepare a new pull request where I use copy_in_user.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v2 0/1] video: initial support for ADV7180
This is a an updated version of my previous patch. Hans: I have updated the patch according to you feedback (almost). Thanks for the feedback btw. * I left the state struct even though it only contains the subdev, it's for the future when more functions are added in. * I left the function for checking the norm, also for the future it's for instance possible to get interrupts when the norm is changed, a schedule work or equal could then use this function too. And yes, Mocean laboratories is the author while it's copyrighted to Intel. --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
[patch v2 1/1] video: initial support for ADV7180
This is an initial driver for Analog Devices ADV7180 Video Decoder.
So far it only supports setting the chip in autodetect mode and query
the detected standard.
Signed-off-by: Richard Röjfors richard.rojfors@mocean-labs.com
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 84b6fc1..ac9f636 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -265,6 +265,15 @@ config VIDEO_SAA6588
comment Video decoders
+config VIDEO_ADV7180
+ tristate Analog Devices ADV7180 decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Analog Devices ADV7180 video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7180.
+
config VIDEO_BT819
tristate BT819A VideoStream decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9f2e321..aac0884 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
+obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
new file mode 100644
index 000..6607321
--- /dev/null
+++ b/drivers/media/video/adv7180.c
@@ -0,0 +1,202 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/i2c-id.h
+#include media/v4l2-ioctl.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+
+#define DRIVER_NAME adv7180
+
+#define ADV7180_INPUT_CONTROL_REG 0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM 0x00
+#define ADV7180_AUTODETECT_ENABLE_REG 0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G 0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+struct adv7180_state {
+ struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+ u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+ switch (status1 ADV7180_STATUS1_AUTOD_MASK) {
+ case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+ return V4L2_STD_NTSC_M_JP;
+ case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+ return V4L2_STD_NTSC_443;
+ case ADV7180_STATUS1_AUTOD_PAL_M:
+ return V4L2_STD_PAL_M;
+ case ADV7180_STATUS1_AUTOD_PAL_60:
+ return V4L2_STD_PAL_60;
+ case ADV7180_STATUS1_AUTOD_PAL_B_G:
+ return V4L2_STD_PAL;
+ case ADV7180_STATUS1_AUTOD_SECAM:
+ return V4L2_STD_SECAM;
+ case ADV7180_STATUS1_AUTOD_PAL_COMB:
+ return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+ case ADV7180_STATUS1_AUTOD_SECAM_525:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ *(v4l2_std_id *)std = determine_norm(client);
+ return 0;
+}
+
+static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return v4l2_chip_ident_i2c_client(client, chip, V4L2_IDENT_ADV7180, 0);
+}
+
dmesg | grep em28xx
[ 127.817075] em28xx #0: Unknown AC97 audio processor detected! [ 127.848013] em28xx #0: v4l2 driver version 0.1.2 [ 127.883086] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 [ 127.899532] usbcore: registered new interface driver em28xx [ 127.899540] em28xx driver loaded -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=d=20090811 -- 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://kernellabs.com/hg/~mkrufky/sms1xxx
Em Sat, 1 Aug 2009 14:03:24 -0400 Michael Krufky mkru...@kernellabs.com escreveu: On Sat, Aug 1, 2009 at 12:40 AM, Mauro Carvalho Chehabmche...@infradead.org wrote: Em Fri, 31 Jul 2009 11:25:55 -0400 Michael Krufky mkru...@kernellabs.com escreveu: Please review this patch yourself -- you will see I am simply removing Hauppauge-specific handling that was incorrectly added by Uri, resulting in the crippling of these devices under Linux. Fair enough. I'll apply the patch. Yet, we should address with Udi what else is needed in order to sync their tree with ours without breaking support for any existing device. I cant stress enough how important it is that this changeset gets merged upstream to Linus asap. The 2.6.31-rc kernel is broken without this change. I'll add it on my next upstream changeset. Thanks for applying the fix patch. Now, at least those devices will work again, but there is still a regression since the previous kernels supported the LED and LNA functionality that my next patch restores. Hopefully we will hear from Udi soon. Just to be clear, the patch that we'd like Udi's comments on is this one: http://kernellabs.com/hg/~mkrufky/sms1xxx/rev/tip As this code is in the smsdvb common code, it calls into sms-cards and will return harmlessly to the caller on the non-hauppauge devices. The functionality is only changed for those cards that have this functionality defined in the sms-cards.c structures. Hopefully, Udi can agree to merge this into the 2.6.31 kernel, while we can work on Siano's internal event interface for the next kernel. Once that is working perfectly, we can remove the patch that I'm proposing now, and convert the Hauppauge devices to the newer event interface. Since: a) the pull request were sent on Jul, 28; b) we didn't have any answer from Siano up to today; c) a closer analysis showed that this patch won't affect non Hauppauge devices; I'm merging the fix today. Udi, the better is to work at the event interface in a way that it won't cause troubles with the existing Hauppauge devices. After having it done, we may just remove the legacy SMS code 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
gspca: Trust webcam WB 300P ID 093a:2608 doesn't work
Hello, I'm trying to use the Trust webcam WB 300P (ID 093a:2608 ) unsuccessful. The complete lsusb command is following: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 093a:2608 Pixart Imaging, Inc. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub When I use amsn, I can select the webcam but I get an error (unable to capture ...) The /var/log/message is following: Aug 11 18:35:06 cchi-desktop kernel: [ 3447.714061] usb 1-2.4: new full speed USB device using ehci_hcd and address 3 Aug 11 18:35:06 cchi-desktop kernel: [ 3447.836067] usb 1-2.4: configuration #1 chosen from 1 choice Aug 11 18:35:06 cchi-desktop kernel: [ 3448.112057] gspca: main v2.3.0 registered Aug 11 18:35:06 cchi-desktop kernel: [ 3448.170206] gspca: probing 093a:2608 Aug 11 18:35:06 cchi-desktop kernel: [ 3448.180041] gspca: probe ok Aug 11 18:35:06 cchi-desktop kernel: [ 3448.180041] gspca: probing 093a:2608 Aug 11 18:35:06 cchi-desktop kernel: [ 3448.180041] gspca: probing 093a:2608 Aug 11 18:35:06 cchi-desktop kernel: [ 3448.180041] usbcore: registered new interface driver pac7311 Aug 11 18:35:06 cchi-desktop kernel: [ 3448.180041] pac7311: registered Aug 11 18:35:07 cchi-desktop kernel: [ 3448.724060] usbcore: registered new interface driver snd-usb-audio Aug 11 18:35:08 cchi-desktop pulseaudio[3943]: alsa-util.c: Device hw:2 doesn't support 44100 Hz, changed to 16000 Hz. Aug 11 18:35:08 cchi-desktop pulseaudio[3943]: alsa-util.c: Device hw:2 doesn't support 2 channels, changed to 1. Aug 11 18:44:25 cchi-desktop kernel: [ 4007.040063] gspca: usb_submit_urb [0] err -28 Aug 11 18:44:40 cchi-desktop kernel: [ 4022.040062] gspca: usb_submit_urb [0] err -28 Thanks Claudio -- 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: add g_std/s_std methods
On Sun, 09 Aug 2009 22:13:12 +0200 Olaf Titz olaf.t...@inka.de wrote: Some applications are unhappy about getting EINVAL errors for query/set TV standard operations, especially (or only?) when working over the v4l1compat.so bridge. This patch adds the appropriate methods to the gspca driver (claim to support all TV modes, setting TV mode does nothing). The vidioc_s_std() has been removed last month by Németh Márton according to the v4l2 API http://v4l2spec.bytesex.org/spec/x448.htm -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
On Tue, 2009-08-11 at 02:31 -0700, Catalin Marinas wrote: On Thu, 2009-08-06 at 22:59 -0700, David Xiao wrote: The V7 speculative prefetching will then probably apply to DMA coherency issue in general, both kernel and user space DMAs. Could this be addressed by inside the dma_unmap_sg/single() calling dma_cache_maint() when the direction is DMA_FROM_DEVICE/DMA_BIDIRECTIONAL, to basically invalidate the related cache lines in case any filled by prefetching? Assuming dma_unmap_sg/single() is called after each DMA operation is completed. Theoretically, with speculative prefetching on ARMv7 and the FROM_DEVICE case we need to invalidate the corresponding D-cache lines both before and after the DMA transfer, i.e. in both dma_map_sg and dma_unmap_sg, otherwise there is a risk of stale data in the cache. The dma_map_sg() code is already calling dma_cache_maint() to invalidate the cache lines in the DMA_FROM_DEVICE/DMA_BIDIRECTIONAL direction cases. And the suggestion was to do something similar in dma_unmap_sg() case to deal with the speculative prefetching on ARMv7, and Russel has other postings talking about the details of this in terms of feasibility/etc. Furthermore, duplicate MMU mappings in the kernel bring more twists to this problem as explained in this email chain as well, especially in the case of DMA-coherent memory (dma_alloc_coherent()). David -- 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: add g_std/s_std methods
Jean-Francois Moine wrote:
The vidioc_s_std() has been removed last month by Németh Márton
according to the v4l2 API http://v4l2spec.bytesex.org/spec/x448.htm
Ah, I see. This is a recent change, which explains why it has not come
up earlier :-)
The standard clearly states that my change is incorrect, but then
v4l1-compat.c is wrong in how it implements v4l_compat_get_input_info()
and v4l1_compat_set_input(). These calls query rsp. set video input and
standard in one call, and there is no special provision for webcams in
http://v4l2spec.bytesex.org/spec/x309.htm, so these calls should not
fail. IOW, something like this would be in order instead (untested):
--- a/linux/drivers/media/video/v4l1-compat.c Sat Aug 08 03:28:41 2009
-0300
+++ b/linux/drivers/media/video/v4l1-compat.c Tue Aug 11 20:30:47 2009
+0200
@@ -540,7 +540,7 @@
{
long err;
struct v4l2_input input2;
- v4l2_std_id sid;
+ v4l2_std_id sid = V4L2_STD_UNKNOWN;
memset(input2, 0, sizeof(input2));
input2.index = chan-channel;
@@ -566,19 +566,21 @@
break;
}
chan-norm = 0;
- err = drv(file, VIDIOC_G_STD, sid);
- if (err 0)
- dprintk(VIDIOCGCHAN / VIDIOC_G_STD: %ld\n, err);
- if (err == 0) {
- if (sid V4L2_STD_PAL)
- chan-norm = VIDEO_MODE_PAL;
- if (sid V4L2_STD_NTSC)
- chan-norm = VIDEO_MODE_NTSC;
- if (sid V4L2_STD_SECAM)
- chan-norm = VIDEO_MODE_SECAM;
- if (sid == V4L2_STD_ALL)
- chan-norm = VIDEO_MODE_AUTO;
- }
+{
+int err2 = drv(file, VIDIOC_G_STD, sid);
+if (err2 0)
+dprintk(VIDIOCGCHAN / VIDIOC_G_STD: %ld\n, err2);
+if (err2 == 0) {
+if (sid V4L2_STD_PAL)
+chan-norm = VIDEO_MODE_PAL;
+if (sid V4L2_STD_NTSC)
+chan-norm = VIDEO_MODE_NTSC;
+if (sid V4L2_STD_SECAM)
+chan-norm = VIDEO_MODE_SECAM;
+if (sid == V4L2_STD_ALL)
+chan-norm = VIDEO_MODE_AUTO;
+}
+}
done:
return err;
}
@@ -609,9 +611,9 @@
break;
}
if (0 != sid) {
- err = drv(file, VIDIOC_S_STD, sid);
- if (err 0)
- dprintk(VIDIOCSCHAN / VIDIOC_S_STD: %ld\n, err);
+ int err2 = drv(file, VIDIOC_S_STD, sid);
+ if (err2 0)
+ dprintk(VIDIOCSCHAN / VIDIOC_S_STD: %ld\n, err2);
}
return err;
}
I'm not sure if v4l1_compat_get_tuner() needs this kind of change too.
We also should keep the input-std = V4L2_STD_ALL; because an
application may bomb with something like Invalid standard PAL, valid
choices are: (empty). This (and the EINVAL) breaks at least ekiga 2
with the v4l1 module (which is what Ubuntu has) run over
libv4l1compat.so. (Ekiga 3 with the v4l2 module does work.) It also
breaks xawtv, the canonical v4l test app...
Olaf
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] TechnoTrend TT-connect S2-3650 CI
Op Di, 11 augustus, 2009 20:32, schreef Christopher Thornley: -- SNIP -- I probably would like to get both the S2API and Multiprot methods working. Many Thanks Chris That won't be possible. It's S2API or Multiproto. And since S2API is the official standard - besides the fact that Multiproto is old and absolete - you should forget about Multiproto. So in short, your DVB devices should be used using the S2API drivers. You can use v4l or s2-liplianin (I use s2-liplianin myself) which are both S2API. Only v4l is the official tree while s2-liplianin is more experimental. After fetching v4l or s2-liplianin you can easily install them for your kernel using: make ; make install ; reboot. Then check if your cards were detected using dmesg (it should tell you information if the DVB devices were detected) and you can check /dev/dvb. You should have two folders containing adapter0 and adapter1. Normally, a simple check would be to use a DVB application like Kaffeine. Alternatively you can use MythTV 0.22 (which supports S2API), VDR 1.7.0 with my S2API patch or VDR 1.7.4 or higher (latest version is 1.7.8). Regards, Niels Wagenaar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4 - v2] V4L: vpfe capture driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
This patch incorporated comments received against v1 patch series.
Following are the major comments incorporated:-
1) retained vpfe_g_std() since for vbi support g_std handling in v4l2
framework
is not sufficient.
2) rename name field in vpfe_subdev_info to module_name and camera to
is_camera.
also grouped bit field variables
Additional features added on top v1 patch:-
2) vpfe_enable/disable_clock restructered to allow configuration of
required
clocks in vpfe_capture configuration. This is required for upcoming
DM365
support.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/vpfe_capture.c | 545 +---
include/media/davinci/vpfe_capture.h | 30 ++-
2 files changed, 436 insertions(+), 139 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..ff43446 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,10 +59,8 @@
*TODO list
* - Support multiple REQBUF after open
* - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
* - Support for chaining Image Processor
* - Support for static allocation of buffers
- * - Support for USERPTR IO
* - Support for STREAMON before QBUF
* - Support for control ioctls
*/
@@ -79,11 +77,24 @@
static int debug;
static u32 numbuffers = 3;
static u32 bufsize = (720 * 576 * 2);
+static int interface;
+module_param(interface, bool, S_IRUGO);
module_param(numbuffers, uint, S_IRUGO);
module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, interface 0-1 (default:0));
MODULE_PARM_DESC(numbuffers, buffer count (default:3));
MODULE_PARM_DESC(bufsize, buffer size in bytes (default:720 x 576 x 2));
MODULE_PARM_DESC(debug, Debug level 0-1);
@@ -143,6 +154,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -152,6 +164,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -161,6 +174,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -170,6 +184,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -179,6 +194,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -188,12 +204,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
};
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
*/
static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
{
@@ -241,19 +260,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it during vpfe probe
[PATCH 2/4 - v2] V4L: ccdc driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
There was no comment against v1 of the patch. So no change in this file
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/dm355_ccdc.c | 16 +++-
drivers/media/video/davinci/dm644x_ccdc.c | 13 +
include/media/davinci/dm355_ccdc.h|2 +-
include/media/davinci/dm644x_ccdc.h |2 +-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 4629cab..4efffc2 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -92,7 +92,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
/* Object for CCDC ycbcr mode */
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
.fid_pol = VPFE_PINPOL_POSITIVE,
@@ -548,7 +548,7 @@ static int ccdc_config_vdfc(struct ccdc_vertical_dft *dfc)
*/
static void ccdc_config_csc(struct ccdc_csc *csc)
{
- u32 val1, val2;
+ u32 val1 = 0, val2;
int i;
if (!csc-enable)
@@ -925,8 +925,11 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
+ break;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -961,9 +964,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm355_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index 2f19a91..5dff8d9 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -65,7 +65,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.fid_pol = VPFE_PINPOL_POSITIVE,
.vd_pol = VPFE_PINPOL_POSITIVE,
.hd_pol = VPFE_PINPOL_POSITIVE,
@@ -825,8 +825,10 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -861,9 +863,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm644x_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm644x_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/include/media/davinci/dm355_ccdc.h
b/include/media/davinci/dm355_ccdc.h
index df8a7b1..9395900 100644
--- a/include/media/davinci/dm355_ccdc.h
+++ b/include/media/davinci/dm355_ccdc.h
@@ -254,7 +254,7 @@ struct ccdc_config_params_raw {
#ifdef __KERNEL__
#include linux/io.h
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
#define CCDC_WIN_VGA {0, 0, 640, 480}
struct ccdc_params_ycbcr {
diff --git a/include/media/davinci/dm644x_ccdc.h
b/include/media/davinci/dm644x_ccdc.h
index 3e178eb..e34a54a 100644
--- a/include/media/davinci/dm644x_ccdc.h
+++ b/include/media/davinci/dm644x_ccdc.h
@@ -131,7 +131,7 @@ struct ccdc_config_params_raw {
#define NUM_EXTRALINES 8
/* settings for commonly used video formats */
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
/* ntsc square pixel */
#define CCDC_WIN_VGA {0, 0, (640 + NUM_EXTRAPIXELS), (480 + NUM_EXTRALINES)}
--
1.6.0.4
--
To unsubscribe from this list: send
[PATCH 3/4 - v2] V4L: ccdc driver - select MSP driver for CCDC input selection
From: Muralidharan Karicheri m-kariche...@ti.com There were no comments against v1 of this patch. So no change from v1 of the patch Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to V4L-DVB linux-next repository drivers/media/video/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 8460013..a70d75a 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -565,13 +565,15 @@ config VIDEO_DM355_CCDC tristate DM355 CCDC HW module depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM + select MFD_DM355EVM_MSP default y help Enables DM355 CCD hw module. DM355 CCDC hw interfaces with decoder modules such as TVP5146 over BT656 or sensor module such as MT9T001 over a raw interface. This module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders + video frame capture from a slave decoders. MFD_DM355EVM_MSP + is enabled to select input to CCDC at run time. To compile this driver as a module, choose M here: the module will be called vpfe. -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Tue, 11 Aug 2009 17:08:27 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: I also agree with Trent that, instead of having to maintain some sort of list or code to identify string controls, the better would be to reserve one bit to indicate pointer controls (like bit 31). People tend to forget about v4l2-compat32 layer, and I bet that, if we do some sort of list, people will forget to update it when adding a new control, and compat32 layer will break. So, ctrl_is_pointer() can be just: #define ctrl_is_pointer(id) (id (1 31)) Now THAT is ugly. Anyway, you can't do it like that. Control IDs are not random but are grouped in control classes so that similar controls are together when you enumerate them. Adding flags to mark it as a specific type is 1) an ugly hack to work around an infrastructure problem, and 2) will make it impossible to group string controls together with controls that have a similar purpose. You just need to create separate groups for strings. As there are very few cases where passing a string to a control is valid, I don't see this as a big issue. The point here is that compat layer adds an extra parsing time, since it needs to repeat what is done later at v4l2-ioctl. That's said, once we have all drivers migrated to use video_ioctl2, we can work on optimizing it by removing the compat layer parser from it and letting this job to be done after parsed, at v4l2-ioctl. This will help to save the costs added by this layer. What should have happened is that we could test whether the size field is non-zero. Unfortunately, some apps do not set that field (currently a reserved field) to 0 and we never checked that in the kernel. So sadly we have to do it another way. It is not a Kernel task to check if the userspace is bad coded. If the userspace apps are not respecting V4L2 API by not zeroing the reserved fields, they need to be fixed, or they'll break sooner or later. What applications are know to break with such change? Also note that it is very likely that these two functions will disappear again in a few months: once the v4l framework has proper control support these functions should no longer be needed since this information can then be obtained directly from the framework. This don't change the fact that you'll need a sort of list or code that associates a control id with a type, called by the compat layer. Testing for a bit costs less than any table seek method. O(log N) where N is the number of registered controls. It's implemented as a binary search. It is generic and will work with whatever types we might create in the future. Since you'll probably need to run it again when parsing the control code at the framework, it will be, in fact, doubled, since you'll need to run this code twice. On the other hand, a bit seek or a a test if size is zero is O(0) 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
