Re: Cinergy T2 stopped working with kernel 2.6.30

[emagick]

There are two new discoveries about my Cinergy T2 problem:

- the Cinergy T2 works when attached to an Intel Core2 board, but doesn't work 
when
  attached to an Intel Atom N270 board (tuning times out)

- git bisect of the Linux kernel points to a bad merge of
  commit 60db56422043aaa455ac7f858ce23c273220f9d9 (good) and
  commit be0ea69674ed95e1e98cb3687a241badc756d228 (good) yielding
  commit 6e15cf04860074ad032e88c306bea656bbdd0f22 (bad).

So, the problem is probably interrupt-related, not dvb-usb-related.
Any idea on how to continue from here?
--
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: Problems with Pinnacle 310i (saa7134) and recent kernels

[hermann pitton]

Hi,

Am Mittwoch, den 22.07.2009, 12:41 + schrieb Avl Jawrowski:
 Hi,
 
 hermann pitton hermann-pitton at arcor.de writes:
 
  there is no excuse for getting errors on linux ;)
  
  Where you got this card from and did it ever work on the same machine
  with m$ stuff?
 
 I don't have m$ stuff.

also fine. We can exclude the eeprom was messed up by windows toys.

  Clean up your module mess, read again, and if the eeprom has still
  nothing to tell than 1 for all, get rid of it.
 
 The errors were caused by a statically compiled v4l module.
 However the patch seems makes no difference. Maybe it make working
 the EPG but I haven't test it enough because the card works occasionally.

As said, 2.6.25 is reported working fine without LNA or other issues.
If that doesn't work, there are issues with your card itself or other
hardware environment involved.

 Is the eeprom so important? With a certain kernel configuration (all modules
 compiled) gives no errors but only fs:

The eeprom content is not important on that card at all, except for auto
detection, but flaky eeprom read outs likely indicate more and other
hardware trouble.

If it seems to deliver stable results now, you can even try to re-flash
it with rewrite_eeprom.pl in v4l2-apps/util. Read the instructions on
top of it. 

 Linux video capture interface: v2.00
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7134 :01:01.0: PCI INT A - GSI 21 (level, low) - IRQ 21
 saa7133[0]: found at :01:01.0, rev: 209, irq: 21, latency: 32, mmio:
 0xcfddf800
 saa7133[0]: subsystem: :, board: Pinnacle PCTV 310i [card=101,insmod
 option]
 saa7133[0]: board init: gpio is 600e000
 IRQ 21/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7133[0]: i2c eeprom 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 tuner 1-004b: chip found @ 0x96 (saa7133[0])
 tda829x 1-004b: setting tuner address to 61
 tda829x 1-004b: type set to tda8290+75a
 saa7133[0]: registered device video0 [v4l2]
 saa7133[0]: registered device vbi0
 saa7133[0]: registered device radio0
 dvb_init() allocating 1 frontend
 DVB: registering new adapter (saa7133[0])
 DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)...
 tda1004x: setting up plls for 48MHz sampling clock
 tda1004x: found firmware revision 29 -- ok
 saa7134 ALSA driver for DMA sound loaded
 IRQ 21/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7133[0]/alsa: saa7133[0] at 0xcfddf800 irq 21 registered as card -1
 
 But now the card don't works not even with Kaffeine:

Hm, with the patch on current v4l-dvb and 2.6.30 something? On 2.6.25
current v4l-dvb won't compile anymore and you should try that kernel
without any changes.

 /dev/dvb/adapter0/frontend0 : opened ( Philips TDA10046H DVB-T ) (0ms)
 0 EPG plugins loaded for device 0:0.
 Loaded epg data : 0 events (0 msecs)
 DvbCam::probe(): /dev/dvb/adapter0/ca0: : No such file or directory
 Using DVB device 0:0 Philips TDA10046H DVB-T
 Not able to lock to the signal on the given frequency
 Frontend closed
 Tuning delay: 1701 ms

Also increase tuning delay to 5000 ms and check for different signal and
SNR values. In that mentioned 2.6.26 regression ... thread analog TV
functionality was fully restored by a similar hack, but also lots of
changes to the drivers since 2.6.25.  

 I think the occasional nonfunctional are caused by this error:
 
 IRQ 21/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 
 Is it possible?

We see that hint on almost all drivers since 2.6.29 and not using that
IRQ flag anymore did not make any difference so far, for what I can
tell.

 The option disable_ir=1 has no effect. Changing PCI slot makes no difference.
 Anyway with w_scan and Kaffeine in normal conditions the tuner works almost
 always.

Thanks for your reports and sorry for not having a final conclusion yet.

Cheers,

Re: [linux-dvb] Help Request: DM1105 STV0299 DVB-S PCI - Unable to tune

[Simon Kenyon]

Shaun Murdoch wrote:

Hi everyone,

First post so please be gentle :-)

I was wondering if anyone can help me please - I am trying to get a 
DVB-S PCI card working with Linux (Ubuntu 9.04). So far I can get the 
card recognised by Linux, but it won't tune - Kaffeine does tell me 
that there is 95% signal and 80% SNR, and I am using the same 
frequencies etc that a standard Sky box uses.


The card is very common on eBay so I am sure there are plenty people 
who have tried this / would want this working.


Some details that I hope will help someone who knows more than I do 
about this!


The card is one of these:
http://cgi.ebay.co.uk/DVB-S-Satellite-TV-Tuner-Video-Capture-PCI-Card-Remote_W0QQitemZ130314645048QQcmdZViewItemQQptZUK_Computing_Computer_Components_Graphics_Video_TV_Cards_TW?hash=item1e575bae38_trksid=p3286.c0.m14_trkparms=65:12|66:2|39:1|72:1690|293:1|294:50 
http://cgi.ebay.co.uk/DVB-S-Satellite-TV-Tuner-Video-Capture-PCI-Card-Remote_W0QQitemZ130314645048QQcmdZViewItemQQptZUK_Computing_Computer_Components_Graphics_Video_TV_Cards_TW?hash=item1e575bae38_trksid=p3286.c0.m14_trkparms=65:12%7C66:2%7C39:1%7C72:1690%7C293:1%7C294:50


lspci:
03:09.0 Ethernet controller: Device 195d:1105 (rev 10)

My dmesg output - looks ok?:
$ dmesg | grep DVB
[   12.174738] DVB: registering new adapter (dm1105)
[   12.839501] DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)...
[   12.839633] input: DVB on-card IR receiver as 
/devices/pci:00/:00:1e.0/:03:09.0/input/input

My output from scan -* the problem*:
$ sudo scan -vv /usr/share/dvb/dvb-s/Astra-28.2E
scanning /usr/share/dvb/dvb-s/Astra-28.2E
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'

 tune to: 11778:v:0:27500
DiSEqC: switch pos 0, 13V, hiband (index 2)
diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
DVB-S IF freq is 1178000
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
 tuning status == 0x03
WARNING:  tuning failed!!!
/This is the correct satellite for my location (south UK), I believe. 
Have tried plenty. Nothing locks./


I'm using the latest liplianin drivers - did a mercurial checkout and 
build today:

$ modinfo dm1105
filename:   
/lib/modules/2.6.28-13-server/kernel/drivers/media/dvb/dm1105/dm1105.ko
license:GPL
description:SDMC DM1105 DVB driver
author: Igor M. Liplianin liplia...@me.by mailto:liplia...@me.by
srcversion: 46C1B3C3627D1937F75D732
alias:  pci:v195Dd1105sv*sd*bc*sc*i*
alias:  pci:v109Fd036Fsv*sd*bc*sc*i*
depends:ir-common,dvb-core
vermagic:   2.6.28-13-server SMP mod_unload modversions
parm:   card:card type (array of int)
parm:   ir_debug:enable debugging information for IR decoding (int)
parm:   adapter_nr:DVB adapter numbers (array of short)
Have also tried the latest v4l-dvb drivers and get exactly the same 
tuning problems.


