Re: [linux-dvb] [patch] Improvement dvb-s2 lock with KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
jlac vdr wrote: > Hi, > > This is a patch which improve locking on dvb-s2 channels for card > using stb0899 (KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat > DVB-S2) > Can you please explain what your patch is trying to do ? I couldn't understand what you are trying to do. Also did you check with the KNC1 and the Satelco cards whether your patch, brings in an improvement on the LOCK 'ing ? If so, what improvement do you see ? With the current tree i get a lock within less than half a second. ~ 300 - 400 mS. (A bit hard to measure) Do you get a LOCK faster than that ? Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] DVB-T scan file for de-Brocken_Magdeburg
Hi, attached to this mail please find the scan file for dvbscan for the region Brocken/Harz/Magdeburg-Stadt (Mt. Brocken / Harz Mountain Area / Magdeburg-City, western part of Saxony-Anhalt in Germany). Official lauch is today (October 9, 2007); broadcasting has already started. There are two locations with the same specifications: - from Mt. Brocken and - from within the city of Magdeburg Scan file derived from following technical information at: http://www.dvbt-mitteldeutschland.de/index.php?content=Programme&menu=Technische®ion=MD Analogue transmissions from Brocken will be discontinued, and also from the following fill-in transmitters: http://www.dvbt-mitteldeutschland.de/Presse/download/071009_TVU_Abschaltungen_MDR_ARD_ZDF.pd Kind regards, Tobias # DVB-T Brocken/Magdeburg (Germany) # Generated by Tobias Stoeber <[EMAIL PROTECTED]> # info from: http://www.dvbt-mitteldeutschland.de/index.php?content=Programme&menu=Technische®ion=MD T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH29: ARD Das Erste, EinsFestival, arte, Phoenix (TSMB/MDR1.1) T 54600 8MHz 2/3 NONE QAM16 8k 1/4 NONE # CH30: 3sat, ZDFDoku/KIKA, ZDF, ZDFInfo (ZDF) T 57800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # CH34: MDR S-ANHALT, rbb Brandenburg, WDR Koeln, NDR FS NDS (TSMB/MDR2.2) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re : TT S-1500 CI not finding fro ntend driver
Just to add another problem: it was working great, I watched TV and dumped some channels to do some epg work and then at some point it issued an "Invalid PC Card insterted", whereas I did not insert/eject it, and now I tried to insert/eject it several times with no succes, each time it says "Invalid...". So I rebooted and now nothing: no message about CAM even if I insert/eject it, nothing (dvb_core has cam_debug=1 option), but frontend seems to work beautifully though as szap gets a lock on any channel. Arghh, please tell me that you can help me before I have no more hair left ;-) Thx Bye Manu ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] New card for http://www.bttv-gallery.de/
On 10/8/07, David Campbell <[EMAIL PROTECTED]> wrote: > Aidan Thornton wrote: > > On 10/6/07, David Campbell <[EMAIL PROTECTED]> wrote: > > > >> Nils Kassube wrote: > >> > >>> There is a new version of sniffusb available here: > >>> > >>> http://www.pcausa.com/Utilities/UsbSnoop/default.htm > >>> > >>> That version lets you set a refresh interval and even disable refresh of > >>> the display. > >>> > >> Great! Thanks for that. The usb capture works very well with that. > >> Much better. > >> > >> I've now captured about 260Mb of log output on XP and then processed to > >> http://www.aaa.net.au/campbell/analyzed.log > >> > > > > Okay - looks like an xc3028 tuner, tuner reset GPIO 6f/7f, slightly > > unusual GPIO init. Probably needs a new card type (the Terratec > > Cinergy T XS is closest, but doesn't have the same GPIO init). > > > Thanks for the info. > > Is the 6f/7f GPIO init easy enough to handle in code? Should be. (The GPIO init is actually 0x7e, 0x5e, 0x7e for some reason - totally different from all the other cards). > Are you interested in whipping up something that might work? I'm happy > to test and provide feedback if you are. Try the code from http://www.makomk.com/hg/v4l-dvb-makomk with card=62. (I'm not sure how to detect the card type automatically.) Aidan ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [patch] Improvement dvb-s2 lock with KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Hi,
This is a patch which improve locking on dvb-s2 channels for card
using stb0899 (KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat
DVB-S2)
Regards,
JLac
--- linux/drivers/media/dvb/frontends/stb0899_algo.c.org 2007-10-08 21:25:09.0 +0200
+++ linux/drivers/media/dvb/frontends/stb0899_algo.c 2007-10-08 21:25:06.0 +0200
@@ -1351,7 +1351,17 @@
s32 offsetfreq, searchTime, FecLockTime, pilots, iqSpectrum;
int i = 0;
+int cpt = 0;
u32 reg, csm1;
+s32 retry = 0;
+
+
+reg = STB0899_READ_S2REG( STB0899_S2DEMOD, DMD_CNTRL2 );
+STB0899_SETFIELD_VAL( SPECTRUM_INVERT, reg, 1 );
+stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_DMD_CNTRL2, STB0899_OFF0_DMD_CNTRL2, reg );
+
+do
+{
if (internal->srate <= 200) {
searchTime = 5000; /* 5000 ms max time to lock UWP and CSM, SYMB <= 2Mbs */
@@ -1381,9 +1391,16 @@
STB0899_SETFIELD_VAL(FRESRS, reg, 1);
stb0899_write_reg(state, STB0899_TSTRES, reg);
+reg = STB0899_READ_S2REG( STB0899_S2DEMOD, CRL_NOM_FREQ );
+STB0899_SETFIELD_VAL( CRL_NOM_FREQ, reg, 0xd0 );
+stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_CRL_NOM_FREQ, STB0899_OFF0_CRL_NOM_FREQ, 0xd0 );
+
/* Move tuner to frequency */
if (state->config->tuner_set_frequency)
state->config->tuner_set_frequency(&state->frontend, internal->freq);
+
+msleep( 100 );
+
if (state->config->tuner_get_frequency)
state->config->tuner_get_frequency(&state->frontend, &internal->freq);
@@ -1400,23 +1417,13 @@
/* Initialisation */
stb0899_dvbs2_init_calc(state);
- reg = STB0899_READ_S2REG(STB0899_S2DEMOD, DMD_CNTRL2);
- switch (internal->inversion) {
- case IQ_SWAP_OFF:
- STB0899_SETFIELD_VAL(SPECTRUM_INVERT, reg, 0);
- break;
- case IQ_SWAP_ON:
- STB0899_SETFIELD_VAL(SPECTRUM_INVERT, reg, 1);
- break;
- case IQ_SWAP_AUTO: /* use last successful search first */
- STB0899_SETFIELD_VAL(SPECTRUM_INVERT, reg, 1);
- break;
- }
- stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_DMD_CNTRL2, STB0899_OFF0_DMD_CNTRL2, reg);
+stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_DMD_CNTRL2, STB0899_OFF0_DMD_CNTRL, 0x0005 );
+
stb0899_dvbs2_reacquire(state);
/* Wait for demod lock (UWP and CSM) */
internal->status = stb0899_dvbs2_get_dmd_status(state, searchTime);
+cpt++;
if (internal->status == DVBS2_DEMOD_LOCK) {
dprintk(state->verbose, FE_DEBUG, 1, "> DVB-S2 DEMOD LOCK !");
@@ -1432,51 +1439,28 @@
/* Set the Nominal frequency to the found frequency offset for the next reacquire*/
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_NOM_FREQ);
STB0899_SETFIELD_VAL(CRL_NOM_FREQ, reg, offsetfreq);
- stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_CRL_NOM_FREQ, STB0899_OFF0_CRL_NOM_FREQ, reg);
+stb0899_write_s2reg( state, STB0899_S2DEMOD, STB0899_BASE_CRL_NOM_FREQ,
+ STB0899_OFF0_CRL_NOM_FREQ, offsetfreq );
stb0899_dvbs2_reacquire(state);
internal->status = stb0899_dvbs2_get_fec_status(state, searchTime);
i++;
}
}
- if (internal->status != DVBS2_FEC_LOCK) {
- if (internal->inversion == IQ_SWAP_AUTO) {
+if( internal->status != DVBS2_FEC_LOCK )
+{
+/* IQ Inversion */
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, DMD_CNTRL2);
iqSpectrum = STB0899_GETFIELD(SPECTRUM_INVERT, reg);
/* IQ Spectrum Inversion */
STB0899_SETFIELD_VAL(SPECTRUM_INVERT, reg, !iqSpectrum);
stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_DMD_CNTRL2, STB0899_OFF0_DMD_CNTRL2, reg);
- /* start acquistion process */
- stb0899_dvbs2_reacquire(state);
- /* Wait for demod lock (UWP and CSM) */
- internal->status = stb0899_dvbs2_get_dmd_status(state, searchTime);
- if (internal->status == DVBS2_DEMOD_LOCK) {
-i = 0;
-/* Demod Locked, check FEC */
-internal->status = stb0899_dvbs2_get_fec_status(state, FecLockTime);
-/*try thrice for false locks, (UWP and CSM Locked but no FEC) */
-while ((internal->status != DVBS2_FEC_LOCK) && (i < 3)) {
- /* Read the frequency offset*/
- offsetfreq = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_FREQ);
+}
+else
+{
- /* Set the Nominal frequency to the found frequency offset for the next reacquire*/
- reg = STB0899_READ_S2REG(STB0899_S2DEMOD, CRL_NOM_FREQ);
- STB0899_SETFIELD_VAL(CRL_NOM_FREQ, reg, offsetfreq);
- stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_CRL_NOM_FREQ, STB0899_OFF0_CRL_NOM_FREQ, reg);
- stb0899_dvbs2_reacquire(state);
- internal->status = stb0899_dvbs2_get_fec_status(state, searchTime);
- i++;
-}
- }
-/*
- if (pParams->DVBS2State == FE_DVBS2_FEC_LOCKED)
-pParams->IQLocked = !iqSpectrum;
-*/
- }
- }
- if (internal->status == DVBS2_FEC_LOCK) {
dprintk(state->verbose, FE_DEBUG, 1, "> DVB-S2 FEC Lock !");
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, UWP_STAT2);
modcod
[linux-dvb] TT S-1500 CI not finding frontend driver
Hi ,all I have the following problem with a TT S-1500 CI. It used to work with no problem (card+ci OK). At some point things went bad, namely either the cam is working (like in the following log) and the frontend does not attach with a i2c timeout, but sometimes it is the reverse, and finally unfrequently both work. Is this a known problem, it does smell like an irq problem but I already tried different settings in the bios and even when it worked it did no last (eg the card works for a while and then quit working with no notice (with no power cycle in beetween). Is it a hardware failure? Thx for any help Bye Manu PS : the verbose dmesg when modprobing budget_ci [ 640.600816] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 662.638775] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 857.587933] saa7146: unregister extension 'budget_ci dvb'. [ 857.599366] ACPI: PCI interrupt for device :00:0b.0 disabled [ 901.954036] saa7146: register extension 'budget_ci dvb'. [ 901.954767] ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 20 [ 901.954998] saa7146: found saa7146 @ mem de9f4000 (revision 1, irq 20) (0x13c2,0x1017). [ 901.955171] saa7146 (0): dma buffer size 192512 [ 901.955265] DVB: registering new adapter (TT-Budget/S-1500 PCI). [ 902.018025] adapter has MAC addr = 00:d0:5c:24:90:ae [ 902.019542] input: Budget-CI dvb ir receiver saa7146 (0) as /class/input/input7 [ 902.019769] dvb_ca_en50221_init [ 902.019892] budget_ci: CI interface initialised [ 902.019896] CAMCHANGE IRQ slot:0 change_type:1 [ 902.019899] dvb_ca_en50221_thread_wakeup [ 902.052394] dvb_ca_en50221_thread [ 902.060343] saa7146_i2c_writeout: timed out waiting for end of xfer [ 902.137120] CAMREADY IRQ slot:0 [ 902.137133] dvb_ca_en50221_thread_wakeup [ 902.137308] TUPLE type:0x1d length:4 [ 902.137316] 0x00: 0x00 . [ 902.137323] 0x01: 0xdb . [ 902.137341] 0x02: 0x08 . [ 902.137347] 0x03: 0xff . [ 902.137358] TUPLE type:0x1c length:3 [ 902.137365] 0x00: 0x00 . [ 902.137372] 0x01: 0x08 . [ 902.137379] 0x02: 0xff . [ 902.137391] TUPLE type:0x15 length:23 [ 902.137398] 0x00: 0x05 . [ 902.137405] 0x01: 0x00 . [ 902.137412] 0x02: 0x41 A [ 902.137419] 0x03: 0x53 S [ 902.137426] 0x04: 0x54 T [ 902.137432] 0x05: 0x4f O [ 902.137439] 0x06: 0x4e N [ 902.137446] 0x07: 0x00 . [ 902.137453] 0x08: 0x44 D [ 902.137459] 0x09: 0x56 V [ 902.137465] 0x0a: 0x42 B [ 902.137472] 0x0b: 0x20 [ 902.137479] 0x0c: 0x43 C [ 902.137486] 0x0d: 0x41 A [ 902.137493] 0x0e: 0x20 [ 902.137500] 0x0f: 0x4d M [ 902.137507] 0x10: 0x6f o [ 902.137514] 0x11: 0x64 d [ 902.137521] 0x12: 0x75 u [ 902.137527] 0x13: 0x6c l [ 902.137534] 0x14: 0x65 e [ 902.137541] 0x15: 0x00 . [ 902.137548] 0x16: 0xff . [ 902.137560] TUPLE type:0x20 length:4 [ 902.137567] 0x00: 0xff . [ 902.137574] 0x01: 0xff . [ 902.137580] 0x02: 0x01 . [ 902.137586] 0x03: 0x00 . [ 902.137597] TUPLE type:0x1a length:21 [ 902.137604] 0x00: 0x01 . [ 902.137611] 0x01: 0x0f . [ 902.137618] 0x02: 0x00 . [ 902.137624] 0x03: 0x02 . [ 902.137630] 0x04: 0x01 . [ 902.137636] 0x05: 0xc0 . [ 902.137643] 0x06: 0x0e . [ 902.137650] 0x07: 0x41 A [ 902.137656] 0x08: 0x02 . [ 902.137663] 0x09: 0x44 D [ 902.137670] 0x0a: 0x56 V [ 902.137677] 0x0b: 0x42 B [ 902.137684] 0x0c: 0x5f _ [ 902.137691] 0x0d: 0x43 C [ 902.137696] 0x0e: 0x49 I [ 902.137702] 0x0f: 0x5f _ [ 902.137708] 0x10: 0x56 V [ 902.137714] 0x11: 0x31 1 [ 902.137721] 0x12: 0x2e . [ 902.137728] 0x13: 0x30 0 [ 902.137734] 0x14: 0x30 0 [ 902.137747] TUPLE type:0x1b length:17 [ 902.137754] 0x00: 0xc9 . [ 902.137761] 0x01: 0x41 A [ 902.137768] 0x02: 0x19 . [ 902.137774] 0x03: 0x37 7 [ 902.137781] 0x04: 0x55 U [ 902.137788] 0x05: 0x4e N [ 902.137795] 0x06: 0x5e ^ [ 902.137802] 0x07: 0x1d . [ 902.137809] 0x08: 0x56 V [ 902.137816] 0x09: 0xaa . [ 902.137822] 0x0a: 0x60 ` [ 902.137829] 0x0b: 0x20 [ 902.137836] 0x0c: 0x03 . [ 902.137842] 0x0d: 0x03 . [ 902.137849] 0x0e: 0x50 P [ 902.137855] 0x0f: 0xff . [ 902.137862] 0x10: 0xff . [ 902.137872] TUPLE type:0x1b length:37 [ 902.137879] 0x00: 0xcf . [ 902.137886] 0x01: 0x04 . [ 902.137893] 0x02: 0x09 . [ 902.137899] 0x03: 0x37 7 [ 902.137906] 0x04: 0x55 U [ 902.137913] 0x05: 0x4d M [ 902.137919] 0x06: 0x5d ] [ 902.137926] 0x07: 0x1d . [ 902.137933] 0x08: 0x56 V [ 902.137940] 0x09: 0x22 " [ 902.137946] 0x0a: 0xc0 . [ 902.137953] 0x0b: 0x09 . [ 902.137960] 0x0c: 0x44 D [ 902.137967] 0x0d: 0x56 V [ 902.137974] 0x0e: 0x42 B [ 902.137980] 0x0f: 0x5f _ [ 902.137987] 0x10: 0x48 H [ 902.137994] 0x11: 0x4f O [ 902.138001] 0x12: 0x53 S [ 902.138008] 0x13: 0x54 T [ 902.138015] 0x14: 0x00 . [ 902.138022] 0x15: 0xc1 . [ 902.138028] 0x16: 0x0e . [ 902.138035]
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Hi,
On Mon, Oct 08, 2007 at 08:41:15PM +0200, Ralf Jelinek wrote:
> Manu Abraham wrote:
> [...]
> > Please give it a go.
> > Testers, please give results with the stb0899 module with verbose=5 module
> > parameter
> > by the way i forgot to mention the tree. http://jusst.de/hg/multiproto
> > Please change the subject to reflect the hardware you have, for getting
> > back results.
>
> Hi Manu !
>
> I tried to update my kernel to 2.6.22-gentoo-r8
>
> I copied your tree to /usr/src/linux.
>
> make menuconfig
> make
>
> and then this errormsg:
>
> CC [M] drivers/media/common/ir-functions.o
> drivers/media/common/ir-functions.c:71:5: warning: "LINUX_VERSION_CODE"
> is not defined
> drivers/media/common/ir-functions.c:71:26: warning: "KERNEL_VERSION" is
> not defined
> drivers/media/common/ir-functions.c:71:40: error: missing binary
> operator before token "("
> make[3]: *** [drivers/media/common/ir-functions.o] Error 1
> make[2]: *** [drivers/media/common] Error 2
> make[1]: *** [drivers/media] Error 2
> make: *** [drivers] Error 2
Install your kernel to /usr/src/linux, compile it and install it.
Do NOT compile the DVB modules included in the kernel.
Then download the tree to a different directory eg. /usr/src/multiproto
or somewhere else like in your home directory.
The go to this directory and run make and make install.
Regards, Artem
--
Artem Makhutov
Unterort Str. 36
D-65760 Eschborn
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] KNC1 DVB-S2 Plus, Satelco DVB-S2, TT S2 3200, Technisat DVB-S2
Manu Abraham wrote:
> Hi folks,
>
> I have pushed out a tree containing support for the mentioned hardware.
> Please note, support is still incomplete. Still much more to happen.
>
> NOTE: Still in BETA stage.
>
> Please collect all your issues, will go through one by one. I can go through
> the issues one
> by one only, so please bear with me.
>
> The hacked szap is here http://abraham.manu.googlepages.com/szap.c
>
> I would like to know the issues you face. Some people have said that the
> STB0899 tunes and LOCK's
> incredibly faster than any of the demodulator drivers we have.
>
> Would like to verify this as well. I am wondering whether this is too good to
> believe.
>
> Please give it a go.
> Testers, please give results with the stb0899 module with verbose=5 module
> parameter
> by the way i forgot to mention the tree. http://jusst.de/hg/multiproto
> Please change the subject to reflect the hardware you have, for getting back
> results.
>
> Will get some sleep now.
>
> Regards,
> Manu
>
> ___
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
>
Hi Manu !
I tried to update my kernel to 2.6.22-gentoo-r8
I copied your tree to /usr/src/linux.
make menuconfig
make
and then this errormsg:
CC [M] drivers/media/common/ir-functions.o
drivers/media/common/ir-functions.c:71:5: warning: "LINUX_VERSION_CODE"
is not defined
drivers/media/common/ir-functions.c:71:26: warning: "KERNEL_VERSION" is
not defined
drivers/media/common/ir-functions.c:71:40: error: missing binary
operator before token "("
make[3]: *** [drivers/media/common/ir-functions.o] Error 1
make[2]: *** [drivers/media/common] Error 2
make[1]: *** [drivers/media] Error 2
make: *** [drivers] Error 2
Any ideas ?
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
Wolfgang Wegner wrote: > Hi, > > On Sat, Sep 29, 2007 at 01:01:31PM +0200, Felix Domke wrote: > [...] >> I don't know if broadcasters are required to send non-inverted signals. >> I just know (read: remember) that some do. I might be wrong, so second >> opinions are welcome. > > sorry for the delay... > > Finally I checked again and it is really a transponder on turksat > that uses inverted spectrum: > 42°East, 10.956 GHz V SR 5859 FEC 5/6 > > This is also mentioned here: (Turksat 1C) > http://www.satundkabel.de/print.php?sid=11988 > > And I just checked it with an old STV0299 frontend. > There may be others, too, but as of now I can state that one as confirmed. ;-) > Thanks for verifying it. I couldn't make out anything from that page. ;-) But anyway not much of a concern if you have verified the same. I really wonder the cause whether it is really a broadcaster having a wrongly wired modulator. Don't see any reason why there should be inversion in that case of Ku band. Anyway that doesn't matter for many/most demods to do a flip-flop in software, as they can detect an inversion. I guess device specifics should have been hidden in the specific devices only (ie not being able to find many devices that _cannot_ detect an inversion) Though not a big issue, as we have a workaround such that those ones can avoid that unnecessary flip-flop (Usually we do things to make devices that do not work resort to workarounds, but here we have a logic inversion, in this case) It is just that we have to resort to some workarounds, to avoid those funky things being done for all devices, because some really few devices cannot do those. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Some thoughts and questions
Hi, On Sat, Sep 29, 2007 at 01:01:31PM +0200, Felix Domke wrote: [...] > I don't know if broadcasters are required to send non-inverted signals. > I just know (read: remember) that some do. I might be wrong, so second > opinions are welcome. sorry for the delay... Finally I checked again and it is really a transponder on turksat that uses inverted spectrum: 42°East, 10.956 GHz V SR 5859 FEC 5/6 This is also mentioned here: (Turksat 1C) http://www.satundkabel.de/print.php?sid=11988 And I just checked it with an old STV0299 frontend. There may be others, too, but as of now I can state that one as confirmed. ;-) Regards, Wolfgang ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote:
>>> I don't like to create a video-buf.h header. This will make non-pci
>>> devices dependent on PCI, or will require some additional logic for
>>> checking kernel Kconfig symbols. I also expect that other newer videobuf
>>> methods to be created. So, this header will just generate undesirable
>>> mess.
>>>
>> This would not create dependencies of non-pci devices on pci -- a
>> simple header inclusion is optimized by the c compiler -- only needed
>> methods are considered and are actually included in the build.
>>
>
> Wrong. This has nothing to do with c optimizer. Try this:
>
> Create this as header.h:
>
> struct foo {
> struct some_pci_struct foo;
> };
>
> Create this as main.c:
>
> #include "header.h"
>
> int main (void)
> {
> return 0;
> }
>
> You will got the following error:
>
> /tmp/header.h:2: error: field ‘foo’ has incomplete type
>
> If we use your approach, a non-pci videobuf driver will work only at the
> architectures where you have a PCI bus (since the pci structs won't
> exist on that architecture).
>
OK, I wasn't thinking clearly when I had written that at first... We
would have to use some #ifdef logic within video-buf.h in order to avoid
this, but that's ugly, and more trouble than it's worth.
You've proven your point.
>
>>> What we might do is to rename the generic abstract method to another
>>> name. This will generate compilation errors, making easier for people to
>>> realize what happened.
>>>
>> If we rename it to video-buf.h, it would cover the issue that I have in
mind.
>>
>>
> It is much more clear to include videobuf-vmalloc or videobuf-dma-sg,
> depending on the proper videobuf module that will be needed by a driver.
>
> Creating a video-buf.h that just includes the two will be unused by the
> drivers. So, what's the sense of creating a header file at the kernel
> that aren't used inside kernel?
>
It would just be nice to have errors when a module calls a function
defined in the old header, rather than the new one.
This is a concern, but a minor one, as this is only an issue during the
transitional kernels. If we've fixed all instances, then there should
be nothing to worry about.
In general, I just don't like modules building against the wrong headers
and not reporting any errors... I guess we'll just have to live with it
this way for now.
>
>>> I'm not sure if this is valuable enough, since I don't know any other
>>> DMA S/G driver using videobuf being developed for their inclusion at
>>> Kernel.
>>>
>> Maybe an out of tree driver uses it?
>>
>
> Although there's no intention to make life harder for out-of-tree
> drivers, they shouldn't be considered on changes made at kernel
> internals. The proper place for a kernel driver is in-kernel, not
> outside.
>
> Anyway, a compilation with a driver including video-buf.h currently will
> generate an error, indicating that something has changed at v4l
> infrastructure. By creating a header like you're proposing won't fix
> this.
>
>> Maybe there is an in-tree driver that still might have old methods
being used but we didnt hit those bugs yet due to incomplete testing
methods?
>>
>
> The only in-kernel drivers that use videobuf infrastructure are:
> cx88, saa7134, bttv, saa7146 and, now, cx23885.
>
> After the patch, all of they are already converted.
>
> grep videobuf_queue_pci_init *.c
> bttv-driver.c: videobuf_queue_pci_init(&fh->cap, &bttv_video_qops,
> bttv-driver.c: videobuf_queue_pci_init(&fh->vbi, &bttv_vbi_qops,
> cx23885-dvb.c: videobuf_queue_pci_init(&port->dvb.dvbq, &dvb_qops,
> dev->pci, &port->slock,
> cx88-blackbird.c: videobuf_queue_pci_init(&fh->mpegq,
> &blackbird_qops,
> cx88-dvb.c: videobuf_queue_pci_init(&dev->dvb.dvbq, &dvb_qops,
> cx88-video.c: videobuf_queue_pci_init(&fh->vidq, &cx8800_video_qops,
> cx88-video.c: videobuf_queue_pci_init(&fh->vbiq, &cx8800_vbi_qops,
> saa7134-dvb.c: videobuf_queue_pci_init(&dev->dvb.dvbq,
> &saa7134_ts_qops,
> saa7134-empress.c: videobuf_queue_pci_init(&dev->empress_tsq,
> &saa7134_ts_qops,
> saa7134-video.c:videobuf_queue_pci_init(&fh->cap, &video_qops,
> saa7134-video.c:videobuf_queue_pci_init(&fh->vbi,
> &saa7134_vbi_qops,
> saa7146_vbi.c: videobuf_queue_pci_init(&fh->vbi_q, &vbi_qops,
> saa7146_video.c:videobuf_queue_pci_init(&fh->video_q,
> &video_qops,
> videobuf-dma-sg.c:void videobuf_queue_pci_init(struct videobuf_queue* q,
>
> There's no other driver using the abstract videobuf_queue_init.
>
OK, we should be fine, then.
> A final point for your consideration:
>
> videobuf_queue_init is the only function that had its meaning changed
> without changing its parameters (currently, it is just an abstract
> method. In the past, this were the function that were used to initialize
> a videobuf queue).
>
> The changes you're proposing won't solve the target you've addressed in
> the first place, since it w
Re: [linux-dvb] [RFC-final] videobuf tree
> > The proper change is simply doing something like: > > > > s/videobuf_queue_init/videobuf_queue_abstract_init/ > > > > After this, on all places where videobuf stuff is used without > > conversion, an error will be generated. > > > This wouldn't be a bad idea. > > After my considerations, if you still think this is important, I'll > > accept a patch renaming the old videobuf_queue_init to a new name. > > > > I think that you've proven that it is NOT important... although, it > still might be a good idea. I'm not sure -- I was only making a > suggestion. Agreed. I'll try to do such patch when I have some time. -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
> > I don't like to create a video-buf.h header. This will make non-pci
> > devices dependent on PCI, or will require some additional logic for
> > checking kernel Kconfig symbols. I also expect that other newer videobuf
> > methods to be created. So, this header will just generate undesirable
> > mess.
>
> This would not create dependencies of non-pci devices on pci -- a
> simple header inclusion is optimized by the c compiler -- only needed
> methods are considered and are actually included in the build.
Wrong. This has nothing to do with c optimizer. Try this:
Create this as header.h:
struct foo {
struct some_pci_struct foo;
};
Create this as main.c:
#include "header.h"
int main (void)
{
return 0;
}
You will got the following error:
/tmp/header.h:2: error: field ‘foo’ has incomplete type
If we use your approach, a non-pci videobuf driver will work only at the
architectures where you have a PCI bus (since the pci structs won't
exist on that architecture).
> > What we might do is to rename the generic abstract method to another
> > name. This will generate compilation errors, making easier for people to
> > realize what happened.
>
> If we rename it to video-buf.h, it would cover the issue that I have in mind.
>
It is much more clear to include videobuf-vmalloc or videobuf-dma-sg,
depending on the proper videobuf module that will be needed by a driver.
Creating a video-buf.h that just includes the two will be unused by the
drivers. So, what's the sense of creating a header file at the kernel
that aren't used inside kernel?
> > I'm not sure if this is valuable enough, since I don't know any other
> > DMA S/G driver using videobuf being developed for their inclusion at
> > Kernel.
>
> Maybe an out of tree driver uses it?
Although there's no intention to make life harder for out-of-tree
drivers, they shouldn't be considered on changes made at kernel
internals. The proper place for a kernel driver is in-kernel, not
outside.
Anyway, a compilation with a driver including video-buf.h currently will
generate an error, indicating that something has changed at v4l
infrastructure. By creating a header like you're proposing won't fix
this.
>
> Maybe there is an in-tree driver that still might have old methods being
> used but we didnt hit those bugs yet due to incomplete testing methods?
The only in-kernel drivers that use videobuf infrastructure are:
cx88, saa7134, bttv, saa7146 and, now, cx23885.
After the patch, all of they are already converted.
grep videobuf_queue_pci_init *.c
bttv-driver.c: videobuf_queue_pci_init(&fh->cap, &bttv_video_qops,
bttv-driver.c: videobuf_queue_pci_init(&fh->vbi, &bttv_vbi_qops,
cx23885-dvb.c: videobuf_queue_pci_init(&port->dvb.dvbq, &dvb_qops,
dev->pci, &port->slock,
cx88-blackbird.c: videobuf_queue_pci_init(&fh->mpegq,
&blackbird_qops,
cx88-dvb.c: videobuf_queue_pci_init(&dev->dvb.dvbq, &dvb_qops,
cx88-video.c: videobuf_queue_pci_init(&fh->vidq, &cx8800_video_qops,
cx88-video.c: videobuf_queue_pci_init(&fh->vbiq, &cx8800_vbi_qops,
saa7134-dvb.c: videobuf_queue_pci_init(&dev->dvb.dvbq,
&saa7134_ts_qops,
saa7134-empress.c: videobuf_queue_pci_init(&dev->empress_tsq,
&saa7134_ts_qops,
saa7134-video.c:videobuf_queue_pci_init(&fh->cap, &video_qops,
saa7134-video.c:videobuf_queue_pci_init(&fh->vbi,
&saa7134_vbi_qops,
saa7146_vbi.c: videobuf_queue_pci_init(&fh->vbi_q, &vbi_qops,
saa7146_video.c:videobuf_queue_pci_init(&fh->video_q,
&video_qops,
videobuf-dma-sg.c:void videobuf_queue_pci_init(struct videobuf_queue* q,
There's no other driver using the abstract videobuf_queue_init.
A final point for your consideration:
videobuf_queue_init is the only function that had its meaning changed
without changing its parameters (currently, it is just an abstract
method. In the past, this were the function that were used to initialize
a videobuf queue).
The changes you're proposing won't solve the target you've addressed in
the first place, since it will still compile without warning, if you
forget to rename it to videobuf_queue_pci_init.
The proper change is simply doing something like:
s/videobuf_queue_init/videobuf_queue_abstract_init/
After this, on all places where videobuf stuff is used without
conversion, an error will be generated.
After my considerations, if you still think this is important, I'll
accept a patch renaming the old videobuf_queue_init to a new name.
--
Cheers,
Mauro
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Hauppauge Nova-T 500 not recognised by driver due to USB ID.
Hi Andrew, On Sun, 7 Oct 2007, Andrew Preater wrote: > In summary: I have a Hauppauge Nova-T 500 dual-tuner DVB-T PCI > card that is not recognised by the DVB driver because it has a > strange USB ID. When the source is edited to force recognition > of the card as a Nova-T 500, it works. > > I had some spare time this weekend so decided to upgrade the OS > on the house MythTV box, add a DVB-T tuner card, and swap > architecture to amd64 distribution from i386. I now have Debian > 4.0 (etch) for amd64, running the current stable 2.6.18-5-686 > kernel. Following the linuxtv wiki page for this card, I > downloaded the driver with mercurial and compiled it > against my kernel. I needed to create a symlink from > /lib/modules/2.6.18-5-amd64/source to /lib/modules/2.6.18-5-amd64/build > as the driver expected 'source', otherwise the build and install > was clean and smooth. dvb-usb-dib0700-03-pre1.fw is in place. I > am in the United Kingdom and therefore am using PAL-I. > BTW I know I have an early-ish model Nova-T, definitely not the > "Diversity" card. FWIW these are the markings on my card: > > WinTV-NOVA-T-500 > DVB-T 99101 LF > Rev D8B5 > > Initially the card doesn't work. When dvb-usb-dib0700 is > modprobed, this all that appears in dmesg: > > dib0700: loaded with support for 5 different device-types > usbcore: registered new driver dvb_usb_dib0700 > > That's it, just the two lines. Searching around this problem, the > penny dropped when I saw talk about a change to the USB ID of the > Nova-T cards with the unsupported "Diversity" revision - my card > doesn't have a Hauppauge ID it seems: > > $ lsusb > Bus 006 Device 001: ID : > Bus 005 Device 002: ID 10b8:0066 DiBcom The eeprom of your card seems to be erased or most likely broken. > I can now scan for channels, tune in with tzap and watch a > programme with mplayer, so I conclude the card would be OK if the > driver included the relevant ID in dvb-usb-ids.h. The IDs used by your device are the standard IDs of the dib0700-usb-chip. We cannot add those to the list, because they are not unqiue. I suggest to exchange your card if you have warranty. Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote: >> Mauro, >> >> This new patch fixed the problem. CX23885 functionality is restored! :-) > Good! If you send your reviewed-by, I'll add at the proper changesets > touching videobuf. 3762b92e232a - V4L/DVB (6287) - Fix DMA Scatter/Gather constructor Reviewed-by: Michael Krufky <[EMAIL PROTECTED]> >> side note: If we had left a single header, video-buf.h, we could have >> avoided this problem. When we rename files like this, we run the risk >> of building against the wrong headers, if errors are not caught & >> corrected quickly enough. >> >> Are you open to merging the videobuf-*.h into a single video-buf.h >> header file, to match the filename in previous kernel versions so that >> we can avoid this issue from recurring? Either that, or including the >> current headers into a new video-buf.h would do the same job. >> >> What do you think? > > I don't like to create a video-buf.h header. This will make non-pci > devices dependent on PCI, or will require some additional logic for > checking kernel Kconfig symbols. I also expect that other newer videobuf > methods to be created. So, this header will just generate undesirable > mess. This would not create dependencies of non-pci devices on pci -- a simple header inclusion is optimized by the c compiler -- only needed methods are considered and are actually included in the build. > What we might do is to rename the generic abstract method to another > name. This will generate compilation errors, making easier for people to > realize what happened. If we rename it to video-buf.h, it would cover the issue that I have in mind. > I'm not sure if this is valuable enough, since I don't know any other > DMA S/G driver using videobuf being developed for their inclusion at > Kernel. Maybe an out of tree driver uses it? Maybe there is an in-tree driver that still might have old methods being used but we didnt hit those bugs yet due to incomplete testing methods? Cheers, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
> Mauro, > > This new patch fixed the problem. CX23885 functionality is restored! :-) Good! If you send your reviewed-by, I'll add at the proper changesets touching videobuf. > side note: If we had left a single header, video-buf.h, we could have > avoided this problem. When we rename files like this, we run the risk > of building against the wrong headers, if errors are not caught & > corrected quickly enough. > > Are you open to merging the videobuf-*.h into a single video-buf.h > header file, to match the filename in previous kernel versions so that > we can avoid this issue from recurring? Either that, or including the > current headers into a new video-buf.h would do the same job. > > What do you think? I don't like to create a video-buf.h header. This will make non-pci devices dependent on PCI, or will require some additional logic for checking kernel Kconfig symbols. I also expect that other newer videobuf methods to be created. So, this header will just generate undesirable mess. What we might do is to rename the generic abstract method to another name. This will generate compilation errors, making easier for people to realize what happened. I'm not sure if this is valuable enough, since I don't know any other DMA S/G driver using videobuf being developed for their inclusion at Kernel. Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Mauro Carvalho Chehab wrote: > Michael, > > > >> However, cx23885 is now broken. Upon starting a DVB stream, the >> following OOPS is generated: >> > > I've reviewed cx23885 videobuf stuff. I noticed a problem at the > conversions: It is still using the abstract videobuf constructor, > instead of the pci DMA S/G one. I've just added a patch fixing this at > v4l-dvb tree. Probably, this will fix the issue. Mauro, This new patch fixed the problem. CX23885 functionality is restored! :-) side note: If we had left a single header, video-buf.h, we could have avoided this problem. When we rename files like this, we run the risk of building against the wrong headers, if errors are not caught & corrected quickly enough. Are you open to merging the videobuf-*.h into a single video-buf.h header file, to match the filename in previous kernel versions so that we can avoid this issue from recurring? Either that, or including the current headers into a new video-buf.h would do the same job. What do you think? -Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Michael, > However, cx23885 is now broken. Upon starting a DVB stream, the > following OOPS is generated: I've reviewed cx23885 videobuf stuff. I noticed a problem at the conversions: It is still using the abstract videobuf constructor, instead of the pci DMA S/G one. I've just added a patch fixing this at v4l-dvb tree. Probably, this will fix the issue. Please test. - Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HVR4000 - several questions [sls][spam-bayes][heur][bcc][faked-from]
Igor Nikanov wrote: > Hi > > on http://www.tbc.ru/index.php?option=com_content&task=view&id=36&Itemid=31 I > read about > supported FEC Rates 1/2, 2/3, 3/4, 5/6, 7/8 - and what about fec = 9/10 - > is it supported ? > > The hardware supports those rates, if the driver does not then it's a minor change. > on http://www.hauppauge.co.uk/pages/products/data_hvr4000.html > I read about DiSEqC 1.0 supported , and what about other version - 1.1, 1.2 ? > > The hardware supports modes 1.0, 1.1 and 1.2. I'm not sure about the tree, it's a very old tree. > is it possible to connect to card the motor for dish, diseqc-commutator and 2 > LNB - for C and Ku bands in > the same time ? which max current can be between this card and motor or LNB > ? 400 ma ? > > Hmm. I'm not sure. > why need automatic DVBS2 pilot support ? what's mean "pilot" function ? > > You don't need to worry about Pilot support, it's automatic in the current driver. > is it possible to capture on harddisc the analog video-signal, connected to > s-video or composite video > input in HVR4000 ? > > That's quetsion better suited to the v4l-dvb mailing list. > is it possible to capture and to record on hdd the analog terrestrial > broadcasting ? > > Yes. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technisat DVB-S2 Skystar HD
Mario Smit wrote: > Hi Manu, > > I was rather busy lately. I just picked up reading on the mailinglist > again. Saw you have been busy lately. :) > > I thought I'll give it a try. Got your latest tree (of today). I have a > TT3200 card. > > Zapping DVB-S works 9 out of 10 times. Zapping DVB-S2 5 out of 10 times. > Looking at the state of the driver a couple of weeks ago I must say I am > very much pleased with this result! > > I am willing to help out to get it 100% stable. Were do I start? Should > I send you some logs like Arthem? Just let me know. > Hold on, will be nice to have some feedback after some more changes, such that i have enough debugging info. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asus Tiger can't find any channels
Marko Ristola wrote: > One thing is, that INVERSION=1 is used in Finland. > Others use INVERSION=0. Thus INVERSION_AUTO > might not work in kernel drivers if the INVERSION_AUTO > is implemented in software, as it is with Twinhan > Cab-CI 2033. If you need INVERSION=1(INVERSION_ON) , why do you specify INVERSION=AUTO in userspace. Seems like incorrect behaviour in a userspace application or configuration. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technisat DVB-S2 Skystar HD
Oliver Bardenheier (obardenh) wrote: > In make menuconfig I have to choose the following (deprecated entry) for > getting the modules: > > Video For Linux > [*] Enable Video For Linux API 1 (DEPRECATED) > --- Enable Video For Linux API 1 compatible Layer > [*] Video capture adapters ---> > > You don't need V4L for DVB, you can safely uncheck it, unless your card needs V4L support. That menu option is in the wrong place, which makes people confused. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asus Tiger can't find any channels
Hi Anssi, I don't have the same card as you, but I live in Finland also. I use DVB-C card Twinhan Cab-CI 2033. It might be that the problems you have seen, are similar that I have seen. (Personally I wouldn't recommend this card even though it works enough for me). Here in Finland there are some things that might be different than in all other countries. My findings are for DVB-C. I don't know whether they are equal with DVB-T. One thing is, that INVERSION=1 is used in Finland. Others use INVERSION=0. Thus INVERSION_AUTO might not work in kernel drivers if the INVERSION_AUTO is implemented in software, as it is with Twinhan Cab-CI 2033. If INVERSION_AUTO tries only INVERSION=0, Kaffeine can't take a lock on the signal. I have to maintain a fork of the drivers to make my PCI card work. It tries first INVERSION=0, and if it can't take a lock with it, it tries INVERSION=1. Kaffeine gets a lock and the card works. So Kaffeine want's INVERSION_AUTO and the driver tries both inversions separately. The driver is so smart that if it previously succeeded with INVERSION=1, it will later try it also with another frequency. Regards, Marko Ristola Anssi Purola wrote: > Hi. > > (sorry about bad English, if you don't understand something I'm > telling, just ask ;) > > I have a Asus Tiger DVB-T card (got it when I bought this used > computer..). lspci says "Philips Semiconductors SAA7133/SAA7135 Video > Broadcast Decoder (rev d1)" and if I don't give any modprobe options, > my system recognices it (dmesg: saa7133[0]: subsystem: 1043:4857, > board: ASUSTeK P7131 Dual [card=78,autodetected]). > > But I just can't get it to actually work. I mostly try to scan the > channels with Kaffeine. I've tried different card=xx tuner=xx > compinations etc. And I have also tried to change tuner_config values > in my saa7134-cards.c and caa7134-dvb.c (I downloaded the latest > sources). > > Right now Kaffeine shows 45% signal, but it doesn't start to scan the > channels (the status indicator just says 0% and terminal says > "Invalid section length or timeout: pid=17 Invalid section length or > timeout: pid=0". Sometime I had quite good signal (60-70%) and > scanning did work, but Kaffeine still couldn't find any channels. And > sometimes Kaffeine shows signal only when it scans the first line from > my source file. > > I have tried scan/tzap also, but they don't find anything. > > dmesg |grep -i saa7 : > > saa7130/34: v4l2 driver version 0.2.14 loaded > saa7133[0]: found at :02:05.0, rev: 209, irq: 22, latency: 32, > mmio: 0xf6006000 > saa7133[0]: subsystem: 1043:4857, board: ASUSTeK P7131 Dual > [card=78,autodetected] > saa7133[0]: board init: gpio is 0 > input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input7 > saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 > saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff > saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 b6 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 21 00 c2 96 10 03 32 15 00 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 scan: found device @ 0x10 [???] > saa7133[0]: i2c scan: found device @ 0x96 [???] > saa7133[0]: i2c scan: found device @ 0xa0 [eeprom] > tuner 1-004b: chip found @ 0x96 (saa7133[0]) > saa7133[0]: registered device video0 [v4l2] > saa7133[0]: registered device vbi0 > saa7133[0]: registered device radio0 > DVB: registering new adapter (saa7133[0]). > > dmesg |grep -i firmw (don't know what's with the ten line..) : > > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > tda1004x: found firmware revision 20 -- ok > > > fi-Alajarvi (the source file): > > T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE > T 73000 8MHz 2/3 NONE QAM64 8k 1/8 NONE > T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE > > scan fi-Alajarvi: > > scanning fi-Alajarvi > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 64200 0 2 9 3 1 2 0 > initial transponder 73000 0 2 9 3 1 2 0 > initial transponder 57800 0 2 9 3 1 2 0 > tune to: 64200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE > WARNING: filter timeout pid 0x0011 > WARNING: filter timeout pid 0x > WARNING: filter timeout pid 0x0010 > tune to: 73000:INVERSION_
Re: [linux-dvb] [RFC-final] videobuf tree
> For now, let me give a quick explanation of the basics of videobuf.
>
> ---
>
(part 2)
As you know, the original author of videobuf is Gerd. At the changes I
did, I've tried to preserve, as much as possible, the code outside
videobuf without changes(*).
(*) This is also true for the binary code that videobuf-core +
videobuf_dma_sg executes: It is almost the same as the original
videobuf, but separated into two separate modules, with distinct
functions.
a) The first one is about the inherited videobuf_buffer class at each
driver.
The approach used on videobuf is somehow different from what other parts
of the Linux Kernel does. For this to work, the first part of a
videobuf_buffer inherited code should do:
cx23885_buffer {
struct videbuf_buffer;
...
}
Otherwise, the videobuf code will fail.
IMO, it would be better to use container_of as you suggested, but this
would mean rewrite more code at the drivers, and do more tests.
b) The destructor used to free videobuf_buffer memory is just kfree. So,
all memory for the entire class should be allocated with just one
kmalloc. The memory model is something like:
struct derivated_class {
struct cx23885_buffer {
struct videobuf_buffer;
// cx23885 own data
}
// dma s/g own data
};
So, videobuf_pci_malloc do something like:
buf=kmalloc (sizeof(struct derivated_class), GFP_KERNEL);
To free a videobuf, you just need to do:
free (buf);
--
Cheers,
Mauro
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
Em Dom, 2007-10-07 às 14:03 -0700, Trent Piepho escreveu:
> On Sun, 7 Oct 2007, Mauro Carvalho Chehab wrote:
> > I took a look at cx23885 code. It seems that there's a serious error on
> > the way you're using cx23885_buffer there:
> >
> > cx23885-dvb.c: return cx23885_buf_prepare(q, port, (struct
> > cx23885_buffer*)vb, field);
> > cx23885-dvb.c: cx23885_buf_queue(port, (struct cx23885_buffer*)vb);
> > cx23885-dvb.c: cx23885_free_buffer(q, (struct cx23885_buffer*)vb);
> >
> > It seems that you are forcing videobuf_buffer to be cx23885_buffer. This
> > is not right!
> >
> > This is what is defined on cx23885.h:
> >
> > struct cx23885_buffer {
> > /* common v4l buffer stuff -- must be first */
> > struct videobuf_buffer vb;
>
> I'm not sure that it is competely wrong. Say one has a cx23885_buffer that
> contains a videobuf_buffer. Now suppose you have a pointer to the
> videobuf_buffer, and you want to get a pointer to the cx23885_buffer that
> contains it. What you should write is:
>
> struct videobuf_buffer *vb = ...;
> struct cx23885_buffer *buf = container_of(vb, struct cx23885_buffer, vb);
>
> But since vb is the first field of the cx23885_buffer struct, the container_of
> will turn into just '(struct cx23885_buffer *)(vb)
>
> This code in videobuf-dma-sg.c looks odd to me:
>
> /* Allocated area consists on 3 parts:
> struct video_buffer
> struct _buffer (cx88_buffer, saa7134_buf, ...)
> struct videobuf_pci_sg_memory
>
> static void *__videobuf_alloc(size_t size)
> {
> struct videbuf_pci_sg_memory *mem;
> struct videobuf_buffer *vb;
>
> vb = kzalloc(size+sizeof(*mem),GFP_KERNEL);
>
> mem = vb->priv = ((char *)vb)+size;
>
> What is 'size', is that the size of the driver buffer? Shouldn't you
> be
> allocating size + sizeof(*vb) + sizeof(*mem)?
>
> Is there documentation for videobuf anywhere? It doesn't look like
> any of
> the videobuf functions have descriptions of that they do or what the
> parameters are.
There aren't any videobuf doc yet. I intend to write one, when I have
some time. IMO, this is the most complex part of V4L core.
For now, let me give a quick explanation of the basics of videobuf.
---
Videobuf uses a memory struct that looks what c++ compilers do when you
use inheritances.
It is something like:
class videobuf_core {
public:
// some data and code
};
class videobuf_dma_sg: public videobuf_core {
private:
// some data and code
}
class foo_buffer: public videobuf_dma_sg {
public:
// some data
}
The "constructor" for any class derivated from videobuf_dma_sg is:
void *videobuf_pci_alloc (size_t size);
Where size is the size of foo_buffer.
The other videobuf_dma methods are the external functions defined on
videobuf-dma-sg.h. All of them start with videobuf_dma_foo.
A similar inehitance concept happens with videobuf_queue. You have an
abstract videobuf_queue class, defined on videobuf-core, where almost
all methods are virtual, and, currently, two derivated class, that
implements their methods: a DMA Scatter/Gather one (videobuf-dma-sg) and
a vmalloc one (videobuf-vmalloc).
To use the full functionality of videobuf, you will need the
videobuf_queue, that is responsible for controlling the state machine of
the videobuffers. The videobuf_queue constructor will allocate a
videobuf_buffer inherited class. Also, when you need mmapped buffers,
videobuf core will allocate one additional videobuf_buffer inherited
class by each queue (generally, a driver allocates, by default, 8 queues
for receiving data - this avoids data loss, when the machine is with
high workloads).
It is also possible just to use a videobuf_buffer derivated class. ALSA
saa7134 and cx88 drivers implement this way. They have their own state
machine.
--
Cheers,
Mauro
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technisat DVB-S2 Skystar HD
In make menuconfig I have to choose the following (deprecated entry) for getting the modules: Video For Linux [*] Enable Video For Linux API 1 (DEPRECATED) --- Enable Video For Linux API 1 compatible Layer [*] Video capture adapters ---> -Original Message- From: Manu Abraham [mailto:[EMAIL PROTECTED] Sent: Samstag, 6. Oktober 2007 22:10 To: Oliver Bardenheier (obardenh) Cc: Artem Makhutov; linux-dvb@linuxtv.org Subject: Re: [linux-dvb] Technisat DVB-S2 Skystar HD Oliver Bardenheier (obardenh) wrote: > Just a stupid question: > Why do we have to use API V1 to get budget-* ? > Any reason for not porting it into API > v1 ? > Didn't follow your question, got lost. Can you please elaborate your question ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Asus Tiger can't find any channels
Hi. (sorry about bad English, if you don't understand something I'm telling, just ask ;) I have a Asus Tiger DVB-T card (got it when I bought this used computer..). lspci says "Philips Semiconductors SAA7133/SAA7135 Video Broadcast Decoder (rev d1)" and if I don't give any modprobe options, my system recognices it (dmesg: saa7133[0]: subsystem: 1043:4857, board: ASUSTeK P7131 Dual [card=78,autodetected]). But I just can't get it to actually work. I mostly try to scan the channels with Kaffeine. I've tried different card=xx tuner=xx compinations etc. And I have also tried to change tuner_config values in my saa7134-cards.c and caa7134-dvb.c (I downloaded the latest sources). Right now Kaffeine shows 45% signal, but it doesn't start to scan the channels (the status indicator just says 0% and terminal says "Invalid section length or timeout: pid=17 Invalid section length or timeout: pid=0". Sometime I had quite good signal (60-70%) and scanning did work, but Kaffeine still couldn't find any channels. And sometimes Kaffeine shows signal only when it scans the first line from my source file. I have tried scan/tzap also, but they don't find anything. dmesg |grep -i saa7 : saa7130/34: v4l2 driver version 0.2.14 loaded saa7133[0]: found at :02:05.0, rev: 209, irq: 22, latency: 32, mmio: 0xf6006000 saa7133[0]: subsystem: 1043:4857, board: ASUSTeK P7131 Dual [card=78,autodetected] saa7133[0]: board init: gpio is 0 input: saa7134 IR (ASUSTeK P7131 Dual) as /class/input/input7 saa7133[0]: i2c eeprom 00: 43 10 57 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 02 03 01 01 03 08 ff 00 b6 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 21 00 c2 96 10 03 32 15 00 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 scan: found device @ 0x10 [???] saa7133[0]: i2c scan: found device @ 0x96 [???] saa7133[0]: i2c scan: found device @ 0xa0 [eeprom] tuner 1-004b: chip found @ 0x96 (saa7133[0]) saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 DVB: registering new adapter (saa7133[0]). dmesg |grep -i firmw (don't know what's with the ten line..) : tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok tda1004x: found firmware revision 20 -- ok fi-Alajarvi (the source file): T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 73000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 57800 8MHz 2/3 NONE QAM64 8k 1/8 NONE scan fi-Alajarvi: scanning fi-Alajarvi using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 64200 0 2 9 3 1 2 0 initial transponder 73000 0 2 9 3 1 2 0 initial transponder 57800 0 2 9 3 1 2 0 >>> tune to: >>> 64200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010 >>> tune to: >>> 73000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 73000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: >>> 57800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 57800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE (tuning failed) WARNING: >>> tuning failed!!! dumping lists (0 services) Done. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] hanftek DVB-T USB on ARM926 ==> can't find firmware
Dear All: Could you give me some idea? Right now, I'm working on an ARM926 Platform, and my linux kernel is 2.6.19.2. the following is my kernel message and I put the firmware in /usr/lib/hotplug/firmware usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1 fsl-ehci fsl-ehci.0: irq 54, io base 0x10024200 fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb 1-1: new full speed USB device using fsl-ehci and address 2 usb 1-1: not running at top speed; connect to a high speed hub usb 1-1: configuration #1 chosen from 1 choice dvb-usb: found a 'Hanftek UMT-010 DVB-T USB2.0' in cold state, will try to load a firmware dvb-usb: did not find the firmware file. (dvb-usb-umt-010-02.fw) Please see linu x/Documentation/dvb/ for more details on firmware-problems. (-2) dvb_usb_umt_010: probe of 1-1:1.0 failed with error -22 usbcore: registered new interface driver dvb_usb_umt_010 where do I miss and what should I do to make this one work on my arm platform? BTW, which dvb-t usb stick is the best one on arm platform? Thank you very much. Best Regards, Akio ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
