[PATCH] Add support for Twinhan 1027 DVB-S card
This patch is the modified version of sfstudio (Denis Romanenko)
patch, adapted for current mercurial revision.
diff -r d6520e486ee6 linux/drivers/media/video/cx88/cx88-cards.c
--- a/linux/drivers/media/video/cx88/cx88-cards.c Sat Jan 30
01:27:34 2010 -0200
+++ b/linux/drivers/media/video/cx88/cx88-cards.c Sat Jan 30
11:02:24 2010 +0300
@@ -2120,6 +2120,18 @@
} },
.mpeg = CX88_MPEG_DVB,
},
+ [CX88_BOARD_TWINHAN_VP1027_DVBS] = {
+ .name = Twinhan VP-1027 DVB-S,
+ .tuner_type = TUNER_ABSENT,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .input = {{
+ .type = CX88_VMUX_DVB,
+ .vmux = 0,
+ } },
+ .mpeg = CX88_MPEG_DVB,
+ },
};
/* -- */
@@ -2584,6 +2596,10 @@
.subvendor = 0xb034,
.subdevice = 0x3034,
.card = CX88_BOARD_PROF_7301,
+ }, {
+ .subvendor = 0x1822,
+ .subdevice = 0x0023,
+ .card = CX88_BOARD_TWINHAN_VP1027_DVBS,
},
};
@@ -3075,6 +3091,13 @@
cx_set(MO_GP1_IO, 0x10);
mdelay(50);
break;
+
+ case CX88_BOARD_TWINHAN_VP1027_DVBS:
+ cx_write(MO_GP0_IO, 0x3230);
+ cx_write(MO_GP0_IO, 0x3210);
+ msleep(1);
+ cx_write(MO_GP0_IO, 0x1230);
+ break;
}
}
diff -r d6520e486ee6 linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c Sat Jan 30 01:27:34 2010 -0200
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c Sat Jan 30 11:02:24 2010 +0300
@@ -57,6 +57,7 @@
#include stv0900.h
#include stb6100.h
#include stb6100_proc.h
+#include mb86a16.h
MODULE_DESCRIPTION(driver for cx2388x based DVB cards);
MODULE_AUTHOR(Chris Pascoe c.pas...@itee.uq.edu.au);
@@ -251,6 +252,10 @@
.if2 = 45600,
};
+static struct mb86a16_config twinhan_vp1027 = {
+ .demod_address = 0x08,
+};
+
#if defined(CONFIG_VIDEO_CX88_VP3054) ||
(defined(CONFIG_VIDEO_CX88_VP3054_MODULE) defined(MODULE))
static int dntv_live_dvbt_pro_demod_init(struct dvb_frontend* fe)
{
@@ -430,15 +435,41 @@
cx_set(MO_GP0_IO, 0x6040);
switch (voltage) {
- case SEC_VOLTAGE_13:
- cx_clear(MO_GP0_IO, 0x20);
- break;
- case SEC_VOLTAGE_18:
- cx_set(MO_GP0_IO, 0x20);
- break;
- case SEC_VOLTAGE_OFF:
- cx_clear(MO_GP0_IO, 0x20);
- break;
+ case SEC_VOLTAGE_13:
+ cx_clear(MO_GP0_IO, 0x20);
+ break;
+ case SEC_VOLTAGE_18:
+ cx_set(MO_GP0_IO, 0x20);
+ break;
+ case SEC_VOLTAGE_OFF:
+ cx_clear(MO_GP0_IO, 0x20);
+ break;
+ }
+
+ if (core-prev_set_voltage)
+ return core-prev_set_voltage(fe, voltage);
+ return 0;
+}
+
+static int vp1027_set_voltage(struct dvb_frontend *fe,
+ fe_sec_voltage_t voltage)
+{
+ struct cx8802_dev *dev = fe-dvb-priv;
+ struct cx88_core *core = dev-core;
+
+ switch (voltage) {
+ case SEC_VOLTAGE_13:
+ dprintk(1, LNB SEC Voltage=13\n);
+ cx_write(MO_GP0_IO, 0x1220);
+ break;
+ case SEC_VOLTAGE_18:
+ dprintk(1, LNB SEC Voltage=18\n);
+ cx_write(MO_GP0_IO, 0x1222);
+ break;
+ case SEC_VOLTAGE_OFF:
+ dprintk(1, LNB Voltage OFF\n);
+ cx_write(MO_GP0_IO, 0x1230);
+ break;
}
if (core-prev_set_voltage)
@@ -1210,6 +1241,19 @@
}
break;
}
+ case CX88_BOARD_TWINHAN_VP1027_DVBS:
+ dev-ts_gen_cntrl = 0x00;
+ fe0-dvb.frontend = dvb_attach(mb86a16_attach,
+ twinhan_vp1027,
+ core-i2c_adap);
+ if (fe0-dvb.frontend) {
+ core-prev_set_voltage =
+ fe0-dvb.frontend-ops.set_voltage;
+ fe0-dvb.frontend-ops.set_voltage =
+ vp1027_set_voltage;
+ }
+ break;
+
default:
printk(KERN_ERR %s/2: The frontend of your DVB/ATSC
card isn't supported yet\n,
core-name);
diff -r d6520e486ee6 linux/drivers/media/video/cx88/cx88.h
--- a/linux/drivers/media/video/cx88/cx88.h Sat Jan 30
pac7302 sporadic plug-in problem fix for 2.6.33?
Dear Jean-Francois and Mauro, I just compiled the vanilla 2.6.33-rc6 kernel and tested together with Labtec Webcam 2200. I realized that this version still has the plug-in problem which was fixed at http://linuxtv.org/hg/~jfrancois/gspca/rev/ea88b3abee04 What do you think, is it possible that this simple but important patch will be pulled to final 2.6.33? If I understand correctly this kind of bugfixes are normally accepted in the current development phase. Regards, 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: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Mauro, Hermann,
On Sat, 30 Jan 2010 01:47:41 +0100, hermann pitton wrote:
Am Freitag, den 29.01.2010, 13:40 -0200 schrieb Mauro Carvalho Chehab:
Jean Delvare wrote:
From: Jean Delvare kh...@linux-fr.org
Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131
Analog (card=146). However, by the time we find out, some
card-specific initialization is missed. In particular, the fact that
the IR is GPIO-based. Set it when we change the card type.
We also have to move the initialization of IR until after the card
number has been changed. I hope that this won't cause any problem.
Hi Jean,
Moving the initialization will likely cause regressions. The reason why
there
are two init codes there were due to the way the old i2c code used to work.
This got fixed after the i2c rework, but it caused regressions on that time.
I don't think there is any problem with having two init sequences. You
need the EEPROM to identify some devices, you need I2C support to
access the EEPROM, and you need some initialization to get I2C
operational.
This doesn't mean that some adjustments to the exact sequence aren't
possible. In particular, I don't see what else can depend on IR being
initialized, so I can't really see what harm can be done in moving IR
init code _later_ in the sequence. Looking at saa7134_input_init1(), I
see that it is essentially setting up software parameters in the
saa7134_dev structure, there is almost no hardware access. Only for a
few cards, we change a couple bits in registers GPIO_GPMODE* and
GPIO_GPSTATUS*. I honestly can't see how doing this _later_ in the init
sequence could be a problem.
The proper way would be to just muve the IR initialization on this board
from init1 to init2, instead of changing it for all other devices.
Hmm, OK. I think it's wrong, but I'm not the one to decide. Patch below.
Mauro, I do agree with you that it is likely better to go a way with
minimum chances for regressions, also given the current testing base and
that only this single card is involved..
I admit I am very surprised that we apparently can't get anyone to test
changes to a driver that supports 176 different models of TV cards :(
Do we end up with something card specific in core code here?
After all, we know this is a no go.
Hartmut and me thought back and forth on how to deal with it for quite
some while, unfortunately Hartmut is not present currently on the list,
but he voted for to have a separate entry for that card finally too.
What we seem to have now is:
1. We don't know, if Jean's patch really would cause regressions,
but it is likely hard to get all the testing done. No problems with a
FlyVideo3000 gpio remote at the time Roman suggested it, but I had
not any i2c remote that time ...
I doubt it matters, given that saa7134_input_init1() only cares about
GPIO-based IR:
int saa7134_input_init1(struct saa7134_dev *dev)
{
(...)
if (dev-has_remote != SAA7134_REMOTE_GPIO)
return -ENODEV;
So the moving the call to this function should have no effect on boards
with I2C-based IR.
(...)
Given what is also in the cruft for bttv, I would not care too much for
that single card on that now also ancient driver, just print what the
user can do to escape and any google would find it quickly too. For Asus
it is a unique problem on that driver so far.
This isn't how we're going to make Linux popular.
I should have some time on Sunday afternoon for testing, if we should go
that way.
Any testing you can provide is very welcome, thanks.
* * * * *
From: Jean Delvare kh...@linux-fr.org
Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131
Analog (card=146). However, by the time we find out, some
card-specific initialization is missed. In particular, the fact that
the IR is GPIO-based. Set it when we change the card type, and run
saa7134_input_init1().
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Daro ghost-ri...@aster.pl
Cc: Roman Kellner muzu...@gmx.net
---
linux/drivers/media/video/saa7134/saa7134-cards.c |5 +
1 file changed, 5 insertions(+)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c
2010-01-30 10:56:50.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-30
11:52:18.0 +0100
@@ -7299,6 +7299,11 @@ int saa7134_board_init2(struct saa7134_d
printk(KERN_INFO %s: P7131 analog only, using
entry of %s\n,
dev-name, saa7134_boards[dev-board].name);
+
+ /* IR init has already happened for other cards, so
+* we have to catch up. */
+ dev-has_remote = SAA7134_REMOTE_GPIO;
+
Re: [PATCH] cx25840: Fix composite detection.
On Sun, 2010-01-10 at 09:31 +0900, Kusanagi Kouichi wrote: If CX25840_VIN1_CH1 and the like is used, input is not detected as composite. Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp This patch is fine for fixing the identified problem. Thanks. Reviewed-by: Andy Walls awa...@radix.net Acked-by: Andy Walls awa...@radix.net Note: I have not reviewed the correctness of the previous patch that added component video input. Not to say that it is right or wrong, just that I have not reviewed it. I really need to streamline this set_input() function in cx25840-core.c module to be more like this version of set_input() the cx18-av-core.c file: http://linuxtv.org/hg/~awalls/cx18-pvr2100-component/file/9d3394f49a90/linux/drivers/media/video/cx18/cx18-av-core.c#l570 because the logic in the former is really getting convoluted, making bugs hard to spot. Regards, Andy --- drivers/media/video/cx25840/cx25840-core.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/cx25840/cx25840-core.c b/drivers/media/video/cx25840/cx25840-core.c index 385ecd5..764c811 100644 --- a/drivers/media/video/cx25840/cx25840-core.c +++ b/drivers/media/video/cx25840/cx25840-core.c @@ -734,10 +734,8 @@ static int set_input(struct i2c_client *client, enum cx25840_video_input vid_inp v4l_dbg(1, cx25840_debug, client, vid_input 0x%x\n, vid_input); reg = vid_input 0xff; - if ((vid_input CX25840_SVIDEO_ON) == CX25840_SVIDEO_ON) - is_composite = 0; - else if ((vid_input CX25840_COMPONENT_ON) == 0) - is_composite = 1; + is_composite = !is_component + ((vid_input CX25840_SVIDEO_ON) != CX25840_SVIDEO_ON); v4l_dbg(1, cx25840_debug, client, mux cfg 0x%x comp=%d\n, reg, is_composite); -- 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: fix regression in pwc_set_shutter_speed???
Greg KH wrote: Video developers, any comments? Jef, were you able to narrow it down to the actual patch that caused the problem. Indeed it was my commit 6b35ca0d3d586b8ecb8396821af21186e20afaf0 I somehow missed the email from Laurent back in August about this. Am checking the rest of that commit now and will send a fix patch soon. Sorry about that. Martin -- 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 0/2] cx18: component video input support
The following two patches add component video input support to the cx18 driver for the only two CX24318 cards known to have component video inputs: the Leadtek PVR2100 and DVR3100 H. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] cx18: Add support for component video inputs
cx18: Add support for component video inputs
From: Andy Walls awa...@radix.net
Priority: normal
Signed-off-by: Andy Walls awa...@radix.net
diff -r ad62ab7e4325 -r 9d3394f49a90
linux/drivers/media/video/cx18/cx18-av-core.c
--- a/linux/drivers/media/video/cx18/cx18-av-core.c Sun Jan 03 21:28:18
2010 -0500
+++ b/linux/drivers/media/video/cx18/cx18-av-core.c Fri Jan 08 23:01:47
2010 -0500
@@ -579,6 +579,7 @@
u8 afe_mux_cfg;
u8 adc2_cfg;
+ u8 input_mode;
u32 afe_cfg;
int i;
@@ -589,6 +590,30 @@
vid_input = CX18_AV_COMPOSITE8) {
afe_mux_cfg = 0xf0 + (vid_input - CX18_AV_COMPOSITE1);
ch[0] = CVBS;
+ input_mode = 0x0;
+ } else if (vid_input = CX18_AV_COMPONENT_LUMA1) {
+ int luma = vid_input 0xf000;
+ int r_chroma = vid_input 0xf;
+ int b_chroma = vid_input 0xf0;
+
+ if ((vid_input ~0xfff000) ||
+ luma CX18_AV_COMPONENT_LUMA1 ||
+ luma CX18_AV_COMPONENT_LUMA8 ||
+ r_chroma CX18_AV_COMPONENT_R_CHROMA4 ||
+ r_chroma CX18_AV_COMPONENT_R_CHROMA6 ||
+ b_chroma CX18_AV_COMPONENT_B_CHROMA7 ||
+ b_chroma CX18_AV_COMPONENT_B_CHROMA8) {
+ CX18_ERR_DEV(sd, 0x%06x is not a valid video input!\n,
+vid_input);
+ return -EINVAL;
+ }
+ afe_mux_cfg = (luma - CX18_AV_COMPONENT_LUMA1) 12;
+ ch[0] = Y;
+ afe_mux_cfg |= (r_chroma - CX18_AV_COMPONENT_R_CHROMA4) 12;
+ ch[1] = Pr;
+ afe_mux_cfg |= (b_chroma - CX18_AV_COMPONENT_B_CHROMA7) 14;
+ ch[2] = Pb;
+ input_mode = 0x6;
} else {
int luma = vid_input 0xf0;
int chroma = vid_input 0xf00;
@@ -598,7 +623,7 @@
luma CX18_AV_SVIDEO_LUMA8 ||
chroma CX18_AV_SVIDEO_CHROMA4 ||
chroma CX18_AV_SVIDEO_CHROMA8) {
- CX18_ERR_DEV(sd, 0x%04x is not a valid video input!\n,
+ CX18_ERR_DEV(sd, 0x%06x is not a valid video input!\n,
vid_input);
return -EINVAL;
}
@@ -613,8 +638,8 @@
afe_mux_cfg |= (chroma - CX18_AV_SVIDEO_CHROMA4) 4;
ch[1] = C;
}
+ input_mode = 0x2;
}
- /* TODO: LeadTek WinFast DVR3100 H WinFast PVR2100 can do Y/Pb/Pr */
switch (aud_input) {
case CX18_AV_AUDIO_SERIAL1:
@@ -650,8 +675,8 @@
/* Set up analog front end multiplexers */
cx18_av_write_expect(cx, 0x103, afe_mux_cfg, afe_mux_cfg, 0xf7);
- /* Set INPUT_MODE to Composite (0) or S-Video (1) */
- cx18_av_and_or(cx, 0x401, ~0x6, ch[0] == CVBS ? 0 : 0x02);
+ /* Set INPUT_MODE to Composite, S-Video, or Component */
+ cx18_av_and_or(cx, 0x401, ~0x6, input_mode);
/* Set CH_SEL_ADC2 to 1 if input comes from CH3 */
adc2_cfg = cx18_av_read(cx, 0x102);
diff -r ad62ab7e4325 -r 9d3394f49a90
linux/drivers/media/video/cx18/cx18-av-core.h
--- a/linux/drivers/media/video/cx18/cx18-av-core.h Sun Jan 03 21:28:18
2010 -0500
+++ b/linux/drivers/media/video/cx18/cx18-av-core.h Fri Jan 08 23:01:47
2010 -0500
@@ -61,6 +61,25 @@
CX18_AV_SVIDEO2 = 0x620,
CX18_AV_SVIDEO3 = 0x730,
CX18_AV_SVIDEO4 = 0x840,
+
+ /* Component Video inputs consist of one luma input (In1-In8) ORed
+ with a red chroma (In4-In6) and blue chroma input (In7-In8) */
+ CX18_AV_COMPONENT_LUMA1 = 0x1000,
+ CX18_AV_COMPONENT_LUMA2 = 0x2000,
+ CX18_AV_COMPONENT_LUMA3 = 0x3000,
+ CX18_AV_COMPONENT_LUMA4 = 0x4000,
+ CX18_AV_COMPONENT_LUMA5 = 0x5000,
+ CX18_AV_COMPONENT_LUMA6 = 0x6000,
+ CX18_AV_COMPONENT_LUMA7 = 0x7000,
+ CX18_AV_COMPONENT_LUMA8 = 0x8000,
+ CX18_AV_COMPONENT_R_CHROMA4 = 0x4,
+ CX18_AV_COMPONENT_R_CHROMA5 = 0x5,
+ CX18_AV_COMPONENT_R_CHROMA6 = 0x6,
+ CX18_AV_COMPONENT_B_CHROMA7 = 0x70,
+ CX18_AV_COMPONENT_B_CHROMA8 = 0x80,
+
+ /* Component Video aliases for common combinations */
+ CX18_AV_COMPONENT1 = 0x861000,
};
enum cx18_av_audio_input {
diff -r ad62ab7e4325 -r 9d3394f49a90 linux/drivers/media/video/cx18/cx18-cards.c
--- a/linux/drivers/media/video/cx18/cx18-cards.c Sun Jan 03 21:28:18
2010 -0500
+++ b/linux/drivers/media/video/cx18/cx18-cards.c Fri Jan 08 23:01:47
2010 -0500
@@ -491,7 +491,7 @@
S-Video 2,
Composite 1,
Composite 2,
- Composite 3
+ Component 1
};
memset(input, 0, sizeof(*input));
diff -r ad62ab7e4325 -r 9d3394f49a90
[PATCH 2/2] cx18: Add a component video input to the PVR2100 and DVR3200H card entries
cx18: Add a component video input to the PVR2100 and DVR3200H card entries
From: Andy Walls awa...@radix.net
This is a guess at the proper configuration for component video on the Leadtek
PVR2100 and DVR3100 H.
Priority: normal
Signed-off-by: Andy Walls awa...@radix.net
diff -r 9d3394f49a90 -r 477109669a0c linux/drivers/media/video/cx18/cx18-cards.c
--- a/linux/drivers/media/video/cx18/cx18-cards.c Fri Jan 08 23:01:47
2010 -0500
+++ b/linux/drivers/media/video/cx18/cx18-cards.c Fri Jan 08 23:09:45
2010 -0500
@@ -381,6 +381,7 @@
{ CX18_CARD_INPUT_SVIDEO1,1,
CX18_AV_SVIDEO_LUMA3 | CX18_AV_SVIDEO_CHROMA4 },
{ CX18_CARD_INPUT_COMPOSITE1, 1, CX18_AV_COMPOSITE7 },
+ { CX18_CARD_INPUT_COMPONENT1, 1, CX18_AV_COMPONENT1 },
},
.audio_inputs = {
{ CX18_CARD_INPUT_AUD_TUNER, CX18_AV_AUDIO5,0 },
@@ -433,6 +434,7 @@
{ CX18_CARD_INPUT_SVIDEO1,1,
CX18_AV_SVIDEO_LUMA3 | CX18_AV_SVIDEO_CHROMA4 },
{ CX18_CARD_INPUT_COMPOSITE1, 1, CX18_AV_COMPOSITE7 },
+ { CX18_CARD_INPUT_COMPONENT1, 1, CX18_AV_COMPONENT1 },
},
.audio_inputs = {
{ CX18_CARD_INPUT_AUD_TUNER, CX18_AV_AUDIO5,0 },
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant = sizeof conversion.
Regression was caused by my commit 6b35ca0d3d586b8ecb8396821af21186e20afaf0
which determined message size using sizeof rather than hardcoded constants.
Unfortunately pwc_set_shutter_speed reuses a 2 byte buffer for a one byte
message too so the sizeof was bogus in this case.
All other uses of sizeof checked and are ok.
Signed-off-by: Martin Fuzzey mfuz...@gmail.com
---
drivers/media/video/pwc/pwc-ctrl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/pwc/pwc-ctrl.c
b/drivers/media/video/pwc/pwc-ctrl.c
index 50b415e..f7f7e04 100644
--- a/drivers/media/video/pwc/pwc-ctrl.c
+++ b/drivers/media/video/pwc/pwc-ctrl.c
@@ -753,7 +753,7 @@ int pwc_set_shutter_speed(struct pwc_device *pdev, int
mode, int value)
buf[0] = 0xff; /* fixed */
ret = send_control_msg(pdev,
- SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, sizeof(buf));
+ SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, 1);
if (!mode ret = 0) {
if (value 0)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] em28xx: add Dikom DK300 hybrid USB tuner
This patch add the Dikom DK300 hybrid usb card.
The patch adds digital and analogue tv support.
Not tested: remote controller
To be done: it seems that with the proposed patch the digital
demodulator remains activated if the tuner is switched from digital to
analogue mode.
Workaorund is to unplug and replug the device when switching from
digital to analogue.
If someone can explain how to verify the gpio settings using the
usbsnoop, the above issue perhaps can be resolved.
I attach the usbsnoop obtained some month ago using windows xp.
Signed-off-by: Andrea Amorosi andrea.amoros...@gmail.com
diff -r d6520e486ee6 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Jan 30
01:27:34 2010 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sat Jan 30
18:04:13 2010 +0100
@@ -245,6 +245,12 @@
{ -1, -1, -1, -1},
};
+static struct em28xx_reg_seq dikom_dk300_digital[] = {
+ {EM28XX_R08_GPIO, 0x6e, ~EM_GPIO_4, 10},
+ {EM2880_R04_GPO,0x08, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
/*
* Board definitions
@@ -1673,6 +1679,22 @@
.tuner_gpio= reddo_dvb_c_usb_box,
.has_dvb = 1,
},
+ [EM2882_BOARD_DIKOM_DK300] = {
+ .name = Dikom DK300,
+ .valid= EM28XX_BOARD_NOT_VALIDATED,
+ .tuner_type = TUNER_XC2028,
+ .tuner_gpio = default_tuner_gpio,
+ .decoder = EM28XX_TVP5150,
+ .mts_firmware = 1,
+ .has_dvb = 1,
+ .dvb_gpio = dikom_dk300_digital,
+ .input= { {
+ .type = EM28XX_VMUX_TELEVISION,
+ .vmux = TVP5150_COMPOSITE0,
+ .amux = EM28XX_AMUX_VIDEO,
+ .gpio = default_analog,
+ } },
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -1812,6 +1834,7 @@
{0xcee44a99, EM2882_BOARD_EVGA_INDTUBE, TUNER_XC2028},
{0xb8846b20, EM2881_BOARD_PINNACLE_HYBRID_PRO, TUNER_XC2028},
{0x63f653bd, EM2870_BOARD_REDDO_DVB_C_USB_BOX, TUNER_ABSENT},
+ {0x4e913442, EM2882_BOARD_DIKOM_DK300, TUNER_XC2028},
};
/* I2C devicelist hash table for devices with generic USB IDs */
@@ -2168,6 +2191,7 @@
ctl-demod = XC3028_FE_DEFAULT;
break;
case EM2883_BOARD_KWORLD_HYBRID_330U:
+ case EM2882_BOARD_DIKOM_DK300:
ctl-demod = XC3028_FE_CHINA;
ctl-fname = XC2028_DEFAULT_FIRMWARE;
break;
@@ -2480,6 +2504,31 @@
em28xx_gpio_set(dev, dev-board.tuner_gpio);
em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
break;
+
+/*
+* The Dikom DK300 is detected as an Kworld VS-DVB-T 323UR.
+*
+* This occurs because they share identical USB vendor and
+* product IDs.
+*
+* What we do here is look up the EEPROM hash of the Dikom
+* and if it is found then we decide that we do not have
+* a Kworld and reset the device to the Dikom instead.
+*
+* This solution is only valid if they do not share eeprom
+* hash identities which has not been determined as yet.
+*/
+ case EM2882_BOARD_KWORLD_VS_DVBT:
+ if (!em28xx_hint_board(dev))
+ em28xx_set_model(dev);
+
+ /* In cases where we had to use a board hint, the call to
+ em28xx_set_mode() in em28xx_pre_card_setup() was a no-op,
+ so make the call now so the analog GPIOs are set properly
+ before probing the i2c bus. */
+ em28xx_gpio_set(dev, dev-board.tuner_gpio);
+ em28xx_set_mode(dev, EM28XX_ANALOG_MODE);
+ break;
}
#if defined(CONFIG_MODULES) defined(MODULE)
diff -r d6520e486ee6 linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Jan 30 01:27:34
2010 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Sat Jan 30 18:04:13
2010 +0100
@@ -504,6 +504,7 @@
break;
case EM2880_BOARD_TERRATEC_HYBRID_XS:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+ case EM2882_BOARD_DIKOM_DK300:
dvb-frontend = dvb_attach(zl10353_attach,
em28xx_zl10353_xc3028_no_i2c_gate,
dev-i2c_adap);
diff -r d6520e486ee6 linux/drivers/media/video/em28xx/em28xx.h
--- a/linux/drivers/media/video/em28xx/em28xx.h Sat Jan 30 01:27:34 2010
-0200
+++ b/linux/drivers/media/video/em28xx/em28xx.h Sat Jan 30 18:04:13 2010
+0100
WinTV Nova-S-USB2
Hi All, Is anyone working on the WinTV Nova-S USB2 gizmo? I would like to get this device to work but need some pointers on where to start. I have it functioning on a VMWare session on Linux (but thats really not the solution :-P) What I can tell from other Wiki pages is that it is a Trident TVMaster TM6000 based device with a Conexant_CX24109 Tuner. Any pointers, Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Douglas, I believe it is you to whom the pull requests must be addressed. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 5 changesets: 01/05: gspca - main: Add input support for interrupt endpoints. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=f77ba6670e1b 02/05: gspca - pac7302: Add support for camera button. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=24ab9e77691d 03/05: gspca - pac7302: Change latin1 text to utf-8. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=bc1c509467f7 04/05: gspca - t613: Support for LT168G sensor. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5ef754bf809f 05/05: gspca - main: Change version to 2.9.0. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=dfa82cf98a85 gspca.c | 209 +- gspca.h | 13 +++ pac7302.c | 39 +++ t613.c| 49 ++ 4 files changed, 307 insertions(+), 3 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: 01/05: cx18: Rename snd_cx18_mixer_lock to snd_cx18_lock and increase visibility http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=5d28c157d0ef 02/05: cx18: Add missing serialization locking to cx18-alsa http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=da3e7202f89e 03/05: cx18: Fix memory leak in cx18-alsa starting of PCM captures http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=600fd701323f 04/05: cx18: Increment driver version for the addition of cx18-alsa and fixes http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=e4fa9f845cbc 05/05: cx18: Add missing serialization locks to cx18-dvb http://linuxtv.org/hg/~awalls/v4l-dvb-bug?cmd=changeset;node=c00c5d613577 These changes fix previously discussed ALSA open race that can put the cx18 driver in a bad state, a DVB operation locking problem, and a memory leak in starting ALSA captures. cx18-alsa-mixer.c | 24 cx18-alsa-pcm.c | 28 ++-- cx18-alsa.h | 16 cx18-dvb.c|4 cx18-version.h|2 +- 5 files changed, 39 insertions(+), 35 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jan 30 19:00:06 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14075:d6520e486ee6 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PAC7302 short datasheet from PixArt
On Sat, 30 Jan 2010, Németh Márton wrote: Hi, if anyone interested there is a brief overview datasheet about PixArt PAC7301/PAC7302 at http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf Márton, First, I am glad that mouse-copying reproduces the accent in your name. If you can help explain how to reproduce such things by typing while using apine over an ssh connection, using a standard US keyboard, I would be glad of the explanation. My wife is Hungarian, and I am thus very sensitized to the importance of the question, how to do the accents required for writing Hungarian properly. Now, as to the substance of the mail above, thanks a lot. I had a bunch of the PixArt datasheets already, but I had missed that one. I would have a question, though: This datasheet gives a lot of information about pinouts on the sensor chip and such good stuff which might be useful if one were constructing a circuit board on which to put the chip. What it does not give, very unfortunately, is any information about the command set which needs to be sent across the USB connection, which in turn actuates the circuits which in turn sends something to the sensor across one of those pins. For example, to set green gain one has to do something on connector X. But how does one send a command from the computer which does something on connector X? Some other datasheets from some other companies (Omnivision, for example) do seem occasionally to provide such information. Thus, a question for you or for anyone else who reads it: Has anyone figured out any shortcuts for matching up the missing pieces of information? Probably the answer is no but I think this is the kind of question which is worth asking again on some periodic basis. Theodore Kilgore
Re: [PATCH] ov534: fix end of frame handling, make the camera work again.
Antonio Ospite wrote:
Fix a regression, probably introduced in the driver split, which made
the ov534 driver unusable: every last packet was discarded because we
were mis-calculating the frame size before actually adding the packet.
Hi Antonio,
Index: gspca/linux/drivers/media/video/gspca/ov534.c
===
--- gspca.orig/linux/drivers/media/video/gspca/ov534.c
+++ gspca/linux/drivers/media/video/gspca/ov534.c
@@ -992,9 +992,9 @@
frame = gspca_get_i_frame(gspca_dev);
if (frame == NULL)
goto discard;
- if (frame-data_end - frame-data !=
+ if (frame-data_end - frame-data + (len - 12) !=
gspca_dev-width * gspca_dev-height * 2) {
- PDEBUG(D_PACK, short frame);
+ PDEBUG(D_PACK, wrong sized frame);
goto discard;
}
gspca_frame_add(gspca_dev, LAST_PACKET,
This change looks correct to me. Thanks.
Acked-by: Jim Paris j...@jtan.com
-jim
--
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