Finally, dvbtune appears to say I have signal but cannot lock:
$ sudo dvbtune -f 1177800 -s 27500 -p v -m -tone 1 -vvv
[sudo] password for shaun:
Using DVB card ST STV0299 DVB-S
tuning DVB-S to L-Band:0, Pol:V Srate=2750, 22kHz=on
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER FE_HAS_VITERBI
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER FE_HAS_VITERBI
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
polling
Getting frontend event
FE_STATUS: *FE_HAS_SIGNAL FE_HAS_CARRIER* FE_HAS_VITERBI
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER

So I am thinking that this could be a driver issue? If the card has 
good signal and SNR in Kaffeine, and dvbtune says it has signal and 
carrier - but cannot lock?


Please can someone help me debug this?

Thanks a lot!
Shaun

i have a few and they work fine
in my small little way i helped to get them to work
in fact i tried to import a bulk shipment from china - but they offered 
the same price for 200 as i can get on ebay - so i didn't bother


are you sure the signal is good? have you tried with another card to check?
--
simon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Lenovo webcam problem which using gspca's vc032x driver

[Jean-Francois Moine]

On Wed, 22 Jul 2009 17:15:15 +0800
AceLan Kao acelan@canonical.com wrote:

 I would like to know which version of vc032x.c won't make 041e:405b
 device display upside down.
 And have you let the 041e:405b device owner to test the SXGA setting
 and with the 1280x960 resolution? What's the result?


Hi AceLan Kao,

The 041e:405b had a good display with the current version of vc032x
(i.e., including the change 'Webcam 041e:405b added and mi1310_soc
updated').

I've just asked the 405b owners to test the XGA resolution. I'll give
you the results as soon as I will get them.

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Help Request: DM1105 STV0299 DVB-S PCI - Unable to tune

[Shaun Murdoch]

Thanks Simon - did you need to do anything special to get them to
work, or did they work out of the box with the latest s2-liplianin /
v4l-dvb drivers?

I've not tried another card (don't have one), but I did try a set-top
box which works fine - and let me get the frequency/lnb/etc info.


2009/7/23 Simon Kenyon si...@koala.ie:
 Shaun Murdoch wrote:

 Hi everyone,

 First post so please be gentle :-)

 I was wondering if anyone can help me please - I am trying to get a DVB-S
 PCI card working with Linux (Ubuntu 9.04). So far I can get the card
 recognised by Linux, but it won't tune - Kaffeine does tell me that there is
 95% signal and 80% SNR, and I am using the same frequencies etc that a
 standard Sky box uses.

 The card is very common on eBay so I am sure there are plenty people who
 have tried this / would want this working.

 Some details that I hope will help someone who knows more than I do about
 this!

 The card is one of these:

 http://cgi.ebay.co.uk/DVB-S-Satellite-TV-Tuner-Video-Capture-PCI-Card-Remote_W0QQitemZ130314645048QQcmdZViewItemQQptZUK_Computing_Computer_Components_Graphics_Video_TV_Cards_TW?hash=item1e575bae38_trksid=p3286.c0.m14_trkparms=65:12|66:2|39:1|72:1690|293:1|294:50
 http://cgi.ebay.co.uk/DVB-S-Satellite-TV-Tuner-Video-Capture-PCI-Card-Remote_W0QQitemZ130314645048QQcmdZViewItemQQptZUK_Computing_Computer_Components_Graphics_Video_TV_Cards_TW?hash=item1e575bae38_trksid=p3286.c0.m14_trkparms=65:12%7C66:2%7C39:1%7C72:1690%7C293:1%7C294:50

 lspci:
 03:09.0 Ethernet controller: Device 195d:1105 (rev 10)

 My dmesg output - looks ok?:
 $ dmesg | grep DVB
 [   12.174738] DVB: registering new adapter (dm1105)
 [   12.839501] DVB: registering adapter 0 frontend 0 (ST STV0299 DVB-S)...
 [   12.839633] input: DVB on-card IR receiver as
 /devices/pci:00/:00:1e.0/:03:09.0/input/input

 My output from scan -* the problem*:
 $ sudo scan -vv /usr/share/dvb/dvb-s/Astra-28.2E
 scanning /usr/share/dvb/dvb-s/Astra-28.2E
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'

  tune to: 11778:v:0:27500
 DiSEqC: switch pos 0, 13V, hiband (index 2)
 diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
 DVB-S IF freq is 1178000
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
  tuning status == 0x03
 WARNING:  tuning failed!!!
 /This is the correct satellite for my location (south UK), I believe. Have
 tried plenty. Nothing locks./

 I'm using the latest liplianin drivers - did a mercurial checkout and
 build today:
 $ modinfo dm1105
 filename:
 /lib/modules/2.6.28-13-server/kernel/drivers/media/dvb/dm1105/dm1105.ko
 license:        GPL
 description:    SDMC DM1105 DVB driver
 author:         Igor M. Liplianin liplia...@me.by
 mailto:liplia...@me.by
 srcversion:     46C1B3C3627D1937F75D732
 alias:          pci:v195Dd1105sv*sd*bc*sc*i*
 alias:          pci:v109Fd036Fsv*sd*bc*sc*i*
 depends:        ir-common,dvb-core
 vermagic:       2.6.28-13-server SMP mod_unload modversions
 parm:           card:card type (array of int)
 parm:           ir_debug:enable debugging information for IR decoding
 (int)
 parm:           adapter_nr:DVB adapter numbers (array of short)
 Have also tried the latest v4l-dvb drivers and get exactly the same tuning
 problems.

 Finally, dvbtune appears to say I have signal but cannot lock:
 $ sudo dvbtune -f 1177800 -s 27500 -p v -m -tone 1 -vvv
 [sudo] password for shaun:
 Using DVB card ST STV0299 DVB-S
 tuning DVB-S to L-Band:0, Pol:V Srate=2750, 22kHz=on
 polling
 Getting frontend event
 FE_STATUS:
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER FE_HAS_VITERBI
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER FE_HAS_VITERBI
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
 polling
 Getting frontend event
 FE_STATUS: *FE_HAS_SIGNAL FE_HAS_CARRIER* FE_HAS_VITERBI
 polling
 Getting frontend event
 FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER

 So I am thinking that this could be a driver issue? If the card has good
 signal and SNR in Kaffeine, and dvbtune says it has signal and carrier - but
 cannot lock?

 Please can someone help me debug this?

 Thanks a lot!
 Shaun

 i have a few and they work fine
 in my small little way i helped to get them to work
 in fact i tried to import a bulk shipment from china - but they offered the
 same price for 200 as i can get on ebay - so i didn't bother

 are you sure the signal is good? have you tried with another card to check?
 --
 simon
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe 

Re: [linux-dvb] Terratec Cinergy HTC USB XS HD

[anderse]

On Sat, Jul 18, 2009 at 12:46 PM, Mario Fetkamario.fe...@gmail.com wrote:
 On Saturday, 18. July 2009 04:06:13 Alain Kalker wrote:
 Op maandag 15-06-2009 om 22:36 uur [tijdzone +0200], schreef sacha:
  Hello
 
  Does anybody know if this devise will ever work with Linux?
  It was promised by one person last year the support will be available
  within months. One year has gone, nothing happens.
  Is there any alternatives to develop a driver for this devise aside from
  this person?

 Since there has been no answer to your question for some time, I think I
 will step in.

 From http://mcentral.de/wiki/index.php5/Terratec_HTC_XS , the future for

 a driver from Markus for this device does seem to look quite bleak.
 However, from looking in the mailinglist archive I gather that Steven
 Toth has offered to try getting it to work if someone is willing to
 provide him with a device.
 Maybe you two could get in contact.
 I myself am also interested in a driver for this device but I haven't
 got one yet.

 Kind regards,

 Alain

 as far as i know there already exists a driver but it could not be published
 as it is based on the micronas refernce driver

 i think the problem is related to

 http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030738.html

 but this new situation with
 http://www.tridentmicro.com/Product_drx_39xyK.asp

 can maby change something about this chip

 and it would be possible to get the rights to publish the driver under  gpl-2


