[PATCH] s2255drv: fixes for big endian arch
# HG changeset patch
# User Dean Anderson
# Date 1267746208 28800
# Node ID ff343fa70b4def92d35f9ef7ee56a953b012d169
# Parent c9c1bcda21557cea425589f281b6b3100e2c15a0
s2255drv: fixes for big endian arch
From: Dean Anderson
s2255drv fixes for big endian architecture
Priority: normal
Signed-off-by: Dean Anderson
diff -r c9c1bcda2155 -r ff343fa70b4d linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Wed Mar 03 14:28:53 2010 -0800
+++ b/linux/drivers/media/video/s2255drv.c Thu Mar 04 15:43:28 2010 -0800
@@ -78,11 +78,11 @@
#define S2255_SETMODE_TIMEOUT 500
#define S2255_VIDSTATUS_TIMEOUT 350
#define MAX_CHANNELS 4
-#define S2255_MARKER_FRAME 0x2255DA4AL
-#define S2255_MARKER_RESPONSE 0x2255ACACL
-#define S2255_RESPONSE_SETMODE 0x01
-#define S2255_RESPONSE_FW 0x10
-#define S2255_RESPONSE_STATUS 0x20
+#define S2255_MARKER_FRAME cpu_to_le32(0x2255DA4AL)
+#define S2255_MARKER_RESPONSE cpu_to_le32(0x2255ACACL)
+#define S2255_RESPONSE_SETMODE cpu_to_le32(0x01)
+#define S2255_RESPONSE_FW cpu_to_le32(0x10)
+#define S2255_RESPONSE_STATUS cpu_to_le32(0x20)
#define S2255_USB_XFER_SIZE(16 * 1024)
#define MAX_CHANNELS 4
#define MAX_PIPE_BUFFERS 1
@@ -141,12 +141,12 @@
#define DEF_HUE0
/* usb config commands */
-#define IN_DATA_TOKEN 0x2255c0de
-#define CMD_2255 0xc2255000
-#define CMD_SET_MODE (CMD_2255 | 0x10)
-#define CMD_START (CMD_2255 | 0x20)
-#define CMD_STOP (CMD_2255 | 0x30)
-#define CMD_STATUS (CMD_2255 | 0x40)
+#define IN_DATA_TOKEN cpu_to_le32(0x2255c0de)
+#define CMD_2255 cpu_to_le32(0xc2255000)
+#define CMD_SET_MODE cpu_to_le32((CMD_2255 | 0x10))
+#define CMD_START cpu_to_le32((CMD_2255 | 0x20))
+#define CMD_STOP cpu_to_le32((CMD_2255 | 0x30))
+#define CMD_STATUS cpu_to_le32((CMD_2255 | 0x40))
struct s2255_mode {
u32 format; /* input video format (NTSC, PAL) */
@@ -310,7 +310,7 @@
/* Need DSP version 5+ for video status feature */
#define S2255_MIN_DSP_STATUS5
#define S2255_MAJOR_VERSION1
-#define S2255_MINOR_VERSION15
+#define S2255_MINOR_VERSION16
#define S2255_RELEASE 0
#define S2255_VERSION KERNEL_VERSION(S2255_MAJOR_VERSION, \
S2255_MINOR_VERSION, \
@@ -1219,9 +1219,8 @@
struct s2255_mode *mode)
{
int res;
- u32 *buffer;
+ __le32 *buffer;
unsigned long chn_rev;
-
mutex_lock(&dev->lock);
chn_rev = G_chnmap[chn];
dprintk(3, "mode scale [%ld] %p %d\n", chn, mode, mode->scale);
@@ -1247,7 +1246,7 @@
/* set the mode */
buffer[0] = IN_DATA_TOKEN;
- buffer[1] = (u32) chn_rev;
+ buffer[1] = (__le32) cpu_to_le32(chn_rev);
buffer[2] = CMD_SET_MODE;
memcpy(&buffer[3], &dev->mode[chn], sizeof(struct s2255_mode));
dev->setmode_ready[chn] = 0;
@@ -1278,7 +1277,7 @@
u32 *pstatus)
{
int res;
- u32 *buffer;
+ __le32 *buffer;
u32 chn_rev;
mutex_lock(&dev->lock);
chn_rev = G_chnmap[chn];
@@ -1291,7 +1290,7 @@
}
/* form the get vid status command */
buffer[0] = IN_DATA_TOKEN;
- buffer[1] = chn_rev;
+ buffer[1] = (__le32) cpu_to_le32(chn_rev);
buffer[2] = CMD_STATUS;
*pstatus = 0;
dev->vidstatus_ready[chn] = 0;
@@ -1971,14 +1970,14 @@
if (frm->ulState == S2255_READ_IDLE) {
int jj;
unsigned int cc;
- s32 *pdword;
+ __le32 *pdword; /*data from dsp is little endian */
int payload;
/* search for marker codes */
pdata = (unsigned char *)pipe_info->transfer_buffer;
+ pdword = (__le32 *)pdata;
for (jj = 0; jj < (pipe_info->cur_transfer_size - 12); jj++) {
- switch (*(s32 *) pdata) {
+ switch (*pdword) {
case S2255_MARKER_FRAME:
- pdword = (s32 *)pdata;
dprintk(4, "found frame marker at offset:"
" %d [%x %x]\n", jj, pdata[0],
pdata[1]);
@@ -2002,7 +2001,6 @@
dev->jpg_size[dev->cc] = pdword[4];
break;
case S2255_MARKER_RESPONSE:
- pdword = (s32 *)pdata;
pdata += DEF_USB_BLOCK;
jj += DEF_USB_BLOCK;
if (pdword[1] >= MAX_CHANNELS)
@@ -2437,9 +2435,9 @@
}
/* send the start command */
- *(u32 *) buffer = IN_DATA_TOKEN;
- *((u32 *) buffer + 1) = (u32) chn_rev;
- *((u32 *) buffer + 2) = (u32) CMD_START;
+
[PATCH] em28xx: Support for Kworld VS-DVB-T 323UR
em28xx: Support for Kworld VS-DVB-T 323UR
From: Antonio Larrosa
This patch adapts the changes submitted by Dainius Ridzevicius to the
linux-media mailing list on 8/14/09, to the current sources in order
to make the Kworld VS-DVB-T 323UR usb device work.
I also removed the "not validated" flag since I own the device and validated
that it works fine after the patch is applied.
Thanks to Devin Heitmueller for his guidance with the code.
Priority: normal
Signed-off-by: Antonio Larrosa
diff -r 41c5482f2dac linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Mar 04 02:49:46
2010 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Fri Mar 05 01:41:46
2010 +0100
@@ -1456,10 +1456,14 @@
},
[EM2882_BOARD_KWORLD_VS_DVBT] = {
.name = "Kworld VS-DVB-T 323UR",
- .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 = kworld_330u_digital,
+ .xclk = EM28XX_XCLK_FREQUENCY_12MHZ, /* NEC IR */
+ .ir_codes = &ir_codes_kworld_315u_table,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
@@ -2198,6 +2202,7 @@
break;
case EM2883_BOARD_KWORLD_HYBRID_330U:
case EM2882_BOARD_DIKOM_DK300:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
ctl->demod = XC3028_FE_CHINA;
ctl->fname = XC2028_DEFAULT_FIRMWARE;
break;
diff -r 41c5482f2dac linux/drivers/media/video/em28xx/em28xx-dvb.c
--- a/linux/drivers/media/video/em28xx/em28xx-dvb.c Thu Mar 04 02:49:46
2010 -0300
+++ b/linux/drivers/media/video/em28xx/em28xx-dvb.c Fri Mar 05 01:41:46
2010 +0100
@@ -506,6 +506,7 @@
case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
case EM2881_BOARD_PINNACLE_HYBRID_PRO:
case EM2882_BOARD_DIKOM_DK300:
+ case EM2882_BOARD_KWORLD_VS_DVBT:
dvb->frontend = dvb_attach(zl10353_attach,
&em28xx_zl10353_xc3028_no_i2c_gate,
&dev->i2c_adap);
--
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
"Invalid module format"
Hi, I just upgraded to the stock 2.6.33 kernel in Slackware-current. Also after having the troubles described below I cloned a completely new copy of the gspca tree from http://linuxtv.org/hg/~hgoede/gspca, intending to get some work done on a project recently started. I did make menuconfig (preceded on the first occasion by make distclean, of course) and chose my options. Then I did make and make install. When I plugged in a camera, nothing. So I tried modprobe gspca_main and here is what happens r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# Any suggestions? Theodore Kilgore -- 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: DM1105: could not attach frontend 195d:1105
Hendrik Skarpeid skrev: Igor M. Liplianin skrev: On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote: Igor M. Liplianin wrote: Now to find GPIO's for LNB power control and ... watch TV :) Yep. No succesful tuning at the moment. There might also be an issue with the reset signal and writing to GPIOCTR, as the module at the moment loads succesfully only once. As far as I can make out, the LNB power control is probably GPIO 16 and 17, not sure which is which, and how they work. GPIO15 is wired to tuner #reset New patch to test No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2721 - Release Date: 03/03/10 20:34:00 modprobe si21xx debug=1 produces this output when scanning. [ 2187.998349] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2187.998353] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2187.999881] si21xx: si21xx_setacquire [ 2187.999884] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.022645] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x01 [ 2188.054350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.054355] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.055875] si21xx: si21xx_setacquire [ 2188.055879] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.110359] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.110366] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.111885] si21xx: si21xx_setacquire [ 2188.111889] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.166350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.166354] si21xx: si21xx_set_frontend : FE_SET_FRONTEND Since the tuner at hand uses a Si2109 chip, VSTATUS 0x01 and 0x02 would indicate that blind scanning is used. Blind scanning is a 2109/2110 specific function, and may not very usable since we always use initial tuning files anyway. 2109/10 also supports the legacy scanning method which is supported by Si2107708. Is the use of blind scanning intentional? Sorry, my bad. Mixed up the registers. Got a VSTATUS: 0x0b once. Mostly I'm getting 0x01 and 0x02. Sometimes 0x00 and 0x03 -- 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] Compro U80 Nearly there???
Please see if there is more information on the tuner in the logging with debugging switched on: sudo modprobe -r dvb-usb-rtl2831u sudo modprobe dvb-usb-rtl2831u debug=1 The ~jhoogenraad/rtl2831-r2 has two tuners hard-coded in the driver (no separation of back-end and front-end), and logs the interactions with those tuners in debug mode. I maintain the wiki with info on the driver: http://www.linuxtv.org/wiki/index.php/Rtl2831_devices Please also try the new driver (alas with no IR remote support) from ~anttip/rtl2831u peter wrote: I'm running Ubuntu Karmic, and have a Compro U80 Device USB ID 185b:0150. To get this close to working I have: 1) Added 50-udev.rules which seem to allow the device to be recognised. 2) Compiled the ~jhoogenraad/rtl2831-r2 version of the driver. This gets me to the point where: - /dev/dvb exists. - my applications recognise the device - In the log I see: [ 14.311735] dvb-usb: found a 'VideoMate U90' in warm state. [ 14.311743] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 14.312131] DVB: registering new adapter (VideoMate U90) [ 14.312420] DVB: registering adapter 0 frontend 0 (Realtek RTL2831 DVB-T)... [ 14.312521] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb1/1-1/input/input5 [ 14.312552] dvb-usb: schedule remote query interval to 300 msecs. [ 14.312558] dvb-usb: VideoMate U90 successfully initialized and connected. [ 14.312589] usbcore: registered new interface driver dvb_usb_rtd2831u So looking good so far. However, if i used scan, or an application like Kaffeine tuning fails. I know that the device works as I can get it to work on windows. So I have been looking at the RTL2831U data sheets which I know from the windows driver that this is based on. (I don't know much about this hardware I am trying to figure it out ). So this chip is just doing the demodulating and the USB interface. It must therefore be paired with tuner. It seems logical to me (but is possibly wrong ) that if the demodulator is working and I cant tune, then the issue is with the tuner part of the driver. The windows drivers refer to both the MT2060 and the QT1010, but I don't know which one is being used. (I have not had the guts to rip the thing apart yet). Docu in the code of for the driver implies that it can support the MT2060 but not the QT1010 so I guess with my luck it is the quantec one. Has any one got any advice as to where I should look next? Has anyone got this to work? It seems to be quite close. I any suggestions would be appreciated. Thanks Peter ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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: DM1105: could not attach frontend 195d:1105
Igor M. Liplianin skrev: On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote: Igor M. Liplianin wrote: Now to find GPIO's for LNB power control and ... watch TV :) Yep. No succesful tuning at the moment. There might also be an issue with the reset signal and writing to GPIOCTR, as the module at the moment loads succesfully only once. As far as I can make out, the LNB power control is probably GPIO 16 and 17, not sure which is which, and how they work. GPIO15 is wired to tuner #reset New patch to test No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2721 - Release Date: 03/03/10 20:34:00 modprobe si21xx debug=1 produces this output when scanning. [ 2187.998349] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2187.998353] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2187.999881] si21xx: si21xx_setacquire [ 2187.999884] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.022645] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x01 [ 2188.054350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.054355] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.055875] si21xx: si21xx_setacquire [ 2188.055879] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.110359] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.110366] si21xx: si21xx_set_frontend : FE_SET_FRONTEND [ 2188.111885] si21xx: si21xx_setacquire [ 2188.111889] si21xx: si21xx_set_symbolrate : srate = 2750 [ 2188.166350] si21xx: si21_read_status : FE_READ_STATUS : VSTATUS: 0x02 [ 2188.166354] si21xx: si21xx_set_frontend : FE_SET_FRONTEND Since the tuner at hand uses a Si2109 chip, VSTATUS 0x01 and 0x02 would indicate that blind scanning is used. Blind scanning is a 2109/2110 specific function, and may not very usable since we always use initial tuning files anyway. 2109/10 also supports the legacy scanning method which is supported by Si2107708. Is the use of blind scanning intentional? -- 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: DM1105: could not attach frontend 195d:1105
Igor M. Liplianin skrev:
On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote:
Igor M. Liplianin wrote:
Now to find GPIO's for LNB power control and ... watch TV :)
Yep. No succesful tuning at the moment. There might also be an issue
with the reset signal and writing to GPIOCTR, as the module at the
moment loads succesfully only once.
As far as I can make out, the LNB power control is probably GPIO 16 and
17, not sure which is which, and how they work.
GPIO15 is wired to tuner #reset
New patch to test
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2721 - Release Date: 03/03/10 20:34:00
A little tweaking produced the required voltages for the LNB:
switch (voltage) {
case SEC_VOLTAGE_18:
dm1105_gpio_set(dev, GPIO16 | GPIO17);
break;
case SEC_VOLTAGE_13:
dm1105_gpio_andor(dev, GPIO16 | GPIO17, GPIO17);
break;
default:
dm1105_gpio_clear(dev, GPIO16 | GPIO17);
break;
}
But unfortunately tuning is still failing. Could it be an issue with the
21xx driver? I will read up on the Si2109.
--
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: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On Thu, Mar 4, 2010 at 3:44 PM, Pedro Ribeiro wrote: > I think you are right. I was to quick to blame it. It occurs whether > or not the DVB adapter is connected. > > Once again, thanks. > > Pedro Ok, that's great to hear. I'm putting linux-media back into the CC in case anyone else finds this thread in the mailing list archives. 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 10/11] ov534: Add Powerline Frequency control
Max Thrun wrote: > On Thu, Mar 4, 2010 at 3:14 PM, Jim Paris wrote: > > > Antonio Ospite wrote: > > > On Wed, 3 Mar 2010 23:55:33 -0500 > > > Jim Paris wrote: > > > > > > > Antonio Ospite wrote: > > > [...] > > > > > > > > > > I see. It would be interesting to see how Powerline Frequency > > filtering > > > > > is done on PS3. I added Jim Paris on CC. > > > > > > > > Hi Antonio and Mosalam, > > > > > > > > I tried, but I can't capture that. My USB logger only does USB 1.1, > > > > which is too slow for the camera to run normally, but good enough to > > > > see the initialization sequence. However, the 50/60Hz option only > > > > appears later, once the PS3 is receiving good frame data. > > > > > > > > I can open up the camera and sniff the I2C bus instead. It'll take > > > > a little longer. > > > > > > > > > > Thanks for your time Jim. > > > > No problem, glad to help. > > Looks like Mosalam's patch is correct: > > > > --- i2c-60hz.log2010-03-04 15:09:23.0 -0500 > > +++ i2c-50hz.log2010-03-04 15:09:27.0 -0500 > > @@ -69,7 +69,7 @@ > > ov_write_verify 8C E8 > > ov_write_verify 8D 20 > > ov_write_verify 0C 90 > > -ov_write_verify 2B 00 > > +ov_write_verify 2B 9E > > ov_write_verify 22 7F > > ov_write_verify 23 03 > > ov_write_verify 11 01 > > > > I'll attach the full logs. > > > > -jim > > > > Jim, I'm really interested in how you went about sniffing the bus. Can you > share some details about what you use to do it? Sure. I borrowed one of these from a friend: http://www.totalphase.com/products/beagle_ism/ and tapped the GND, SCL, and SDA pins off the camera EEPROM. I exported a CSV from the Beagle software and used a quick Perl script to parse it into a more useful read/write/write_verify format. -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
Re: [PATCH 10/11] ov534: Add Powerline Frequency control
Antonio Ospite wrote: > On Wed, 3 Mar 2010 23:55:33 -0500 > Jim Paris wrote: > > > Antonio Ospite wrote: > [...] > > > > > > I see. It would be interesting to see how Powerline Frequency filtering > > > is done on PS3. I added Jim Paris on CC. > > > > Hi Antonio and Mosalam, > > > > I tried, but I can't capture that. My USB logger only does USB 1.1, > > which is too slow for the camera to run normally, but good enough to > > see the initialization sequence. However, the 50/60Hz option only > > appears later, once the PS3 is receiving good frame data. > > > > I can open up the camera and sniff the I2C bus instead. It'll take > > a little longer. > > > > Thanks for your time Jim. No problem, glad to help. Looks like Mosalam's patch is correct: --- i2c-60hz.log2010-03-04 15:09:23.0 -0500 +++ i2c-50hz.log2010-03-04 15:09:27.0 -0500 @@ -69,7 +69,7 @@ ov_write_verify 8C E8 ov_write_verify 8D 20 ov_write_verify 0C 90 -ov_write_verify 2B 00 +ov_write_verify 2B 9E ov_write_verify 22 7F ov_write_verify 23 03 ov_write_verify 11 01 I'll attach the full logs. -jim ov_write 12 80 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 3D 03 ov_write_verify 17 26 ov_write_verify 18 A0 ov_write_verify 19 07 ov_write_verify 1A F0 ov_write_verify 32 00 ov_write_verify 29 A0 ov_write_verify 2C F0 ov_write_verify 65 20 ov_write_verify 11 01 ov_write_verify 42 7F ov_write_verify 63 E0 ov_write_verify 64 FF ov_write_verify 66 00 ov_write_verify 13 F0 ov_write_verify 0D 41 ov_write_verify 0F C5 ov_write_verify 14 11 ov_write_verify 22 7F ov_write_verify 23 03 ov_write_verify 24 40 ov_write_verify 25 30 ov_write_verify 26 A1 ov_write_verify 2A 00 ov_write_verify 2B 00 ov_write_verify 6B AA ov_write_verify 13 FF ov_write_verify 90 05 ov_write_verify 91 01 ov_write_verify 92 03 ov_write_verify 93 00 ov_write_verify 94 60 ov_write_verify 95 3C ov_write_verify 96 24 ov_write_verify 97 1E ov_write_verify 98 62 ov_write_verify 99 80 ov_write_verify 9A 1E ov_write_verify 9B 08 ov_write_verify 9C 20 ov_write_verify 9E 81 ov_write_verify A6 04 ov_write_verify 7E 0C ov_write_verify 7F 16 ov_write_verify 80 2A ov_write_verify 81 4E ov_write_verify 82 61 ov_write_verify 83 6F ov_write_verify 84 7B ov_write_verify 85 86 ov_write_verify 86 8E ov_write_verify 87 97 ov_write_verify 88 A4 ov_write_verify 89 AF ov_write_verify 8A C5 ov_write_verify 8B D7 ov_write_verify 8C E8 ov_write_verify 8D 20 ov_write_verify 0C 90 ov_write_verify 2B 00 ov_write_verify 22 7F ov_write_verify 23 03 ov_write_verify 11 01 ov_read 0C 90 ov_write_verify 0C 90 ov_read 64 FF ov_write_verify 64 FF ov_read 0D 41 ov_write_verify 0D 41 ov_read 14 11 ov_write_verify 14 41 ov_read 0E 79 ov_write_verify 0E CD ov_read AC FF ov_write_verify AC BF ov_write_verify 8E 00 ov_read 0C 90 ov_write_verify 0C D0 ov_write 12 80 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 11 01 ov_write_verify 3D 03 ov_write_verify 17 26 ov_write_verify 18 A0 ov_write_verify 19 07 ov_write_verify 1A F0 ov_write_verify 32 00 ov_write_verify 29 A0 ov_write_verify 2C F0 ov_write_verify 65 20 ov_write_verify 11 01 ov_write_verify 42 7F ov_write_verify 63 E0 ov_write_verify 64 FF ov_write_verify 66 00 ov_write_verify 13 F0 ov_write_verify 0D 41 ov_write_verify 0F C5 ov_write_verify 14 11 ov_write_verify 22 7F ov_write_verify 23 03 ov_write_verify 24 40 ov_write_verify 25 30 ov_write_verify 26 A1 ov_write_verify 2A 00 ov_write_verify 2B 00 ov_write_verify 6B AA ov_write_verify 13 FF ov_write_verify 90 05 ov_write_verify 91 01 ov_write_verify 92 03 ov_write_verify 93 00 ov_write_verify 94 60 ov_write_verify 95 3C ov_write_verify 96 24 ov_write_verify 97 1E ov_write_verify 98 62 ov_write_verify 99 80 ov_write_verify 9A 1E ov_write_verify 9B 08 ov_write_verify 9C 20 ov_write_verify 9E 81 ov_write_verify A6 04 ov_write_verify 7E 0C ov_write_verify 7F 16 ov_write_verify 80 2A ov_write_verify 81 4E ov_write_verify 82 61 ov_write_verify 83 6F ov_write_verify 84 7B ov_write_verify 85 86 ov_write_verify 86 8E ov_write_verify 87 97 ov_write_verify 88 A4 ov_write_verify 89 AF ov_write_verify 8A C5 ov_write_verify 8B D7 ov_write_verify 8C E8 ov_write_verify 8D 20 ov_write_verify 0C 90 ov_write_verify 2B 9E ov_write_verify 22 7F ov_write_verify 23 03 ov_write_verify 11 01 ov_read 0C 90 ov_write_verify 0C 90 ov_read 64 FF ov_write_verify 64 FF ov_read 0D 41 ov_write_verify 0D 41 ov_read 14 11 ov_write_verify 14 41 ov_read 0E 79 ov_write_verify 0E CD ov_read AC FF ov_write_verify AC BF ov_write_verify 8E 00 ov_read 0C 90 ov_write_verify 0C D0
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
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:Thu Mar 4 19:00:19 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14391:41c5482f2dac gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-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: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK spec: OK sparse (linux-2.6.33): ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [PATCH] V4L/DVB: mx1-camera: compile fix
On Thu, Mar 04, 2010 at 08:26:23PM +0100, Uwe Kleine-König wrote: > Hi Guennadi, > > On Thu, Mar 04, 2010 at 06:13:38PM +0100, Guennadi Liakhovetski wrote: > > > +#undef DMA_BASE > > > +#define DMA_BASE MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) > > > > I don't like this. Why the "undef"? Is DMA_BASE already defined? where and > > what is it? If it is - we better use a different name, if not - just > > remove the undef, please. > yes, it's not pretty, but I wanted to make a minimal patch. > > arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h has: > > #define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR) This is only used in the mx1 camera driver, so you can just remove it from dma-mx1-mx2.h and use MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) in the camera driver. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On Thu, Mar 4, 2010 at 6:14 AM, Pedro Ribeiro wrote: > Devin, I noticed that your solution does not alter the remote query > interval from 50 msec. It works, but it is not as effective as my hard > hack because I still get interference every once in a while when the > DVB adapter is connected. > > I can't tell you exactly when and how it happens, because it seems > rather random - but it is much better than previously though. Well, the printk() line is a little misleading, since the code change results in *zero* polling. Basically the driver now registers a bulk URB handler, so whenever a message is delivered on the bulk pipe it is handled immediately. Hence, no polling at all. That said, I should probably find a way to get rid of that line from the dmesg output when the device is in that mode (the issue is that portion of the code is shared with drivers other than the dib0700). If you are still seeing issues, then it is unlikely to have anything to do with the dib0700 RC support. 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] V4L/DVB: mx1-camera: compile fix
Hi Guennadi, On Thu, Mar 04, 2010 at 06:13:38PM +0100, Guennadi Liakhovetski wrote: > > +#undef DMA_BASE > > +#define DMA_BASE MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) > > I don't like this. Why the "undef"? Is DMA_BASE already defined? where and > what is it? If it is - we better use a different name, if not - just > remove the undef, please. yes, it's not pretty, but I wanted to make a minimal patch. arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h has: #define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR) so that was used before. I don't really know the driver, just made it compile again. If you have a nice suggestion, I will happily implement it. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.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
dvb-fe-cx24116.fw firmware versions for Ubuntu releases
Hello all, Ubuntu has shipped corrupted dvb-fe-cx24116.fw firmware for a few releases now. I'm working on rectifying the situation. Working with Andre Newman on the mythtv-users mailing list, we have found the following firmware versions to work: (Note: 1.23.86.1 wasn't tested in any release, it may or may not work) Jaunty: up to 1.22.82 Karmic: up to 1.22.82 Lucid: up to 1.26.90 These are the firmware versions I am looking to package, but I only have one user's anecdotal evidence to back them up. I am interested in any feedback others may have in determining what versions of the firmware should be shipped in each release. Thanks, Chase Douglas -- 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: TBS 6980 Dual DVB-S2 PCIe card
On 3/4/10 1:03 PM, Per Lundberg wrote: Hi Hermann, On Thu, Mar 4, 2010 at 11:05 AM, hermann pitton wrote: Has anyone done any attempt at contacting TBS to see if they can release their changes under the GPLv2? Ideally, they would provide a patch themselves, but it should be fairly simple to diff the linux/ trees from their provided linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, it could be that their patch is so trivial that we could just include it in the stock Linux kernel without asking them for license clarifications... but obviously, if we can get a green sign from them, it would be even better. It is always the other way round. In the end they need a green sign from us. Well... I guess we are both right. :-) They need to assert ownership and license the code under the GPL, and we need to ensure that the quality of the code is high enough (driver is working and does not interfer with other parts of the code base...). We I asked TBS' support about this question they told me they would like to get it out under GPL as it has been done with other cards they sell but that right now it was not possible due to legal contraints related to some of the code in use by some of the chips on the board. No further details were provided. BTW, the TBS dual seems to be fine on m$, but there are some mysterious lockups without any trace, if used in conjunction with some prior S2/HDTV cards. I can't tell yet, if that it is evenly distributed over amd/ati and nvidia stuff or whatever on win7 ... , but people do spend lifetime in vain on it. This is pretty interesting, do you have any references? (forum links or similar) In my particular case, I was thinking about using it as the "only" S2 card in the machine, later possibly adding a DVB-C card if/when we get cable... so, it might not be a problem for me, but it still doesn't feel really good. I guess the card is pretty new, so maybe (hopefully) it will get fixed by a new firmware release. Do we have any readers of this list who own the card and use it in Linux (with the drivers from TBS)? Could you please share your experiences: is the picture quality good? Sound? Does the tuner work well? (e.g. can you receive all channels you normally receive...) Yes I use the card. Have had it for a couple of months now running in a server that acts as a video head-end in my test network. I only tune to specific transponders when I boot the server so I can't really comment on tuning time and related issues. Yes I've used it for S and S2 feeds and so far it fits my requirements. HTH, Thomas -- 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: Ubuntu and AverMedia DVD EZMaker USB Gold
Hello again, I was wrong here, the driver works, the device works great but what's going on is that it uses the tuner as the default input, when I run mplayer with input=1 (composite video) or input=2 (s-video) it works good: mplayer tv:// -tv input=1:device=/dev/video0 But this isn't good enough because cheese and camorama and flash use the default input. How can I set up default input to composite video or s-video? Should I add something to the options that the Avermedia kernel module uses? I would appreciate any help, Cheers Jorge Cabrera wrote: Hi everyone, I'm trying to make an "AverMedia DVD EZMaker USB Gold" work with Ubuntu (tried in a computer with 9.04 and other two with 9.10) with a Sony EVI D70P Camera. I installed the linux drivers from AverMedia and when I connect the device the system shows the following message when i run dmesg: [69302.964025] usb 2-1: new high speed USB device using ehci_hcd and address 6 [69303.637332] usb 2-1: configuration #1 chosen from 1 choice [69303.860132] C038 registered V4L2 device video0[video] [69303.860160] C038 registered V4L2 device vbi0[vbi] [69303.860440] C038 registered ALSA sound card 2 Problem is that when I connect the camera it doesn' work, tried with cheese, gstreamer-properties, camorama and always get the same error: libv4l2: error getting pixformat: Invalid argument I tried connecting the camera with s-video and composite video with the same result. Funny thing is that I get the same error without connecting the camera so I guess it's just a problem with the AverMedia device. Works well on Windows. I've been reading a lot on this but still have no clues. I'm going to try with the drivers at linuxtv.org but I wanted to ask has anyone got this type of device working under linux? I would really appreciate any help. Cheers, -- Jorge Cabrera Ándago Ingeniería - www.andago.com Teléfono: +34 916 011 373 Móvil: +34 637 741 034 e-mail: jorge.cabr...@andago.com C/Alcalde Ángel Arroyo n.º10 1.ªPl. (28904) Getafe, Madrid -- 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
stv 0288 datasheet
Hi all! I'm planning to use stv0288 ic located inside of TeVii S420 for some special purposes , so I need a complete datasheet or at least registers description. I've searched anywhere across the web but can't find anything useful. Can anyone help me with this, please? Best regards, Igor fishmf [at] fishmf [dot] ath [dot] cx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: mx1-camera: compile fix
Hi Uwe On Thu, 4 Mar 2010, Uwe Kleine-König wrote: > This is a regression of > > 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old > names) > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > this went unnoticed up to now as mx1_defconfig doesn't include support > for mx1-camera. > I have a patch pending to change that though. > > Best regards > Uwe > > drivers/media/video/mx1_camera.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/mx1_camera.c > b/drivers/media/video/mx1_camera.c > index 2ba14fb..38e5315 100644 > --- a/drivers/media/video/mx1_camera.c > +++ b/drivers/media/video/mx1_camera.c > @@ -45,6 +45,9 @@ > #include > #include > > +#undef DMA_BASE > +#define DMA_BASE MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) I don't like this. Why the "undef"? Is DMA_BASE already defined? where and what is it? If it is - we better use a different name, if not - just remove the undef, please. > + > /* > * CSI registers > */ > @@ -783,7 +786,7 @@ static int __init mx1_camera_probe(struct platform_device > *pdev) > pcdev); > > imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO, > -IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0); > +IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0); > /* burst length : 16 words = 64 bytes */ > imx_dma_config_burstlen(pcdev->dma_chan, 0); > > -- > 1.7.0 > 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
[PATCH] V4L/DVB: mx1-camera: compile fix
This is a regression of 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old names) Signed-off-by: Uwe Kleine-König --- Hello, this went unnoticed up to now as mx1_defconfig doesn't include support for mx1-camera. I have a patch pending to change that though. Best regards Uwe drivers/media/video/mx1_camera.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c index 2ba14fb..38e5315 100644 --- a/drivers/media/video/mx1_camera.c +++ b/drivers/media/video/mx1_camera.c @@ -45,6 +45,9 @@ #include #include +#undef DMA_BASE +#define DMA_BASE MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + /* * CSI registers */ @@ -783,7 +786,7 @@ static int __init mx1_camera_probe(struct platform_device *pdev) pcdev); imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO, - IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0); + IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0); /* burst length : 16 words = 64 bytes */ imx_dma_config_burstlen(pcdev->dma_chan, 0); -- 1.7.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
TeVii S460 vs. S464
Hello, I'd like to ask about the new TeVii S464 DVB-S2 card. I noticed that the official v4l-dvb doesn't support this card as of yet. However, I found fresh & new patch in the s2-liplianin repo, supposedly adding the support. I've always been using TeVii S460's in my streaming backend, they're reliable, stable and support all features like signal strength, monitoring, etc. My question is - did anybody test this new "revision"? Does it work at least as well as S460? I'm going to buy 5 new cards for my new backend, it's going to be used by the whole household. That's why I'm asking now, because this time I won't be able to test and report bugs for a couple of months before the card becomes usable. If there's any doubt about the card's stability & readiness, I'd rather find another retailer and purchased old S460's. All this aside - are there any actual benefits to using S464 over S460? Is it better HW? More sensitive perhaps? I noticed that it's just smaller, doesn't have a loop-out and basically seem like a scaled down version of S460. If so, it might even be inferior and in that case, I certainly wouldn't buy it. Thank you for any hints, tips or professional opinions! Best wishes, -- David Kubicek -- 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
how to debug radio_i2c_si470x.ko
Hello, I imported this driver from kernel 2.6.32.7 to 2.6.29 on my SGH-i900. The module is loaded and /dev/i2c-0 is created but I can't see any /dev/radio* Did I miss something ? - Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 3b6f1b8..7884207 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -136,6 +136,7 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
{
unsigned long first,last;
int err, rw = 0;
+ struct vm_area_struct *vma;
dma->direction = direction;
switch (dma->direction) {
@@ -153,6 +154,23 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
last = ((data+size-1) & PAGE_MASK) >> PAGE_SHIFT;
dma->offset = data & ~PAGE_MASK;
dma->nr_pages = last-first+1;
+
+ /* In case the buffer is user-allocated and is actually an IO buffer for
+ some other hardware, we cannot map pages for it. It in fact behaves
+ the same as an overlay. */
+ vma = find_vma (current->mm, data);
+ if (vma && (vma->vm_flags & VM_IO)) {
+ /* Only a single contiguous buffer is supported. */
+ if (vma->vm_end < data + size) {
+ dprintk(1, "init user: non-contiguous IO buffer.\n");
+ return -EFAULT; /* same error that get_user_pages()
would give */
+ }
+ dma->bus_addr = (vma->vm_pgoff << PAGE_SHIFT) + (data -
vma->vm_start);
+ dprintk(1,"init user IO [0x%lx+0x%lx => %d pages at 0x%x]\n",
+ data, size, dma->nr_pages, dma->bus_addr);
+ return 0;
+ }
+
dma->pages = kmalloc(dma->nr_pages * sizeof(struct page*),
GFP_KERNEL);
if (NULL == dma->pages)
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen
videobuf_pages_to_sg() and videobuf_vmalloc_to_sg() happen to create
a scatterlist element for every page. However, this is not true for
bus addresses, so other functions shouldn't rely on the length of the
scatter list being equal to nr_pages.
---
drivers/media/video/videobuf-dma-sg.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index da1790e..3b6f1b8 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -244,7 +244,7 @@ int videobuf_dma_map(struct videobuf_queue* q, struct
videobuf_dmabuf *dma)
}
if (!dma->bus_addr) {
dma->sglen = dma_map_sg(q->dev, dma->sglist,
- dma->nr_pages, dma->direction);
+ dma->sglen, dma->direction);
if (0 == dma->sglen) {
printk(KERN_WARNING
"%s: videobuf_map_sg failed\n",__func__);
@@ -262,7 +262,7 @@ int videobuf_dma_sync(struct videobuf_queue *q, struct
videobuf_dmabuf *dma)
MAGIC_CHECK(dma->magic, MAGIC_DMABUF);
BUG_ON(!dma->sglen);
- dma_sync_sg_for_cpu(q->dev, dma->sglist, dma->nr_pages, dma->direction);
+ dma_sync_sg_for_cpu(q->dev, dma->sglist, dma->sglen, dma->direction);
return 0;
}
@@ -272,7 +272,7 @@ int videobuf_dma_unmap(struct videobuf_queue* q,struct
videobuf_dmabuf *dma)
if (!dma->sglen)
return 0;
- dma_unmap_sg(q->dev, dma->sglist, dma->nr_pages, dma->direction);
+ dma_unmap_sg(q->dev, dma->sglist, dma->sglen, dma->direction);
kfree(dma->sglist);
dma->sglist = NULL;
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] Support for zerocopy to DSP on OMAP3
Here is an updated patch, properly split up and with commit messages. I've tested it on my OMAP3 board an it works. I don't have anything else to test it with. Regards, Arnout [PATCH 1/2] V4L/DVB: buf-dma-sg.c: don't assume nr_pages == sglen [PATCH 2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory -- 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: TBS 6980 Dual DVB-S2 PCIe card
Hi Hermann, On Thu, Mar 4, 2010 at 11:05 AM, hermann pitton wrote: >> Has anyone done any attempt at contacting TBS to see if they can release >> their >> changes under the GPLv2? Ideally, they would provide a patch themselves, but >> it >> should be fairly simple to diff the linux/ trees from their provided >> linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in >> fact, it >> could be that their patch is so trivial that we could just include it in the >> stock Linux kernel without asking them for license clarifications... but >> obviously, if we can get a green sign from them, it would be even better. > > It is always the other way round. > > In the end they need a green sign from us. Well... I guess we are both right. :-) They need to assert ownership and license the code under the GPL, and we need to ensure that the quality of the code is high enough (driver is working and does not interfer with other parts of the code base...). > BTW, the TBS dual seems to be fine on m$, but there are some mysterious > lockups without any trace, if used in conjunction with some prior > S2/HDTV cards. I can't tell yet, if that it is evenly distributed over > amd/ati and nvidia stuff or whatever on win7 ... , but people do spend > lifetime in vain on it. This is pretty interesting, do you have any references? (forum links or similar) In my particular case, I was thinking about using it as the "only" S2 card in the machine, later possibly adding a DVB-C card if/when we get cable... so, it might not be a problem for me, but it still doesn't feel really good. I guess the card is pretty new, so maybe (hopefully) it will get fixed by a new firmware release. Do we have any readers of this list who own the card and use it in Linux (with the drivers from TBS)? Could you please share your experiences: is the picture quality good? Sound? Does the tuner work well? (e.g. can you receive all channels you normally receive...) -- Best regards, Per Lundberg -- 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: git over http from linuxtv
m7aalton wrote: > HI. > > On Wed, 2010-03-03 at 15:55 +0100, ext Mauro Carvalho Chehab wrote: >> m7aalton wrote: >>> Hello. >>> >>> On Tue, 2010-03-02 at 20:08 +0100, ext Mauro Carvalho Chehab wrote: m7aalton wrote: > Hi. > > Is it possible to access the linuxtv.org git repositories using http? > I tried to do this: > > git remote add linuxtv git://linuxtv.org/v4l-dvb.git You should be able to use both URL's: URLhttp://git.linuxtv.org/v4l-dvb.git git://linuxtv.org/v4l-dvb.git There were a miss-configuration for the http URL. I just fixed it. >>> >>> Now it works better but I still couldn't clone it properly. The update >>> from linuxtv didn't seem to do anything >>> >>> Here's what happened: >>> >>> $ git clone >>> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >>> v4l-dvb >>> >>> $ cd v4l-dvb >>> >>> $ git remote add linuxtv http://git.linuxtv.org/v4l-dvb.git >>> >>> $ git remote update >>> Updating origin >>> >From http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 >>>13dda80..3a5b27b master -> origin/master >>> Updating linuxtv >>> >>> $ git branch -a >>> * master >>> origin/HEAD >>> origin/master >>> >>> $ git checkout -b media-master linuxtv/master >>> fatal: git checkout: updating paths is incompatible with switching >>> branches. >>> Did you intend to checkout 'linuxtv/master' which can not be resolved as >>> commit? >> This happens when you try to use a gitweb URL instead of the proper one. At >> the above, >> you've used the wrong URL. The correct one is: >> http://linuxtv.org/git/v4l-dvb.git > > OK. Thanks. Earlier your said: > >>> You should be able to use both URL's: URLhttp://git.linuxtv.org/v4l-dvb.git git://linuxtv.org/v4l-dvb.git I've copied it from gitweb URL's. They were wrong. I just fixed it too. > > I didn't realize that you were referring to gitweb... Maybe it would > make sense to have also an example using http on your git repositories > page. The http transport should be used only as the last resort, where some corporate firewalls are configured to block git. The usage of http is less efficient than git, and require to enable a per-repository hook that runs every time a repository is updated. The hook updates some files that http transport needs. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gspca USB driver zc3xx and STV06xx probe the same device ..
Hi, On 03/04/2010 12:36 PM, Erik Andrén wrote: 2010/3/4 Hans de Goede: Hi, On 03/03/2010 02:17 PM, Erik Andrén wrote: 2010/3/3 Gabriel C: Hello, I own a QuickCam Messanger webcam.. I didn't used it in ages but today I plugged it in.. ( Device 002: ID 046d:08da Logitech, Inc. QuickCam Messanger ) Now zc3xx and stv06xx are starting both to probe the device .. In 2.6.33 that result in a not working webcam. ( rmmod both&&modprobe zc3xx one seems to fix that ) On current git head zc3xx works fine even when both are probing the device. Also I noticed stv06xx fails anyway for my webcam with this error: [ 360.910243] STV06xx: Configuring camera [ 360.910244] STV06xx: st6422 sensor detected [ 360.910245] STV06xx: Initializing camera [ 361.161948] STV06xx: probe of 6-1:1.0 failed with error -32 [ 361.161976] usbcore: registered new interface driver STV06xx [ 361.161978] STV06xx: registered . Next thing is stv06xx tells it is an st6422 sensor and does not work with it while zc3xx tells it is an HV7131R(c) sensor and works fine with it. What is right ? Hans, As you added support for the st6422 sensor to the stv06xx subdriver I imagine you best know what's going on. I took the USB-ID in question from the out of tree v4l1 driver I was basing my st6422 work on. Looking at the other ID's (which are very close together) and combining that with this bug report, I think it is safe to say that the USB-ID in question should be removed from the stv06xx driver. Erik will you handle this, or shall I ? Either way is fine by me. I can try to do it tonight. If you could take care of this that would be great! Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mumu DVB & Infinity Smart Card reader
Aslam Mullapilly wrote: > Hi, > > It will be great full if somebody can help me use Infinity smart card reader > to tune scrambled channel in mumudvb. > > > Hello Basically once your soft CAM works, DVB programs as MuMuDVB doesn't need some more extra configuration So your question is making your smart card reader working under linux in general... Unfortunately I cannot tell you more than having a look to sasc-ng and dvbloopback documentation Regards -- Brice -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gspca USB driver zc3xx and STV06xx probe the same device ..
2010/3/4 Hans de Goede : > Hi, > > On 03/03/2010 02:17 PM, Erik Andrén wrote: >> >> 2010/3/3 Gabriel C: >>> >>> Hello, >>> >>> I own a QuickCam Messanger webcam.. I didn't used it in ages but today >>> I plugged it in.. >>> ( Device 002: ID 046d:08da Logitech, Inc. QuickCam Messanger ) >>> >>> Now zc3xx and stv06xx are starting both to probe the device .. In >>> 2.6.33 that result in a not working webcam. >>> ( rmmod both&& modprobe zc3xx one seems to fix that ) >>> >>> On current git head zc3xx works fine even when both are probing the >>> device. >>> >>> Also I noticed stv06xx fails anyway for my webcam with this error: >>> >>> >>> [ 360.910243] STV06xx: Configuring camera >>> [ 360.910244] STV06xx: st6422 sensor detected >>> [ 360.910245] STV06xx: Initializing camera >>> [ 361.161948] STV06xx: probe of 6-1:1.0 failed with error -32 >>> [ 361.161976] usbcore: registered new interface driver STV06xx >>> [ 361.161978] STV06xx: registered >>> . >>> >>> Next thing is stv06xx tells it is an st6422 sensor and does not work >>> with it while zc3xx tells it is an HV7131R(c) sensor and works fine >>> with it. >>> >>> What is right ? >> >> Hans, >> As you added support for the st6422 sensor to the stv06xx subdriver I >> imagine you best know what's going on. >> > > I took the USB-ID in question from the out of tree v4l1 driver I was basing > my > st6422 work on. Looking at the other ID's (which are very close together) > and > combining that with this bug report, I think it is safe to say that the > USB-ID > in question should be removed from the stv06xx driver. > > Erik will you handle this, or shall I ? > Either way is fine by me. I can try to do it tonight. Best regards, ERik > Regards, > > Hans > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gspca USB driver zc3xx and STV06xx probe the same device ..
Hi, On 03/03/2010 02:17 PM, Erik Andrén wrote: 2010/3/3 Gabriel C: Hello, I own a QuickCam Messanger webcam.. I didn't used it in ages but today I plugged it in.. ( Device 002: ID 046d:08da Logitech, Inc. QuickCam Messanger ) Now zc3xx and stv06xx are starting both to probe the device .. In 2.6.33 that result in a not working webcam. ( rmmod both&& modprobe zc3xx one seems to fix that ) On current git head zc3xx works fine even when both are probing the device. Also I noticed stv06xx fails anyway for my webcam with this error: [ 360.910243] STV06xx: Configuring camera [ 360.910244] STV06xx: st6422 sensor detected [ 360.910245] STV06xx: Initializing camera [ 361.161948] STV06xx: probe of 6-1:1.0 failed with error -32 [ 361.161976] usbcore: registered new interface driver STV06xx [ 361.161978] STV06xx: registered . Next thing is stv06xx tells it is an st6422 sensor and does not work with it while zc3xx tells it is an HV7131R(c) sensor and works fine with it. What is right ? Hans, As you added support for the st6422 sensor to the stv06xx subdriver I imagine you best know what's going on. I took the USB-ID in question from the out of tree v4l1 driver I was basing my st6422 work on. Looking at the other ID's (which are very close together) and combining that with this bug report, I think it is safe to say that the USB-ID in question should be removed from the stv06xx driver. Erik will you handle this, or shall I ? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On 4 March 2010 04:18, Mauro Carvalho Chehab wrote: > Devin Heitmueller wrote: >> On Wed, Mar 3, 2010 at 8:00 PM, Pedro Ribeiro wrote: >>> Its working very well, thanks. >>> >>> Can you please tell me if its going to be pushed to .33 stable? And >>> should I close the kernel bug? >> >> It's in Mauro's PULL request for 2.6.34-rc1. It's marked "normal" >> priority so it likely won't get pulled into stable. It was a >> non-trivial restructuring of the code, so doing a minimal fix that >> would be accepted by stable is unlikely. > > The kernel bug should be closed, as this patch has already fixed and > sent upstream. >> >> Devin >> > > > -- > > Cheers, > Mauro > Devin, I noticed that your solution does not alter the remote query interval from 50 msec. It works, but it is not as effective as my hard hack because I still get interference every once in a while when the DVB adapter is connected. I can't tell you exactly when and how it happens, because it seems rather random - but it is much better than previously though. Regards, Pedro -- 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: git over http from linuxtv
HI. On Wed, 2010-03-03 at 15:55 +0100, ext Mauro Carvalho Chehab wrote: > m7aalton wrote: > > Hello. > > > > On Tue, 2010-03-02 at 20:08 +0100, ext Mauro Carvalho Chehab wrote: > >> m7aalton wrote: > >>> Hi. > >>> > >>> Is it possible to access the linuxtv.org git repositories using http? > >>> I tried to do this: > >>> > >>> git remote add linuxtv git://linuxtv.org/v4l-dvb.git > >> You should be able to use both URL's: > >> > >> URLhttp://git.linuxtv.org/v4l-dvb.git > >>git://linuxtv.org/v4l-dvb.git > >> > >> There were a miss-configuration for the http URL. I just fixed it. > > > > > > Now it works better but I still couldn't clone it properly. The update > > from linuxtv didn't seem to do anything > > > > Here's what happened: > > > > $ git clone > > http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > v4l-dvb > > > > $ cd v4l-dvb > > > > $ git remote add linuxtv http://git.linuxtv.org/v4l-dvb.git > > > > $ git remote update > > Updating origin > >>From http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 > >13dda80..3a5b27b master -> origin/master > > Updating linuxtv > > > > $ git branch -a > > * master > > origin/HEAD > > origin/master > > > > $ git checkout -b media-master linuxtv/master > > fatal: git checkout: updating paths is incompatible with switching > > branches. > > Did you intend to checkout 'linuxtv/master' which can not be resolved as > > commit? > > This happens when you try to use a gitweb URL instead of the proper one. At > the above, > you've used the wrong URL. The correct one is: >http://linuxtv.org/git/v4l-dvb.git OK. Thanks. Earlier your said: >> You should be able to use both URL's: > >> > >> URLhttp://git.linuxtv.org/v4l-dvb.git > >>git://linuxtv.org/v4l-dvb.git I didn't realize that you were referring to gitweb... Maybe it would make sense to have also an example using http on your git repositories page. Cheers, Matti > > You don't need to re-do the entire procedure. Just edit .git/config and put > the > correct URL there for the linuxtv remote. > -- 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
Cinergy Hybrid T USB XS (2882) 0ccd:005e
Hi, using kernel 2.6.33, dvb is not working (no /dev/dvb) I'm willing to help and can quickly test patches on em28xx module. Thanks for any advice. Regards, Jérémy. [ 1820.020978] usb 1-2: New USB device found, idVendor=0ccd, idProduct=005e [ 1820.020985] usb 1-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 1820.020991] usb 1-2: Product: Cinergy Hybrid T USB XS (2882) [ 1820.020996] usb 1-2: Manufacturer: TerraTec Electronic GmbH [ 1820.021026] usb 1-2: SerialNumber: 070802004968 [ 1820.053960] em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS (2882) @ 480 Mbps (0ccd:005e, interface 0, class 0) [ 1820.054059] em28xx #0: chip ID is em2882/em2883 [ 1820.229575] em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 5e 00 d0 12 5c 03 9e 40 de 1c [ 1820.229595] em28xx #0: i2c eeprom 10: 6a 34 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 1820.229613] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 1e 00 00 [ 1820.229630] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 [ 1820.229648] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1820.229664] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 1820.229681] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 34 03 54 00 65 00 [ 1820.229698] em28xx #0: i2c eeprom 70: 72 00 72 00 61 00 54 00 65 00 63 00 20 00 45 00 [ 1820.229716] em28xx #0: i2c eeprom 80: 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 69 00 [ 1820.229733] em28xx #0: i2c eeprom 90: 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 40 03 [ 1820.229750] em28xx #0: i2c eeprom a0: 43 00 69 00 6e 00 65 00 72 00 67 00 79 00 20 00 [ 1820.229767] em28xx #0: i2c eeprom b0: 48 00 79 00 62 00 72 00 69 00 64 00 20 00 54 00 [ 1820.229784] em28xx #0: i2c eeprom c0: 20 00 55 00 53 00 42 00 20 00 58 00 53 00 20 00 [ 1820.229801] em28xx #0: i2c eeprom d0: 28 00 32 00 38 00 38 00 32 00 29 00 00 00 1c 03 [ 1820.229818] em28xx #0: i2c eeprom e0: 30 00 37 00 30 00 38 00 30 00 32 00 30 00 30 00 [ 1820.229835] em28xx #0: i2c eeprom f0: 34 00 39 00 36 00 38 00 00 00 00 00 00 00 dc 00 [ 1820.229855] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xde6f68be [ 1820.229859] em28xx #0: EEPROM info: [ 1820.229862] em28xx #0: AC97 audio (5 sample rates) [ 1820.229866] em28xx #0: 500mA max power [ 1820.229870] em28xx #0: Table at 0x27, strings=0x409e, 0x1cde, 0x346a [ 1820.230584] em28xx #0: Identified as Terratec Hybrid XS (em2882) (card=55) [ 1820.235611] tvp5150 2-005c: chip found @ 0xb8 (em28xx #0) [ 1820.241539] tuner 2-0061: chip found @ 0xc2 (em28xx #0) [ 1820.241682] xc2028 2-0061: creating new instance [ 1820.241687] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner [ 1820.241700] usb 1-2: firmware: requesting xc3028-v27.fw [ 1820.248483] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 1820.296074] xc2028 2-0061: Loading firmware for type=BASE MTS (5), id . [ 1821.336717] xc2028 2-0061: Loading firmware for type=MTS (4), id b700. [ 1821.353577] xc2028 2-0061: Loading SCODE for type=MTS LCD NOGD MONO IF SCODE HAS_IF_4500 (6002b004), id b700. [ 1821.536445] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb1/1-2/input/input14 [ 1821.537408] em28xx #0: Config register raw data: 0xd0 [ 1821.538157] em28xx #0: AC97 vendor ID = 0x [ 1821.538521] em28xx #0: AC97 features = 0x6a90 [ 1821.538525] em28xx #0: Empia 202 AC97 audio processor detected [ 1821.668567] tvp5150 2-005c: tvp5150am1 detected. [ 1821.772948] em28xx #0: v4l2 driver version 0.1.2 [ 1821.859523] em28xx #0: V4L2 video device registered as video0 [ 1821.859529] em28xx #0: V4L2 VBI device registered as vbi0 [ 1821.876848] usbcore: registered new interface driver em28xx [ 1821.876855] em28xx driver loaded [ 1821.883693] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 1821.883699] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 1821.884343] Em28xx: Initialized (Em28xx Audio Extension) extension [ 1821.948647] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1821.964394] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1821.980520] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1821.986999] Em28xx: Initialized () extension [ 1821.996529] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1821.996536] tvp5150 2-005c: *** unknown tvp3e04 chip detected. [ 1821.996540] tvp5150 2-005c: *** Rom ver is 12.0 [ 1822.056515] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1822.076390] tvp5150 2-005c: i2c i/o error: rc == -19 (should be 1) [ 1822.252526] tvp5150 2-005c: tvp5150am1 detected. signature.asc Description: OpenPGP digital signature
Re: [PATCH RFCv1] Support for zerocopy to DSP on OMAP3
Hi Arnout, On Wednesday 03 March 2010 20:11:06 Arnout Vandecappelle wrote: > Here's a first attempt at allowing IO memory for USERPTR buffers. > > It also fixes another issue: it was assumed that > dma->sglen == dma->nr_pages. I'll split that up in a separate patch in the > final version. -EMISSINGPATCH :-) Please split the patch and CC Sakari Ailus when you submit them. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TBS 6980 Dual DVB-S2 PCIe card
Am Donnerstag, den 04.03.2010, 08:19 + schrieb Per Lundberg: > Hi! > > I read the old thread about this card, at > http://www.mail-archive.com/linux-media@vger.kernel.org/msg12753.html. I've > also > tried downloading the vendor-provided drivers from > http://www.buydvb.net/download2/TBS6980/tbs6980linuxdriver2.6.32.rar > > As someone has already indicated, it seems like TBS (TurboSight) have made > their > own fork of v4l where the drivers for this card is included. I've also > understood that the card works fine, which is nice (I down own it yet but am > considering getting one). > > Has anyone done any attempt at contacting TBS to see if they can release their > changes under the GPLv2? Ideally, they would provide a patch themselves, but > it > should be fairly simple to diff the linux/ trees from their provided > linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, > it > could be that their patch is so trivial that we could just include it in the > stock Linux kernel without asking them for license clarifications... but > obviously, if we can get a green sign from them, it would be even better. > -- > Best regards, > Per Lundberg > It is always the other way round. In the end they need a green sign from us. Cheers, Hermann BTW, the TBS dual seems to be fine on m$, but there are some mysterious lockups without any trace, if used in conjunction with some prior S2/HDTV cards. I can't tell yet, if that it is evenly distributed over amd/ati and nvidia stuff or whatever on win7 ... , but people do spend lifetime in vain on it. -- 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 10/11] ov534: Add Powerline Frequency control
On Wed, 3 Mar 2010 23:55:33 -0500 Jim Paris wrote: > Antonio Ospite wrote: [...] > > > > I see. It would be interesting to see how Powerline Frequency filtering > > is done on PS3. I added Jim Paris on CC. > > Hi Antonio and Mosalam, > > I tried, but I can't capture that. My USB logger only does USB 1.1, > which is too slow for the camera to run normally, but good enough to > see the initialization sequence. However, the 50/60Hz option only > appears later, once the PS3 is receiving good frame data. > > I can open up the camera and sniff the I2C bus instead. It'll take > a little longer. > Thanks for your time Jim. > Interesting side note, the only change in the initialization sequence > between PS3 firmware 1.93 and 3.15 is 0x0C bit 6 -- horizontal flip :) > So they haven't made any improvements that we can borrow. > > -jim > Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgph7ED2M8f5d.pgp Description: PGP signature
TBS 6980 Dual DVB-S2 PCIe card
Hi! I read the old thread about this card, at http://www.mail-archive.com/linux-media@vger.kernel.org/msg12753.html. I've also tried downloading the vendor-provided drivers from http://www.buydvb.net/download2/TBS6980/tbs6980linuxdriver2.6.32.rar As someone has already indicated, it seems like TBS (TurboSight) have made their own fork of v4l where the drivers for this card is included. I've also understood that the card works fine, which is nice (I down own it yet but am considering getting one). Has anyone done any attempt at contacting TBS to see if they can release their changes under the GPLv2? Ideally, they would provide a patch themselves, but it should be fairly simple to diff the linux/ trees from their provided linux-s2api-tbs6980.tar.bz2 file with the stock Linux 2.6.32 code... in fact, it could be that their patch is so trivial that we could just include it in the stock Linux kernel without asking them for license clarifications... but obviously, if we can get a green sign from them, it would be even better. -- Best regards, Per Lundberg -- 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
