Re: [PATCH] gspca: add missing .type field check in VIDIOC_G_PARM
David Ellingsworth wrote:
2009/3/18 Németh Márton nm...@freemail.hu:
From: Márton Németh nm...@freemail.hu
The gspca webcam driver does not check the .type field of struct
v4l2_streamparm.
This field is an input parameter for the driver according to V4L2 API
specification,
revision 0.24 [1]. Add the missing check.
The missing check was recognised by v4l-test 0.10 [2] together with
gspca_sunplus driver
and with Trust 610 LCD pow...@m ZOOM webcam. This patch was verified also
with
v4l-test 0.10.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r11680.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: Márton Németh nm...@freemail.hu
---
--- linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c.orig 2009-03-14
12:29:38.0 +0100
+++ linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c 2009-03-18
16:51:03.0 +0100
@@ -1320,6 +1320,9 @@ static int vidioc_g_parm(struct file *fi
{
struct gspca_dev *gspca_dev = priv;
+ if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
memset(parm, 0, sizeof *parm);
parm-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
^^^
This line should be deleted as it's no longer needed.
Because memset() clears the whole parm structure this line is necessary. In
other
drivers the following code is there:
tmp = parm-type;
memset(parm, 0, sizeof(*parm));
parm-type = parm;
Maybe changing the code similar to this would be easier to read?
Márton Németh
--
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: gspca/v4l - HP Webcam 1.3 - Device Request
On Wed, 18 Mar 2009 06:45:13 -0600 svwindbird svwindb...@gmail.com wrote: Hope this is the correct place for requesting to add a device. I'm also assuming that it's a gspca/VC032x driver problem, as it's counter-part in windows in usbvm326. Name: HP Webcam 1.3 Megapixal (USB) Model: rd345aa USB_id: 15b8:6001 Env: Suse 11.1 (Kernel 2.6.27 64bit) uname: Linux liana 2.6.27.19-3.2-default #1 SMP 2009-02-25 15:40:44 +0100 x86_64 x86_64 x86_64 GNU/Linux v4l 0.5.8-0 (packaged with Suse)... (hacked from gspca-3b1ce192115d.tar.bz2) (d/l'ed from linuxtv) Toshiba P205D-7438 AMD Athlon X2 - see lspci output at bottom for for info Synopsis: Runs with driver usbvm326 under windows. tried hacking VC032x.c, forcing use of... BRIDGE_VC0323 = got a constant framebuffer overruns, then tried, BRIDGE_VC0321 = ran, but picture out of sync and possibly b/w picture (hard to tell). Sorry, but my so-called expertise stops about here. Hello Diana, I have one ms-win usbvm326.inf, but it deals with 15b8:6001 only and it includes USB code for the sensors hv7131r and po1200. Does your usbvm326 include other sensors? (look at the 'HKR,%%, Init...' lines) You sent some traces, but they don't show information from the vc032x subdriver. Have you such traces that give indications about the sensor? Best regards. -- 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: [PATCH] gspca: add missing .type field check in VIDIOC_G_PARM
On Thu, 19 Mar 2009, [ISO-8859-1] N?meth M?rton wrote:
David Ellingsworth wrote:
2009/3/18 N?meth M?rton nm...@freemail.hu:
From: M?rton N?meth nm...@freemail.hu
The gspca webcam driver does not check the .type field of struct
v4l2_streamparm.
This field is an input parameter for the driver according to V4L2 API
specification,
revision 0.24 [1]. Add the missing check.
The missing check was recognised by v4l-test 0.10 [2] together with
gspca_sunplus driver
and with Trust 610 LCD pow...@m ZOOM webcam. This patch was verified
also with
v4l-test 0.10.
References:
[1] V4L2 API specification, revision 0.24
http://v4l2spec.bytesex.org/spec/r11680.htm
[2] v4l-test: Test environment for Video For Linux Two API
http://v4l-test.sourceforge.net/
Signed-off-by: M?rton N?meth nm...@freemail.hu
---
--- linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c.orig 2009-03-14
12:29:38.0 +0100
+++ linux-2.6.29-rc8/drivers/media/video/gspca/gspca.c 2009-03-18
16:51:03.0 +0100
@@ -1320,6 +1320,9 @@ static int vidioc_g_parm(struct file *fi
{
struct gspca_dev *gspca_dev = priv;
+ if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
memset(parm, 0, sizeof *parm);
parm-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
^^^
This line should be deleted as it's no longer needed.
Because memset() clears the whole parm structure this line is necessary. In
other
drivers the following code is there:
tmp = parm-type;
memset(parm, 0, sizeof(*parm));
parm-type = parm;
The memset isn't needed anymore either, I put it into v4l2_ioctl. I
removed most of the code like that but I may have missed some drivers.
--
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] FusionHDTV7 and v4l causes kernel panic
No, changing baud rate to 9600 has no effect. It is simply not sending the log to the serial port. - Original Message - From: Andy Walls awa...@radix.net To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wednesday, March 18, 2009 7:48 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: I've added console=ttyS0,115200 console=tty0 to the kernel command line options and with out the console=tty0 part the dump no longer shows on the monitor, so redirect seems to work but loging the serial port on a second computer gets nothing. I tested the connection with echo and that worked but the kernel dump won't go out the port. The last 2 lines of the screen are: EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 Kernel panic - not syncing: Fatal exception in interrupt Hmm. The only thing in the cx23885 driver that tries to schedule work, and thus the only thing that could possibly pass in a bad argument, is the netup_ci_slot_status() function. It gets called when an IRQ comes in indicating a GPIO[01] event, and the driver thinks the card is a NetUp Dual DVB-S2 CI card. That's consistent with the fatal exception in interrupt, but without the backtrace, one can't be completely sure this call to queue work was initiated by the cx23885 driver and a problem with cx23885 data structures. (But it is the most likely scenario, IMO) I just can't see how netup_ci_slot_status() get's called for your card. Any way to get the dump to go out the serial port? Does 9600 baud help? (Just a guess.) Regards, Andy - Original Message - From: Andy Walls awa...@radix.net To: Timothy D. Lenz tl...@vorgon.com Cc: linux-media@vger.kernel.org Sent: Monday, March 16, 2009 6:07 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Mon, 2009-03-16 at 17:46 -0700, Timothy D. Lenz wrote: When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. Not even Shift+PageUp ? I looked at the logs and the ones that are text had nothing about it. Digital camera or pencil and paper will be least complex way to capture the ooops data. Please don't leave out the Code bytes at the bottom and do your best to make sure those are absolutely correct. Regards, Andy - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic We'll need the oops. - Steve ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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 ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] ov772x: wrong pointer for soc_camera_link is modified
priv-client-dev.platrom_data mean ov772x_camera_info in ov772x driver.
So, struct soc_camera_link doesn't exist there.
This patch modify this bug.
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
drivers/media/video/ov772x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 84b0fc1..34c9819 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -670,7 +670,7 @@ static int ov772x_set_bus_param(struct soc_camera_device
*icd,
static unsigned long ov772x_query_bus_param(struct soc_camera_device *icd)
{
struct ov772x_priv *priv = container_of(icd, struct ov772x_priv, icd);
- struct soc_camera_link *icl = priv-client-dev.platform_data;
+ struct soc_camera_link *icl = priv-info-link;
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
--
1.5.6.3
--
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] gspca
Hi Mauro, I rebuild my repository. I don't see how it could have been broken... Also, I hope this message will arrive to you and the list: previously, Claws-mail said ok to my pull requests, but did nothing... Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11098:0b47e3e38dc8 gspca - main: May have isochronous transfers on altsetting 0. changeset: 11099:5deba1a53e60 gspca - ov534: Bad frame pointer after adding the last packet. changeset: 11100:bc06639e5df9 gspca - ov534: Adjust the packet scan function. changeset: 11101:77ee24ca830b gspca - ov534: New sensor ov965x and re-enable the webcam 06f8:3003. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Results of the 'dropping support for kernels 2.6.22' poll
On Sun, 15 Mar 2009, Hans Verkuil wrote: On Sunday 15 March 2009 17:39:11 Trent Piepho wrote: Because there are patches that touch both the media tree and outside it? I don't buy it. Even for sub-systems that only use full git trees, you almost never see a patch that touches multiple areas of maintainership. It's just too hard to deal with getting acks from everyone involved, dealing with the out-of-sync development git trees of the multiple areas you want to touch, figuring out who will take your patch, etc. Think embedded devices like omap, davinci and other SoC devices. These all require changes in both v4l-dvb and arch at the same time. Easy to do if you have a full git tree, much harder to do in the current situation. These devices will become much more important in the coming months and years, so having a proper git tree will definitely help. This is a relatively new development and before that it was indeed rare to see patches touching on areas outside the media tree. Not anymore, though. ALSA has a full git tree now, so there should be all these patches that touch sound/ and something out side of sound too? I'm not seeing them. The only patches that touch inside and outside of ALSA are the ones that fix some misspelled word in 100 random files or rename a linux header file. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 (V3)] OMAP3EVM Multi-Media Daughter Card Support
From: Vaibhav Hiremath hvaib...@ti.com This is Third version of OMAP3EVM Mulit-Media Daughter Card support. NOTE: Please note that, hence forth I will try to avoid submitting patches on top of V4L2-int framework. The next immediate activity would be migration to sub-device framework. Fixes: - Refreshed with Latest ISP-Camera patches - Comments from 'Tony Lindgren' - Comments from 'Alexey Klimov' TODO: - Need to migrate along with OMAP3-Camera Tested: - TVP5146 (BT656) decoder interface on top of Sakari's Git tree. http://git.gitorious.org/omap3camera/mainline.git - Capturing the frame to file and validate Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/mach-omap2/Kconfig |8 +- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c | 351 + arch/arm/mach-omap2/board-omap3evm-mmdc.h | 42 +++ 4 files changed, 401 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c create mode 100644 arch/arm/mach-omap2/board-omap3evm-mmdc.h diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8fa650d..8dadf2a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -113,7 +113,7 @@ config MACH_OMAP_LDP bool OMAP3 LDP board depends on ARCH_OMAP3 ARCH_OMAP34XX -config MACH_OMAP2EVM +config MACH_OMAP2EVM bool OMAP 2530 EVM board depends on ARCH_OMAP2 ARCH_OMAP24XX @@ -125,6 +125,12 @@ config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX +config MACH_OMAP3EVM_MMDC + bool OMAP 3530 EVM Multi-Media Daughter Card board + depends on MACH_OMAP3EVM + help + Set this if you've got a Multi-Media Daughter Card board. + config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 ARCH_OMAP34XX diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 33b5aa8..715d0e4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -58,6 +58,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ mmc-twl4030.o \ board-omap3evm-flash.o \ twl4030-generic-scripts.o +obj-$(CONFIG_MACH_OMAP3EVM_MMDC) += board-omap3evm-mmdc-v4l.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ mmc-twl4030.o \ twl4030-generic-scripts.o diff --git a/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c b/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c new file mode 100644 index 000..c00a731 --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c @@ -0,0 +1,351 @@ +/* + * arch/arm/mach-omap2/board-omap3evm-mmdc-v4l.c + * + * Driver for OMAP3 EVM Multi Media Daughter Card + * + * Copyright (C) 2008 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * Contributors: + * Anuj Aggarwal anuj.aggar...@ti.com + * Sivaraj R siva...@ti.com + * + * This package 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/init.h +#include linux/i2c.h +#include linux/gpio.h +#include linux/videodev2.h + +#include mach/mux.h + +#include media/v4l2-int-device.h +#include media/tvp514x.h + +/* Include V4L2 ISP-Camera driver related header file */ +#include ../drivers/media/video/omap34xxcam.h +#include ../drivers/media/video/isp/ispreg.h + +#include board-omap3evm-mmdc.h + +#define MODULE_NAMEomap3evm-mmdc + +/* Macro Definitions */ + +/* GPIO pins */ +#define GPIO134_SEL_TVP_Y (134) +#define GPIO54_SEL_EXP_CAM (54) +#define GPIO136_SEL_CAM(136) + +/* board internal information (BEGIN) */ + +/* I2C bus to which all I2C slave devices are attached */ +#define BOARD_I2C_BUSNUM (3) + +/* I2C address of chips present in board */ +#define TVP5146_I2C_ADDR (0x5D) + +#if defined(CONFIG_VIDEO_TVP514X) || defined(CONFIG_VIDEO_TVP514X_MODULE) +#if defined(CONFIG_VIDEO_OMAP3) ||
[patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? --- Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI and others. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r 626c136ec221 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Fri Mar 13 14:35:14 2009 -0700 +++ b/linux/drivers/media/radio/Kconfig Thu Mar 19 15:20:12 2009 +0300 @@ -10,6 +10,13 @@ Say Y here to enable selecting AM/FM radio adapters. if RADIO_ADAPTERS VIDEO_V4L2 + +config RADIO_ADAPTERS_ISA + boolean ISA radio adapters + ---help--- + Enable this if you have ISA-based radio adapter. + +if RADIO_ADAPTERS_ISA config RADIO_CADET tristate ADS Cadet AM/FM Tuner @@ -150,50 +157,6 @@ Say Y here to enable automatic probing for GemTek Radio card. The following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and 0x28c. - -config RADIO_GEMTEK_PCI - tristate GemTek PCI Radio Card support - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this PCI FM radio card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video for Linux API. Information on - this API and pointers to v4l 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-gemtek-pci. - -config RADIO_MAXIRADIO - tristate Guillemot MAXI Radio FM 2000 radio - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this radio card. This card may also be - found as Gemtek PCI FM. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maxiradio. - -config RADIO_MAESTRO - tristate Maestro on board radio - depends on VIDEO_V4L2 PCI - ---help--- - Say Y here to directly support the on-board radio tuner on the - Maestro 2 or 2E sound card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maestro. config RADIO_SF16FMI tristate SF16FMI Radio @@ -339,6 +302,68 @@ help Enter the I/O port of your Zoltrix radio card. +endif # RADIO_ADAPTERS_ISA + +config RADIO_ADAPTERS_PCI + boolean PCI radio adapters + ---help--- + Enable this if you have PCI-based radio adapters. + +if RADIO_ADAPTERS_PCI + +config RADIO_GEMTEK_PCI + tristate GemTek PCI Radio Card support + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this PCI FM radio card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video for Linux API. Information on + this API and pointers to v4l 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-gemtek-pci. + +config RADIO_MAXIRADIO + tristate Guillemot MAXI Radio FM 2000 radio + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this radio card. This card may also be + found as Gemtek PCI FM. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to v4l 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-maxiradio. + +config RADIO_MAESTRO + tristate Maestro on board radio + depends on VIDEO_V4L2 PCI + ---help--- + Say Y here to directly support the on-board radio tuner on the + Maestro 2 or 2E sound card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to v4l 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-maestro. + +endif #
RE: [RFC 4/7] ARM: DaVinci: DM646x Video: Defintions for standards supported by display
Hi Hans,
As of now we will provide support for SD, soon we will add support for HD too.
I am working on the review comments and will submit the revised patches soon.
This time the patch set will be divided into two
Set 1 - support for ADV7343 and THS7303 drivers.
Set 2 - VPIF display driver related patches
Thanks,
Chaithrika
From: Hans Verkuil [hverk...@xs4all.nl]
Sent: Thursday, March 19, 2009 4:05 AM
To: davinci-linux-open-sou...@linux.davincidsp.com; Subrahmanya, Chaithrika
Cc: linux-media@vger.kernel.org
Subject: Re: [RFC 4/7] ARM: DaVinci: DM646x Video: Defintions for standards
supported by display
Hi Chaithrika,
Just a quick note: getting these digital TV standards sorted out is the main
blocking issue for the DM646x. Without this nothing can get merged. In
addition, extending the V4L2 API will take time and usually takes several
review cycles. So I recommend that this gets a high priority.
I'm not sure if the importance of this came across in my initial review. My
apologies if that wasn't clear.
Regards,
Hans
On Saturday 14 March 2009 14:27:09 Hans Verkuil wrote:
On Friday 13 March 2009 10:01:37 chaithr...@ti.com wrote:
From: Chaithrika U S chaithr...@ti.com
Add defintions for Digital TV Standards supported by display driver
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository located at
http://linuxtv.org/hg/v4l-dvb/rev/1fd54a62abde
include/linux/videodev2.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7a8eafd..df4a622 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -704,6 +704,18 @@ typedef __u64 v4l2_std_id;
#define V4L2_STD_ALL(V4L2_STD_525_60 |\
V4L2_STD_625_50)
+#define V4L2_STD_720P_60((v4l2_std_id)(0x0001ULL))
+#define V4L2_STD_1080I_30 ((v4l2_std_id)(0x0002ULL))
+#define V4L2_STD_1080I_25 ((v4l2_std_id)(0x0004ULL))
+#define V4L2_STD_480P_60((v4l2_std_id)(0x0008ULL))
+#define V4L2_STD_576P_50((v4l2_std_id)(0x0010ULL))
+#define V4L2_STD_720P_25((v4l2_std_id)(0x0020ULL))
+#define V4L2_STD_720P_30((v4l2_std_id)(0x0040ULL))
+#define V4L2_STD_720P_50((v4l2_std_id)(0x0080ULL))
+#define V4L2_STD_1080P_25 ((v4l2_std_id)(0x0100ULL))
+#define V4L2_STD_1080P_30 ((v4l2_std_id)(0x0200ULL))
+#define V4L2_STD_1080P_24 ((v4l2_std_id)(0x0400ULL))
+
struct v4l2_standard {
__u32index;
v4l2_std_id id;
This requires an RFC. I'm not convinced that using v4l2_std_id is the
best approach. If you look at the CEA-861-D you see a lot more standards
(and E adds even more). Not to mention that when the DM646x is used in
combination with e.g. an FPGA then it should be possible to supply the
driver with custom timings as well. The v4l2_std_id type was never
designed for that.
My gut feeling is that v4l2_std_id should be effectively frozen and used
for the old TV broadcast standards only, and that a new API should be
created to setup these digital formats.
I've discussed this with Manju in the past, and I suggest that TI should
make a proposal in the form of an RFC that we can then discuss on the
mailinglists. One of the disadvantages of being the first who needs these
HDTV formats. The advantage of being the first is that you can design it
yourself, of course!
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Fri, 13 Mar 2009 16:55:40 -0700 (PDT) Trent Piepho xy...@speakeasy.org wrote: On Fri, 13 Mar 2009, Devin Heitmueller wrote: On Fri, Mar 13, 2009 at 5:11 PM, Trent Piepho xy...@speakeasy.org wrote: I like 8.8 fixed point a lot better. It gives more precision. The range is more in line with that the range of real SNRs are. Computers are binary, so the math can end up faster. It's easier to read when printed out in hex, since you can get the integer part of SNR just by looking at the first byte. E.g., 25.3 would be 0x194C, 0x19 = 25 db, 0x4c = a little more than quarter. Several drivers already use it. Wow, I know you said you like that idea alot better, but I read it and it made me feel sick to my stomach. Once we have a uniform format, we won't need to show it in hex at all. Tools like femon and scan can But if you do see it in hex, it's easier to understand. If it's not shown in hex, you still have better precision and better math. What advantage is there to using something that's 4.1 decimal fixed point on a binary computer? It is most important to set a SNR scale (whatever it is) than to keep this decision up to each driver author. I'm sure we all agree with this. A common good practice in the community is to try to achieve a common sense on what's reasonable, when changing the API. However, sometimes this is not possible. So, if a consensus is not archived, the maintainer should take the hard decision of choosing one proposal in favor of another, after listening to arguments from both sides. I really believe that we can get a consensus in this case. So, I'm proposing that we should discuss about it for some time, comparing each alternatives we have, focused on SNR only. Later, use can use the same approach for the other quality measurements on DVB. In order to start such discussions, I'm summarizing both proposals under the same perspective. I'm also presenting some criteria that are important on this scope People are welcome to contribute and to argue in favor/against each one. Let's establish a timeframe for discussions up to Sunday, 29. It would be really great if we can go into a consensus until then. --- Being objective, we have right now 2 proposals, for using the 16 bit integer. I'll assume that we'll have one bit used by signal on either proposal, since negative SNR's can be measured as well. Yet, for the calculus bellow, I will consider only absolute numbers. So, on both proposals, we have 1 bit for signal and 15 bits to be used for storing the absolute numbering representation. Those are the proposals: 1) use a 0.1 dB in order to represent the SNR. This means that we'll range abs(SNR) from 0.0 dB to 3276.7 dB. The minimal measure step is 0.1 dB. Doing some calculus, the proposal is to use: use 3.3219 bits = log2(10) - for representing the 0.1 step fractional part; use 11.6781 bits for the decimal part (2^11.6781 ~= 3276). The SNR(dB) will be given by: SNR(dB) = driver_SNR_measure / 10; 2) The second proposal is to represent the 7-bits MSB as the integer part of the SNR, in dB, and the 8-bits LSB as the fractional part. Doing some calculus, to have the same set of values, for comparision: The minimum fractional number we can represent is 1/256 = 0.039dB. This means that we'll range abs(SNR) from 0.0 dB to 127.998 dB, with the minimal measure step is 0.039 dB. The SNR(dB) will be given by: SNR(dB) = driver_SNR_measure / 256; If I didn't make any mistake, this is what we have: ---+--++--+--+--- | Abs | Abs | Step | 16 bits usage| Formula for converting into dB |Min dB| Max dB | in dB| signal/int/fraction | ---+--++--+--+--- Proposal 1 | 0.0 | 3276.7 | 0.1 | 1 / 11.6781 / 3.3219 | SNR(dB) = driver_SNR_measure / 10 ---+--++--+--+--- Proposal 2 | 0.0 | 127.998| 0.039| 1 / 7 / 8 | SNR(dB) = driver_SNR_measure / 256 ---+--++--+--+--- In order to compare both proposals, we should establish some decision criteria. Those are the ones that seems to be relevant for such discussions, in order of relevance. 1) Max/min range analysis We should choose the number of bits for the decimal to be capable enough to represent the maximum absolute value for SNR, otherwise, we'll loose precision at the part that interests most. So, we should have enough bits to represent the maximum practical values for SNR. 2) Step analysis The minimal step size, the better precision we'll have. This will help to provide extra info for adjusting antenna, for example, or fine-tuning the frequency to the one that offers more quality. 3) Computational efforts and Math
Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? I think splitting off the ISA drivers is certainly useful. I'm not sure whether you need to split the remainder into PCI and Others. I think that's overkill. Regards, Hans --- Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI and others. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r 626c136ec221 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Fri Mar 13 14:35:14 2009 -0700 +++ b/linux/drivers/media/radio/Kconfig Thu Mar 19 15:20:12 2009 +0300 @@ -10,6 +10,13 @@ Say Y here to enable selecting AM/FM radio adapters. if RADIO_ADAPTERS VIDEO_V4L2 + +config RADIO_ADAPTERS_ISA + boolean ISA radio adapters + ---help--- + Enable this if you have ISA-based radio adapter. + +if RADIO_ADAPTERS_ISA config RADIO_CADET tristate ADS Cadet AM/FM Tuner @@ -150,50 +157,6 @@ Say Y here to enable automatic probing for GemTek Radio card. The following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and 0x28c. - -config RADIO_GEMTEK_PCI - tristate GemTek PCI Radio Card support - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this PCI FM radio card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video for Linux API. Information on - this API and pointers to v4l 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-gemtek-pci. - -config RADIO_MAXIRADIO - tristate Guillemot MAXI Radio FM 2000 radio - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this radio card. This card may also be - found as Gemtek PCI FM. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maxiradio. - -config RADIO_MAESTRO - tristate Maestro on board radio - depends on VIDEO_V4L2 PCI - ---help--- - Say Y here to directly support the on-board radio tuner on the - Maestro 2 or 2E sound card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maestro. config RADIO_SF16FMI tristate SF16FMI Radio @@ -339,6 +302,68 @@ help Enter the I/O port of your Zoltrix radio card. +endif # RADIO_ADAPTERS_ISA + +config RADIO_ADAPTERS_PCI + boolean PCI radio adapters + ---help--- + Enable this if you have PCI-based radio adapters. + +if RADIO_ADAPTERS_PCI + +config RADIO_GEMTEK_PCI + tristate GemTek PCI Radio Card support + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this PCI FM radio card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video for Linux API. Information on + this API and pointers to v4l 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-gemtek-pci. + +config RADIO_MAXIRADIO + tristate Guillemot MAXI Radio FM 2000 radio + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this radio card. This card may also be + found as Gemtek PCI FM. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to v4l 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-maxiradio. + +config RADIO_MAESTRO + tristate Maestro on board radio + depends on VIDEO_V4L2 PCI + ---help--- + Say Y here to directly support the on-board radio tuner on the + Maestro 2 or 2E sound card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to v4l programs may be found at +
Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
On Thu, 19 Mar 2009 16:03:20 +0300 Alexey Klimov klimov.li...@gmail.com wrote: Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to have), it should have already unselected the ISA sub-menu. The remaining PCI and USB drivers are few. So, creating menus for them seem overkill. We could eventually reorganize the item order, and adding a few comments to indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what was done at DVB frontend part of the menu), but still, I can't see much value. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
On Thu, 2009-03-19 at 14:37 +0100, Hans Verkuil wrote: Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? I think splitting off the ISA drivers is certainly useful. I'm not sure whether you need to split the remainder into PCI and Others. I think that's overkill. Regards, Hans Yeah, i can inclose isa drivers by this construction: config RADIO_ADAPTERS_ISA boolean ISA radio adapters ---help--- Enable this if you have ISA-based radio adapter. if RADIO_ADAPTERS_ISA ..isa driver.. endif # RADIO_ADAPTERS_ISA and don't touch other drivers. That looks fine for me. --- Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI and others. Signed-off-by: Alexey Klimov klimov.li...@gmail.com -- diff -r 626c136ec221 linux/drivers/media/radio/Kconfig --- a/linux/drivers/media/radio/Kconfig Fri Mar 13 14:35:14 2009 -0700 +++ b/linux/drivers/media/radio/Kconfig Thu Mar 19 15:20:12 2009 +0300 @@ -10,6 +10,13 @@ Say Y here to enable selecting AM/FM radio adapters. if RADIO_ADAPTERS VIDEO_V4L2 + +config RADIO_ADAPTERS_ISA + boolean ISA radio adapters + ---help--- + Enable this if you have ISA-based radio adapter. + +if RADIO_ADAPTERS_ISA config RADIO_CADET tristate ADS Cadet AM/FM Tuner @@ -150,50 +157,6 @@ Say Y here to enable automatic probing for GemTek Radio card. The following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and 0x28c. - -config RADIO_GEMTEK_PCI - tristate GemTek PCI Radio Card support - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this PCI FM radio card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video for Linux API. Information on - this API and pointers to v4l 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-gemtek-pci. - -config RADIO_MAXIRADIO - tristate Guillemot MAXI Radio FM 2000 radio - depends on VIDEO_V4L2 PCI - ---help--- - Choose Y here if you have this radio card. This card may also be - found as Gemtek PCI FM. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maxiradio. - -config RADIO_MAESTRO - tristate Maestro on board radio - depends on VIDEO_V4L2 PCI - ---help--- - Say Y here to directly support the on-board radio tuner on the - Maestro 2 or 2E sound card. - - In order to control your radio card, you will need to use programs - that are compatible with the Video For Linux API. Information on - this API and pointers to v4l 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-maestro. config RADIO_SF16FMI tristate SF16FMI Radio @@ -339,6 +302,68 @@ help Enter the I/O port of your Zoltrix radio card. +endif # RADIO_ADAPTERS_ISA + +config RADIO_ADAPTERS_PCI + boolean PCI radio adapters + ---help--- + Enable this if you have PCI-based radio adapters. + +if RADIO_ADAPTERS_PCI + +config RADIO_GEMTEK_PCI + tristate GemTek PCI Radio Card support + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this PCI FM radio card. + + In order to control your radio card, you will need to use programs + that are compatible with the Video for Linux API. Information on + this API and pointers to v4l 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-gemtek-pci. + +config RADIO_MAXIRADIO + tristate Guillemot MAXI Radio FM 2000 radio + depends on VIDEO_V4L2 PCI + ---help--- + Choose Y here if you have this radio card. This card may also be + found as Gemtek PCI FM. + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to v4l 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-maxiradio. + +config RADIO_MAESTRO + tristate Maestro on board radio + depends on VIDEO_V4L2 PCI +
Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers
On Thu, Mar 19, 2009 at 5:03 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: On Thu, 19 Mar 2009 16:03:20 +0300 Alexey Klimov klimov.li...@gmail.com wrote: Hello, all What do you think about such patch that makes selecting of radio drivers in menuconfig more comfortable ? Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to have), it should have already unselected the ISA sub-menu. The remaining PCI and USB drivers are few. So, creating menus for them seem overkill. We could eventually reorganize the item order, and adding a few comments to indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what was done at DVB frontend part of the menu), but still, I can't see much value. Okay, well, sorry for bothering. Only one point here - if user want to unselect radio drivers in menuconfig, for example - pci and isa in some bad config file he should pick a lot of times, and with this patch only 2 times. But, okay. -- Best regards, Klimov Alexey -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for March 19 (media/video/au0828)
Stephen Rothwell wrote: Hi all, Changes since 20090318: when ADV_DEBUG=n: drivers/media/video/au0828/au0828-video.c:1438: error: 'const struct v4l2_subdev_core_ops' has no member named 'g_register' drivers/media/video/au0828/au0828-video.c:1453: error: 'const struct v4l2_subdev_core_ops' has no member named 's_register' -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/7] ARM: DaVinci: DM646x Video: Platform and board specific setup
chaithr...@ti.com writes:
From: Chaithrika U S chaithr...@ti.com
Add pin mux definitions, display device setup, clock setup functions
Add pin mux related code for the display device, also add platform device
and resource structures. Also define a platform specific clock setup function
that can be accessed by the driver to configure the clock and CPLD.
Signed-off-by: Chaithrika U S chaithr...@ti.com
Hi Chaithrika,
The mux and clock additions could be separated out into a separate
patch that could go into DaVinci git today since they are independent
of the video subsytem.
Kevin
---
Applies to linux-davinci GIT tree at
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=commit;h=486afa37130356662213cc1a2199a285b4fd72af
arch/arm/mach-davinci/board-dm646x-evm.c| 109
+++
arch/arm/mach-davinci/dm646x.c | 100
arch/arm/mach-davinci/include/mach/dm646x.h |9 ++
arch/arm/mach-davinci/include/mach/mux.h| 17
4 files changed, 235 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 907f424..a6bf180 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -39,6 +39,7 @@
#include mach/serial.h
#include mach/i2c.h
#include mach/mmc.h
+#include mach/mux.h
#include linux/platform_device.h
#include linux/i2c.h
@@ -46,6 +47,21 @@
#include linux/etherdevice.h
#include mach/emac.h
+#include media/adv7343.h
+
+#define VIDCLKCTL_OFFSET (0x38)
+#define VSCLKDIS_OFFSET (0x6c)
+
+#define VCH2CLK_MASK (0x07 8)
+#define VCH2CLK_SYSCLK8 (0x02 8)
+#define VCH2CLK_AUXCLK (0x03 8)
+#define VCH3CLK_MASK (0x07 12)
+#define VCH3CLK_SYSCLK8 (0x02 12)
+#define VCH3CLK_AUXCLK (0x03 12)
+
+#define VIDCH2CLK(0x01 10)
+#define VIDCH3CLK(0x01 11)
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 0),
};
@@ -95,11 +111,54 @@ int dm646xevm_eeprom_write(void *buf, off_t off, size_t
count)
}
EXPORT_SYMBOL(dm646xevm_eeprom_write);
+static struct i2c_client *cpld_client;
+
+static int cpld_video_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ cpld_client = client;
+ return 0;
+}
+
+static int __devexit cpld_video_remove(struct i2c_client *client)
+{
+ cpld_client = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id cpld_video_id[] = {
+ { cpld_video, 0 },
+ { }
+};
+
+static struct i2c_driver cpld_video_driver = {
+ .driver = {
+ .name = cpld_video,
+ },
+ .probe = cpld_video_probe,
+ .remove = cpld_video_remove,
+ .id_table = cpld_video_id,
+};
+
+static void evm_init_cpld(void)
+{
+ i2c_add_driver(cpld_video_driver);
+}
+
static struct i2c_board_info __initdata i2c_info[] = {
{
I2C_BOARD_INFO(24c256, 0x50),
.platform_data = eeprom_info,
},
+ {
+ I2C_BOARD_INFO(adv7343, 0x2A),
+ },
+ {
+ I2C_BOARD_INFO(ths7303, 0x2C),
+ },
+ {
+ I2C_BOARD_INFO(cpld_video, 0x3B),
+ },
};
static struct davinci_i2c_platform_data i2c_pdata = {
@@ -107,10 +166,59 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
+static int set_vpif_clock(int mux_mode, int hd)
+{
+ int val = 0;
+ int err = 0;
+ unsigned int value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ /* disable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value |= (VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (mux_mode == 1)
+ val = ~0x40;
+ else
+ val |= 0x40;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value = ~(VCH2CLK_MASK);
+ value = ~(VCH3CLK_MASK);
+
+ if (hd = 1)
+ value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
+ else
+ value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
+
+ __raw_writel(value, base + VIDCLKCTL_OFFSET);
+
+ /* enable the clock */
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ value = ~(VIDCH3CLK | VIDCH2CLK);
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ return 0;
+}
+
+static struct dm646x_vpif_config vpif_config = {
+ .set_clock = set_vpif_clock,
+};
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
Re: linux-next: Tree for March 19 (media/au8522)
Stephen Rothwell wrote: Hi all, Changes since 20090318: au8522_decoder.c:(.text+0x199898): undefined reference to `v4l2_ctrl_query_fill' au8522_decoder.c:(.text+0x1998b3): undefined reference to `v4l2_ctrl_query_fill' au8522_decoder.c:(.text+0x199944): undefined reference to `v4l2_device_unregister_subdev' au8522_decoder.c:(.text+0x19997c): undefined reference to `v4l2_chip_ident_i2c_client' au8522_decoder.c:(.text+0x199f1e): undefined reference to `v4l2_i2c_subdev_init' config attached. -- ~Randy # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29-rc8 # Thu Mar 19 07:25:59 2009 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_PREEMPT_RCU_TRACE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_INITRAMFS_COMPRESSION_NONE=y # CONFIG_INITRAMFS_COMPRESSION_GZIP is not set # CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set # CONFIG_INITRAMFS_COMPRESSION_LZMA is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_PCI_QUIRKS is not set # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set # CONFIG_SLUB is not set CONFIG_SLQB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq CONFIG_FREEZER=y # # Processor type and features # # CONFIG_NO_HZ is not set #
[REVIEWv2] bttv v4l2_subdev conversion
Hi all,
Here is the revised bttv v4l2_subdev conversion, taking into account all
the input I received.
The tree is here: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-bttv
Short changelog:
- tvaudio: fix mute and s/g_tuner handling
- tvaudio: add tda9875 support.
- tvaudio: always call init_timer to prevent rmmod crash.
- bttv: convert to v4l2_subdev since i2c autoprobing will disappear.
The tvaudio patches are the same as before, except split into two and a
third bug fix (init_timer) was added that I found while testing.
I've included the bttv patch below for easier reviewing.
Please note that the somewhat awkward i2c address lists are temporary.
When all drivers that need it are converted to v4l2_subdev I'll do a
sweep over all of them and clean this up. I want to wait with this until
I have a good overview of how it is used and who needs it.
In addition there are a few conversions in progress as well, so changing
APIs while that's still ongoing is something I want to avoid.
Regards,
Hans
# HG changeset patch
# User Hans Verkuil hverk...@xs4all.nl
# Date 1237493753 -3600
# Node ID 68050e782acbe6c47e3e3c0530ed1d96f0ec651f
# Parent 7191463177cdbf2ab1f2ade8eb3aa7dcad8cc80e
bttv: convert to v4l2_subdev since i2c autoprobing will disappear.
From: Hans Verkuil hverk...@xs4all.nl
Since i2c autoprobing will disappear bttv needs to be converted to use
v4l2_subdev instead.
Without autoprobing the autoload module option has become obsolete. A warning
is generated if it is set, but it is otherwise ignored.
Since the bttv card definitions are of questionable value three new options
were added to allow the user to control which audio module is selected:
msp3400, tda7432 or tvaudio.
By default bttv will use the card definitions and fallback on tvaudio as the
last resort.
If no audio device was found a warning is printed.
The saa6588 RDS device is now also explicitly probed since it is no longer
possible to autoprobe it. A new saa6588 module option was added to override
the card definition since I suspect more cards have this device than one
would guess from the card definitions.
Priority: normal
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
diff -r 7191463177cd -r 68050e782acb
linux/drivers/media/video/bt8xx/bttv-cards.c
--- a/linux/drivers/media/video/bt8xx/bttv-cards.c Thu Mar 19 20:53:32
2009 +0100
+++ b/linux/drivers/media/video/bt8xx/bttv-cards.c Thu Mar 19 21:15:53
2009 +0100
@@ -97,12 +97,12 @@
static unsigned int tuner[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
static unsigned int svhs[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
static unsigned int remote[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = UNSET };
+static unsigned int msp3400[BTTV_MAX];
+static unsigned int tda7432[BTTV_MAX];
+static unsigned int tvaudio[BTTV_MAX];
+static unsigned int saa6588[BTTV_MAX];
static struct bttv *master[BTTV_MAX] = { [ 0 ... (BTTV_MAX-1) ] = NULL };
-#ifdef MODULE
-static unsigned int autoload = 1;
-#else
-static unsigned int autoload;
-#endif
+static unsigned int autoload = UNSET;
static unsigned int gpiomask = UNSET;
static unsigned int audioall = UNSET;
static unsigned int audiomux[5] = { [ 0 ... 4 ] = UNSET };
@@ -121,6 +121,9 @@
module_param_array(tuner,int, NULL, 0444);
module_param_array(svhs, int, NULL, 0444);
module_param_array(remote, int, NULL, 0444);
+module_param_array(msp3400, int, NULL, 0444);
+module_param_array(tda7432, int, NULL, 0444);
+module_param_array(tvaudio, int, NULL, 0444);
module_param_array(audiomux, int, NULL, 0444);
MODULE_PARM_DESC(triton1,set ETBF pci config bit
@@ -131,7 +134,11 @@
MODULE_PARM_DESC(card,specify TV/grabber card model, see CARDLIST file for a
list);
MODULE_PARM_DESC(pll,specify installed crystal (0=none, 28=28 MHz, 35=35
MHz));
MODULE_PARM_DESC(tuner,specify installed tuner type);
-MODULE_PARM_DESC(autoload,automatically load i2c modules like tuner.o,
default is 1 (yes));
+MODULE_PARM_DESC(autoload,obsolete option, please do not use anymore);
+MODULE_PARM_DESC(msp3400, if 1, then load msp3400 only, default (0) is to use
the card definition.);
+MODULE_PARM_DESC(tda7432, if 1, then load tda7432 only, default (0) is to use
the card definition.);
+MODULE_PARM_DESC(tvaudio, if 1, then load tvaudio only, default (0) is to use
the card definition.);
+MODULE_PARM_DESC(saa6588, if 1, then load the saa6588 RDS module, default (0)
is to use the card definition.);
MODULE_PARM_DESC(no_overlay,allow override overlay default (0 disables, 1
enables)
[some VIA/SIS chipsets are known to have problem with
overlay]);
@@ -3332,9 +3339,21 @@
/* initialization part two -- after registering i2c bus */
void __devinit bttv_init_card2(struct bttv *btv)
{
+ static const unsigned short tvaudio_addrs[] = {
+ I2C_ADDR_TDA84251,
+ I2C_ADDR_TEA63001,
+ I2C_ADDR_TEA64201,
+ I2C_ADDR_TDA98401,
+
Re: [PATCH] add new frequency table for Strasbourg, France
(sorry for not answering sooner, I got distracted by good weather and the need to replenish my reserve of beer, depleted during the long wintry weather) On Tue, 17 Mar 2009, Benjamin Zores wrote: Anyway, to the original poster, Benjamin, can you make a short recording of, oh, say, ten seconds, of just PID 16 of only the five or six french muxen which you receive, and somehow deliver Here it goes. See attachment. Thanks -- except, um, somehow the attachments got mangled in the process of being MIMEd. It seems your mailer (Thunderbird) has chosen to tag the files as something like text/xemacs (similar, I can't remember exactly what) and performed some strange irreversible conversion of much of the binary data into character 0x3f, which breaks `dvbsnoop'. I attempted to convert those characters to the padding used to fill out the 188-byte Transport Stream packet, but it still was not enough, as that's not the only character that got mangled. Here's your ARD multiplex (722MHz) dumped after my conversion: from file: /tmp/hexrev : 47 40 10 17 00 40 ff 52 30 38 ff 00 00 ff 05 40 g...@...@.R08.@ 0010: 03 41 52 44 ff 40 38 01 21 14 ff 3a 5a 0b 04 35 .a...@8.!..:Z..5 0020: 45 40 1f 41 3b ff ff ff ff 41 0c 00 ff 01 00 02 e...@.a;A.. 0030: 01 00 03 01 00 06 01 62 1d ff 03 ff ff 40 04 1c ...b.@.. 0040: ff 40 04 4d ff 40 04 66 19 40 04 7e ff 40 04 ff @.m.@@.~.@.. 0050: ff 40 04 ff 57 40 29 ff 74 08 ff ff ff ff ff ff @..w@).t... [...] And here's how it should have looked (the sequential number is different, but the others should be similar or identical): from file: /tmp/ard-fs-DVB_T-17.Mar.2009-04h-NIT.ts : 47 40 10 1e 00 40 f0 52 30 38 d7 00 00 f0 05 40 g...@...@.R08.@ 0010: 03 41 52 44 f0 40 38 01 21 14 f0 3a 5a 0b 04 35 .a...@8.!..:Z..5 0020: 45 40 1f 41 3b ff ff ff ff 41 0c 00 e0 01 00 02 e...@.a;A.. 0030: 01 00 03 01 00 06 01 62 1d ff 03 df d2 40 04 1c ...b.@.. 0040: db 40 04 4d af 40 04 66 19 40 04 7e 83 40 04 8a @.m.@@.~.@.. 0050: b8 40 04 af 57 40 29 df 74 08 ff ff ff ff ff ff @..w@).t... It appears anything above 0x80 (decimal 128, or with high-bit set) is converted by Chunderbird to the 0x3f -- that is, any non-US-ASCII value gets mangled. So I'll ask, can you send the files again, but first make them ASCII-safe, either by `uuencode' or `xxd' or some base64 encoder, before attaching them? And send them directly to me, no need to bother the whole list with them. (Or if you have access to a different mailer which will attach the files as simple octet-stream, that will work with no need to pre-encode) One more question, can you receive anything at 858MHz, channel 69? I have this listed in the frequency allocations from several sources for Strasbourg. If not, I may be able to check myself in the next month or so, if I remember... Thanks! barry bouwsma -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for March 19 (media/video/au0828)
On Thu, 19 Mar 2009 09:54:48 -0700 Randy Dunlap randy.dun...@oracle.com wrote: Stephen Rothwell wrote: Hi all, Changes since 20090318: when ADV_DEBUG=n: drivers/media/video/au0828/au0828-video.c:1438: error: 'const struct v4l2_subdev_core_ops' has no member named 'g_register' drivers/media/video/au0828/au0828-video.c:1453: error: 'const struct v4l2_subdev_core_ops' has no member named 's_register' Fixed, thanks! 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho xy...@speakeasy.org wrote:
On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state-snr / ((1 24) / 10));
The SNR(dB) will be given by:
SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state-snr) 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf(%d.%d dB\n, snr / 10, snr % 10);
/* binary fixed point */
printf(%d.%02d dB\n, snr 8, (snr 0xff) * 100 8);
One more example, converting SNR into a 32-bit floating point number using
only integer operations. These don't do negative numbers but if the SNR
format used a sign bit it would be very easy to add, as IEEE 754 floating
point uses a sign bit too. I would need to think about it more to do 2's
complement.
For binary fixed point the conversion to a float is exact. For decimal
fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
when converted to floating point.
/* For 8.8 binary fixed point, this is the no-float version of:
* float snr_to_float(u16 snr) { return snr / 256.0 } */
u32 snr_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr);
return snr ? ((snr e) 0x7f) | ((142 - e) 23) : 0;
}
/* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
* intermediate value if SNR is above 1638.3 dB! This is the no-float
* version of:
* float snr_to_float(u16 snr) { return snr / 10.0 } */
u32 snr10_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr / 10);
return snr ? snr e) + 5) / 10) 0x7f) | (150 - e) 23 :
0;
}
You'd use the function like this:
float f;
*(u32 *)f = snr_to_float(snr);
== rant mode on ==
Wow, I think we have lost our minds!
The argument being put forth is based on the relative efficiency of
the multiply versus divide opcodes on modern CPU architectures?? And
that you're going to be able to get an SNR with a higher level of
precision than 0.1 dB?? (if the hardware suggests that it can then
it's LYING to you)
If that is the extent of the compelling argument that can be made,
then so be it. But after reading this, I'm kind of dumbfounded that
this is the basis for proposing 8.8 format over just sending it back
in 0.1dB increments. We have officially entered the realm of
ridiculous.
== rant mode off ==
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
--
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
Weird TS Stream from DMX_SET_PES_FILTER
Hello, I've been using the Linux DVB API to grab DBV-S MPEG2 video packets using a TechniSat S2 card. But something seems odd about DMX_SET_PES_FILTER. It returns a TS packets for my pid just fine, but by MPEG2 frames have no PES headers! The raw compressed MPEG2 frames just immediately follow the TS/adapation-field headers directly. When I wrote my TS packet decoder, I was expecting to have to decode PES headers after the TS header. But instead I found the raw compressed frames. They decode fine (with ffmpeg's libavcodec mpeg2 decoder,) and they look fine when rendered using SDL. But besides my own program, I can't get vlc or mplayer to decode this stream. Both vlc and mplayer sense a TS stream, but then they never render anything because, I suspect, that they can't find PES headers. So, two questions: 1. Am I crazy or is DMX_SET_PES_FILTER returning a non-standard TS stream? 2. Is there a way to receive a compliant MPEG-TS (or MPEG2-PS,) stream? 3. Should I use DMX_SET_FILTER instead? 4. If so, what goes in the filter/mask members of the dmx_filter_t struct? Thanks, Bob PS: I use the following to filter on my video stream pid (0x1344): struct dmx_pes_filter_params f; memset(f, 0, sizeof(f)); f.pid = (uint16_t) pid; f.input = DMX_IN_FRONTEND; f.output = DMX_OUT_TS_TAP; f.pes_type = DMX_PES_OTHER; f.flags = DMX_IMMEDIATE_START; -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Devin Heitmueller wrote:
On Thu, Mar 19, 2009 at 6:17 PM, Trent Piepho xy...@speakeasy.org wrote:
On Thu, 19 Mar 2009, Trent Piepho wrote:
Since the driver often needs to use a logarithm from dvb-math to find SNR,
you have code like this in the driver (from lgdt3305.c):
/* report SNR in dB * 10 */
*snr = (state-snr / ((1 24) / 10));
The SNR(dB) will be given by:
SNR(dB) = driver_SNR_measure / 256;
For the driver side, also from lgdt3305 which has both formats with an
ifdef:
/* convert from 8.24 fixed-point to 8.8 */
*snr = (state-snr) 16;
FWIW, converting to decimal to print using only integer math:
/* decimal fixed point */
printf(%d.%d dB\n, snr / 10, snr % 10);
/* binary fixed point */
printf(%d.%02d dB\n, snr 8, (snr 0xff) * 100 8);
One more example, converting SNR into a 32-bit floating point number using
only integer operations. These don't do negative numbers but if the SNR
format used a sign bit it would be very easy to add, as IEEE 754 floating
point uses a sign bit too. I would need to think about it more to do 2's
complement.
For binary fixed point the conversion to a float is exact. For decimal
fixed point it's not. For example 334 (33.4 dB) will become 33.42 dB
when converted to floating point.
/* For 8.8 binary fixed point, this is the no-float version of:
* float snr_to_float(u16 snr) { return snr / 256.0 } */
u32 snr_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr);
return snr ? ((snr e) 0x7f) | ((142 - e) 23) : 0;
}
/* For .1 decimal fixed point. NOTE: This will overflow the 32-bit
* intermediate value if SNR is above 1638.3 dB! This is the no-float
* version of:
* float snr_to_float(u16 snr) { return snr / 10.0 } */
u32 snr10_to_float(u16 snr)
{
unsigned int e = 23 - __fls(snr / 10);
return snr ? snr e) + 5) / 10) 0x7f) | (150 - e) 23 :
0;
}
You'd use the function like this:
float f;
*(u32 *)f = snr_to_float(snr);
== rant mode on ==
Wow, I think we have lost our minds!
The argument being put forth is based on the relative efficiency of
the multiply versus divide opcodes on modern CPU architectures?? And
that you're going to be able to get an SNR with a higher level of
precision than 0.1 dB?? (if the hardware suggests that it can then
it's LYING to you)
If that is the extent of the compelling argument that can be made,
then so be it. But after reading this, I'm kind of dumbfounded that
this is the basis for proposing 8.8 format over just sending it back
in 0.1dB increments. We have officially entered the realm of
ridiculous.
I have been going through this thread with much interest to see
where it was going.
In fact, what i found after reading the emails in this thread:
People would like to see standardized Signal stats in whatever apps
they like.
* Some users prefer a dB scale
* Some users prefer a percent scale
* Some prefer a relative scale.
Some need a signal monitor to do specific activity.
All this needs one to require the existing format into one common
format as required, which needs all drivers to be converted.
The Pros:
* Application can just read the value from the IOCTL and be happy
dispalying the value.
The Cons:
* Converting all drivers is no joke. Many drivers are Reverse
Engineered, Some are written from specs, Some are written from
sample code.
* Assuming that everything is alright, many do think that statistics
can be just used in a 1:1 proportion depending on some sample code.
But it has to be borne in mind that it is for a very specific
reference platform that it is. Lot of things do affect it directly.
Eventually what you consider statistics from a demod driver, from
where you get statistics, depends on other frontend components.
* Now assume that it is correct for the reference platform too..
Just think how many users are really conversant with all those units
and how to interpret it .. ? I would say hardly few ...
* Doing format/protocol conversions in kernel is not something
that's appreciated.
* Different types of conversions would be needed. All the conersions
need to be foolproof, else you shoot your foot, with some odd values
as well..
* This concept provides a single format with little or no flexibility.
I had been thinking a bit on this in the large view. My idea was
that it would be better not not to modify any driver as it is, but
get that value out to userspace with that exact representation.
The current existing API does the statistics correctly, but all it
needs is that the user/application needs to be told what units it
expects the statistics in.
That said, i did a small implementation, with almost all parctical
possible combinations.
The Pros:
* Application can choose whether it wants to display the statistics
in a specific way the application would like
* Application can also choose what format the driver
Re: [PATCH] gspca: add missing .type field check in VIDIOC_G_PARM
On Thu, 19 Mar 2009, [UTF-8] N??meth M??rton wrote: The gspca webcam driver does not check the .type field of struct v4l2_streamparm. This field is an input parameter for the driver according to V4L2 API specification, revision 0.24 [1]. Add the missing check. I think this check could go in the v4l2 core too. It already does a similar check for QUERYBUF, QBUF, DQBUF, etc. If the driver doesn't provide a method for -vidioc_try_fmt_foo() then the v4l2 core will reject a call with .type == V4L2_BUF_TYPE_foo. It seems like it should be ok to do this for S_PARM and G_PARM too. -- 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] FusionHDTV7 and v4l causes kernel panic
After searching the internet for ways to redirect the error to serial or other system and not getting to work, I typed out by hand what is on the screen minus the cpu dump which is mostly scrolled off anyway and thus gone. In trying to get the dump out ttyS0 I found I was getting different dumps to screen. When I use: kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet console=ttyS0,115200n8 console=tty0 I get: Call Trace: [f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885] [f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885] [c013d10c] handle_IRQ_event+0x1a/0x3f [c013df36] handle_fasteoi_irq+0x76/0xab [c0105236] do_IRQ+0x4f/0x65 [c010366f] common_interrupt+0x23/0x28 === Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 51 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19 c0 31 c9 85 c0 75 54 8d 42 04 39 42 04 74 04 EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7733f40 Kernel panic - not syncing: Fatal exception in interrupt When I use the default setting: kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet I get: Call Trace: [f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885] [f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885] [c013d10c] handle_IRQ_event+0x1a/0x3f [c013df36] handle_fasteoi_irq+0x76/0xab [c0105236] do_IRQ+0x4f/0x65 [c010366f] common_interrupt+0x23/0x28 [c0308096] _spin_unlock_irq+0x5/0x19 [c011e3ba] do_syslog+0x12f/0x2f1 [c010369c] reschedule_interrupt+0x28/0x30 [c012cd38] autoremove_wake_function+0x0/0x2d [c018f27a] kmsg_read+0x0/0x36 [c01888cf] proc_reg_read+0x60/0x73 [c018886f] proc_reg_read+0x0/0x73 [c015d9cf] vfs_read+0x81/0xf4 [c015dada] sys_read+0x3c/0x63 [c0102c7d] sysenter_past_esp+0x6a/0x91 === Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 51 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19 c0 31 c9 85 c0 75 54 8d 42 04 39 42 04 74 04 EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7693e7c Kernel panic - not syncing: Fatal exception in interrupt It may be a bit different each time because I think I've seen longer Call Trace dumps - Original Message - From: Andy Walls awa...@radix.net To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wednesday, March 18, 2009 7:48 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: I've added console=ttyS0,115200 console=tty0 to the kernel command line options and with out the console=tty0 part the dump no longer shows on the monitor, so redirect seems to work but loging the serial port on a second computer gets nothing. I tested the connection with echo and that worked but the kernel dump won't go out the port. The last 2 lines of the screen are: EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 Kernel panic - not syncing: Fatal exception in interrupt Hmm. The only thing in the cx23885 driver that tries to schedule work, and thus the only thing that could possibly pass in a bad argument, is the netup_ci_slot_status() function. It gets called when an IRQ comes in indicating a GPIO[01] event, and the driver thinks the card is a NetUp Dual DVB-S2 CI card. That's consistent with the fatal exception in interrupt, but without the backtrace, one can't be completely sure this call to queue work was initiated by the cx23885 driver and a problem with cx23885 data structures. (But it is the most likely scenario, IMO) I just can't see how netup_ci_slot_status() get's called for your card. Any way to get the dump to go out the serial port? Does 9600 baud help? (Just a guess.) Regards, Andy - Original Message - From: Andy Walls awa...@radix.net To: Timothy D. Lenz tl...@vorgon.com Cc: linux-media@vger.kernel.org Sent: Monday, March 16, 2009 6:07 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Mon, 2009-03-16 at 17:46 -0700, Timothy D. Lenz wrote: When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. Not even Shift+PageUp ? I looked at the logs and the ones that are text had nothing about it. Digital camera or pencil and paper will be least complex way to capture the ooops data. Please don't leave out the Code bytes at the bottom and do your best to make sure those are absolutely correct. Regards, Andy - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic
[PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
V4L2 supports chroma keying added new flags for the
source chroma keying which is exactly opposite of the
chorma keying supported by V4L2. In current implementation
video data is replaced by the graphics buffer data for some
specific color. While for the source chroma keying grahics
data is replaced by the video data for some specific color.
Both are exactly opposite so are mutually exclusive
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-common.c |7 +++
linux/include/linux/videodev2.h |6 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 3c42316..fa408f0 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATION: return Rotation;
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+step = 1;
+break;
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -571,6 +577,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_BG_COLOR:
qctrl-flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index 2c83935..592d1c8 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -548,6 +548,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
+#define V4L2_FBUF_CAP_SRC_CHROMAKEY0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@@ -555,6 +556,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
+#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct v4l2_clip {
struct v4l2_rectc;
@@ -882,6 +884,8 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+#define V4L2_CID_ROTATION (V4L2_CID_BASE+32)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+33)
enum v4l2_colorfx {
V4L2_COLORFX_NONE = 0,
V4L2_COLORFX_BW = 1,
@@ -889,7 +893,7 @@ enum v4l2_colorfx {
};
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.5.6
--
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: About white balance control.
Hi Bill, Thank you for your explanation. I think this one-shot white balance cal feature should be supported by H/W, or we should implement this with AWB activation for short period and lock immediately. That should be hard to tune properly to make it work in every circumstances. I'll do some research on it to make it work properly with my mobile camera module devices. Any technical advise appreciated. Cheers, Nate 2009/3/20 Bill Dirks b...@thedirks.org: DO_WHITE_BALANCE is intended to do a one-shot white balance calibration and then hold it. So you would hold up, for example, a white piece of paper in front of the camera and click the do white balance. Then the white balance should be correct as long as the lighting doesn't change. This can work better than auto white balance which can be fooled by colored walls, etc. Some video cameras used to have a button like this. Bill. Dongsoo, Nathaniel Kim wrote: Thank you Pingchart. So, V4L2_CID_DO_WHITE_BALANCE acts WB adjustment at every single time it has issued when device is in manual WB mode like V4L2_CID_WHITE_BALANCE_TEMPERATURE? Now I get it. But CID still missing for white balance presets like cloudy, sunny, fluorescentand so on. I think some sort of menu type CID could be useful to handle them, because WB presets differ for each devices. Cheers, Nate 2009/3/18 Laurent Pinchart laurent.pinch...@skynet.be: Hi Kim, On Wednesday 18 March 2009 05:32:08 Dongsoo, Nathaniel Kim wrote: Hello, I accidently realized today that I was using white balance control in wrong way. As far as I understand we've got V4L2_CID_AUTO_WHITE_BALANCE which activate auto white balance adjustment in runtime, V4L2_CID_DO_WHITE_BALANCE_TEMPERATURE specifying absolute kelvin value I suppose you mean V4L2_CID_WHITE_BALANCE_TEMPERATURE here. but can't get what V4L2_CID_DO_WHITE_BALANCE is for. I think after issuing V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, the white balance functionality works immediately. Isn't it right? What exactly is the button type V4L2_CID_DO_WHITE_BALANCE for? Because the V4L2 API document says that (the value is ignored). Does that mean that even we have issued V4L2_CID_AUTO_WHITE_BALANCE and V4L2_CID_WHITE_BALANCE_TEMPERATURE, we can't see the white balance working at that moment? V4L2_CID_AUTO_WHITE_BALANCE to enables or disables automatic white balance adjustment. When automatic white balance is enabled the device adjusts the white balance continuously. V4L2_CID_WHITE_BALANCE_TEMPERATURE controls the white balance adjustment manually. The control is only effective when automatic white balance is disabled. V4L2_CID_DO_WHITE_BALANCE instructs the device to run the automatic white balance adjustment algorithm once and use the results for white balance correction. It only makes sense when automatic white balance is disabled. And one more thing. If I want to serve several white balance presets, like cloudy, dawn, sunny and so on, what should I do? I think it should be supported as menu type, but most of drivers are using white balance CID with integer type...then what should I do? Define preset names with kelvin number like this? #define WB_CLOUDY 8000 Pretty confusing... anyone knows what should I do? Best regards, Laurent Pinchart -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