This won't solve the issue that the AVFB4910 has been discontinued.
This affects FM Radio, Analogue TV, Composite and S-Video, that IC
didn't get bought by Trident.

regards,
Markus

Did Devin Heitmueller comment on that? AFAIK he already finished a driver for 
the DRX-3933J and I would think he might have interest to get in contact with 
trident in order of being allowed to publish his work.
Should be a rather small step compared to the work he has done so far.
And Trident has some history in cooperating together with XFree developers, 
letting them develop graphics card drivers.

What about this AVFB4910? Is it possible to get a working DVB-C/DVB-T solution 
without getting in contact with this chip? And once this would be done, there 
should still be the option of reverse engineering the protocol of that one.

Meanwhile, Terratec has dicontinued the Cinergy HTC USB XS HD, but what about 
the H5? Does anyone know about its internals already? 

AFAIK, these are still the only non-PCI DVB-C solutions on the market.

Hmm, did micronas give up this full range of products? Sold the 'interesting' 
part to trident and ceased production of everything else? Maybe half a year 
ago, they didn't want to disturb ongoing selling negotiations by giving away 
their intellectual property for free in parallel, and now, after all is 
settled, maybe they don't mind anymore. 
So contacting those people again could be worth it, too.

best regards, 

Raimund


-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
--
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] Terratec Cinergy HTC USB XS HD

[Markus Rechberger]

On Thu, Jul 23, 2009 at 1:10 PM, ande...@gmx.de wrote:
On Sat, Jul 18, 2009 at 12:46 PM, Mario Fetkamario.fe...@gmail.com wrote:
 On Saturday, 18. July 2009 04:06:13 Alain Kalker wrote:
 Op maandag 15-06-2009 om 22:36 uur [tijdzone +0200], schreef sacha:
  Hello
 
  Does anybody know if this devise will ever work with Linux?
  It was promised by one person last year the support will be available
  within months. One year has gone, nothing happens.
  Is there any alternatives to develop a driver for this devise aside from
  this person?

 Since there has been no answer to your question for some time, I think I
 will step in.

 From http://mcentral.de/wiki/index.php5/Terratec_HTC_XS , the future for

 a driver from Markus for this device does seem to look quite bleak.
 However, from looking in the mailinglist archive I gather that Steven
 Toth has offered to try getting it to work if someone is willing to
 provide him with a device.
 Maybe you two could get in contact.
 I myself am also interested in a driver for this device but I haven't
 got one yet.

 Kind regards,

 Alain

 as far as i know there already exists a driver but it could not be published
 as it is based on the micronas refernce driver

 i think the problem is related to

 http://www.linuxtv.org/pipermail/linux-dvb/2008-December/030738.html

 but this new situation with
 http://www.tridentmicro.com/Product_drx_39xyK.asp

 can maby change something about this chip

 and it would be possible to get the rights to publish the driver under  
 gpl-2


This won't solve the issue that the AVFB4910 has been discontinued.
This affects FM Radio, Analogue TV, Composite and S-Video, that IC
didn't get bought by Trident.

regards,
Markus

 Did Devin Heitmueller comment on that? AFAIK he already finished a driver for 
 the DRX-3933J and I would think he might have interest to get in contact with 
 trident in order of being allowed to publish his work.
 Should be a rather small step compared to the work he has done so far.
 And Trident has some history in cooperating together with XFree developers,
 letting them develop graphics card drivers.

 What about this AVFB4910? Is it possible to get a working DVB-C/DVB-T 
 solution without getting in contact with this chip? And once this would be 
 done, there should still be the option of reverse engineering the protocol of 
 that one.


For those who are interested in such a solution:

http://support.sundtek.de/index.php/topic,2.0.html

http://sundtek.de/shop/Digital-TV-Sticks/Sundtek-MediaTV-Pro.html

There's a fully supported solution available for Linux already, it
also includes online Linux support. The installation of the drivers
can't be easier.

Best Regards,
Markus

 Meanwhile, Terratec has dicontinued the Cinergy HTC USB XS HD, but what about 
 the H5? Does anyone know about its internals already?

 AFAIK, these are still the only non-PCI DVB-C solutions on the market.

 Hmm, did micronas give up this full range of products? Sold the 'interesting' 
 part to trident and ceased production of everything else? Maybe half a year 
 ago, they didn't want to disturb ongoing selling negotiations by giving away 
 their intellectual property for free in parallel, and now, after all is 
 settled, maybe they don't mind anymore.
 So contacting those people again could be worth it, too.

 best regards,

 Raimund


 --
 Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechbergermrechber...@gmail.com wrote:
 Hey,

 [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
 [24004.018618] Vendor/Product ID= eb1a:2861
 [24004.018622] AC97 audio (5 sample rates)
 [24004.018626] 500mA max power
 [24004.018629] Table at 0x04, strings=0x206a, 0x, 0x
 [24004.049201]  failed!
 [24004.049210] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049444]  failed!
 [24004.049451] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049655]  failed!
 [24004.049659] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049891]  failed!
 [24004.049895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050141]  failed!
 [24004.050145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050393]  failed!
 [24004.050396] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050641]  failed!
 [24004.050644] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050890]  failed!
 [24004.050894] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051141]  failed!
 [24004.051145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051392]  failed!
 [24004.051395] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051641]  failed!
 [24004.051645] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051892]  failed!
 [24004.051895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052140]  failed!
 [24004.052143] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052393]  failed!
 [24004.052396] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052642]  failed!
 [24004.052645] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052892]  failed!
 [24004.052895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.057741]  failed!
 [24004.057746] em28xx #0: reading from i2c device failed (error=-71)
 [24004.057880]  failed!
 [24004.057884] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058125]  failed!
 [24004.058129] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058379]  failed!
 [24004.058383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058628]  failed!
 [24004.058633] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058880]  failed!
 [24004.058883] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059128]  failed!
 [24004.059131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059380]  failed!
 [24004.059383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059636]  failed!
 [24004.059640] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059914]  failed!
 [24004.059917] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060140]  failed!
 [24004.060145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060388]  failed!
 [24004.060392] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060636]  failed!
 [24004.060640] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060884]  failed!
 [24004.060887] em28xx #0: reading from i2c device failed (error=-71)
 [24004.061126]  failed!
 [24004.061132] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062214]  failed!
 [24004.062219] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062378]  failed!
 [24004.062383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062632]  failed!
 [24004.062636] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062884]  failed!
 [24004.062889] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063126]  failed!
 [24004.063131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063375]  failed!
 [24004.063380] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063626]  failed!
 [24004.063631] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063875]  failed!
 [24004.063880] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064127]  failed!
 [24004.064132] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064376]  failed!
 [24004.064380] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064625]  failed!
 [24004.064630] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064876]  failed!
 [24004.064881] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065126]  failed!
 [24004.065130] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065376]  failed!
 [24004.065381] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065626]  failed!
 [24004.065632] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065875]  failed!
 [24004.065880] em28xx #0: reading from i2c device failed (error=-71)
 [24004.066126]  failed!
 [24004.066131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.066376]  failed!
 [24004.066381] em28xx #0: reading from i2c device failed (error=-71)
 [24004.066625]  

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 1:41 PM, Devin
Heitmuellerdheitmuel...@kernellabs.com wrote:
 On Thu, Jul 23, 2009 at 5:40 AM, Markus Rechbergermrechber...@gmail.com 
 wrote:
 Hey,

 [24004.018614] EEPROM ID= 0x9567eb1a, hash = 0x1067368a
 [24004.018618] Vendor/Product ID= eb1a:2861
 [24004.018622] AC97 audio (5 sample rates)
 [24004.018626] 500mA max power
 [24004.018629] Table at 0x04, strings=0x206a, 0x, 0x
 [24004.049201]  failed!
 [24004.049210] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049444]  failed!
 [24004.049451] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049655]  failed!
 [24004.049659] em28xx #0: reading from i2c device failed (error=-71)
 [24004.049891]  failed!
 [24004.049895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050141]  failed!
 [24004.050145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050393]  failed!
 [24004.050396] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050641]  failed!
 [24004.050644] em28xx #0: reading from i2c device failed (error=-71)
 [24004.050890]  failed!
 [24004.050894] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051141]  failed!
 [24004.051145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051392]  failed!
 [24004.051395] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051641]  failed!
 [24004.051645] em28xx #0: reading from i2c device failed (error=-71)
 [24004.051892]  failed!
 [24004.051895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052140]  failed!
 [24004.052143] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052393]  failed!
 [24004.052396] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052642]  failed!
 [24004.052645] em28xx #0: reading from i2c device failed (error=-71)
 [24004.052892]  failed!
 [24004.052895] em28xx #0: reading from i2c device failed (error=-71)
 [24004.057741]  failed!
 [24004.057746] em28xx #0: reading from i2c device failed (error=-71)
 [24004.057880]  failed!
 [24004.057884] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058125]  failed!
 [24004.058129] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058379]  failed!
 [24004.058383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058628]  failed!
 [24004.058633] em28xx #0: reading from i2c device failed (error=-71)
 [24004.058880]  failed!
 [24004.058883] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059128]  failed!
 [24004.059131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059380]  failed!
 [24004.059383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059636]  failed!
 [24004.059640] em28xx #0: reading from i2c device failed (error=-71)
 [24004.059914]  failed!
 [24004.059917] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060140]  failed!
 [24004.060145] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060388]  failed!
 [24004.060392] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060636]  failed!
 [24004.060640] em28xx #0: reading from i2c device failed (error=-71)
 [24004.060884]  failed!
 [24004.060887] em28xx #0: reading from i2c device failed (error=-71)
 [24004.061126]  failed!
 [24004.061132] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062214]  failed!
 [24004.062219] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062378]  failed!
 [24004.062383] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062632]  failed!
 [24004.062636] em28xx #0: reading from i2c device failed (error=-71)
 [24004.062884]  failed!
 [24004.062889] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063126]  failed!
 [24004.063131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063375]  failed!
 [24004.063380] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063626]  failed!
 [24004.063631] em28xx #0: reading from i2c device failed (error=-71)
 [24004.063875]  failed!
 [24004.063880] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064127]  failed!
 [24004.064132] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064376]  failed!
 [24004.064380] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064625]  failed!
 [24004.064630] em28xx #0: reading from i2c device failed (error=-71)
 [24004.064876]  failed!
 [24004.064881] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065126]  failed!
 [24004.065130] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065376]  failed!
 [24004.065381] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065626]  failed!
 [24004.065632] em28xx #0: reading from i2c device failed (error=-71)
 [24004.065875]  failed!
 [24004.065880] em28xx #0: reading from i2c device failed (error=-71)
 [24004.066126]  failed!
 [24004.066131] em28xx #0: reading from i2c device failed (error=-71)
 [24004.066376]  failed!

