Re: 1b80:d393 Afatech supported?
Please use linux-media@vger.kernel.org, video4linux-l...@redhat.com is dead. On Thu, Jul 08, 2010 at 10:54:23PM +0200, Norbert Wegener wrote: I got a Conceptronics usb dvb-t stick. lsusb displays it as: ... Bus 001 Device 007: ID 1b80:d393 Afatech Although it says Afatech, this one has a Realtek chip. AFAIK there is currently only the out-of-tree driver written by Realtek. I suggest following criticalmess' instructions in here: https://bugs.launchpad.net/ubuntu/+source/me-tv/+bug/478379 Should this driver maybe be put into staging? Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/6] v4l: subdev: Add device node support
Hi Mauro,
On Thursday 08 July 2010 15:51:33 Mauro Carvalho Chehab wrote:
Em 08-07-2010 09:08, Laurent Pinchart escreveu:
On Wednesday 07 July 2010 22:53:40 Mauro Carvalho Chehab wrote:
Em 07-07-2010 16:44, Laurent Pinchart escreveu:
On Wednesday 07 July 2010 16:58:01 Mauro Carvalho Chehab wrote:
Em 07-07-2010 08:53, Laurent Pinchart escreveu:
[snip]
+static long subdev_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return video_usercopy(file, cmd, arg, subdev_do_ioctl);
This is a legacy call. Please, don't use it.
What should I use instead then ? I need the functionality of
video_usercopy. I could copy it to v4l2-subdev.c verbatim. As
video_ioctl2 shares lots of code with video_usercopy I think
video_usercopy should stay, and video_ioctl2 should use it.
The bad thing of video_usercopy() is that it has a compat code, to fix
broken definitions of some iotls (see video_fix_command()), and that a
few drivers still use it, instead of video_ioctl2.
video_ioctl2 has the same compat code.
Yes, in order to avoid breaking binary compatibility with files compiled
against the old videodev2.h header that used to declare some ioctls as:
[snip]
This doesn't make sense for subdev, as old binary-only applications will
never use the legacy ioctl definitions.
Probably, we can mark this legacy support for removal at
Documentation/feature-removal-schedule.txt, and remove
it on a latter version of the kernel. It seems that the old ioctl
definitions are before 2005 (before 2.6.12):
Good idea.
[snip]
What about renaming video_usercopy to __video_usercopy, adding an
argument to enable/disable the compat code, create a new video_usercopy
that calls __video_usercopy with compat code enabled, have video_ioctl2
call __video_usercopy with compat code enabled, and having subdev_ioctl
call __video_usercopy with compat code disabled ?
Seems good, but maybe the better is to put the call to video_fix_command()
outside the common function.
Agreed. It belongs to video_usercopy and video_ioctl2.
We may add also a printk for the video_usercopy wrapper printing that the
driver is using a legacy API call, and that this will be removed on a next
kernel version. Maybe this way, people will finally submit patches porting
the last remaining drivers to video_ioctl2.
I suspect, however, that we'll end by needing a subdev-specific version of
__video_usercopy, as we add new ioctls to subdev.
If we need one then I'll create one in v4l2-subdev.c, but as long as we don't
there's little point in duplicating the code.
I've had a look at video_usercopy and video_ioctl2, and the functions are
mostly identical. The differences are
- video_ioctl2 passes the original arg argument to __video_do_ioctl for _IO
ioctls. video_usercopy passes NULL. This seems to be used by the ivtv driver
to handle DVB _IO ioctls (VIDEO_SELECT_SOURCE, AUDIO_SET_MUTE,
AUDIO_CHANNEL_SELECT and AUDIO_BILINGUAL_CHANNEL_SELECT) that pass an integer
through the ioctl argument. Any objection against passing the original
argument to the ioctl handler in video_usercopy as well ? I've quickly checked
the video_usercopy users and none of them seem to check that arg is NULL for
_IO ioctls. This should thus be harmless.
- For argument of known ioctls that have a few input fields at the beginning
of the structure followed by output fields, video_ioctl2 only copies the input
fields from userspace and zeroes out the rest. video_usercopy doesn't. Do we
have video_usercopy drivers that abuse the output fields to pass information
to the driver, or could the video_ioctl2 behaviour be generalized to
video_usercopy ?
If the answer to the two questions is yes, video_usercopy and video_ioctl2
could use the same code. Otherwise they can't, and in that case I should
probably use video_usercopy in v4l2-subdev.c, replacing it with a private copy
when it will disappear.
--
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: V4L2 radio drivers for TI-WL7
On Tuesday 06 July 2010 07:07:12 Pavan Savoy wrote: --- On Mon, 5/7/10, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hverk...@xs4all.nl Subject: Re: V4L2 radio drivers for TI-WL7 To: pavan_sa...@ti.com Cc: linux-media@vger.kernel.org, matti.j.aalto...@nokia.com, mche...@infradead.org, pavan savoy pavan_sa...@yahoo.co.in, eduardo.valen...@nokia.com Date: Monday, 5 July, 2010, 11:51 AM On Friday 02 July 2010 09:01:34 Pavan Savoy wrote: Hi, We have/in process of developing a V4L2 driver for the FM Radio on the Texas Instruments WiLink 7 module. For transport/communication with the chip, we intend to use the shared transport driver currently staged in mainline at drivers/staging/ti-st/. To which tree should I generate patches against? is the tree git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git fine ? to be used with the v4l_for_2.6.35 branch ? You patch against git://git.linuxtv.org/v4l-dvb.git. Also, this is over the UART/TTY unlike the WL1273 i2c mfd driver... Is the WiLink 7 a platform device (i.e. an integral part of the CPU) or a separate chip that can be used with any hardware? Will the FM Radio always be controlled over a UART/TTY bus or is that specific to your development platform? WiLink 7 would be a peripheral which has 1 interface with apps processor being UART, more details at, http://www.google.co.in/url?sa=tsource=webcd=3ved=0CBQQFjACurl=http%3A%2F%2Ffocus.ti.com%2Fgeneral%2Fdocs%2Fwtbu%2Fwtbuproductcontent.tsp%3FtemplateId%3D6123%26navigationId%3D12859%26contentId%3D67453%26DCMP%3Dwtbu_wilink7_2010%26HQS%3DOther%2BPR%2Bwilink7videosei=d7kyTKPXMoTGlQfJ-7W-Cwusg=AFQjCNEjN2jc9TdSDWDRtWcmbZn6Szhbugsig2=DN4gAQls9AdOeHQhlPlvjA Since there exists only 1 interface for all BT/FM and GPS cores on chip, a shared transport driver has been developed and placed at drivers/staging/ti-st/ It sounds like this will be typically used in embedded systems and implemented as a platform device. Would it be suitable if we place the V4L2 FM driver at drivers/staging/ti-st/ to ? Since we don't have the common interface headers such as st.h in include/linux.. Staging is fine. This driver can still be merged through the v4l-dvb repositories, even if it is in staging. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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 v4 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hi Matti,
My apologies for the long delay in reviewing. But here is (finally!) my
review of this code.
On Friday 04 June 2010 12:34:20 Matti J. Aaltonen wrote:
This is a parent driver for two child drivers: the V4L2 driver and
the ALSA codec driver. The MFD part provides the I2C communication
to the device and a couple of functions that are called from both
children.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
drivers/mfd/Kconfig |6 +
drivers/mfd/Makefile|2 +
drivers/mfd/wl1273-core.c | 616
+++
include/linux/mfd/wl1273-core.h | 326 +
4 files changed, 950 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 413576a..5998a94 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -135,6 +135,12 @@ config TWL4030_CODEC
select MFD_CORE
default n
+config WL1273_CORE
+ bool
+ depends on I2C
+ select MFD_CORE
+ default n
+
config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 78295d6..46e611d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o
twl6030-irq.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_TWL4030_CODEC) += twl4030-codec.o
+obj-$(CONFIG_WL1273_CORE)+= wl1273-core.o
+
obj-$(CONFIG_MFD_MC13783)+= mc13783-core.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..6c7dbba
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,616 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen matti.j.aalto...@nokia.com
+ *
+ * Copyright: (C) 2010 Nokia 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include asm/unaligned.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/platform_device.h
+#include linux/mfd/core.h
+#include linux/mfd/wl1273-core.h
+#include media/v4l2-common.h
+
+#define DRIVER_DESC WL1273 FM Radio Core
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT | \
+ WL1273_POW_ENB_EVENT)
+
+static const struct band_info bands[] = {
+ /* USA Europe */
+ {
+ .bottom_frequency = 87500,
+ .top_frequency = 108000,
+ .band = V4L2_FM_BAND_OTHER,
+ },
+ /* Japan */
+ {
+ .bottom_frequency = 76000,
+ .top_frequency = 9,
+ .band = V4L2_FM_BAND_JAPAN,
+ },
+};
+
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
+ */
+static unsigned char radio_band = 1;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, Band: 0=Japan, 1=USA-Europe*);
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0);
+MODULE_PARM_DESC(rds_buf, RDS buffer entries: *100*);
+
+int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+ struct i2c_client *client = core-i2c_dev;
+ u8 b[2];
+ int r;
+
+ r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
+ if (r != 2) {
+ dev_err(client-dev, %s: Read: %d fails.\n, __func__, reg);
+ return -EREMOTEIO;
+ }
+
+ *value = (u16)b[0] 8 | b[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_read_reg);
+
+int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+ struct i2c_client *client = core-i2c_dev;
+ u8 buf[] = { (param 8) 0xff, param 0xff };
+ int r;
+
+ r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
Re: [PATCH v4 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.
On Friday 04 June 2010 12:34:22 Matti J. Aaltonen wrote:
This file implements V4L2 controls for using the Texas Instruments
WL1273 FM Radio.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1907
3 files changed, 1923 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate Texas Instruments WL1273 I2C FM Radio
+depends on I2C VIDEO_V4L2 SND
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..473c194
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1907 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen matti.j.aalto...@nokia.com
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include asm/unaligned.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/mfd/wl1273-core.h
+#include linux/platform_device.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+
+#define DRIVER_DESC Wl1273 FM Radio - V4L2
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FM (1 0)
+#define WL1273_POWER_SET_RDS (1 1)
+#define WL1273_POWER_SET_RETENTION (1 4)
+
+#define WL1273_PUPD_SET_OFF 0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION0x10
+
+#define WL1273_FREQ_MULT (1 / 625)
+#define WL1273_INV_FREQ_MULT (625 / 1)
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
+ */
+static unsigned char radio_band = 1;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, Band: 0=Japan, 1=USA-Europe*);
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, Radio Nr);
+
+struct wl1273_device {
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ struct file *owner;
+ char *write_buf;
+ bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+ int r = 0;
+
+ if (freq 76000) {
+ dev_err(core-i2c_dev-dev,
+ Frequency out of range: %d %d\n,
+ freq, core-bands[core-band].bottom_frequency);
+ return -EDOM;
+ }
+
+ if (freq 108000) {
+ dev_err(core-i2c_dev-dev,
+ Frequency out of range: %d %d\n,
+ freq, core-bands[core-band].top_frequency);
+
Re: [PATCH v4 1/5] V4L2: Add seek spacing and FM RX class.
On Friday 04 June 2010 12:34:19 Matti J. Aaltonen wrote:
Add spacing field to v4l2_hw_freq_seek and also add FM RX class to
control classes.
Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
include/linux/videodev2.h | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..95675cd 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -935,6 +935,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099 /* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a/* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
#define V4L2_CTRL_ID_MASK (0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1313,6 +1314,17 @@ enum v4l2_preemphasis {
#define V4L2_CID_TUNE_POWER_LEVEL(V4L2_CID_FM_TX_CLASS_BASE +
113)
#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
+/* FM Tuner class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE(V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_FM_RX_BAND (V4L2_CID_FM_TX_CLASS_BASE + 1)
+enum v4l2_fm_rx_band {
+ V4L2_FM_BAND_OTHER = 0,
+ V4L2_FM_BAND_JAPAN = 1,
+ V4L2_FM_BAND_OIRT = 2
+};
I've been thinking about this a bit more. Would it be possible to do this
automatically
in the driver? I.e. based on the frequency you switch the device into the
appropriate
band?
If that is not possible, then you shouldn't forget to document this new control
in the spec.
When you document it you should give some background information as well: the
freq ranges of
these bands and roughly where they are used.
Regards,
Hans
+
/*
* T U N I N G
*/
@@ -1377,7 +1389,8 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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: Confusing mediabus formats
On Tuesday 11 May 2010 09:07:25 Guennadi Liakhovetski wrote: On Mon, 10 May 2010, Guennadi Liakhovetski wrote: (added Laurent to CC as he once asked me about these on IRC too) On Sun, 9 May 2010, Hans Verkuil wrote: Hi Guennadi, I'm preparing a patch series that replaces enum/g/try/s_fmt with enum/g/try/s/_mbus_fmt in all subdevs. While doing that I stumbled on a confusing definition of the YUV mediabus formats. Currently we have these: V4L2_MBUS_FMT_YUYV8_2X8_LE, V4L2_MBUS_FMT_YVYU8_2X8_LE, V4L2_MBUS_FMT_YUYV8_2X8_BE, V4L2_MBUS_FMT_YVYU8_2X8_BE, The meaning of 2X8 is defined as: 'one pixel is transferred in two 8-bit samples'. This is confusing since you cannot really say that a Y and U pair constitutes one pixel. And is it Y or U/V which constitutes the 'most-significant bits' in such a 16-bit number? To recap, as we discussed it earlier this notation was one of your suggestions: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/12830/focus=13394 Yes, I certainly agree, that LE and BE notations are not necessarily very logical here, as you say, they don't make much sense in the YUV case. But they do, e.g., in RGB565 case, as we discussed this with Laurent on IRC. Basically, the information we want to include in the name is: pixel format family (YUYV8) number of samples, that constitute one pixel (*) and bits per sample order of samples in pixel Now that I think about it a bit more, it looks like we only have to distinguish between two cases: consecutive storage order of samples in memory (sample0 to address0, sample1 to address1, etc.) or reverse order. This is relatively easy to formulate, when samples span across bytes, but not so easy, when they get packed into one byte. E.g., for a 4-bit interface, do we have to specify two ordering parameters: nibbles in bytes and bytes in memory? Any name propositions for these ordering variants? Remember that in the case of a bus there are no 'bytes' as such. Just data flowing through the bus. In all existing mbus_pixelcodes (except the four YUV codes) it is clear what the meaning is: V4L2_MBUS_FMT_sample_bus width[_padding][_endianness] Where sample describes what a single pixel sample looks like: the total width and the order of the subsamples inside. The bus width is the number of lines used to transport the sample over the bus. If a sample is split up in two consecutive writes (e.g. 2X8), then additional info is provided for optional padding and endianness. Perfectly understandable. The problem with the YUV variants is that the term 'sample' does not really apply. It's similar to the V4L2_MBUS_FMT_SBGGR8_1X8 bayer format: here the sample width is just 8 bits and 'BGGR' describes the order of the blue, green and red samples over the bus. I wonder, does the prefix 'S' in the sample description mean that the sub-sample order is described? If so, then to be consistent I would propose these mediabus formats: V4L2_MBUS_FMT_SYUYV8_1X8, V4L2_MBUS_FMT_SYVYU8_1X8, V4L2_MBUS_FMT_SUYVY8_1X8, V4L2_MBUS_FMT_SVYUY8_1X8, Regarding 4-bit wide busses: the scheme is generic enough for that: E.g. V4L2_MBUS_FMT_SYUYV8_1X8 for a 4-bit bus would become: V4L2_MBUS_FMT_SYUYV8_2X4_LE V4L2_MBUS_FMT_SYUYV8_2X4_BE Again, how this ends up in memory is unrelated to these mbus_pixelcodes. As discussed in Helsinki we need to get this sorted out soon since this header is going to be public in the near future. Regards, Hans Thanks Guennadi (*) pixel is not necessarily a complete pixel, i.e., might not carry all colours in it. E.g., in YUYV pixel refers to any of the YU and YV pairs. In other words, this is just = frame size * 8 / number of pixels / bits-per-sample. In my particular case I have to translate a V4L2_PIX_FMT_UYVY to a suitable mediabus format. I think it would map to V4L2_MBUS_FMT_YUYV8_2X8_LE, but frankly I'm not sure. My suggestion is to rename these mediabus formats to: V4L2_MBUS_FMT_YUYV8_1X8, V4L2_MBUS_FMT_YVYU8_1X8, V4L2_MBUS_FMT_UYVY8_1X8, V4L2_MBUS_FMT_VYUY8_1X8, But what do you do with, e.g., RGB565? You have to differentiate between rggb bggr gggrbggg gggbrggg with the current notation they are RGB565_2X8_BE BGR565_2X8_BE BGR565_2X8_LE RGB565_2X8_LE and how would you call them? And what do you do with Y10_2X8_LE and _BE (padding omitted for simplicity)? Also, Laurent has suggested V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_YVYU8_2X8, V4L2_MBUS_FMT_UYVY8_2X8, V4L2_MBUS_FMT_VYUY8_2X8, and I like that better, than 1X8, but still it doesn't resolve my above doubts. Ideas? Suggestions? Here it is immediately
Re: [PATCH] Mantis DMA transfer cleanup, fixes data corruption and a race, improves performance. (signed-off this time)
Marko Ristola marko.rist...@kolumbus.fi writes: This is a resend of the exactly same patch than I sent 2010-06-20, to sign off it. Signed-off-by: Marko M Ristola marko.rist...@kolumbus.fi I have successfully used this patch with a Terratec Cinergy C PCI HD since Marko posted it on 2010-06-20. My impression is that it does improve driver stability, although I do not have any hard numbers to support that. Anyway, if it helps review, feel free to add Tested-by: Bjørn Mork bj...@mork.no to the patch. BTW, I have imported this patch in a local git repository for my own use, together with a few other mantis patches currently under review. Please let me know if any of you would want to pull from there to make the process easier. The repository is currently based on git://linuxtv.org/v4l-dvb.git devel/for_v2.6.36 Bjørn -- 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] Mantis: append tasklet maintenance for DVB stream delivery
Marko Ristola marko.rist...@kolumbus.fi writes:
20.06.2010 16:51, Bjørn Mork kirjoitti:
Note that mantis_core_exit() is never called. Unless I've missed
something, the drivers/media/dvb/mantis/mantis_core.{h,c} files can
just be deleted. They look like some development leftovers?
I see. mantis_core.ko kernel module exists though.
Maybe the mantis/Makefile references for mantis_core.c, mantis.c and
hopper.c are just some leftovers too.
I moved tasklet_enable/disable calls into mantis_dvb.c where almost
all other tasklet code is located.
So the following reasoning still holds:
1. dvb_dmxdev_filter_stop() calls mantis_dvb_stop_feed: mantis_dma_stop()
2. dvb_dmxdev_filter_stop() calls release_ts_feed() or some other
filter freeing function.
3. tasklet: mantis_dma_xfer calls dvb_dmx_swfilter to copy DMA
buffer's content into freed memory, accessing freed spinlocks.
This case might occur while tuning into another frequency.
Perhaps cdurrhau has found some version from this bug at
http://www.linuxtv.org/pipermail/linux-dvb/2010-June/032688.html:
This is what I get on the remote console via IPMI:
40849.442492] BUG: soft lockup - CPU#2 stuck for 61s! [section
handler:4617]
New reasoning for the patch (same as the one above, but from higher level):
After dvb-core has called mantis-fe-stop_feed(dvbdmxfeed) the last
time (count to zero),
no data should ever be copied with dvb_dmx_swfilter() by a tasklet:
the target structure might be in an unusable state.
Caller of mantis_fe-stop_feed() assumes that feeding is stopped after
stop_feed() has been called, ie. dvb_dmx_swfilter()
isn't running, and won't be called.
There is a risk that dvb_dmx_swfilter() references freed resources
(memory or spinlocks or ???) causing instabilities.
Thus tasklet_disable(mantis-tasklet) must be called inside of
mantis-fe-stop_feed(dvbdmxfeed) when necessary.
Signed-off-by: Marko Ristola marko.rist...@kolumbus.fi
Tested-by: Bjørn Mork bj...@mork.no
I have successfully used this patch with a Terratec Cinergy C PCI HD
card in a system with a quad-core CPU and one other DVB-C card. I
believe it does improve stability under these conditions.
Don't know if this helps anyone, but I guess it can't harm in an
environment where there are noone willing to do even an Acked-by...
Bjørn
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index 99d82ee..a9864f7 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -117,6 +117,7 @@ static int mantis_dvb_start_feed(struct
dvb_demux_feed *dvbdmxfeed)
if (mantis-feeds == 1) {
dprintk(MANTIS_DEBUG, 1, mantis start feed dma);
mantis_dma_start(mantis);
+tasklet_enable(mantis-tasklet);
}
return mantis-feeds;
@@ -136,6 +137,7 @@ static int mantis_dvb_stop_feed(struct
dvb_demux_feed *dvbdmxfeed)
mantis-feeds--;
if (mantis-feeds == 0) {
dprintk(MANTIS_DEBUG, 1, mantis stop feed and dma);
+tasklet_disable(mantis-tasklet);
mantis_dma_stop(mantis);
}
@@ -216,6 +218,7 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
dvb_net_init(mantis-dvb_adapter, mantis-dvbnet,
mantis-demux.dmx);
tasklet_init(mantis-tasklet, mantis_dma_xfer, (unsigned long)
mantis);
+tasklet_disable(mantis-tasklet);
if (mantis-hwconfig) {
result = config-frontend_init(mantis, mantis-fe);
if (result 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
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
Em 08-07-2010 19:10, Ivan escreveu: On 07/08/2010 05:49 PM, Devin Heitmueller wrote: That card does have an onboard scaler, although it's not clear to me why it isn't working. Exactly what command line did you use? At first, I was always using mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC which defaults to a resolution of 640x480. This output looked correct (except for vertical stripes) in kernel 2.6.32-23-generic, but was horizontally shifted after I updated to the current mercurial sources. I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Then I noticed that mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC:width=720 gives a correct picture with current hg source. v4l2: 1199 frames successfully processed, -3 frames dropped. This is not a V4L issue. A negative number of dropping frames makes no sense. It is probably a mplayer bug. I would try to get a newer version of mplayer and double check. If your video adapter is not fast enough, or if some post-processing logic at mplayer are enabled and you don't have enough processing speed at both CPU and GPU, mplayer may complain about frames dropped. It may also be related to audio driver, if you're enabling alsa at .mplayer/config. When you have frames dropped, it may help to replace the video and audio output (-vo and -ao) to use one of the several different mplayer output drivers. On my own tests, I generally use sdl, gl or gl2 drivers for output, instead of x11, as they provide a better performance with the video adapters I have here. To get a list of available drivers, you may use: $ mplayer -vo help ... Yeah, I don't know. You would have to ask the mplayer/mencoder people. Ah, so those statistics are generated by mplayer, then, not by v4l. It would also seem that V4L doesn't actually discard any frames... ...blah blah blah about mencoder... Again, this would be an mplayer/mencoder thing. I guess I'm just trying to confirm that v4l doesn't try to enforce a strict NTSC framerate, but just passes all frames on even if they appear at a slightly different framerate. V4L doesn't enforce a framerate. It will just send frames to userspace as they're being available by the hardware and provided that the application is fast enough to get frames at the hardware speed. em28xx hardware outputs NTSC frames at about 30 fps. Ivan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/35] ivtv: use kthread_worker instead of workqueue
On Tue, 2010-07-06 at 09:01 +0200, Tejun Heo wrote: On 07/05/2010 07:11 PM, Andy Walls wrote: Assuming the new kthread_worker implementation is OK, this change for ivtv looks good. Reviewed-by: Andy Walls awa...@md.metrocast.net Acked-by: Andy Walls awa...@md.metrocast.net May I route this patch through wq branch? As it's not clear how this whole patchset will end up, I think it would be better to keep things isolated in this branch. Yes, I think that is the best way to do things. Regards, Andy -- 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: Question about BTTV-video controls whitecrush upper/lower
On Tue, 2010-07-06 at 13:27 +0200, Frank Schaefer wrote: Hi, there are two video controls in the Bttv-driver called whitecrush upper and whitecrush lower. But what does whitecrush mean ? Is it the same as white noise ? The german KDE translators are currently trying to translate these strings... White Crush is Conexant's term for adapting to nonstandard or varying Sync to White level voltage differences of the incoming video signal. It's basically an adaptive AGC to prevent blooming of the video signal due to very high Luminance levels. The public BT878A datasheet has terse descriptions of what the registers settings do: they are basically upper and lower thresholds to determine when to adapt the automatic gain control. The public CX25840 datasheet gives a better written description of white crush in section 3.4.9: http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf I'm actually surprised the bttv driver has those presented as user controls at all. Regards, Andy Thanks, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] OMAP2/3 Bug Fixes
The following changes since commit 8310922e9b094c90665df0db6823172fbf053889: Mauro Carvalho Chehab (1): Merge tag 'v2.6.35-rc3' into devel/for_v2.6.35 are available in the git repository at: http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git linux-media-devel-for_v2.6.35 Vaibhav Hiremath (3): OMAP_VOUT:Build FIX: Rebased against latest DSS2 changes OMAP_VOUT:FIX:Replaced dma-sg with dma-contig OMAP_VOUT:FIX: Module params were not working through bootargs drivers/media/video/omap/Kconfig |4 +- drivers/media/video/omap/Makefile|4 +- drivers/media/video/omap/omap_vout.c | 81 ++--- 3 files changed, 38 insertions(+), 51 deletions(-) Thanks, Vaibhav Hiremath -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 0/7] V4L2 subdev userspace API
Hi everybody, Here's the second version of the V4L2 subdev userspace API patches. Comments received on the first version have been incorporated, with the exception of the video_usercopy usage as this is still under discussion. A problem with module reference counting has also been solved by setting the owner of the subdev device node to the subdev driver, not videodev.ko. This required a change to the v4l2_i2c_new_subdev_board function prototype, and thus a modification to the radio-si4713 driver. Due to the fast review (thanks everybody) I haven't had time to finish the media controller core patches, but they will arrive soon. Laurent Pinchart (6): v4l: subdev: Don't require core operations v4l: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev v4l: subdev: Add device node support v4l: subdev: Uninline the v4l2_subdev_init function v4l: subdev: Control ioctls support v4l: subdev: Generic ioctl support Sakari Ailus (1): v4l: subdev: Events support Documentation/video4linux/v4l2-framework.txt | 57 + drivers/media/radio/radio-si4713.c |2 +- drivers/media/video/Makefile |2 +- drivers/media/video/soc_camera.c |2 +- drivers/media/video/v4l2-common.c| 22 ++-- drivers/media/video/v4l2-dev.c | 27 ++--- drivers/media/video/v4l2-device.c| 25 - drivers/media/video/v4l2-subdev.c| 172 ++ include/media/v4l2-common.h | 21 +--- include/media/v4l2-dev.h | 18 +++- include/media/v4l2-subdev.h | 40 --- 11 files changed, 326 insertions(+), 62 deletions(-) create mode 100644 drivers/media/video/v4l2-subdev.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 1/7] v4l: subdev: Don't require core operations
There's no reason to require subdevices to implement the core
operations. Remove the check for non-NULL core operations when
initializing the subdev.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 02c6f4d..6088316 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -437,8 +437,7 @@ static inline void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops)
{
INIT_LIST_HEAD(sd-list);
- /* ops-core MUST be set */
- BUG_ON(!ops || !ops-core);
+ BUG_ON(!ops);
sd-ops = ops;
sd-v4l2_dev = NULL;
sd-flags = 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 2/7] v4l: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev
v4l2_i2c_new_subdev_cfg is called by v4l2_i2c_new_subdev only. Merge the
two functions into v4l2_i2c_new_subdev.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-common.c |7 ++-
include/media/v4l2-common.h | 15 +--
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 4e53b0b..bbda421 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -897,10 +897,9 @@ error:
}
EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_board);
-struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device *v4l2_dev,
+struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
const char *module_name, const char *client_type,
- int irq, void *platform_data,
u8 addr, const unsigned short *probe_addrs)
{
struct i2c_board_info info;
@@ -910,13 +909,11 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct
v4l2_device *v4l2_dev,
memset(info, 0, sizeof(info));
strlcpy(info.type, client_type, sizeof(info.type));
info.addr = addr;
- info.irq = irq;
- info.platform_data = platform_data;
return v4l2_i2c_new_subdev_board(v4l2_dev, adapter, module_name,
info, probe_addrs);
}
-EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev_cfg);
+EXPORT_SYMBOL_GPL(v4l2_i2c_new_subdev);
/* Return i2c client address of v4l2_subdev. */
unsigned short v4l2_i2c_subdev_addr(struct v4l2_subdev *sd)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 98b3264..6fc3d7a 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -139,24 +139,11 @@ struct v4l2_subdev_ops;
/* Load an i2c module and return an initialized v4l2_subdev struct.
Only call request_module if module_name != NULL.
The client_type argument is the name of the chip that's on the adapter. */
-struct v4l2_subdev *v4l2_i2c_new_subdev_cfg(struct v4l2_device *v4l2_dev,
+struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter,
const char *module_name, const char *client_type,
- int irq, void *platform_data,
u8 addr, const unsigned short *probe_addrs);
-/* Load an i2c module and return an initialized v4l2_subdev struct.
- Only call request_module if module_name != NULL.
- The client_type argument is the name of the chip that's on the adapter. */
-static inline struct v4l2_subdev *v4l2_i2c_new_subdev(struct v4l2_device
*v4l2_dev,
- struct i2c_adapter *adapter,
- const char *module_name, const char *client_type,
- u8 addr, const unsigned short *probe_addrs)
-{
- return v4l2_i2c_new_subdev_cfg(v4l2_dev, adapter, module_name,
- client_type, 0, NULL, addr, probe_addrs);
-}
-
struct i2c_board_info;
struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 7/7] v4l: subdev: Generic ioctl support
Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 89bd881..581e7db 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -365,6 +365,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 31bec67..ce47772 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -120,7 +120,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg); default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 6/7] v4l: subdev: Events support
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Provide v4l2_subdevs with v4l2_event support. Subdev drivers only need very
little to support events.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: David Cohen david.co...@nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/video4linux/v4l2-framework.txt | 18 +++
drivers/media/video/v4l2-subdev.c| 71 +-
include/media/v4l2-subdev.h | 10
3 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index 9c3f33c..89bd881 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -347,6 +347,24 @@ VIDIOC_TRY_EXT_CTRLS
controls can be also be accessed through one (or several) V4L2 device
nodes.
+VIDIOC_DQEVENT
+VIDIOC_SUBSCRIBE_EVENT
+VIDIOC_UNSUBSCRIBE_EVENT
+
+ The events ioctls are identical to the ones defined in V4L2. They
+ behave identically, with the only exception that they deal only with
+ events generated by the sub-device. Depending on the driver, those
+ events can also be reported by one (or several) V4L2 device nodes.
+
+ Sub-device drivers that want to use events need to set the
+ V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize
+ v4l2_subdev::nevents to events queue depth before registering the
+ sub-device. After registration events can be queued as usual on the
+ v4l2_subdev::devnode device node.
+
+ To properly support events, the poll() file operation is also
+ implemented.
+
I2C sub-device drivers
--
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 0ebd760..31bec67 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -18,26 +18,64 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include linux/types.h
#include linux/ioctl.h
+#include linux/slab.h
+#include linux/types.h
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
static int subdev_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_fh *vfh;
+ int ret;
if (!sd-initialized)
return -EAGAIN;
+ vfh = kzalloc(sizeof(*vfh), GFP_KERNEL);
+ if (vfh == NULL)
+ return -ENOMEM;
+
+ ret = v4l2_fh_init(vfh, vdev);
+ if (ret)
+ goto err;
+
+ if (sd-flags V4L2_SUBDEV_FL_HAS_EVENTS) {
+ ret = v4l2_event_init(vfh);
+ if (ret)
+ goto err;
+
+ ret = v4l2_event_alloc(vfh, sd-nevents);
+ if (ret)
+ goto err;
+ }
+
+ v4l2_fh_add(vfh);
+ file-private_data = vfh;
+
return 0;
+
+err:
+ v4l2_fh_exit(vfh);
+ kfree(vfh);
+
+ return ret;
}
static int subdev_close(struct file *file)
{
+ struct v4l2_fh *vfh = file-private_data;
+
+ v4l2_fh_del(vfh);
+ v4l2_fh_exit(vfh);
+ kfree(vfh);
+
return 0;
}
@@ -45,6 +83,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
{
struct video_device *vdev = video_devdata(file);
struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_fh *fh = file-private_data;
switch (cmd) {
case VIDIOC_QUERYCTRL:
@@ -68,6 +107,18 @@ static long subdev_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
case VIDIOC_TRY_EXT_CTRLS:
return v4l2_subdev_call(sd, core, try_ext_ctrls, arg);
+ case VIDIOC_DQEVENT:
+ if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
+ return -ENOIOCTLCMD;
+
+ return v4l2_event_dequeue(fh, arg, file-f_flags O_NONBLOCK);
+
+ case VIDIOC_SUBSCRIBE_EVENT:
+ return v4l2_subdev_call(sd, core, subscribe_event, fh, arg);
+
+ case VIDIOC_UNSUBSCRIBE_EVENT:
+ return v4l2_subdev_call(sd, core, unsubscribe_event, fh, arg);
+
default:
return -ENOIOCTLCMD;
}
@@ -81,11 +132,29 @@ static long subdev_ioctl(struct file *file, unsigned int
cmd,
return video_usercopy(file, cmd, arg, subdev_do_ioctl);
}
+static unsigned int subdev_poll(struct file *file, poll_table *wait)
+{
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_subdev *sd = vdev_to_v4l2_subdev(vdev);
+ struct v4l2_fh *fh = file-private_data;
+
+ if (!(sd-flags V4L2_SUBDEV_FL_HAS_EVENTS))
+ return POLLERR;
+
+
[RFC/PATCH v2 4/7] v4l: subdev: Uninline the v4l2_subdev_init function
The function isn't small or performance sensitive enough to be inlined.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-subdev.c | 14 ++
include/media/v4l2-subdev.h | 15 ++-
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index f016376..37142ae 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -63,3 +63,17 @@ const struct v4l2_file_operations v4l2_subdev_fops = {
.unlocked_ioctl = subdev_ioctl,
.release = subdev_close,
};
+
+void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
+{
+ INIT_LIST_HEAD(sd-list);
+ BUG_ON(!ops);
+ sd-ops = ops;
+ sd-v4l2_dev = NULL;
+ sd-flags = 0;
+ sd-name[0] = '\0';
+ sd-grp_id = 0;
+ sd-priv = NULL;
+ sd-initialized = 1;
+}
+EXPORT_SYMBOL(v4l2_subdev_init);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index dc0ccd3..9ee45c8 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -444,19 +444,8 @@ static inline void *v4l2_get_subdevdata(const struct
v4l2_subdev *sd)
return sd-priv;
}
-static inline void v4l2_subdev_init(struct v4l2_subdev *sd,
- const struct v4l2_subdev_ops *ops)
-{
- INIT_LIST_HEAD(sd-list);
- BUG_ON(!ops);
- sd-ops = ops;
- sd-v4l2_dev = NULL;
- sd-flags = 0;
- sd-name[0] = '\0';
- sd-grp_id = 0;
- sd-priv = NULL;
- sd-initialized = 1;
-}
+void v4l2_subdev_init(struct v4l2_subdev *sd,
+ const struct v4l2_subdev_ops *ops);
/* Call an ops of a v4l2_subdev, doing the right checks against
NULL pointers.
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v2 3/7] v4l: subdev: Add device node support
Create a device node named subdevX for every registered subdev.
As the device node is registered before the subdev core::s_config
function is called, return -EGAIN on open until initialization
completes.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Vimarsh Zutshi vimarsh.zut...@nokia.com
---
Documentation/video4linux/v4l2-framework.txt | 18 +++
drivers/media/radio/radio-si4713.c |2 +-
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_camera.c |2 +-
drivers/media/video/v4l2-common.c| 15 +-
drivers/media/video/v4l2-dev.c | 27 --
drivers/media/video/v4l2-device.c| 25 +-
drivers/media/video/v4l2-subdev.c| 65 ++
include/media/v4l2-common.h |6 ++-
include/media/v4l2-dev.h | 18 ++-
include/media/v4l2-subdev.h | 16 ++-
11 files changed, 166 insertions(+), 30 deletions(-)
create mode 100644 drivers/media/video/v4l2-subdev.c
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index e831aac..164bb0f 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -314,6 +314,24 @@ controlled through GPIO pins. This distinction is only
relevant when setting
up the device, but once the subdev is registered it is completely transparent.
+V4L2 sub-device userspace API
+-
+
+Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2
+sub-devices can also be controlled directly by userspace applications.
+
+When a sub-device is registered, a device node named v4l-subdevX can be created
+in /dev. If the sub-device supports direct userspace configuration it must set
+the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered.
+
+For I2C and SPI sub-devices, the v4l2_device driver can disable registration of
+the device node if it wants to control the sub-device on its own. In that case
+it must set the v4l2_i2c_new_subdev_board or v4l2_spi_new_subdev enable_devnode
+argument to 0. Setting the argument to 1 will only enable device node
+registration if the sub-device driver has set the V4L2_SUBDEV_FL_HAS_DEVNODE
+flag.
+
+
I2C sub-device drivers
--
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index 13554ab..58dd199 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -292,7 +292,7 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
}
sd = v4l2_i2c_new_subdev_board(rsdev-v4l2_dev, adapter, si4713_i2c,
- pdata-subdev_board_info, NULL);
+ pdata-subdev_board_info, NULL, 0);
if (!sd) {
dev_err(pdev-dev, Cannot get v4l2 subdevice\n);
rval = -ENODEV;
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..c9c07e5 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -11,7 +11,7 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o
omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
- v4l2-event.o
+ v4l2-event.o v4l2-subdev.o
# V4L2 core modules
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 475757b..10fae27 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -895,7 +895,7 @@ static int soc_camera_init_i2c(struct soc_camera_device
*icd,
icl-board_info-platform_data = icd;
subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
- icl-module_name, icl-board_info, NULL);
+ icl-module_name, icl-board_info, NULL, 0);
if (!subdev)
goto ei2cnd;
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index bbda421..4265562 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -838,7 +838,8 @@ EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
/* Load an i2c sub-device. */
struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev,
struct i2c_adapter *adapter, const char *module_name,
- struct i2c_board_info *info, const unsigned short *probe_addrs)
+ struct i2c_board_info *info, const unsigned short *probe_addrs,
+ int enable_devnode)
{
struct v4l2_subdev *sd = NULL;
struct i2c_client *client;
@@ -868,9 +869,12 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct
v4l2_device *v4l2_dev,
if (!try_module_get(client-driver-driver.owner))
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/09/2010 08:47 AM, Mauro Carvalho Chehab wrote: I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Huh? Does there even *exist* a proprietary linux driver for my card? And because you never saw stripes with em28xx, they must not exist? :^P You might want to reread the thread-- we already figured the stripes out. v4l2: 1199 frames successfully processed, -3 frames dropped. This is not a V4L issue. I'm aware of that by now. A negative number of dropping frames makes no sense. It is probably a mplayer bug. I would try to get a newer version of mplayer and double check. Newer than latest svn? :^D If you look at the mplayer code that calculates the supposed number of frames dropped (it's in stream/tvi_v4l2.c), it would seem that it's just an indicator of how close the stream came to the nominal framerate (3/1001 in my case). In other words, if mplayer sees an actual framerate of less than 29.97 coming from v4l, it assumes (perhaps incorrectly) that this is because some frames were dropped. If you do the same calculation when the actual framerate is greater than 29.97, you get a negative number of dropped frames. It looks weird, but it makes a kind of sense if you know what it really means. -- 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] Mantis: append tasklet maintenance for DVB stream delivery
Resending into linux-media, for confirming authorship:
I have personally done this patch.
Acked-by: Marko M Ristola marko.rist...@kolumbus.fi
Regards,
Marko
20.06.2010 16:51, Bjørn Mork kirjoitti:
Note that mantis_core_exit() is never called. Unless I've missed
something, the drivers/media/dvb/mantis/mantis_core.{h,c} files can
just be deleted. They look like some development leftovers?
I see. mantis_core.ko kernel module exists though.
Maybe the mantis/Makefile references for mantis_core.c, mantis.c and hopper.c
are just some leftovers too.
I moved tasklet_enable/disable calls into mantis_dvb.c where almost all other
tasklet code is located.
So the following reasoning still holds:
1. dvb_dmxdev_filter_stop() calls mantis_dvb_stop_feed: mantis_dma_stop()
2. dvb_dmxdev_filter_stop() calls release_ts_feed() or some other filter
freeing function.
3. tasklet: mantis_dma_xfer calls dvb_dmx_swfilter to copy DMA buffer's content
into freed memory, accessing freed spinlocks.
This case might occur while tuning into another frequency.
Perhaps cdurrhau has found some version from this bug at
http://www.linuxtv.org/pipermail/linux-dvb/2010-June/032688.html:
This is what I get on the remote console via IPMI:
40849.442492] BUG: soft lockup - CPU#2 stuck for 61s! [section
handler:4617]
New reasoning for the patch (same as the one above, but from higher level):
After dvb-core has called mantis-fe-stop_feed(dvbdmxfeed) the last time (count
to zero),
no data should ever be copied with dvb_dmx_swfilter() by a tasklet: the target
structure might be in an unusable state.
Caller of mantis_fe-stop_feed() assumes that feeding is stopped after
stop_feed() has been called, ie. dvb_dmx_swfilter()
isn't running, and won't be called.
There is a risk that dvb_dmx_swfilter() references freed resources (memory or
spinlocks or ???) causing instabilities.
Thus tasklet_disable(mantis-tasklet) must be called inside of
mantis-fe-stop_feed(dvbdmxfeed) when necessary.
Signed-off-by: Marko Ristola marko.rist...@kolumbus.fi
Marko
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index 99d82ee..a9864f7 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -117,6 +117,7 @@ static int mantis_dvb_start_feed(struct dvb_demux_feed
*dvbdmxfeed)
if (mantis-feeds == 1) {
dprintk(MANTIS_DEBUG, 1, mantis start feed dma);
mantis_dma_start(mantis);
+tasklet_enable(mantis-tasklet);
}
return mantis-feeds;
@@ -136,6 +137,7 @@ static int mantis_dvb_stop_feed(struct dvb_demux_feed
*dvbdmxfeed)
mantis-feeds--;
if (mantis-feeds == 0) {
dprintk(MANTIS_DEBUG, 1, mantis stop feed and dma);
+tasklet_disable(mantis-tasklet);
mantis_dma_stop(mantis);
}
@@ -216,6 +218,7 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
dvb_net_init(mantis-dvb_adapter, mantis-dvbnet, mantis-demux.dmx);
tasklet_init(mantis-tasklet, mantis_dma_xfer, (unsigned long) mantis);
+tasklet_disable(mantis-tasklet);
if (mantis-hwconfig) {
result = config-frontend_init(mantis, mantis-fe);
if (result 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
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Thu, 8 Jul 2010 18:54:41 -0400 Kyle Baker kyleaba...@gmail.com wrote: My conclusion, reducing gspca_dev-nbalt by values 1-5 apparently fix the bandwidth issue and don't alter the video input. However, they also do not correct the issue where the microphone breaks and becomes disabled. OK. So, this means that the sonixj driver sets something in the webcam which prevents the audio to run. I don't see anything but the GPIO. I have no ms-win trace from your webcam. May you do it? I just need the connection and one second of streaming with a USB sniffer in text mode as sniffbin. Thanks. -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
Em 09-07-2010 14:19, Ivan escreveu: On 07/09/2010 08:47 AM, Mauro Carvalho Chehab wrote: I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Huh? Does there even *exist* a proprietary linux driver for my card? And because you never saw stripes with em28xx, they must not exist? :^P Well, it depends. What are your video adapter card? ATI? Nvidia? You might want to reread the thread-- we already figured the stripes out. v4l2: 1199 frames successfully processed, -3 frames dropped. This is not a V4L issue. I'm aware of that by now. A negative number of dropping frames makes no sense. It is probably a mplayer bug. I would try to get a newer version of mplayer and double check. Newer than latest svn? :^D Well, then try a stable version ;) If you look at the mplayer code that calculates the supposed number of frames dropped (it's in stream/tvi_v4l2.c), it would seem that it's just an indicator of how close the stream came to the nominal framerate (3/1001 in my case). In other words, if mplayer sees an actual framerate of less than 29.97 coming from v4l, it assumes (perhaps incorrectly) that this is because some frames were dropped. If you do the same calculation when the actual framerate is greater than 29.97, you get a negative number of dropped frames. It looks weird, but it makes a kind of sense if you know what it really means. Such logic is broken. In the case of webcams, the framerate is generally less than 29.97 fps. For example, em2750 webcams, supported by em28xx driver, have a framerate of about 5 fps, due to sensor limits. -- 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
RFC: Use of s_std calling s_freq when tuner powered down
Hello all, Here's the scenario: 1. I have a USB device that supports both an analog tuner and composite/s-video inputs 2. The bridge is smart enough to power down the tuner when capturing on composite/s-video 3. Changing the video standard appears to send set_freq() calls to the tuner, which in i2c fail because it's powered down. So I looked at the tuner-core code, and I'm seeing that tuner_s_std() will call set_freq() if the tuner-tv_freq field is nonzero. This seems reasonable, except as far as I can tell there is no way to set it to zero (because the places that set the value to zero will return failure because zero is outside the tuning range). This behavior happens with tvtime, which always does a tuning on startup, before switching to the A/V inputs. While I agree that I should probably fix tvtime so it doesn't do this, it seems strange that there is no way to reset tv_freq to zero when toggling away from the tuner input, so that these errors don't occur. Any thoughts? Obviously I would like to eliminate the i2c errors from littering the dmesg log when there is no real failure condition. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On Fri, Jul 9, 2010 at 2:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-07-2010 14:19, Ivan escreveu: On 07/09/2010 08:47 AM, Mauro Carvalho Chehab wrote: I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Huh? Does there even *exist* a proprietary linux driver for my card? And because you never saw stripes with em28xx, they must not exist? :^P Well, it depends. What are your video adapter card? ATI? Nvidia? Mauro, His issue with the vertical stripes has been fixed when he updated to the latest v4l-dvb code. It's the issue I fixed a couple of months ago with the saa7113 chroma gain behavior when there is an overdriven signal. The problem he's having now with the latest is the picture appears to be shifted. I have to wonder if perhaps I screwed something up when I did the VBI support, in that it may not work properly when the scaler is in use. I will have to do some testing. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4] Multi-plane buffer support for V4L2 API
Hello,
This is the fourth version of the multi-plane API extensions proposal.
I think that we have reached a stage at which it is more or less finalized.
Rationale can be found at the beginning of the original thread:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11212
===
I. Multiplanar API description/negotiation
===
1. Maximum number of planes
--
We've chosen the maximum number of planes to be 8 per buffer:
+#define VIDEO_MAX_PLANES 8
2. Capability checks
--
If a driver supports multiplanar API, it can turn on one (or both) of the
new capability flags:
+/* Is a video capture device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x1000
+/* Is a video output device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x2000
- any combination of those flags is valid;
- any combinations with the old, non-multiplanar V4L2_CAP_VIDEO_CAPTURE and
V4L2_CAP_VIDEO_OUTPUT flags are also valid;
- the new flags indicate, that a driver supports the new API, but it does NOT
have to actually use multiplanar formats; it is perfectly possible and valid
to use the new API for 1-plane buffers as well;
using the new API for both 1-planar and n-planar formats makes the
applications simpler, as they do not have to fall back to the old API in the
former case.
3. Describing multiplanar formats
--
To describe multiplanar formats, we have to extend the format struct:
struct v4l2_format {
enum v4l2_buf_type type;
union {
struct v4l2_pix_format pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE */
+ struct v4l2_pix_format_mplane mp_pix; /*
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
struct v4l2_window win; /*
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format vbi; /*
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format sliced; /*
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
__u8raw_data[200]; /* user-defined */
} fmt;
};
We need a new buffer type to recognize when to use mp_pix instead of pix.
Or, actually, two buffer types, for both OUTPUT and CAPTURE:
enum v4l2_buf_type {
/* ... */
+ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
+ V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
/* ... */
};
For those buffer types, we use struct v4l2_pix_format_mplane:
+/**
+ * struct v4l2_pix_format_mplane - multiplanar format definition
+ * @pix_fmt: definition of an image format for all planes
+ * @plane_fmt: per-plane information
+ */
+struct v4l2_pix_format_mplane {
+ struct v4l2_pix_format pix_fmt;
+ struct v4l2_plane_formatplane_fmt[VIDEO_MAX_PLANES];
+} __attribute__ ((packed));
The pix_fmt member is to be used in the same way as in the old API. Its fields:
- width, height, field, colorspace, priv retain their old meaning;
- pixelformat is still fourcc, but new fourcc values have to be introduced
for multiplanar formats;
- bytesperline, sizeimage lose their meanings and are replaced by their
counterparts in the new, per-plane format struct.
The plane format struct is as follows:
+/**
+ * struct v4l2_plane_format - additional, per-plane format definition
+ * @sizeimage: maximum size in bytes required for data, for which
+ * this plane will be used
+ * @bytesperline: distance in bytes between the leftmost pixels in two
+ * adjacent lines
+ */
+struct v4l2_plane_format {
+ __u32 sizeimage;
+ __u16 bytesperline;
+ __u16 reserved[7];
+} __attribute__ ((packed));
Note that bytesperline is u16 now, but that shouldn't hurt.
Fitting everything into v4l2_format's union (which is 200 bytes long):
v4l2_pix_format shouldn't be larger than 40 bytes.
8 * struct v4l2_plane_format + struct v4l2_pix_format = 8 * 20 + 40 = 200
4. Format enumeration
--
struct v4l2_fmtdesc, used for format enumeration, does include the v4l2_buf_type
enum as well, so the new types can be handled properly here as well.
For drivers supporting both versions of the API, 1-plane formats should be
returned for multiplanar buffer types as well, for consistency. In other words,
for multiplanar buffer types, the formats returned are a superset of those
returned when enumerating with the old buffer types.
5. Requesting buffers (buffer allocation)
--
VIDIOC_REQBUFS includes v4l2_buf_type as well, so everything works as expected.
===
II. Multiplanar buffer and plane descriptors
===
1. Adding
Re: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/09/2010 02:12 PM, Devin Heitmueller wrote: On Fri, Jul 9, 2010 at 2:03 PM, Mauro Carvalho Chehab wrote: Well, it depends. What are your video adapter card? ATI? Nvidia? Sorry Mauro, I misread your earlier comment. I thought you were talking about the capture device, not my graphics card. My video driver is indeed proprietary (Nvidia) and has terrible tearing issues, but at least it doesn't do anything as bad as introduce vertical stripes with periodicity 4.3. :^D The problem he's having now with the latest is the picture appears to be shifted. I have to wonder if perhaps I screwed something up when I did the VBI support, in that it may not work properly when the scaler is in use. I will have to do some testing. By the way, if you can't find other hardware that exhibits the same problem, let me know what I can do to help. I tried other picture resolutions and found that the shifting only happens when the picture height is the full 480. If you fix the height at 480 and let the width vary, the picture is shifted over by 1/4 of the width (or 3/4, depending how you look at it), except when the width is very close to 720. At width 718 the shift is more like 1/3, and then at width 720 the picture isn't shifted at all. Here are some tarred up snapshots if you want to take a look: http://ifile.it/hpui0j4/em28xx-height480.tar Ivan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jul 9 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS 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: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of the patches under review at LMML (60 patches)
Hi!
On 08.07.2010 05:31, Mike Isely wrote:
These are cx25840 patches and I'm not the maintainer of that module. I
can't really speak to the correctness of the changes. Best I can do is
to try the patch with a few pvrusb2-driven devices here that use the
cx25840 module. I've done that now (HVR-1950 and PVR-USB2 model 24012)
and everything continues to work fine.
I also retested the patch (with the recent v4l changes) and my device
continues to work as expected (using your current snapshot from July,
Mike :) ).
Note, this part of the patch:
int hw_fix = state-pvr150_workaround;
-
- if (std == V4L2_STD_NTSC_M_JP) {
+ if (std == V4L2_STD_NTSC_M_JP) {
/* Japan uses EIAJ audio standard */
cx25840_write(client, 0x808, hw_fix ? 0x2f : 0xf7);
} else if (std == V4L2_STD_NTSC_M_KR) {
is a whitespace-only change which introduces a bogus tab and messes up
the indentation of that opening if-statement. It should probably be
removed from the patch.
I wonder how that came in there... my excuses for this (and also the
removed new line some lines below that).
Other than that, you have my ack:
Acked-By: Mike Iselyis...@pobox.com
-Mike
Hmm... I've read a bit in the wiki about submitting patches and read
that one should sign-off his/her patches... as I didn't do that back
then (as I thought that patch would be open for discussion ^^ - note to
self: add RFC next time), should I resend the patch with a comment and
the sign-off (and excluding the indentation mistake) or should I just
send a sign-off in reference to this patch? Or something else?
Regards,
Sven
--
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: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
Oh, sorry for the long delay. Yes, I was using my fake-id patch. @Torsten: just open linux-2.6/drivers/media/video/em28xx/em28xx-cards.c and search for EM2870_BOARD_TERRATEC_XS. Then copy this line and the one above it, and finally change the usb id in the copied line according to the output of lsusb. Thorsten Maybe i need the patch Thorsten did too, to patch the em28xx-cards.c to get the new wrong usb id regognized as a em28xx device so that i can reflash the eeprom of the device. I might give this a try later this day. Please try it, should be the root cause. -- 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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250
I know this is an old thread, however i have an card that meets the requirements to be tested by the patches made by andy, and so far with what i've tried it's been doing really well for input. I pretty much just downloaded and tested Andy's patch set... http://linuxtv.org/hg/~awalls/cx23885-ir2 The tests where done on ubuntu 10.04 with kernel 2.6.32-23-generic (64-bit) and this appears to be working perfectly. (This even properly identifies the card I'm using down to the model) card notes: Hauppauge WinTV-HVR1250 (Model: 79001) oh and the only change i made to the test is i commented out the 4 lines in the makefile that generate the firedtv module so i could compile the tests -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
Em 09-07-2010 15:12, Devin Heitmueller escreveu: On Fri, Jul 9, 2010 at 2:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-07-2010 14:19, Ivan escreveu: On 07/09/2010 08:47 AM, Mauro Carvalho Chehab wrote: I never saw the em28xx scaler generating such vertical stripes. This could be a mplayer or a video adapter driver problem. Are you using a proprietary video driver? You may try to use ffmeg or mencoder to generate a mpeg file at 640x480 and then try to play it on another player (preferably on another machine), to see if this problem disappears. Huh? Does there even *exist* a proprietary linux driver for my card? And because you never saw stripes with em28xx, they must not exist? :^P Well, it depends. What are your video adapter card? ATI? Nvidia? Mauro, His issue with the vertical stripes has been fixed when he updated to the latest v4l-dvb code. It's the issue I fixed a couple of months ago with the saa7113 chroma gain behavior when there is an overdriven signal. The problem he's having now with the latest is the picture appears to be shifted. I have to wonder if perhaps I screwed something up when I did the VBI support, in that it may not work properly when the scaler is in use. I will have to do some testing. I meant that vertical risk that appeared when scaling is on. I never saw em28xx scaler doing something like that. It maybe some bug at mplayer or at the nvidia proprietary driver. We know that this driver has serious issues with their Xv support, and that it do some evil things when allocating kernel memory. 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: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Fri, Jul 9, 2010 at 2:03 PM, Jean-Francois Moine moin...@free.fr wrote: OK. So, this means that the sonixj driver sets something in the webcam which prevents the audio to run. I don't see anything but the GPIO. I was considering adding more code to print out more detailed IO information. I have no ms-win trace from your webcam. May you do it? I just need the connection and one second of streaming with a USB sniffer in text mode as sniffbin. I tried using a couple of USB sniffers in Windows 7, but I'm unable to find one that has an option to save in text mode as sniffbin. Apologies in advanced for the length of the log files that I managed to capture. I captured the device connection, video capture start and stop, then device removed. The capture start took a moment to begin since the application loaded more slowly with usb capturing in progress. --- I tried using the open source SnoopyPro under Windows 7 and I'm not sure how well it works normally, but I was unable to capture any usb traffic in Win7. If you have any other suggestions let me know, because I've never used a usb sniffer before. I connected my webcam to a Windows XP laptop and was able to get it to capture (Windows XP laptop is 32-bit, Windows7/Ubuntu 10.10 desktop is 64-bit...which is what I am working to get the webcam working on). http://sourceforge.net/projects/usbsnoop/ In the USB Devices list I see my camera listed 3 times: USB\VID_045EPID_00F7REV_0101MI_00,USB\VID_045EPID_00F7MI_00 USB\VID_045EPID_00F7REV_0101MI_01,USB\VID_045EPID_00F7MI_01 USB\VID_045EPID_00F7REV_0101,USB\VID_045EPID_00F7 Log file from SnoopyPro: http://bit.ly/bNJiLu --- I also installed a free usb sniffer called Simple USB Logger that seemed to do a very good job and I captured data from the point that the camera was plugged into usb, then start capture, end capture and unplugged from usb. So it should be a large bit of the data you will need. http://www.all-freeware.com/download/67384/simple-usb-logger.html Log file from Simple USB Logger: http://bit.ly/92ipQ8 --- I hope these help and are what you were looking for. Let me know if you needed something different or if there is more information I can send to you. I've saved the exact program versions in case you have trouble getting them for any reason and would like to look into them: SnoopyPro: http://bit.ly/bX6r9r Simple USB Logger: http://bit.ly/bshLuz Thanks. -- Kyle Baker -- 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: em28xx: success report for KWORLD DVD Maker USB 2.0 (VS-USB2800) [eb1a:2860]
On 07/09/2010 04:57 PM, Mauro Carvalho Chehab wrote: I meant that vertical risk that appeared when scaling is on. I never saw em28xx scaler doing something like that. It maybe some bug at mplayer or at the nvidia proprietary driver. We know that this driver has serious issues with their Xv support, and that it do some evil things when allocating kernel memory. Sorry, what? You still want to argue that your vague suggestions trump the direct experiences of Devin and myself? That particular bug has already been identified and squashed (and I don't think it had much to do with scaling, but Devin could tell you for sure). -- 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] lirc: use unlocked_ioctl
New code should not rely on the big kernel lock,
so use the unlocked_ioctl file operation in lirc.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
The lirc code currently conflicts with my removal of the .ioctl
operation, which I'd like to get into linux-next.
drivers/media/IR/ir-lirc-codec.c |7 +++
drivers/media/IR/lirc_dev.c | 12 ++--
drivers/media/IR/lirc_dev.h |3 +--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
index aff31d1..178bc5b 100644
--- a/drivers/media/IR/ir-lirc-codec.c
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -97,8 +97,7 @@ out:
return ret;
}
-static int ir_lirc_ioctl(struct inode *node, struct file *filep,
-unsigned int cmd, unsigned long arg)
+static long ir_lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long
arg)
{
struct lirc_codec *lirc;
struct ir_input_dev *ir_dev;
@@ -154,7 +153,7 @@ static int ir_lirc_ioctl(struct inode *node, struct file
*filep,
break;
default:
- return lirc_dev_fop_ioctl(node, filep, cmd, arg);
+ return lirc_dev_fop_ioctl(filep, cmd, arg);
}
return ret;
@@ -173,7 +172,7 @@ static void ir_lirc_close(void *data)
static struct file_operations lirc_fops = {
.owner = THIS_MODULE,
.write = ir_lirc_transmit_ir,
- .ioctl = ir_lirc_ioctl,
+ .unlocked_ioctl = ir_lirc_ioctl,
.read = lirc_dev_fop_read,
.poll = lirc_dev_fop_poll,
.open = lirc_dev_fop_open,
diff --git a/drivers/media/IR/lirc_dev.c b/drivers/media/IR/lirc_dev.c
index 9e141d5..3fd6150 100644
--- a/drivers/media/IR/lirc_dev.c
+++ b/drivers/media/IR/lirc_dev.c
@@ -160,7 +160,7 @@ static struct file_operations fops = {
.read = lirc_dev_fop_read,
.write = lirc_dev_fop_write,
.poll = lirc_dev_fop_poll,
- .ioctl = lirc_dev_fop_ioctl,
+ .unlocked_ioctl = lirc_dev_fop_ioctl,
.open = lirc_dev_fop_open,
.release= lirc_dev_fop_close,
};
@@ -242,9 +242,9 @@ int lirc_register_driver(struct lirc_driver *d)
goto out;
} else if (!d-rbuf) {
if (!(d-fops d-fops-read d-fops-poll
- d-fops-ioctl)) {
+ d-fops-unlocked_ioctl)) {
dev_err(d-dev, lirc_dev: lirc_register_driver:
- neither read, poll nor ioctl can be NULL!\n);
+ neither read, poll nor unlocked_ioctl can be
NULL!\n);
err = -EBADRQC;
goto out;
}
@@ -425,6 +425,7 @@ int lirc_dev_fop_open(struct inode *inode, struct file
*file)
retval = -ENODEV;
goto error;
}
+ file-private_data = ir;
dev_dbg(ir-d.dev, LOGHEAD open called\n, ir-d.name, ir-d.minor);
@@ -516,12 +517,11 @@ unsigned int lirc_dev_fop_poll(struct file *file,
poll_table *wait)
}
EXPORT_SYMBOL(lirc_dev_fop_poll);
-int lirc_dev_fop_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg)
+long lirc_dev_fop_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
unsigned long mode;
int result = 0;
- struct irctl *ir = irctls[iminor(inode)];
+ struct irctl *ir = file-private_data;
dev_dbg(ir-d.dev, LOGHEAD ioctl called (0x%x)\n,
ir-d.name, ir-d.minor, cmd);
diff --git a/drivers/media/IR/lirc_dev.h b/drivers/media/IR/lirc_dev.h
index 4afd96a..b1f6066 100644
--- a/drivers/media/IR/lirc_dev.h
+++ b/drivers/media/IR/lirc_dev.h
@@ -216,8 +216,7 @@ void *lirc_get_pdata(struct file *file);
int lirc_dev_fop_open(struct inode *inode, struct file *file);
int lirc_dev_fop_close(struct inode *inode, struct file *file);
unsigned int lirc_dev_fop_poll(struct file *file, poll_table *wait);
-int lirc_dev_fop_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg);
+long lirc_dev_fop_ioctl(struct file *file, unsigned int cmd, unsigned long
arg);
ssize_t lirc_dev_fop_read(struct file *file, char *buffer, size_t length,
loff_t *ppos);
ssize_t lirc_dev_fop_write(struct file *file, const char *buffer, size_t
length,
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Strange Problem with Antti's af9015 driver on gentoo 2.6.30-r5
Hello TV-Friends, today i checked out Antti's last af9015 (af9013) driver and encountered a strange problem on my gentoo 2.6.30-r5 box. If i install this driver, udev (149) start to behave strange and take a long time to finish. When it comes to set to utf8 the whole box hang without any chance to do anything. I need to erase all the modules in the /lib/modules/./media -tree (chroot from a boot-cd) to make it boot again. With the driver from around May all seems to work (except that weird bug with not getting a lock anymore sometimes on my digivox-stick). I wonder what changed in the meantime and what i missed on my gentoo-box to make it work..? Am i need a more recent kernel? More recent udev-version? Any help would be nice, cause i would love to test the last change of that driver and all your wonderful work. Thanks in advance, Andreas -- 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] lirc: use unlocked_ioctl
On Fri, Jul 09, 2010 at 11:35:39PM +0200, Arnd Bergmann wrote: New code should not rely on the big kernel lock, so use the unlocked_ioctl file operation in lirc. Signed-off-by: Arnd Bergmann a...@arndb.de --- The lirc code currently conflicts with my removal of the .ioctl operation, which I'd like to get into linux-next. drivers/media/IR/ir-lirc-codec.c |7 +++ drivers/media/IR/lirc_dev.c | 12 ++-- drivers/media/IR/lirc_dev.h |3 +-- 3 files changed, 10 insertions(+), 12 deletions(-) Still works for both rx and tx here w/one of my mceusb transceivers here. Tested-by: Jarod Wilson ja...@redhat.com Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
