dib3000mc.c and dib7000p.c compiler warnings
Hi Patrick, The daily build reports these warnings for dib3000mc.c and dib7000p.c: /marune/build/v4l-dvb-master/v4l/dib3000mc.c: In function 'dib3000mc_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib3000mc.c:863: warning: the frame size of 1508 bytes is larger than 1024 bytes /marune/build/v4l-dvb-master/v4l/dib7000p.c: In function 'dib7000p_i2c_enumeration': /marune/build/v4l-dvb-master/v4l/dib7000p.c:1341: warning: the frame size of 1568 bytes is larger than 1024 bytes In both cases a big state struct is allocated on the stack. Would it be possible to optimize that? If you are not the right person to deal with this, who might it be? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPL code for Omnivision USB video camera available.
Hi Erik, For the latest version of the gspca ov519 driver, with all me recent work for adding ov511 and ov518 support in it see: http://linuxtv.org/hg/~hgoede/gspca Regards, Hans On 06/13/2009 02:45 AM, Erik de Castro Lopo wrote: Hans de Goede wrote: This looks to me like its just ov51x-jpeg made to compile with the latest kernel. Its more than that. This driver supports a number of cameras and the only one we (bCODE) are really interested in is the ovfx2 driver. Did you make any functional changes? I believe the ovfx2 driver is completely new. Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline. Sorry its the ovfx2 that I'm interested in pushing into the kernel. May I ask what cam you have? I could certainly use more people testing this. It looks like this on the USB bus: Bus 007 Device 002: ID 05a9:2800 OmniVision Technologies, Inc. Cheers, Erik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - ivtv/cx18: fix regression: class controls are no longer seen - v4l2-ctl: add modulator get/set options. - v4l2-spec: update VIDIOC_G/S_MODULATOR section. - compat: fix __fls check for the arm architecture. - smscoreapi: fix compile warning The first one is a high prio bug as it is a 2.6.30 regression. Mike, once this is merged in the git tree this one can be queued for the 2.6.30 stable series. The other changes are small stuff. Thanks, Hans diffstat: linux/drivers/media/dvb/siano/smscoreapi.c |4 - linux/drivers/media/video/cx18/cx18-controls.c |2 linux/drivers/media/video/cx2341x.c|2 linux/drivers/media/video/ivtv/ivtv-controls.c |2 v4l/compat.h |3 v4l2-apps/util/v4l2-ctl.cpp| 78 + v4l2-spec/vidioc-g-modulator.sgml | 13 ++-- 7 files changed, 95 insertions(+), 9 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH (V2)] TVP514x: Migration to sub-device framework
On Wednesday 06 May 2009 20:31:33 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
Changes (From Previous post):
- Added static function to_decoder which will replace all
container_of instances.
- unsigned int replaced with u32.
- Cleaned up for line indentation.
- pdata initialized, was missing in earlier patch.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Reviewed By Hans Verkuil.
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
---
drivers/media/video/tvp514x.c | 854
++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 330 insertions(+), 538 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..12b49ad 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,11 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-int-device.h
+
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-i2c-drv.h
#include media/tvp514x.h
#include tvp514x_regs.h
@@ -49,13 +53,13 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
-#define dump_reg(client, reg, val) \
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
Why not turn this into a static inline function? Much better than a macro.
-/**
+/*
* enum tvp514x_std - enum for supported standards
*/
enum tvp514x_std {
@@ -64,15 +68,7 @@ enum tvp514x_std {
STD_INVALID
};
-/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
+/*
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -87,35 +83,29 @@ struct tvp514x_std_info {
};
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
-/**
+/*
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @state: TVP5146/47 decoder state - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int state;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +114,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+ * Input and Output Routing parameters
+ */
+ u32 input;
+ u32 output;
};
/* TVP514x default register values */
@@ -191,7 +184,8 @@ static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_TERM, 0, 0},
};
-/* List of image formats supported by TVP5146/47 decoder
+/*
+ * List of image formats supported by TVP5146/47 decoder
* Currently we are using 8 bit mode only, but can be
* extended to 10/20 bit mode.
*/
@@ -240,35 +234,27 @@ static struct tvp514x_std_info
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Sunday 14 June 2009 11:50:51 Hans Verkuil wrote: Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the following: - ivtv/cx18: fix regression: class controls are no longer seen - v4l2-ctl: add modulator get/set options. - v4l2-spec: update VIDIOC_G/S_MODULATOR section. - compat: fix __fls check for the arm architecture. - smscoreapi: fix compile warning The first one is a high prio bug as it is a 2.6.30 regression. Mike, once this is merged in the git tree this one can be queued for the 2.6.30 stable series. The other changes are small stuff. Added one more minor change: - v4l2-i2c-drv.h: add comment describing when not to use this header. Regards, Hans Thanks, Hans diffstat: linux/drivers/media/dvb/siano/smscoreapi.c |4 - linux/drivers/media/video/cx18/cx18-controls.c |2 linux/drivers/media/video/cx2341x.c|2 linux/drivers/media/video/ivtv/ivtv-controls.c |2 v4l/compat.h |3 v4l2-apps/util/v4l2-ctl.cpp| 78 + v4l2-spec/vidioc-g-modulator.sgml | 13 ++-- 7 files changed, 95 insertions(+), 9 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [linux-dvb] TT-Connect S2 -3650 CI and Pinnacle PCTV Dual Sat Pro PCI 4000I
-- Forwarded Message -- Subject: [linux-dvb] Fwd: TT-Connect S2 -3650 CI and Pinnacle PCTV Dual Sat Pro PCI 4000I Date: Sunday 14 June 2009 From: Christian Heidingsfelder [Heidingsfelder + Partner] christ...@heidingsfelder-partner.de To: linux-...@linuxtv.org First of all : Hi to all (and especially to Faruk) :) . It seems i own the two not working DVB-S Devices on linux. Its a TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I. Is there any chance to get one of them working. I use Gentoo with the 2.6.29- gentoo-r5 kernel. Regards Chris -- Mit freundlichen Grüßen Christian Heidingsfelder Heidingsfelder + Partner Kirchgasse 9 72474 Winterlingen-Benzingen Tel: +49 7577 933864 Fax: +49 7577 933863 christ...@heidingsfelder.eu DE -- *** Diese eMailadresse ist keine Zustelladresse. Aus technischen Gruenden kann ich Ihre eMail nicht sofort nach Eingang darauf überpruefen, ob sie Fristen oder Termine enthaelt. Daher uebernehme ich keine Gewaehr, daß Ihre Nachricht so rechtzeitig gelesen wird, daß alle zur Einhaltung von etwaigen Fristen oder Terminen notwendigen Massnahmen ergriffen werden koennen. Bitte uebermitteln Sie solche Schriftstuecke per Fax oder Brief an die weiter obenstehende Anschrift. *** Hiermit widerspreche ich ausdruecklich jeglicher Nutzung oder Uebermittlung meiner Daten, gleichgueltig, zu welchen Zwecken oder an welchen Empfaenger sie erfolgt. Insbesondere widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbe, Markt- oder Meinungsforschungszwecken gemaess § 28 Absatz 3 Bundesdatenschutzgesetz. *** Sicherheitshinweis: Wie Sie wissen, können eMails missbräuchlich unter fremden Namen erstellt oder verändert werden. Aus diesem Grunde bitte ich um Verständnis dafür, daß ich zu Ihrem und meinem Schutz die rechtliche Verbindlichkeit der in dieser eMail gemachten Erklärungen ausschliessen muß. Diese Regelung gilt nur dann nicht, wenn ich mit Ihnen eine anderweitige schriftliche Vereinbarung über die Einhaltung von Sicherheits- und Verschlüsselungstandards getroffen habe. *** Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (Falls dieser umherreisende Brief, der in unsichere Winde entsendet, aber Gott anvertraut wurde, zufällig in fremde Hände geraten ist, so bitte ich, dass er dem gegeben werde, an wen allein er gerichtet ist, und dass niemand ihn stiehlt, für den er nicht gemacht ist.) --- -- -- Mit freundlichen Grüßen Christian Heidingsfelder Heidingsfelder + Partner Kirchgasse 9 72474 Winterlingen-Benzingen Tel: +49 7577 933864 Fax: +49 7577 933863 christ...@heidingsfelder.eu DE -- *** Diese eMailadresse ist keine Zustelladresse. Aus technischen Gruenden kann ich Ihre eMail nicht sofort nach Eingang darauf überpruefen, ob sie Fristen oder Termine enthaelt. Daher uebernehme ich keine Gewaehr, daß Ihre Nachricht so rechtzeitig gelesen wird, daß alle zur Einhaltung von etwaigen Fristen oder Terminen notwendigen Massnahmen ergriffen werden koennen. Bitte uebermitteln Sie solche Schriftstuecke per Fax oder Brief an die weiter obenstehende Anschrift. *** Hiermit widerspreche ich ausdruecklich jeglicher Nutzung oder Uebermittlung meiner Daten, gleichgueltig, zu welchen Zwecken oder an welchen Empfaenger sie erfolgt. Insbesondere widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbe, Markt- oder Meinungsforschungszwecken gemaess § 28 Absatz 3 Bundesdatenschutzgesetz. *** Sicherheitshinweis: Wie Sie wissen, können eMails missbräuchlich unter fremden Namen erstellt oder verändert werden. Aus diesem Grunde bitte ich um Verständnis dafür, daß ich zu Ihrem und meinem Schutz die rechtliche Verbindlichkeit der in dieser eMail gemachten Erklärungen ausschliessen muß. Diese Regelung gilt nur dann nicht, wenn ich mit Ihnen eine anderweitige schriftliche Vereinbarung über die Einhaltung von Sicherheits- und Verschlüsselungstandards getroffen habe. *** Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata. (Falls dieser umherreisende Brief, der in unsichere Winde entsendet, aber Gott anvertraut wurde, zufällig in fremde Hände geraten ist, so bitte ich, dass er dem gegeben werde, an wen allein er gerichtet ist, und dass niemand ihn stiehlt, für den er nicht gemacht ist.) ___ linux-dvb users mailing list For V4L/DVB development, please use instead
Re: [PATCHv7 5/9] v4l2-spec: Add documentation description for FM TX extended control class
On Friday 12 June 2009 19:30:36 Eduardo Valentin wrote: This single patch adds documentation description for FM Modulator (FM_TX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- v4l2-spec/Makefile |1 + v4l2-spec/biblio.sgml | 10 +++ v4l2-spec/controls.sgml | 205 +++ 3 files changed, 216 insertions(+), 0 deletions(-) diff --git a/v4l2-spec/Makefile b/v4l2-spec/Makefile index 7a19924..bfe2965 100644 --- a/v4l2-spec/Makefile +++ b/v4l2-spec/Makefile @@ -242,6 +242,7 @@ ENUMS = \ v4l2_power_line_frequency \ v4l2_priority \ v4l2_tuner_type \ + v4l2_fm_tx_preemphasis \ STRUCTS = \ v4l2_audio \ diff --git a/v4l2-spec/biblio.sgml b/v4l2-spec/biblio.sgml index b013ece..0921849 100644 --- a/v4l2-spec/biblio.sgml +++ b/v4l2-spec/biblio.sgml @@ -11,6 +11,16 @@ url=http://www.eia.org;http://www.eia.org/ulink)/corpauthor Service/title /biblioentry +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev + authorgroup + corpauthorCENELEC European Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor + /authorgroup + titleEN 50067 Specification of the radio data system (RDS) for +VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz/title +/biblioentry + biblioentry id=en300294 abbrevENnbsp;300nbsp;294/abbrev authorgroup diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..0bb6f00 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -458,6 +458,12 @@ video is actually encoded into that format./para paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,205 @@ control must support read access and may support write access./entry /tgroup /table /section + +section id=fm-tx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fm-tx-control-id + titleFM_TX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FM_TX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FM_TX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry coding - encodes + /row + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrSets the Programme Service name (PS_NAME) for transmission. +It is intended for static display on a receiver. It is the primary aid to listeners in
Re: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Friday 12 June 2009 19:30:33 Eduardo Valentin wrote:
This patch adds a new class of extended controls. This class
is intended to support FM Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and preemphasis properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index b8cffc9..9733435 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -806,6 +806,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098 /* Old-style 'user' 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_ID_MASK (0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1144,6 +1145,39 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE(V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FM_TX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FM_TX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FM_TX_CLASS_BASE + 5)
I think these RDS controls should be renamed to V4L2_CID_RDS_TX_. This makes
it clear that these controls relate to the RDS transmitter instead of a
receiver. I would not be surprised to see similar controls appear for an RDS
receiver in the future.
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (V4L2_CID_FM_TX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FM_TX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FM_TX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FM_TX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FM_TX_CLASS_BASE + 16)
+
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE + 17)
+enum v4l2_fm_tx_preemphasis {
+ V4L2_FM_TX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FM_TX_PREEMPHASIS_50_uS= 1,
+ V4L2_FM_TX_PREEMPHASIS_75_uS= 2,
+};
I suggest renaming this to V4L2_CID_FM_TX_PREEMPHASIS. There is already a
similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in the
future, so I think this name should be more specific to the FM_TX API.
+#define V4L2_CID_TUNE_POWER_LEVEL(V4L2_CID_FM_TX_CLASS_BASE + 18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
{wanted] support for PDTV001 dual tuner PCI DVB-T card [EC188/EC100 and 2x MxL5003S]
just bought one of these on the off-chance that it might work i did not know what chips were on the car when i bought it but at €17 for a dual tuner dvb-t pci card i reckoned it was worth a try i have looked at the card and it has: the e3c EC188/EC100 pair of pci chips a pair of MaxLinear MxL5003S silicon tuners it seems that there is support for the tuners but i only found support for the EC168 USB chip set. is there any prospect of support for this card? i don't think i could write it myself but i certainly could test it. regards -- simon -- 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: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
Hi Hans,
On Sun, Jun 14, 2009 at 1:46 PM, Hans Verkuilhverk...@xs4all.nl wrote:
On Friday 12 June 2009 19:30:33 Eduardo Valentin wrote:
This patch adds a new class of extended controls. This class
is intended to support FM Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and preemphasis properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/linux/include/linux/videodev2.h
b/linux/include/linux/videodev2.h
index b8cffc9..9733435 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -806,6 +806,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098 /* Old-style 'user' 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_ID_MASK (0x0fff)
#define V4L2_CTRL_ID2CLASS(id) ((id) 0x0fffUL)
@@ -1144,6 +1145,39 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FM_TX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FM_TX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FM_TX_CLASS_BASE + 5)
I think these RDS controls should be renamed to V4L2_CID_RDS_TX_. This makes
it clear that these controls relate to the RDS transmitter instead of a
receiver. I would not be surprised to see similar controls appear for an RDS
receiver in the future.
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED
(V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (V4L2_CID_FM_TX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FM_TX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FM_TX_CLASS_BASE +
11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED (V4L2_CID_FM_TX_CLASS_BASE +
14)
+#define V4L2_CID_PILOT_TONE_DEVIATION
(V4L2_CID_FM_TX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY
(V4L2_CID_FM_TX_CLASS_BASE + 16)
+
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE +
17)
+enum v4l2_fm_tx_preemphasis {
+ V4L2_FM_TX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FM_TX_PREEMPHASIS_50_uS = 1,
+ V4L2_FM_TX_PREEMPHASIS_75_uS = 2,
+};
I suggest renaming this to V4L2_CID_FM_TX_PREEMPHASIS. There is already a
similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in the
future, so I think this name should be more specific to the FM_TX API.
Right. Agreed for both suggestions.
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE +
18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Eduardo Bezerra Valentin
--
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: [PATCHv7 5/9] v4l2-spec: Add documentation description for FM TX extended control class
Hi Hans, On Sun, Jun 14, 2009 at 1:41 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Friday 12 June 2009 19:30:36 Eduardo Valentin wrote: This single patch adds documentation description for FM Modulator (FM_TX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- v4l2-spec/Makefile | 1 + v4l2-spec/biblio.sgml | 10 +++ v4l2-spec/controls.sgml | 205 +++ 3 files changed, 216 insertions(+), 0 deletions(-) diff --git a/v4l2-spec/Makefile b/v4l2-spec/Makefile index 7a19924..bfe2965 100644 --- a/v4l2-spec/Makefile +++ b/v4l2-spec/Makefile @@ -242,6 +242,7 @@ ENUMS = \ v4l2_power_line_frequency \ v4l2_priority \ v4l2_tuner_type \ + v4l2_fm_tx_preemphasis \ STRUCTS = \ v4l2_audio \ diff --git a/v4l2-spec/biblio.sgml b/v4l2-spec/biblio.sgml index b013ece..0921849 100644 --- a/v4l2-spec/biblio.sgml +++ b/v4l2-spec/biblio.sgml @@ -11,6 +11,16 @@ url=http://www.eia.org;http://www.eia.org/ulink)/corpauthor Service/title /biblioentry + biblioentry id=en50067 + abbrevENnbsp;50067/abbrev + authorgroup + corpauthorCENELEC European Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor + /authorgroup + titleEN 50067 Specification of the radio data system (RDS) for +VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz/title + /biblioentry + biblioentry id=en300294 abbrevENnbsp;300nbsp;294/abbrev authorgroup diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..0bb6f00 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -458,6 +458,12 @@ video is actually encoded into that format./para paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,205 @@ control must support read access and may support write access./entry /tgroup /table /section + + section id=fm-tx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fm-tx-control-id + titleFM_TX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FM_TX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FM_TX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry coding - encodes Right. + /row + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrSets the Programme Service name (PS_NAME) for transmission. +It is
Re: [PATCHv7 6/9] FMTx: si4713: Add files to add radio interface for si4713
On Friday 12 June 2009 19:30:37 Eduardo Valentin wrote:
This patch adds files which creates the radio interface
for si4713 FM transmitter (modulator) devices.
In order to do the real access to device registers, this
driver uses the v4l2 subdev interface exported by si4713 i2c driver.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/drivers/media/radio/radio-si4713.c | 325
++
linux/include/media/si4713.h | 40
2 files changed, 365 insertions(+), 0 deletions(-)
create mode 100644 linux/drivers/media/radio/radio-si4713.c
create mode 100644 linux/include/media/si4713.h
diff --git a/linux/drivers/media/radio/radio-si4713.c
b/linux/drivers/media/radio/radio-si4713.c
new file mode 100644
index 000..4c23120
--- /dev/null
+++ b/linux/drivers/media/radio/radio-si4713.c
@@ -0,0 +1,325 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/si4713.h
+
+/* Driver state struct */
+struct radio_si4713_device {
+ struct v4l2_device v4l2_dev;
+ struct video_device *radio_dev;
+};
+
+/* module parameters */
+static int radio_nr = -1;/* radio device minor (-1 == auto assign) */
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_fill_audout(struct v4l2_audioout *vao)
+{
+ /* TODO: check presence of audio output */
+ memset(vao, 0, sizeof(*vao));
No need for memset, the v4l2 core has done that for you already.
+ strlcpy(vao-name, FM Modulator Audio Out, 32);
+
+ return 0;
+}
+
+static int radio_si4713_enumaudout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ return radio_si4713_fill_audout(vao);
+}
+
+static int radio_si4713_g_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ int rval = radio_si4713_fill_audout(vao);
+
+ vao-index = 0;
+
+ return rval;
+}
+
+static int radio_si4713_s_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ if (vao-index != 0)
+ return -EINVAL;
+
+ return radio_si4713_fill_audout(vao);
It is a write only ioctl, so you can just do this:
return vao-index ? -EINVAL : 0;
+}
+
+/* radio_si4713_querycap - query device capabilities */
+static int radio_si4713_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713, sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 Modulator,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_MODULATOR;
+
+ return 0;
+}
+
+/* radio_si4713_queryctrl - enumerate control items */
+static int radio_si4713_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+
Unnecessary empty line.
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_MUTE,
+ 0
+ };
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 fmtx_ctrls[] = {
+ V4L2_CID_FM_TX_CLASS,
+ V4L2_CID_RDS_ENABLED,
+
Re: [PATCHv7 0/9] FM Transmitter (si4713) and another changes
On Friday 12 June 2009 19:30:31 Eduardo Valentin wrote: Hello all, I'm resending the FM transmitter driver and the proposed changes in v4l2 api files in order to cover the fmtx extended controls class. Difference from version #6 is that now I've added added lots of comments made by Hans. Here is a list of changes: - Reduce card type string - Remove unused ext controls - Remove s/g_audio and add s/g_audout and enumaudout - remove g/s_input - remove s/g_tuner and add s/g_modulator on subdev and platform driver - reduce function names - Update documentation - remove a few unused and empty lines - remove sysfs interface - rename dev_to_v4l2 to si4713_to_v4l2 (and vice-versa) macros - Remove disabled controls - Add string support - remove v4l2_i2c_driver_data - Join si4713.c with si4713-subdev.c - move platform data to include/media - update documentation And now this series is based on two of Hans' trees: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2. http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-str. The first tree has refactoring of v4l2 i2c helper functions. The second one has string support for extended controls, which is used in this driver. So, now the series includes changes to add the new v4l2 FMTX extended controls (and its documetation) and si4713 i2c and platform drivers (and its documentation as well). Besides that, there is also a patch to add g_modulator to v4l2-subdev and a patch to add support for fm tx class in v4l2-ctl util. In the TODO list there are two things: i. the signal level measurement property is missing. ii. Re-factor the driver so all that get/set internal functions are removed. I believe those TODO's can be done later on, if there is still time to get this driver merged into this window. But of course, this is my opinion, I will understand also if you ask to do them before merge it. I think the refactoring should be done first. I don't believe it is that much work and experience shows that it is better to do this right away while you are still motivated :-) The string control support should not go into 2.6.31. I would like to do that only in the v4l-dvb tree (so it will appear in 2.6.32) since I want to give that a bit more time to mature. I implemented it very quickly and I do not feel comfortable queueing this for 2.6.31. In addition it is still unclear if Mauro will merge my v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will hamper the development of this and other embedded platforms. I also need to add a new V4L2_CAP_MODULATOR (which needs a review as well). And finally I realized that we need to add some v4l2_modulator capabilities for the RDS encoder similar to the upcoming v4l2_tuner RDS capabilities as is described in this RFC: http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html I haven't had time to implement this RFC and I know that is not going to make 2.6.31. It's now almost at the top of my TODO list, so it should go in soon (pending unforeseen circumstances). As a result of rereading this RFC I also started to wonder about whether the si4713 supports the MMBS functionality. Do you know anything about that? Taken all together I think that 2.6.31 is probably not feasible. If it was another two weeks until the merge window, then it would. But the merge window is already open, and there are just too many little TODOs for this driver. And it's also a new API, so we need to be more careful than usual. Regards, Hans With these series, the driver is now functional through the v4l2 extended controls changes. Here is an output of v4l2-ctl: # v4l2-ctl -d /dev/radio0 -l --all Driver Info: Driver name : radio-si4713 Card type : Silicon Labs Si4713 Modulator Bus info : Driver version: 0 Capabilities : 0x0008 Modulator Audio output: 0 (FM Modulator Audio Out) Frequency: 1552000 (97000.00 MHz) Video Standard = 0x Modulator: Name : FM Modulator Capabilities : 62.5 Hz stereo Frequency range : 76.0 MHz - 108.0 MHz Available subchannels: mono stereo User Controls mute (bool) : default=1 value=0 FM Radio Modulator Controls rds_feature_enabled (bool) : default=1 value=1 rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0 rds_program_type (int) : min=0 max=31 step=1 default=0 value=0 rds_ps_name (str) : value='Si4713 ' len=8 ' len=9 rds_radio_text (str) : value='Si4713 audio_limiter_feature_enabled (bool) : default=1 value=1 audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider audio_limiter_deviation (int) : min=0 max=9 step=10 default=66250 value=66250 flags=slider
Re: [PATCH (V2)] TVP514x: Migration to sub-device framework
On Sunday 14 June 2009 12:14:38 Hans Verkuil wrote:
On Wednesday 06 May 2009 20:31:33 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
Changes (From Previous post):
- Added static function to_decoder which will replace all
container_of instances.
- unsigned int replaced with u32.
- Cleaned up for line indentation.
- pdata initialized, was missing in earlier patch.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Reviewed By Hans Verkuil.
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
---
drivers/media/video/tvp514x.c | 854
++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 330 insertions(+), 538 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..12b49ad 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
snip
+/*
* tvp514x_remove - decoder driver i2c remove handler
* @client: i2c driver client device structure
*
@@ -1460,13 +1301,10 @@ out_free:
*/
static int __exit tvp514x_remove(struct i2c_client *client)
This can't be __exit since it is called when the adapter is removed, not when
the driver is removed. And that's perfectly valid even if this driver is
compiled in the kernel instead of as a module.
{
- struct tvp514x_decoder *decoder = i2c_get_clientdata(client);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct tvp514x_decoder *decoder = to_decoder(sd);
- if (!client-adapter)
- return -ENODEV; /* our client isn't attached */
-
- v4l2_int_device_unregister(decoder-v4l2_int_device);
- i2c_set_clientdata(client, NULL);
+ v4l2_device_unregister_subdev(sd);
kfree(decoder);
return 0;
}
@@ -1485,11 +1323,9 @@ static const struct tvp514x_reg
tvp5146_init_reg_seq[] = {
{TOK_WRITE, REG_VBUS_DATA_ACCESS_NO_VBUS_ADDR_INCR, 0x00},
{TOK_WRITE, REG_OPERATION_MODE, 0x01},
{TOK_WRITE, REG_OPERATION_MODE, 0x00},
+ {TOK_TERM, 0, 0},
};
-static const struct tvp514x_init_seq tvp5146_init = {
- .no_regs = ARRAY_SIZE(tvp5146_init_reg_seq),
- .init_reg_seq = tvp5146_init_reg_seq,
-};
+
/*
* TVP5147 Init/Power on Sequence
*/
@@ -1512,22 +1348,18 @@ static const struct tvp514x_reg
tvp5147_init_reg_seq[] ={
{TOK_WRITE, REG_VBUS_DATA_ACCESS_NO_VBUS_ADDR_INCR, 0x00},
{TOK_WRITE, REG_OPERATION_MODE, 0x01},
{TOK_WRITE, REG_OPERATION_MODE, 0x00},
+ {TOK_TERM, 0, 0},
};
-static const struct tvp514x_init_seq tvp5147_init = {
- .no_regs = ARRAY_SIZE(tvp5147_init_reg_seq),
- .init_reg_seq = tvp5147_init_reg_seq,
-};
+
/*
* TVP5146M2/TVP5147M1 Init/Power on Sequence
*/
static const struct tvp514x_reg tvp514xm_init_reg_seq[] = {
{TOK_WRITE, REG_OPERATION_MODE, 0x01},
{TOK_WRITE, REG_OPERATION_MODE, 0x00},
+ {TOK_TERM, 0, 0},
};
-static const struct tvp514x_init_seq tvp514xm_init = {
- .no_regs = ARRAY_SIZE(tvp514xm_init_reg_seq),
- .init_reg_seq = tvp514xm_init_reg_seq,
-};
+
/*
* I2C Device Table -
*
@@ -1535,48 +1367,22 @@ static const struct tvp514x_init_seq tvp514xm_init
= {
* driver_data - Driver data
*/
static const struct i2c_device_id tvp514x_id[] = {
- {tvp5146, (unsigned long)tvp5146_init},
- {tvp5146m2, (unsigned long)tvp514xm_init},
- {tvp5147, (unsigned long)tvp5147_init},
- {tvp5147m1, (unsigned long)tvp514xm_init},
+ {tvp5146, (unsigned long)tvp5146_init_reg_seq},
+ {tvp5146m2, (unsigned long)tvp514xm_init_reg_seq},
+ {tvp5147, (unsigned long)tvp5147_init_reg_seq},
+ {tvp5147m1, (unsigned long)tvp514xm_init_reg_seq},
{},
};
MODULE_DEVICE_TABLE(i2c, tvp514x_id);
-static struct i2c_driver tvp514x_i2c_driver = {
- .driver = {
- .name = TVP514X_MODULE_NAME,
- .owner = THIS_MODULE,
- },
+static struct v4l2_i2c_driver_data v4l2_i2c_data = {
+ .name = TVP514X_MODULE_NAME,
Please don't use v4l2_i2c_driver_data. That is only necessary if this module
has to support pre-2.6.26 kernels. Since this driver will never be built for
such older kernels there is also no need to use this struct. Do it the same
as was done in the ths7303 driver, i.e. as a regular i2c driver.
Don't forget to remove the
Re: TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I
Hi Chris, Christian Heidingsfelder [Heidingsfelder + Partner] wrote: It seems i own the two not working DVB-S Devices on linux. Its a TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I. Is there any chance to get one of them working. I use Gentoo with the 2.6.29- gentoo-r5 kernel. a driver for the Pinnacle PCTV Sat HDTV Pro USB (452e) was written by Dominik Kuhlen at the beginning of last year. This Pinnacle device is based on the same hardware as the TechnoTrend S2-3600. From what I know Michael H. Schimek has contributed the S2-3650 code and CI handling for the box(anyone, please correct me if I am wrong). Some interim state of drivers for above mentioned devices is currently included in Igor M. Liplianin's repository at http://mercurial.intuxication.org/hg/s2-liplianin/ The linuxtv.org wiki lists a patch under http://www.linuxtv.org/wiki/index.php/TechnoTrend_TT-connect_S2-3650_CI#S2API to be applied, but it fails on some chunks... I'd say your best chance is to start asking the people who wrote the drivers to create a diff against http://linuxtv.org/hg/v4l-dvb that will eventually go into the kernel. As for the Pinnacle PCTV Dual Sat Pro PCI 4000I... All I know is that the wiki at http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_Dual_Sat_Pro_PCI_4000I lists this device as not supported. Regards. André -- 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 7/10 - v2] DM355 platform changes for vpfe capture driver
On Thursday 11 June 2009 19:00:46 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM355 platform and board setup
This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.
Added registration of vpss platform driver based on last review
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm355-evm.c| 72 +++-
arch/arm/mach-davinci/dm355.c | 83
arch/arm/mach-davinci/include/mach/dm355.h |2 +
arch/arm/mach-davinci/include/mach/mux.h |9 +++
4 files changed, 163 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..cf87e21 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
#include linux/io.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/videodev2.h
+#include media/tvp514x.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
@@ -134,12 +136,23 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+#define TVP5146_I2C_ADDR 0x5D
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
- { I2C_BOARD_INFO(dm355evm_msp, 0x25),
+ { I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
- /* plus irq */ },
+ },
+ {
+ I2C_BOARD_INFO(tvp5146, TVP5146_I2C_ADDR),
+ .platform_data = tvp5146_pdata,
+ },
+ /* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
Huh? What's this? I only know the tlv320aic23b and that's an audio driver.
- /* { I2C_BOARD_INFO(tvp5146, 0x5d), }, */
};
static void __init evm_init_i2c(void)
@@ -178,6 +191,57 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
Please, don't use all-caps. Just use Composite and S-Video.
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
As mentioned elsewhere: v4l2_routing will disappear, so please don't use it.
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ }
+};
A general remark: currently you link your inputs directly to a subdev. This
approach has two disadvantages:
1) It doesn't work if there are no subdevs at all (e.g. because everything
goes through an fpga).
2) It fixes the reported order of the inputs to the order of the subdevs.
I think it is better to have a separate array of input descriptions that
refer to a subdev when an input is associated with that subdev. It's more
flexible that way, and I actually think that the vpfe driver will be
simplified as well.
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM355 EVM,
+ .ccdc = DM355 CCDC,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -189,6 +253,8 @@ static struct davinci_uart_config uart_config __initdata
= {
static void __init dm355_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9baeed3..3263af8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@
Re: [PATCH 8/10 - v2] DM6446 platform changes for vpfe capture driver
On Thursday 11 June 2009 19:00:47 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
DM644x platform and board setup
This adds plarform and board setup changes required to support
vpfe capture driver on DM644x
Added registration of vpss platform driver based on last comment
Reviewed By Hans Verkuil.
Reviewed By Laurent Pinchart.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm644x-evm.c| 68
++-
arch/arm/mach-davinci/dm644x.c | 56 ++
arch/arm/mach-davinci/include/mach/dm644x.h |2 +
3 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..13b73a7 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
#include linux/io.h
#include linux/phy.h
#include linux/clk.h
-
+#include linux/videodev2.h
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
@@ -195,6 +196,57 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = COMPOSITE,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = SVIDEO,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
No all-caps.
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct v4l2_routing tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ },
+};
Same remark as for patch 7: suggest using a separate input array.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tcm825x.c: migrating to sub-device framework? (was: TVP514x: Migration to sub-device framework)
On Sunday 14 June 2009 14:44:53 Hans Verkuil wrote: On Sunday 14 June 2009 12:14:38 Hans Verkuil wrote: On Wednesday 06 May 2009 20:31:33 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com This patch converts TVP514x driver to sub-device framework from V4L2-int framework. Now that tvp514x is converted to using v4l2_subdev (pending a few small final tweaks) there is only one driver left that uses the v4l2-int-device.h API: tcm825x.c. What is involved in converting this driver as well? And who can do this? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Did I miss any other patches or RFCs that need to be reviewed?
Hi all, I think I've finally finished reviewing all the pending patches. Are there any that I've missed? Or are there other postings that need my attention? Please let me know, otherwise I assume that I'm (finally!) up to date. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I
Hi André first of all, thanks for responding :-) http://www.linuxtv.org/wiki/index.php/TechnoTrend_TT-connect_S2-3650_CI#S2A PI to be applied, but it fails on some chunks... yep, i tried it (maybe i did something wrong !? ) : snip--- scheffeneu ~ # mkdir 3650 scheffeneu ~ # cd 3650 scheffeneu 3650 # hg clone -r 9263 http://mercurial.intuxication.org/hg/s2- liplianin destination directory: s2-liplianin requesting all changes adding changesets adding manifests adding file changes added 9264 changesets with 24422 changes to 1647 files updating working directory 1189 files updated, 0 files merged, 0 files removed, 0 files unresolved scheffeneu 3650 # wget http://hem.passagen.se/faruks/3650/my_s2api_pctv452e.txt --2009-06-14 15:43:18-- http://hem.passagen.se/faruks/3650/my_s2api_pctv452e.txt Resolving hem.passagen.se... 91.196.241.100 Connecting to hem.passagen.se|91.196.241.100|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 43373 (42K) [text/plain] Saving to: `my_s2api_pctv452e.txt' 100%[] 43,373 71.3K/s in 0.6s 2009-06-14 15:43:22 (71.3 KB/s) - `my_s2api_pctv452e.txt' saved [43373/43373] scheffeneu 3650 # cd s2-liplianin scheffeneu s2-liplianin # patch -p1 ../my_s2api_pctv452e.txt patching file linux/drivers/media/dvb/dvb-usb/pctv452e.c patching file linux/drivers/media/dvb/frontends/lnbp22.c patching file linux/drivers/media/dvb/frontends/stb0899_algo.c patching file linux/drivers/media/dvb/frontends/stb0899_drv.c patching file linux/drivers/media/dvb/frontends/stb0899_drv.h patching file linux/drivers/media/dvb/frontends/stb0899_priv.h patching file linux/drivers/media/dvb/frontends/stb6100.c patching file linux/drivers/media/dvb/frontends/stb6100.h patching file linux/drivers/media/dvb/frontends/stb6100_cfg.h patching file linux/include/linux/dvb/frontend.h scheffeneu s2-liplianin # make make -C /root/3650/s2-liplianin/v4l /bin/sh: /sbin/lsmod: No such file or directory make[1]: Entering directory `/root/3650/s2-liplianin/v4l' No version yet, using 2.6.29-gentoo-r5 make[1]: Leaving directory `/root/3650/s2-liplianin/v4l' /bin/sh: /sbin/lsmod: No such file or directory make[1]: Entering directory `/root/3650/s2-liplianin/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.29 Created default (all yes) .config file ./scripts/make_myconfig.pl make[1]: Leaving directory `/root/3650/s2-liplianin/v4l' /bin/sh: /sbin/lsmod: No such file or directory make[1]: Entering directory `/root/3650/s2-liplianin/v4l' perl
Re: [PATCH] adding support for setting bus parameters in sub device
On Fri, 12 Jun 2009, Hans Verkuil wrote: On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. TBH, the argumentation like someone changes the autoconf algorithm or previously undocumented register is discovered doesn't convince me. In any case, I am adding authors, maintainers and major contributors to various soc-camera host drivers to CC and asking them to express their opinion on this matter. I will not add anything else here to avoid any unfair competition:-) they will have to go a couple emails back in this thread to better understand what is being discussed here. Suddenly the board doesn't work because it was never verified or tested with that different polarity. Or worse: it glitches only 0.001% of the time. That's going to be a nasty bug to find. You generally verify your board with specific bus settings, and that's what should also be configured explicitly. Sure, it is nice not to have to think about this. The problem is that I believe that you *have* to think about it. The longer I think about this, the more convinced I am that relying on autoconfiguration is a bad design. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: {wanted] support for PDTV001 dual tuner PCI DVB-T card [EC188/EC100 and 2x MxL5003S]
On 06/14/2009 01:48 PM, Simon Kenyon wrote: just bought one of these on the off-chance that it might work i did not know what chips were on the car when i bought it but at €17 for a dual tuner dvb-t pci card i reckoned it was worth a try i have looked at the card and it has: the e3c EC188/EC100 pair of pci chips a pair of MaxLinear MxL5003S silicon tuners EC188 chip contains PCI -bridge and integrated EC100 demodulator. Just like EC168 that is USB equivalent interface chip. it seems that there is support for the tuners but i only found support for the EC168 USB chip set. Tuners are supported and also demodulator part have some kind of base driver in my EC168 devel tree. Someone should write PCI -bridge driver. I don't have any PCI -experience and I am not very motivated even finalize EC188/EC100 due to lack of specs. is there any prospect of support for this card? i don't think i could write it myself but i certainly could test it. In my understanding, no one is working for that currently. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Sun, 14 Jun 2009, Eduardo Valentin wrote:
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS ? ? ? ? ? ? ? ? (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_ENABLED ? ? ? ? ? ? ? ? (V4L2_CID_FM_TX_CLASS_BASE +
1)
+#define V4L2_CID_RDS_PI ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY ? ? ? ? ? ? ? ? ? ? (V4L2_CID_FM_TX_CLASS_BASE +
3)
+#define V4L2_CID_RDS_PS_NAME ? ? ? ? ? ? ? ? (V4L2_CID_FM_TX_CLASS_BASE +
4)
+#define V4L2_CID_RDS_RADIO_TEXT ? ? ? ? ? ? ? ? ? ?
?(V4L2_CID_FM_TX_CLASS_BASE + 5)
I think these RDS controls should be renamed to V4L2_CID_RDS_TX_. This makes
it clear that these controls relate to the RDS transmitter instead of a
receiver. I would not be surprised to see similar controls appear for an RDS
receiver in the future.
So there should there be different controls to set the same thing, one set
for tx and another for rx?
+#define V4L2_CID_PREEMPHASIS ? ? ? ? ? ? ? ? (V4L2_CID_FM_TX_CLASS_BASE +
17)
+enum v4l2_fm_tx_preemphasis {
+ ? ? V4L2_FM_TX_PREEMPHASIS_DISABLED ? ? ? ? = 0,
+ ? ? V4L2_FM_TX_PREEMPHASIS_50_uS ? ? ? ? ? ?= 1,
+ ? ? V4L2_FM_TX_PREEMPHASIS_75_uS ? ? ? ? ? ?= 2,
+};
I suggest renaming this to V4L2_CID_FM_TX_PREEMPHASIS. There is already a
similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in the
future, so I think this name should be more specific to the FM_TX API.
The cx88 driver could get support for setting the fm preemphasis via a
control. I added support via a module option, but a control would be
better. You're saying it shouldn't use this fm preemphasis control?
--
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: [PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
On Sunday 14 June 2009 18:23:41 Trent Piepho wrote:
On Sun, 14 Jun 2009, Eduardo Valentin wrote:
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FM_TX_CLASS_BASE
+ 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FM_TX_CLASS_BASE
+ 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FM_TX_CLASS_BASE
+ 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FM_TX_CLASS_BASE + 5)
I think these RDS controls should be renamed to V4L2_CID_RDS_TX_. This
makes
it clear that these controls relate to the RDS transmitter instead of a
receiver. I would not be surprised to see similar controls appear for an
RDS
receiver in the future.
So there should there be different controls to set the same thing, one set
for tx and another for rx?
Sure. Say some RDS decoder stores the PI in a register. I can imagine that
we add a V4L2_CID_RDS_RX_PI control for that. Whereas a V4L2_CID_RDS_TX_PI
control will return the PI sent out by the encoder.
Currently no such controls exist (or are needed) for an RDS decoder, but I
wouldn't be surprised at all if we need them at some point in the future.
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE
+ 17)
+enum v4l2_fm_tx_preemphasis {
+ V4L2_FM_TX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FM_TX_PREEMPHASIS_50_uS = 1,
+ V4L2_FM_TX_PREEMPHASIS_75_uS = 2,
+};
I suggest renaming this to V4L2_CID_FM_TX_PREEMPHASIS. There is already a
similar V4L2_CID_MPEG_EMPHASIS control and others might well appear in the
future, so I think this name should be more specific to the FM_TX API.
The cx88 driver could get support for setting the fm preemphasis via a
control. I added support via a module option, but a control would be
better. You're saying it shouldn't use this fm preemphasis control?
Correct. This set the pre-emphasis when transmitting. For receiving you want
a separate control. Although the enum should be made generic. So FM_TX can be
removed from the enum.
Why should we have one rx and one tx control for this? Because you can have
both receivers and transmitters in one device and you want independent control
of the two.
It is my believe that the other fm_tx controls are unambiguously transmitter
related, so I don't think they need a TX prefix. It doesn't hurt if someone
can double check that, though.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding support for setting bus parameters in sub device
On Sunday 14 June 2009 17:33:19 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. TBH, the argumentation like someone changes the autoconf algorithm or previously undocumented register is discovered doesn't convince me. The point I'm making here is that since the autoconf part is done in software it *can* be changed. And while just looking at the code there is no reason why choosing a positive vs. negative polarity makes any difference if both host and i2c device support it, from a hardware standpoint it *can* make a difference. In practice you verify and certify your hardware using specific bus settings. An autoconf algorithm just obfuscates those settings. And relying on it to always return the same settings in the future seems also wishful thinking. In any case, I am adding authors, maintainers and major contributors to various soc-camera host drivers to CC and asking them to express their opinion on this matter. I will not add anything else here to avoid any unfair competition:-) they will have to go a couple emails back in this thread to better understand what is being discussed here. It will definitely be interesting to see what others think. Regards, Hans Suddenly the board doesn't work because it was never verified or tested with that different polarity. Or worse: it glitches only 0.001% of the time. That's going to be a nasty bug to find. You generally verify your board with specific bus settings, and that's what should also be configured explicitly. Sure, it is nice not to have to think about this. The problem is that I believe that you *have* to think about it. The longer I think about this, the more convinced I am that relying on autoconfiguration is a bad design. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding support for setting bus parameters in sub device
On Sun, 14 Jun 2009, Hans Verkuil wrote: The point I'm making here is that since the autoconf part is done in software it *can* be changed. And while just looking at the code there is no reason why choosing a positive vs. negative polarity makes any difference if both host and i2c device support it, from a hardware standpoint it *can* make a difference. In practice you verify and certify your hardware using specific bus settings. An autoconf algorithm just obfuscates those settings. And relying on it to always return the same settings in the future seems also wishful thinking. Ok, I think, now I get it. Your real concern is the only case when both parties can be configured in software for either polarity. And whereas we think (ok, make it I think) this means, both configurations should work, in practice only one of them is guaranteed to. And you think having an optional board preference flag is not enough, it should be mandatory. I see your point now. I am still not positive this case alone is enough to force all boards to specify all polarities. How about, we use autonegotiation where there's only one valid configuration. If both possibilities and no preference is set - ok, we can decide. Either we complain loudly in the log and try our luck, or we complain and fail. Let's see: hs hi hs lo vs hi vs lo pclk rise pclk fall d hi d lo master slave mt9v022 x x x xx x x - x x mt9m001 x - x -- x x - x - mt9m111 x - x -x - x - x - mt9t031 x - x -x x x - x - ov772xx - x -x - x - x - tw9910x - x -x - x - x - (hs = hsync, vs = vsync, pclk = pixel clock, d = data) So, as you see, this free choice is not so often. In any case, I am adding authors, maintainers and major contributors to various soc-camera host drivers to CC and asking them to express their opinion on this matter. I will not add anything else here to avoid any unfair competition:-) they will have to go a couple emails back in this thread to better understand what is being discussed here. It will definitely be interesting to see what others think. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding support for setting bus parameters in sub device
Let's begin the maintainers party. A board designer knows what the host supports, knows what the sensor supports, and knows if he added any inverters on the board, and based on all that information he can just setup these parameters for the sensor chip. Settings that are fixed on the sensor chip he can just ignore, he only need to specify those settings that the sensor really needs. I don't think that's true Hans. A lot of mainline's kernel boards have been written by passionate people, having no access to boards layout (for pxa, the includes corgi, tosa, hx4700, mioa701, all palm series, ...) For these people, having an autonegociation algorithm is one less thing to bother about. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. If you're afraid of side effects, you can force the polarity in board code with the current framework. If we reduce the current autonegociation code to polarity (forget bus witdh, ...) : - if board coder sets unique polarities, they'll be chosen (1) - if board coder doesn't set them, the autonegociation algorithm will choose (2) What you want to do is to force all board developers to explicitely polarities, to only use subset (1) of current negociation algorithm. I see no technical point motivating this. The existing algorithm is richer. Personnaly, I'll consider that reducing soc_camera framework to (1) instead of (1)+(2) is a regretable regression. As part of the board maintaineers having no access to my board's design, I find the current framework a help. I still don't understand clearly why delete (2) from current framework. As I said, the board designer knows polarities doesn't stand in our communauty where board are developped without prior knowledge. So Hans, why do you want to delete (2) ? -- Robert -- 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 7/10 - v2] DM355 platform changes for vpfe capture driver
On Sunday 14 June 2009, Hans Verkuil wrote:
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
Huh? What's this? I only know the tlv320aic23b and that's an audio driver.
AIC33 is another audio codec chip:
http://focus.ti.com/docs/prod/folders/print/tlv320aic33.html
One can't list audio codecs with other board-specific data until
the ASoC initialization gets re-worked to allow it. That's why
it's commented out of the list-of-i2c-devices-on-the-board.
--
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 (V2)] TVP514x: Migration to sub-device framework
On Sunday 14 June 2009, Hans Verkuil wrote:
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
Why not turn this into a static inline function? Much better than a macro.
IMO, too big for either. Make it a real function.
--
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] SDMC DM1105N not being detected
Igor M. Liplianin wrote: On 6 June 2009 23:37:47 Simon Kenyon wrote: Igor M. Liplianin wrote: On 5 June 2009 21:41:46 Simon Kenyon wrote: Simon Kenyon wrote: Simon Kenyon wrote: the picture seems to be breaking up badly will revert to my version and see if that fixes it [sorry for the delay. i was away on business] i've checked and your original code, modified to compile and including my changes to control the LNB works very well; the patch you posted does not. i have swapped between the two and rebooted several times to make sure. i will do a diff and see what the differences are regards -- simon the main changes seem to be a reworking of the interrupt handling and some i2c changes -- simon How fast is your system? reasonably fast it is a dual core AMD64 X2 running at 3.1GHz Main change is to move demuxing from interrupt to work handler. So I prepaired another patch, with separate work queue. May be you find some time to test. I wonder CPU usage and interrupts count(cat /proc/interrupts) while viewing DVB. I guess your card generates a lot of unnecessary(unknown ?) irq's. Another idea is to increase dma buffer. i've tested that now sorry for the delay - at a family wedding anyway, that seems to work fine. will st some more, but the first results (with kaffeine) seem good. i did a complete scan and then tried about 20 different channels. they all seemed to work fine. thanks -- simon -- 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] SDMC DM1105N not being detected
On 15 June 2009 01:49:09 Simon Kenyon wrote: Igor M. Liplianin wrote: On 6 June 2009 23:37:47 Simon Kenyon wrote: Igor M. Liplianin wrote: On 5 June 2009 21:41:46 Simon Kenyon wrote: Simon Kenyon wrote: Simon Kenyon wrote: the picture seems to be breaking up badly will revert to my version and see if that fixes it [sorry for the delay. i was away on business] i've checked and your original code, modified to compile and including my changes to control the LNB works very well; the patch you posted does not. i have swapped between the two and rebooted several times to make sure. i will do a diff and see what the differences are regards -- simon the main changes seem to be a reworking of the interrupt handling and some i2c changes -- simon How fast is your system? reasonably fast it is a dual core AMD64 X2 running at 3.1GHz Main change is to move demuxing from interrupt to work handler. So I prepaired another patch, with separate work queue. May be you find some time to test. I wonder CPU usage and interrupts count(cat /proc/interrupts) while viewing DVB. I guess your card generates a lot of unnecessary(unknown ?) irq's. Another idea is to increase dma buffer. i've tested that now sorry for the delay - at a family wedding anyway, that seems to work fine. will st some more, but the first results (with kaffeine) seem good. i did a complete scan and then tried about 20 different channels. they all seemed to work fine. thanks -- simon Good news. Thank you for testing. Igor -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following 4 changesets: 01/04: Remote control debugging for dw2102 driver based USB cards http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6d3b1e91f924 02/04: Add keymaps for TeVii and TBS USB DVB-S/S2 cards http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=8ebfde1bb8d1 03/04: Add support for DVBWorld DVB-C USB Cable card. http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=3de9ad52e9af 04/04: Add support for yet another SDMC DM1105 based DVB-S card. http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=2ddb4eb239ff dm1105/dm1105.c | 137 ++ dvb-usb/dw2102.c | 334 +-- dvb-usb/dw2102.h |1 3 files changed, 388 insertions(+), 84 deletions(-) Thanks, Igor -- 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: GPL code for Omnivision USB video camera available.
On Sat, 13 Jun 2009 18:12:10 +1000 Hans de Goede hdego...@redhat.com wrote: Getting ovfx2 support into the mainline kernel sounds like a good idea! I'm not such a big fan of merging the driver as is though, as it does its own buffer management (and ioctl handling, usb interrupt handling, locking, etc). I understand completely. For adding the ovfx2 driver, you could start by copying ov519.c, which already has setup and control code fro most ov sensors and then rewrite the bridge part to be ovfx2 code, then later we can try to move the sensor code to a shared c file for the ov519 and ovfx2 driver, depending on how much you needed to change the sensor code. Or you could add support for the ovfx2 to the ov519 driver. Note I've recently being doing quite a bit of work on the ov519 driver, adding support for the ov511 and ov518 and adding more controls. I'll make a mercurial tree available with my latest code in it asap. Ok, there's the rub. I am simply way too busy at the moment to push this through myself. I was hoping I could contract someone to take the existing code and massage it into shape ready for merging. I would prefer it if that someone was already a V4L hacker, but if I can't find anyone with pre-existing V4L experience I'll find someone local with general Linux kernel/driver experience. Cheers, Erik -- === erik de castro lopo senior design engineer bCODE level 2, 2a glen street milsons point sydney nsw 2061 australia tel +61 (0)2 9954 4411 fax +61 (0)2 9954 4422 www.bcode.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: My DVB-card is flooding the consol with recv bulk message failed
To add another data-point, I am also getting this error with the same board ... as far as I have been able to test, it's something that was OK in 2.6.27, regressed in 2.6.28 and is still a problem in 2.6.30. Note that this is the rev.1 DViCO lsb_release -rd Description:Ubuntu karmic (development branch) Release:9.10 uname -a Linux nina 2.6.30-8-generic #9-Ubuntu SMP Wed Jun 3 15:23:55 UTC 2009 i686 GNU/Linux I get spammed by this console message every 1 second and the board does not operate: [ 375.385180] dvb-usb: bulk message failed: -110 (4/0) I see the same problem with mythbuntu-9.04 (2.6.28) So I put in a new disc and installed Fedora-10 (2.6.27) with the same firmware: /lib/firmware/xc3028-v27.fw ... and it's working fine now. Earlier history: It was working fine on Ubuntu Hardy (it was an earlier kernel (2.6.20??) with the v4l-dvb drivers downloaded with hg and compiled locally). Ubuntu Intrepid was also OK. I also tried powering off, removing the power cable and taking the board out of the machine before re-trying in a different PCI slot - it made no difference. lsusb gives: Bus 002 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc302 (initialized) Bus 002 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc302 (initialized) From /var/log/messages, it seems to be loading the firmware but then running into problems with writing to the zl10353: Jun 13 15:01:45 nina kernel: [ 26.488234] dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital 4' in warm state. Jun 13 15:01:45 nina kernel: [ 26.488611] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 13 15:01:45 nina kernel: [ 26.519611] DVB: registering new adapter (DViCO FusionHDTV DVB-T Dual Digital 4) Jun 13 15:01:45 nina kernel: [ 26.937373] cxusb: No IR receiver detected on this device. Jun 13 15:01:45 nina kernel: [ 26.937383] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... Jun 13 15:01:45 nina kernel: [ 27.057256] xc2028 2-0061: creating new instance Jun 13 15:01:45 nina kernel: [ 27.057262] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner Jun 13 15:01:45 nina kernel: [ 27.057887] dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initialized and connected. Jun 13 15:01:45 nina kernel: [ 27.057913] dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital 4' in warm state. Jun 13 15:01:45 nina kernel: [ 27.058049] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 13 15:01:45 nina kernel: [ 27.089208] DVB: registering new adapter (DViCO FusionHDTV DVB-T Dual Digital 4) Jun 13 15:01:45 nina kernel: [ 27.136536] cxusb: No IR receiver detected on this device. Jun 13 15:01:45 nina kernel: [ 27.136545] DVB: registering adapter 1 frontend 0 (Zarlink ZL10353 DVB-T)... Jun 13 15:01:45 nina kernel: [ 27.136737] xc2028 3-0061: creating new instance Jun 13 15:01:45 nina kernel: [ 27.136741] xc2028 3-0061: type set to XCeive xc2028/xc3028 tuner Jun 13 15:01:45 nina kernel: [ 27.137404] dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initialized and connected. . . . Jun 13 15:02:25 nina kernel: [ 118.801333] i2c-adapter i2c-2: firmware: requesting xc3028-v27.fw Jun 13 15:02:25 nina kernel: [ 118.922171] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 Jun 13 15:02:25 nina kernel: [ 118.932344] xc2028 2-0061: Loading firmware for type=BASE F8MHZ (3), id . Jun 13 15:02:27 nina kernel: [ 120.659451] xc2028 2-0061: Loading firmware for type=D2633 DTV7 (90), id . Jun 13 15:02:27 nina kernel: [ 120.685823] xc2028 2-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . Jun 13 15:02:27 nina kernel: [ 120.989117] i2c-adapter i2c-3: firmware: requesting xc3028-v27.fw Jun 13 15:02:27 nina kernel: [ 120.993890] xc2028 3-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 Jun 13 15:02:27 nina kernel: [ 121.004235] xc2028 3-0061: Loading firmware for type=BASE F8MHZ (3), id . Jun 13 15:02:29 nina kernel: [ 122.735596] xc2028 3-0061: Loading firmware for type=D2633 DTV7 (90), id . Jun 13 15:02:29 nina kernel: [ 122.762090] xc2028 3-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . Jun 13 15:02:30 nina kernel: [ 123.853864] usbcore: registered new interface driver hiddev Jun 13 15:02:30 nina kernel: [ 123.853884] usbcore: registered new interface driver usbhid Jun 13 15:02:30 nina kernel: [ 123.853887] usbhid: v2.6:USB HID core driver Jun 13 15:02:30 nina kernel: [ 123.868170] zl10353: write to reg 62 failed (err = -121)! Jun 13 15:02:32 nina kernel: [ 125.868184] zl10353: write to reg 50 failed (err = -121)! Jun 13 15:03:03 nina kernel: [ 157.456355] IRQ 16/nvidia: IRQF_DISABLED is not
[PULL] http://kernellabs.com/hg/~dheitmueller/au8522-qam64
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/au8522-qam64 for the following: - au8522: add support for QAM-64 modulation type The patch went in unmodified after doing some testing to ensure it didn't break anything with VSB or QAM256 (and adding a proper patch description). There is some opportunity for refactoring a bit in relation to the QAM256 code, but there is not a pressing need for such a change and I don't want to hold up support for this any longer since it works as-is. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] adding support for setting bus parameters in sub device
On Wed, Jun 10, 2009 at 5:55 AM, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
re-sending with RFC in the header
This patch adds support for setting bus parameters such as bus type
(BT.656, BT.1120 etc), width (example 10 bit raw image data bus)
and polarities (vsync, hsync, field etc) in sub device. This allows
bridge driver to configure the sub device for a specific set of bus
parameters through s_bus() function call.
Reviewed By Hans Verkuil.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..c1cfb3b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,41 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the bridge device through a bus that
+ * carries * the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used by bridge driver to
+ * set the desired bus parameters in the sub device to work with it.
+ */
+enum v4l2_subdev_bus_type {
+ /* BT.656 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_656,
+ /* BT.1120 interface. Embedded sync */
+ V4L2_SUBDEV_BUS_BT_1120,
+ /* 8 bit muxed YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_8,
+ /* 16 bit YCbCr bus, separate sync and field signals */
+ V4L2_SUBDEV_BUS_YCBCR_16,
+ /* Raw Bayer image data bus , 8 - 16 bit wide, sync signals */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_subdev_bus {
+ enum v4l2_subdev_bus_type type;
+ u8 width;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
As for the pins/signals, I wonder if per-signal polarity/edge is
enough. If this is going to be used by/replace the soc_camera
interface then we also need to know if the signal is present or not.
For instance, I have a SuperH board using my CEU driver together with
one OV7725 camera or one TW9910 video decoder. Some revisions of the
board do not route the field signal between the SuperH on-chip CEU and
the TW9910. Both the CEU and the TW9910 support this signal, it just
happen to be missing. I think we need a way to include this board
specific property somehow.
/ magnus
--
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