Re: [linux-dvb] Terratec Cinergy HTC USB XS HD

[Markus Rechberger]

On Thu, Jul 23, 2009 at 1:51 PM, Devin
Heitmuellerdheitmuel...@kernellabs.com wrote:
 On Thu, Jul 23, 2009 at 7:10 AM, ande...@gmx.de wrote:
 Did Devin Heitmueller comment on that? AFAIK he already finished a driver 
 for the DRX-3933J and I would think he might have interest to get in contact 
 with trident in order of being allowed to publish his work.

 I was aware of the Micronas sale.  At this point I would continue to
 encourage users interested in Linux support for tuners to stay away
 from the products that include the drx-k or drx-j.


we now do offer professional Linux support for DRX-K and DRX-J devices
for customers.

Best Regards,
Markus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechbergermrechber...@gmail.com wrote:
 one thing, you might remove that autodetecting part and taking a
 footprint of unknown devices
 this causes more problems than everything else with those devices.
 Maybe make this optional if someone wants to force autodetection over
 it it might be acceptable
 but doing that by default can also heat up devices.
 Also if it thinks it has detected something, after toggling some gpios
 the footprint might look different
 again after reloading it.. it's just a failed technique doing it that way...

I agree that I'm not particularly happy with how the autodetection
logic works today.  The current logic though is based on the
power-on-reset states of the GPIOs and GPOs though, so we are only
changing the GPIOs if the board matches a known profile.

That said, unless the hardware design was laid out such that the
device would burn out if no driver were loaded at all, I think the
risk is pretty minimal for a device that does not match a known
profile.

If Empia wants to describe a better heuristic for identifying their
various hardware designs with the same USB ID but different board
layouts and GPIO configs, that would be useful information and
eliminate the need for autodetection code.

Anyway, I'll take a look at the code and see if I can determine
specifically where the errors are occurring in your case.

The fun of dealing with hardware vendors that let their customers use
default USB IDs for different hardware designs  :-)

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 2:03 PM, Devin
Heitmuellerdheitmuel...@kernellabs.com wrote:
 On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechbergermrechber...@gmail.com 
 wrote:
 one thing, you might remove that autodetecting part and taking a
 footprint of unknown devices
 this causes more problems than everything else with those devices.
 Maybe make this optional if someone wants to force autodetection over
 it it might be acceptable
 but doing that by default can also heat up devices.
 Also if it thinks it has detected something, after toggling some gpios
 the footprint might look different
 again after reloading it.. it's just a failed technique doing it that way...

 I agree that I'm not particularly happy with how the autodetection
 logic works today.  The current logic though is based on the
 power-on-reset states of the GPIOs and GPOs though, so we are only
 changing the GPIOs if the board matches a known profile.

 That said, unless the hardware design was laid out such that the
 device would burn out if no driver were loaded at all, I think the
 risk is pretty minimal for a device that does not match a known
 profile.

 If Empia wants to describe a better heuristic for identifying their
 various hardware designs with the same USB ID but different board
 layouts and GPIO configs, that would be useful information and
 eliminate the need for autodetection code.

 Anyway, I'll take a look at the code and see if I can determine
 specifically where the errors are occurring in your case.

 The fun of dealing with hardware vendors that let their customers use
 default USB IDs for different hardware designs  :-)


There's a pretty good disclosed detection from Empia available, the
linux kernel driver
just doesn't support it and very likely will never support it. Instead
of doing it the
wrong way it's better to turn it off or explicitly ask the user if he
wants to do something
undefined with his device.
The nvidia setup tools also provide an option to force it instead of
letting the software
just do whatever some developers don't know what it will cause...
You don't know what will happen to the device when doing that detection.
The initial device in question had to be replugged after we removed
the driver from the system.
You shouldn't invite people to do undefined things with their hardware
so they might break them
I think I will submit a few photos what physically can happen to the
device with wrong settings.

Markus
--
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

Problem scanning channels with s2-liplianin drivers on Terratec Cynergy C PCI HD

[Beepo / Vanguard]

Hi,

Sorry if this is cross posting. I already sent this message to linux-dvb list, 
but got a bounce from there saying that I should come here instead. So anyway 
here it goes:

I've been struggling for a while to get the channel scanning to work with my 
Terratec Cynergy C PCI HD DVB card. I'm using drivers from 
http://mercurial.intuxication.org/hg/s2-liplianin on Gentoo x86_64 system. Any 
help is greatly appreciated.

The problem might have something to do with dmesg entry: mantis_ack_wait (0): 
Slave RACK Fail !

By googling I found some patch for other card with same error message but the 
patch was quite old and didn't apply to the recent driver source.

I've tried with Gentoo genkernel (2.6.29-gentoo-r5) and with my own 
configuration (optimized for athlon64)
I've tried dvbscan that comes with gentoo pakage linuxtv-dvb-apps and with 
http://mercurial.intuxication.org/hg/scan-s2

The s2-liplianin driver for this card has worked with my previous Ubuntu 
installation few months ago.

I tried to gather as much information about the problem as I could:

http://www.vanguard.fi/terratec/dvbscan_output.txt
http://www.vanguard.fi/terratec/dmesg.txt
http://www.vanguard.fi/terratec/lspci.txt
http://www.vanguard.fi/terratec/emergeinfo.txt
http://www.vanguard.fi/terratec/kernel-config

Thank you in advance!

- Beepo
--
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

Do not restrict image buffer allocation to multiple of PAGE_SIZE

[tuukka . o . toivonen]

This patchset removes the constraint which enforced image buffer
size to be multiple of PAGE_SIZE. It improves efficiency by allowing
storing images directly to Ximage buffers removing the need to copy
image data.

It is tested with mmap and userptr methods, changes to V4L1
compatibility layer are not tested.

The first patch applies directly to the V4L2 framework, rest of the
patches make the necessary modifications also to omap34xxcam and
OMAP3 ISP drivers and require those first to be included.


--
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] omap34xxcam: each video buffer takes multiple of PAGE_SIZE bytes

[tuukka . o . toivonen]

From: Tuukka Toivonen tuukka.o.toivo...@nokia.com

When restricting the required memory for video buffers,
take into account that each buffer allocation takes multiple
of PAGE_SIZE bytes.

Signed-off-by: Tuukka Toivonen tuukka.o.toivo...@nokia.com
---
 drivers/media/video/omap34xxcam.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap34xxcam.c 
b/drivers/media/video/omap34xxcam.c
index 08d8253..be2dd2d 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -154,7 +154,8 @@ static int omap34xxcam_vbq_setup(struct videobuf_queue 
*vbq, unsigned int *cnt,
 
*size = vdev-pix.sizeimage;
 
-   while (*size * *cnt  fh-vdev-vdev_sensor_config.capture_mem)
+   while (PAGE_ALIGN(*size) * *cnt 
+  fh-vdev-vdev_sensor_config.capture_mem)
(*cnt)--;
 
return isp_vbq_setup(vdev-cam-isp, vbq, cnt, size);
-- 
1.5.4.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] v4l2: do not force buffer size to be multiple of PAGE_SIZE

[tuukka . o . toivonen]

From: Tuukka Toivonen tuukka.o.toivo...@nokia.com

When the image size (bytesperline*height) is not multiple
of PAGE_SIZE, v4l2 rounded the required buffer size to
be multiple of PAGE_SIZE. This prevented user space
to store images directly into userptr buffers which were
not multiple of PAGE_SIZE. This constraint is removed.

The start address is still assumed to be required
page-aligned, ie., when v4l2 allocates mmap buffers,
the offset between different buffers is page-aligned.

Signed-off-by: Tuukka Toivonen tuukka.o.toivo...@nokia.com
---
 drivers/media/video/videobuf-core.c   |7 +++
 drivers/media/video/videobuf-dma-sg.c |4 ++--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index b7b0584..0b18ac2 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -358,7 +358,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
q-bufs[i]-bsize  = bsize;
switch (memory) {
case V4L2_MEMORY_MMAP:
-   q-bufs[i]-boff  = bsize * i;
+   q-bufs[i]-boff = PAGE_ALIGN(bsize) * i;
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
@@ -428,9 +428,8 @@ int videobuf_reqbufs(struct videobuf_queue *q,
count = VIDEO_MAX_FRAME;
size = 0;
q-ops-buf_setup(q, count, size);
-   size = PAGE_ALIGN(size);
dprintk(1, reqbufs: bufs=%d, size=0x%x [%d pages total]\n,
-   count, size, (count*size)PAGE_SHIFT);
+   count, size, (count*PAGE_ALIGN(size))PAGE_SHIFT);
 
retval = __videobuf_mmap_setup(q, count, size, req-memory);
if (retval  0) {
@@ -1096,7 +1095,7 @@ int videobuf_cgmbuf(struct videobuf_queue *q,
mbuf-size   = 0;
for (i = 0; i  mbuf-frames; i++) {
mbuf-offsets[i]  = q-bufs[i]-boff;
-   mbuf-size   += q-bufs[i]-bsize;
+   mbuf-size   += PAGE_ALIGN(q-bufs[i]-bsize);
}
 
return 0;
diff --git a/drivers/media/video/videobuf-dma-sg.c 
b/drivers/media/video/videobuf-dma-sg.c
index 21d979f..2a8ade7 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -588,7 +588,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
retval = -EBUSY;
goto done;
}
-   size += q-bufs[last]-bsize;
+   size += PAGE_ALIGN(q-bufs[last]-bsize);
if (size == (vma-vm_end - vma-vm_start))
break;
}
@@ -610,7 +610,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
continue;
q-bufs[i]-map   = map;
q-bufs[i]-baddr = vma-vm_start + size;
-   size += q-bufs[i]-bsize;
+   size += PAGE_ALIGN(q-bufs[i]-bsize);
}
 
map-count= 1;
-- 
1.5.4.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] isp: do not force buffer size to be multiple of PAGE_SIZE

[tuukka . o . toivonen]

From: Tuukka Toivonen tuukka.o.toivo...@nokia.com


Signed-off-by: Tuukka Toivonen tuukka.o.toivo...@nokia.com
---
 drivers/media/video/isp/isp.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/isp/isp.c b/drivers/media/video/isp/isp.c
index ab40110..809b846 100644
--- a/drivers/media/video/isp/isp.c
+++ b/drivers/media/video/isp/isp.c
@@ -1309,8 +1309,7 @@ static int isp_try_pipeline(struct device *dev,
}
 
pix_output-field = V4L2_FIELD_NONE;
-   pix_output-sizeimage =
-   PAGE_ALIGN(pix_output-bytesperline * pix_output-height);
+   pix_output-sizeimage = pix_output-bytesperline * pix_output-height;
pix_output-priv = 0;
 
for (ifmt = 0; ifmt  NUM_ISP_CAPTURE_FORMATS; ifmt++) {
-- 
1.5.4.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

Re: em28xx driver crashes device

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@gmail.com wrote:
 There's a pretty good disclosed detection from Empia available, the
 linux kernel driver
 just doesn't support it and very likely will never support it. Instead
 of doing it the
 wrong way it's better to turn it off or explicitly ask the user if he
 wants to do something
 undefined with his device.
 The nvidia setup tools also provide an option to force it instead of
 letting the software
 just do whatever some developers don't know what it will cause...
 You don't know what will happen to the device when doing that detection.
 The initial device in question had to be replugged after we removed
 the driver from the system.
 You shouldn't invite people to do undefined things with their hardware
 so they might break them
 I think I will submit a few photos what physically can happen to the
 device with wrong settings.

Well, if there is a known heuristic, I would be very happy to get rid
of the autodetection logic.  I haven't looked at the Empia code in
months so I should probably do that.

Since I used to design hardware for a living, I am quite familiar with
what can happen with incorrect GPIOs so I do not believe you need to
attempt to convince me with photos, which is why I am in favor of
removing the logic in question.  We just need to figure out how to do
it without causing a regression in current device support.

Interesting...  I took a quick look at the code, and it seems like the
USB errors occur before we change any GPIOs, and more interesting it
appears that the em2861 itself is wedged (which I believe is the first
time I've seen that).  The code in the log above suggests that the
autodetection concluded that the profile was not known, so it did not
arbitrarily pick some incorrect device.  I am a bit surprised that
just reading the eeprom once and doing a scan of the i2c bus would
wedge the chip.

Is there any information you can give about the board in question in
terms of what product it is or what components it contains?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx driver crashes device

[Markus Rechberger]

On Thu, Jul 23, 2009 at 4:05 PM, Devin
Heitmuellerdheitmuel...@kernellabs.com wrote:
 On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@gmail.com 
 wrote:
 There's a pretty good disclosed detection from Empia available, the
 linux kernel driver
 just doesn't support it and very likely will never support it. Instead
 of doing it the
 wrong way it's better to turn it off or explicitly ask the user if he
 wants to do something
 undefined with his device.
 The nvidia setup tools also provide an option to force it instead of
 letting the software
 just do whatever some developers don't know what it will cause...
 You don't know what will happen to the device when doing that detection.
 The initial device in question had to be replugged after we removed
 the driver from the system.
 You shouldn't invite people to do undefined things with their hardware
 so they might break them
 I think I will submit a few photos what physically can happen to the
 device with wrong settings.

 Well, if there is a known heuristic, I would be very happy to get rid
 of the autodetection logic.  I haven't looked at the Empia code in
 months so I should probably do that.

 Since I used to design hardware for a living, I am quite familiar with
 what can happen with incorrect GPIOs so I do not believe you need to
 attempt to convince me with photos, which is why I am in favor of
 removing the logic in question.  We just need to figure out how to do
 it without causing a regression in current device support.

 Interesting...  I took a quick look at the code, and it seems like the
 USB errors occur before we change any GPIOs, and more interesting it
 appears that the em2861 itself is wedged (which I believe is the first
 time I've seen that).  The code in the log above suggests that the
 autodetection concluded that the profile was not known, so it did not
 arbitrarily pick some incorrect device.  I am a bit surprised that
 just reading the eeprom once and doing a scan of the i2c bus would
 wedge the chip.

 Is there any information you can give about the board in question in
 terms of what product it is or what components it contains?


it was a simple TVP5150 based device...

I do not mean my old code either it's also a failure as I got more information
for the new driver after we dropped the old project.
As you know the new driver is entirely in Userpace and supported by all involved
chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack.

Also vendors have a very low interest in supporting those devices in Kernelspace
as installing devices which should be sold now are not supported by
any distributions.
Devices which have been sold one year ago have a very low till no
motivation anymore.
Most people are simply not able to compile the drivers and/or prepare
the kernel development
environment just for installing and using a TV Card.

Regards,
Markus
--
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] Terratec Cinergy HTC USB XS HD

[Markus Rechberger]

On Thu, Jul 23, 2009 at 4:39 PM, Benny Amorsenbenny+use...@amorsen.dk wrote:
 Markus Rechberger mrechber...@gmail.com writes:

 For those who are interested in such a solution:

 http://support.sundtek.de/index.php/topic,2.0.html

 http://sundtek.de/shop/Digital-TV-Sticks/Sundtek-MediaTV-Pro.html

 This doesn't appear to have any support for CA modules? DVB-C is not
 very useful around here without a CAM...


We are currently discussing this with one of our partners as the
situation changed
with having everything in userspace the devices will usually have
manufacturer support.

 There's a fully supported solution available for Linux already, it
 also includes online Linux support. The installation of the drivers
 can't be easier.

 I have to admit that it is cool that the driver is in user space. How
 about getting it included in the various Linux distributions?


We do not aim to include the drivers in any distribution as we can
keep control on driver updates
any time.
The driver can be downloaded on our site.
It is tested with various Linuxversions between 2.6.15 and 2.6.30 (32
and 64bit).
The entire system can coexist with already available Kerneldrivers
(eg. linuxuvc driver), but it
does not need any video4linux or dvb support in the kernel to be supported.
It makes installing videodrivers a totally new experience, doable
within a few seconds on
most systems.

Best Regards,
Markus
--
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] Terratec Cinergy HTC USB XS HD

[Benny Amorsen]

Markus Rechberger mrechber...@gmail.com writes:

 For those who are interested in such a solution:

 http://support.sundtek.de/index.php/topic,2.0.html

 http://sundtek.de/shop/Digital-TV-Sticks/Sundtek-MediaTV-Pro.html

This doesn't appear to have any support for CA modules? DVB-C is not
very useful around here without a CAM...

 There's a fully supported solution available for Linux already, it
 also includes online Linux support. The installation of the drivers
 can't be easier.

I have to admit that it is cool that the driver is in user space. How
about getting it included in the various Linux distributions?


/Benny

--
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] Terratec Cinergy HTC USB XS HD

[Benny Amorsen]

ande...@gmx.de writes:

 AFAIK, these are still the only non-PCI DVB-C solutions on the market.

The FireDTV is still for sale and works quite well at least for
unencrypted channels.

I have ordered a decoder card; it will be interesting to see whether
that works too.


/Benny

--
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] Siano: Read buffer overflow

[Roel Kluin]

With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
This can be reached only when coredev-device_flags contains SMS_DEVICE_FAMILY2,
codedev-modes_supported does not include the DEVICE_MODE_RAW_TUNER bit flag,
and the initial attempt to load firmware. Can this happen in practice on the
hardware in question?

diff --git a/drivers/media/dvb/siano/smscoreapi.c 
b/drivers/media/dvb/siano/smscoreapi.c
index a246903..bd9ab9d 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -816,7 +816,7 @@ int smscore_set_device_mode(struct smscore_device_t 
*coredev, int mode)
 
sms_debug(set device mode to %d, mode);
if (coredev-device_flags  SMS_DEVICE_FAMILY2) {
-   if (mode  DEVICE_MODE_DVBT || mode  DEVICE_MODE_RAW_TUNER) {
+   if (mode  DEVICE_MODE_DVBT || mode = DEVICE_MODE_RAW_TUNER) {
sms_err(invalid mode specified %d, mode);
return -EINVAL;
}
--
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: WARNINGS, 2.6.16-2.6.21: ERRORS

[Hans Verkuil]

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 Jul 23 19:00:03 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   12324:6477aa1782d5
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.31-rc3-armv5: OK
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29.1-armv5-ixp: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-rc3-armv5-ixp: OK
linux-2.6.28-armv5-omap2: OK
linux-2.6.29.1-armv5-omap2: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-rc3-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: OK
linux-2.6.30-i686: WARNINGS
linux-2.6.31-rc3-i686: OK
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.31-rc3-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-rc3-mips: WARNINGS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-rc3-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: OK
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-rc3-x86_64: OK
sparse (linux-2.6.30): OK
sparse (linux-2.6.31-rc3): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

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 V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
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] DVB-T support for Pinnacle PCTV Hybrid Pro Stick

[Devin Heitmueller]

On Thu, Jul 23, 2009 at 2:32 PM, Angelo Fontanafont...@gmail.com wrote:
 Hi,
 I'm trying to use my USB PTCV with linux (Debian Lenny).
 After compiling, installing the latest version of v4l-dvb drivers and
 loading em28xx-dvb module i can't use DVB features of the device.

 This is the output of dmesg:
snip
 Something wrong in my configuration?
 Is there any plan for a support of Pinnacle PCTV Hybrid Stick Pro in linux?

 Thanks and regards.
 Angelo Fontana.

The 330e is on the list of devices I am actively working on and I hope
to have something committed in the next couple of weeks (the DVB side
is known to not be working currently).

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: em28xx driver crashes device

[Mauro Carvalho Chehab]

Em Thu, 23 Jul 2009 16:29:02 +0200
Markus Rechberger mrechber...@gmail.com escreveu:

 On Thu, Jul 23, 2009 at 4:05 PM, Devin
 Heitmuellerdheitmuel...@kernellabs.com wrote:
  On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechbergermrechber...@gmail.com 
  wrote:
  There's a pretty good disclosed detection from Empia available, the
  linux kernel driver
  just doesn't support it and very likely will never support it. Instead
  of doing it the
  wrong way it's better to turn it off or explicitly ask the user if he
  wants to do something
  undefined with his device.
  The nvidia setup tools also provide an option to force it instead of
  letting the software
  just do whatever some developers don't know what it will cause...
  You don't know what will happen to the device when doing that detection.
  The initial device in question had to be replugged after we removed
  the driver from the system.
  You shouldn't invite people to do undefined things with their hardware
  so they might break them
  I think I will submit a few photos what physically can happen to the
  device with wrong settings.
 
  Well, if there is a known heuristic, I would be very happy to get rid
  of the autodetection logic.  I haven't looked at the Empia code in
  months so I should probably do that.
 
  Since I used to design hardware for a living, I am quite familiar with
  what can happen with incorrect GPIOs so I do not believe you need to
  attempt to convince me with photos, which is why I am in favor of
  removing the logic in question.  We just need to figure out how to do
  it without causing a regression in current device support.
 
  Interesting...  I took a quick look at the code, and it seems like the
  USB errors occur before we change any GPIOs, and more interesting it
  appears that the em2861 itself is wedged (which I believe is the first
  time I've seen that).  The code in the log above suggests that the
  autodetection concluded that the profile was not known, so it did not
  arbitrarily pick some incorrect device.  I am a bit surprised that
  just reading the eeprom once and doing a scan of the i2c bus would
  wedge the chip.
 
  Is there any information you can give about the board in question in
  terms of what product it is or what components it contains?
 
 
 it was a simple TVP5150 based device...
 
 I do not mean my old code either it's also a failure as I got more information
 for the new driver after we dropped the old project.
 As you know the new driver is entirely in Userpace and supported by all 
 involved
 chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack.
 
 Also vendors have a very low interest in supporting those devices in 
 Kernelspace
 as installing devices which should be sold now are not supported by
 any distributions.
 Devices which have been sold one year ago have a very low till no
 motivation anymore.
 Most people are simply not able to compile the drivers and/or prepare
 the kernel development
 environment just for installing and using a TV Card.

PLEASE STOP WITH FUD. THIS FORUM IS FOR OPEN SOURCE DRIVER DISCUSSION. AS YOU
DECIDED TO GO TO THE DARK SIDE, PLEASE STOP POSTING HERE OR AT THE OPEN SOURCE 
#IRC CHANNEL.

Thanks.
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

[PATCH] Read buffer overflow

[Roel Kluin]

parport[n] is checked before n  MAX_CAMS

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
probably harmless

diff --git a/drivers/media/video/bw-qcam.c b/drivers/media/video/bw-qcam.c
index 10dbd4a..9e39bc5 100644
--- a/drivers/media/video/bw-qcam.c
+++ b/drivers/media/video/bw-qcam.c
@@ -992,7 +992,7 @@ static int accept_bwqcam(struct parport *port)
 
if (parport[0]  strncmp(parport[0], auto, 4) != 0) {
/* user gave parport parameters */
-   for(n=0; parport[n]  nMAX_CAMS; n++){
+   for (n = 0; n  MAX_CAMS  parport[n]; n++) {
char *ep;
unsigned long r;
r = simple_strtoul(parport[n], ep, 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] ivtv: Read buffer overflow

[Roel Kluin]

This mistakenly tests against sizeof(freqs) instead of the array size. Due to
the mask the only illegal value possible was 3.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/video/ivtv/ivtv-controls.c 
b/drivers/media/video/ivtv/ivtv-controls.c
index a3b77ed..4a9c8ce 100644
--- a/drivers/media/video/ivtv/ivtv-controls.c
+++ b/drivers/media/video/ivtv/ivtv-controls.c
@@ -17,6 +17,7 @@
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
+#include linux/kernel.h
 
 #include ivtv-driver.h
 #include ivtv-cards.h
@@ -281,7 +282,7 @@ int ivtv_s_ext_ctrls(struct file *file, void *fh, struct 
v4l2_ext_controls *c)
idx = p.audio_properties  0x03;
/* The audio clock of the digitizer must match the codec sample
   rate otherwise you get some very strange effects. */
-   if (idx  sizeof(freqs))
+   if (idx  ARRAY_SIZE(freqs))
ivtv_call_all(itv, audio, s_clock_freq, freqs[idx]);
return err;
}
--
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

New tree with final (?) string control implementation

[Hans Verkuil]

Hi Eduardo,

I've prepared a new tree:

http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-strctrl

This contains the full string control implementation, including updates to 
the v4l2-spec, based on the RFC that I posted on Monday.

Can you prepare your si4713 patches against this tree and verify that 
everything is working well?

If it is, then I can make a pull request for this tree and soon after that 
you should be able to merge your si4713 driver as well. If I'm not mistaken 
the string controls API is the only missing bit that prevents your driver 
from being merged.

Thanks,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] V4L/DVB: dm646x: fix DMA_nnBIT_MASK

[Kevin Hilman]

Fix deprecated use of DMA_nnBIT_MASK which now gives a compiler
warning.

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
This compiler warning patch is on top of the master branch of Mauro's 
linux-next tree.

 arch/arm/mach-davinci/dm646x.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 73a7e8b..8f38371 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -720,7 +720,7 @@ static struct platform_device vpif_display_dev = {
.id = -1,
.dev= {
.dma_mask   = vpif_dma_mask,
-   .coherent_dma_mask  = DMA_32BIT_MASK,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
},
.resource   = vpif_resource,
.num_resources  = ARRAY_SIZE(vpif_resource),
-- 
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

Re: [Bug 13708] Aiptek DV-T300 support is incomplete

[Andrew Morton]

On Mon, 20 Jul 2009 22:37:08 +0200
Bal__zs H__morszky bal...@gmail.com wrote:

 I don't have my kernel tree with me (I'm at vacation atm.). The patch
 is made with only the -uN options, but I can make a new one on Friday
 (if needed).
 

The patch doesn't apply to current kernels and fixing it looks non-trivial.

There's no hurry - please email us a complete (tested, changelogged,
signed-off) patch when you have time to get onto it, 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

Re: [PATCH] ivtv: Read buffer overflow

[Andy Walls]

On Thu, 2009-07-23 at 23:31 +0200, Roel Kluin wrote:
 This mistakenly tests against sizeof(freqs) instead of the array size. Due to
 the mask the only illegal value possible was 3.
 
 Signed-off-by: Roel Kluin roel.kl...@gmail.com

Acked-by: Andy Walls awa...@radix.net

The cx18 driver suffers from the exact same defect in cx18-controls.c.

 ---
 diff --git a/drivers/media/video/ivtv/ivtv-controls.c 
 b/drivers/media/video/ivtv/ivtv-controls.c
 index a3b77ed..4a9c8ce 100644
 --- a/drivers/media/video/ivtv/ivtv-controls.c
 +++ b/drivers/media/video/ivtv/ivtv-controls.c
 @@ -17,6 +17,7 @@
  along with this program; if not, write to the Free Software
  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
   */
 +#include linux/kernel.h
  
  #include ivtv-driver.h
  #include ivtv-cards.h
 @@ -281,7 +282,7 @@ int ivtv_s_ext_ctrls(struct file *file, void *fh, struct 
 v4l2_ext_controls *c)
   idx = p.audio_properties  0x03;
   /* The audio clock of the digitizer must match the codec sample
  rate otherwise you get some very strange effects. */
 - if (idx  sizeof(freqs))
 + if (idx  ARRAY_SIZE(freqs))
   ivtv_call_all(itv, audio, s_clock_freq, freqs[idx]);
   return err;
   }
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

[Andy Walls]

On Wed, 2009-07-22 at 20:33 -0400, Andy Walls wrote:
 Mauro,
 
 Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb
 
 for the following 3 changesets:
[snip]
 Many thanks to Ravi A. for doing work to get information to better
 support AVerMedia cards with a M113 PCB, testing the changes, and
 troubleshooting the errant audio input switch on a video standard
 change.

Mauro,

I'm adding the {ivtv,cx18}-controls.c bug pointed by Roel Kluin to my
previous PULL request.

Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb

for the following 5 changesets:

01/05: tuner-simple: Add an entry for the Partsnic PTI-5NF05 NTSC tuner
http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=41ff81d0ec9e

02/05: ivtv: Fix errors in AVerTV M113 card definitions and add a new M113 card
http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=035747b98b61

03/05: ivtv: Fix improper GPIO audio mux input switch on video standard change
http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=892610bec939

04/05: ivtv: Read buffer overflow
http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=f8c53e25ce11

05/05: cx18: Read buffer overflow
http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=83131c18cb5f


 Documentation/video4linux/CARDLIST.tuner  |1 
 drivers/media/common/tuners/tuner-types.c |   25 ++
 drivers/media/video/cx18/cx18-controls.c  |3 +-
 drivers/media/video/ivtv/ivtv-cards.c |   33 +-
 drivers/media/video/ivtv/ivtv-controls.c  |3 +-
 drivers/media/video/ivtv/ivtv-gpio.c  |   13 ---
 include/media/tuner.h |1 
 7 files changed, 50 insertions(+), 29 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

TBS 8920 still fails to initialize - cx24116_readreg error

[Mark Zimmerman]

Greetings:

Using current current v4l-dvb drivers, I get the following in the
dmesg:

cx88[1]/2: subsystem: 8920:, board: TBS 8920 DVB-S/S2 [card=72]
cx88[1]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
cx24116_readreg: reg=0xff (error=-6)
cx24116_readreg: reg=0xfe (error=-6)
Invalid probe, probably not a CX24116 device
cx88[1]/2: frontend initialization failed
cx88[1]/2: dvb_register failed (err = -22)
cx88[1]/2: cx8802 probe failed, err = -22

Does this mean that one of the chips on this card is different than
expected? How can I gather useful information about this?

-- Mark

--
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

Problem with My Tuner card

[unni krishnan]

Hi All,

I have some problem in getting my tuner card working in Linux. The
dmesg look like

###
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: LifeView FlyTV Platinum FM /
Gold [card=54,insmod option]
saa7130[0]: board init: gpio is 804000
input: saa7134 IR (LifeView FlyTV Plat as
/devices/pci:00/:00:04.0/:01:07.0/input/input7
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
saa7130[0]: registered device radio0
tuner-simple 2-0060: destroying instance
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: Items MuchTV Plus / IT-005
[card=37,insmod option]
saa7130[0]: board init: gpio is 81
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
saa7130[0]: registered device radio0
tuner-simple 2-0060: destroying instance
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: Pinnacle PCTV Stereo
(saa7134) [card=26,insmod option]
saa7130[0]: board init: gpio is 81
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
tuner-simple 2-0060: destroying instance
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: LifeView FlyTV Platinum FM /
Gold [card=54,insmod option]
saa7130[0]: board init: gpio is 81
input: saa7134 IR (LifeView FlyTV Plat as
/devices/pci:00/:00:04.0/:01:07.0/input/input8
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
saa7130[0]: registered device radio0
tuner-simple 2-0060: destroying instance
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: Items MuchTV Plus / IT-005
[card=37,insmod option]
saa7130[0]: board init: gpio is 81
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
saa7130[0]: registered device radio0
tuner-simple 2-0060: destroying instance
saa7130/34: v4l2 driver version 0.2.15 loaded
saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
0xd800
saa7130[0]: subsystem: 1131:, board: LifeView/Typhoon FlyVIDEO2000
[card=3,insmod option]
saa7130[0]: board init: gpio is 81
saa7130[0]: there are different flyvideo cards with different tuners
saa7130[0]: out there, you might have to use the tuner=nr insmod
saa7130[0]: option to override the default value.
input: saa7134 IR (LifeView/Typhoon Fl as
/devices/pci:00/:00:04.0/:01:07.0/input/input9
IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7130[0]: Huh, no eeprom present (err=-5)?
All bytes are equal. It is not a TEA5767
tuner 2-0060: chip found @ 0xc0 (saa7130[0])
tuner-simple 2-0060: creating new instance
tuner-simple 2-0060: type set to 69 (Tena TNF 5335 and similar models)
saa7130[0]: registered device video0 [v4l2]
saa7130[0]: registered device vbi0
saa7130[0]: registered device radio0
tuner-simple 2-0060: destroying instance

Re: Problem with My Tuner card

[hermann pitton]

Am Freitag, den 24.07.2009, 09:32 +0530 schrieb unni krishnan:
 Hi All,
 
 I have some problem in getting my tuner card working in Linux. The
 dmesg look like
 
 ###
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: LifeView FlyTV Platinum FM /
 Gold [card=54,insmod option]
 saa7130[0]: board init: gpio is 804000
 input: saa7134 IR (LifeView FlyTV Plat as
 /devices/pci:00/:00:04.0/:01:07.0/input/input7
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 saa7130[0]: registered device video0 [v4l2]
 saa7130[0]: registered device vbi0
 saa7130[0]: registered device radio0
 tuner-simple 2-0060: destroying instance
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: Items MuchTV Plus / IT-005
 [card=37,insmod option]
 saa7130[0]: board init: gpio is 81
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 saa7130[0]: registered device video0 [v4l2]
 saa7130[0]: registered device vbi0
 saa7130[0]: registered device radio0
 tuner-simple 2-0060: destroying instance
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: Pinnacle PCTV Stereo
 (saa7134) [card=26,insmod option]
 saa7130[0]: board init: gpio is 81
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 saa7130[0]: registered device video0 [v4l2]
 saa7130[0]: registered device vbi0
 tuner-simple 2-0060: destroying instance
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: LifeView FlyTV Platinum FM /
 Gold [card=54,insmod option]
 saa7130[0]: board init: gpio is 81
 input: saa7134 IR (LifeView FlyTV Plat as
 /devices/pci:00/:00:04.0/:01:07.0/input/input8
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 saa7130[0]: registered device video0 [v4l2]
 saa7130[0]: registered device vbi0
 saa7130[0]: registered device radio0
 tuner-simple 2-0060: destroying instance
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: Items MuchTV Plus / IT-005
 [card=37,insmod option]
 saa7130[0]: board init: gpio is 81
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
 saa7130[0]: registered device video0 [v4l2]
 saa7130[0]: registered device vbi0
 saa7130[0]: registered device radio0
 tuner-simple 2-0060: destroying instance
 saa7130/34: v4l2 driver version 0.2.15 loaded
 saa7130[0]: found at :01:07.0, rev: 1, irq: 18, latency: 64, mmio:
 0xd800
 saa7130[0]: subsystem: 1131:, board: LifeView/Typhoon FlyVIDEO2000
 [card=3,insmod option]
 saa7130[0]: board init: gpio is 81
 saa7130[0]: there are different flyvideo cards with different tuners
 saa7130[0]: out there, you might have to use the tuner=nr insmod
 saa7130[0]: option to override the default value.
 input: saa7134 IR (LifeView/Typhoon Fl as
 /devices/pci:00/:00:04.0/:01:07.0/input/input9
 IRQ 18/saa7130[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7130[0]: Huh, no eeprom present (err=-5)?
 All bytes are equal. It is not a TEA5767
 tuner 2-0060: chip found @ 0xc0 (saa7130[0])
 tuner-simple 2-0060: creating new instance
 tuner-simple 2-0060: type set to 69 (Tena TNF 5335 and