[linux-dvb] Re: dvb module parameters and more

[rolf.siebrecht@t-online.de (Rolf Siebrecht)]

Hi!

On Thu, 27 Sep 2001, Andrei Boros wrote:
>  I use siemens-0.8.2 because I can't upgrade to 2.4 kernel yet (other
> drivers are not yet supported) and 0.9 won't compile with syntax errors.
> (odd, but deffered for the moment).

After tiny modifications DVB-0.8.2 compiles and runs very well under 
2.4. Vice versa, after rather few changes DVB-0.9 compiles under 2.2, at
least former revisions of DVB-0.9.

> i2c_core.o:
>  debug=1 print debugging information

Right.

> videodev.o: ?

None.
 
> saa7146_core.o: 
>  mode=0(PAL), 1(NTSC)
>  buffers=2(double buffering), 4(more buffers for high performance
> capture.
>  debug - debugging levels

mode=0 is the default. It doesn't need to be listed as module option.

Regarding "buffers" the default is 4, so explicitly specify buffers=2. The
immense buffer space is else allocated but wasted. Because of a bug in the
code additional buffers are not used. I think buffers=1 would suffice, but 
the current code sets the minimum to 2.  

If you are fit with programming move the rvmalloc() and rvfree() calls to
newly created routines which for their part are called along dvb_open()
resp. dvb_close(). This way, precious kernel memory is only allocated when
and as long as a V4L application is accessing the driver.

> saa7146_v4l.o:
>  debug=1 print debugging information

Right.

> [...] 
> dmxdev.o: ?
> 
> dvb_demux.o: ?

Both, none.
 
> dvb.o:
>  debug=1 print debugging information
>  fdebug ?????

Not really clear. "fdebug" should have the meaning to print debug infos
when certain functions are _entered_. "debug" should print debug infos
from the processing _inside_ of the functions. May be it's my subjective
interpretation of these items. 

>  vidmem ????? (allocate memory for video what? buffers? what units does
> it use?)
>  vidlow ?????

No, not allocation. The driver is informed about the LFB address (linear
frame buffer) of the graphics card. It's only needed for overlay mode
(direct access of the graphics card's memory by the DVB card). tuxview,
xawtv, kwintv,... put this information automatically via VIDIOCSFBUF.

vidmem takes the higher 4 digits of the 8-digit hex address. vidlow takes
the lower 4 digits if any one of them is different from zero.

>  outstream ?????

I must admit: I don't know.

>  vidmode=CVBS_RGB_OUT (default). Analog output enabled (RCA connector on
> back plate).
>         =NO_OUT. disable analog output
> 	=CVBS_YC_OUT ???? (Y/C output on cards that have an S-Video connector
> ?)
> 	                  (Y/C output on internal on-board connector? If so,
> what's the pinout?)
> 	                  (simultaneous with CVBS output on RCA connector)
> 	=YC_OUT	?????     (Only Y/C output, on what connector?)

This may be true. I don't use the CVBS connector, so I haven't cared about
it.
You can use only numeric values as module argument, no symbolic values.

> ??????? How do I enable the RGB outputs of the SkyStar 1 card ? (related
> to this parameter?)

Use the Jx connector. (I don't have the x-number ready at the moment.
That 10-pin jumper between the tuner module and the DSP chip.) There were
already instructions in this mailing list how to use it.

>  napi=1 ???? (napi=new api?)

new API, yes. There is only one usage in the source code:
   if (napi)
      dvb_register_front...
I recommend not to waste too many thoughts about it. Simply don't use it
as module option.

>  init_chan=0 (default) show Pro7 on analog output when loading module.
> Dish on Astra 1.
>           =2           show n-tv on analog output when loading module.
> Dish on Astra 1.
>  why both predefined set to Astra 1?

init_chan=0: No initial channel is tuned in.
init_chan=2: n-tv is initially tuned in.
init_chan=<any other>: Pro7 is initially tuned in.

Change the code to whatever you like...

> tuner.o:
>  debug=1 print debugging information
>  type=-1 (default) tuner type. As defined in tuner.h
>           Not sure how it is automatically selected for the existing
> card.

-1 means "unset". It must be set if tuner.o shall work properly. Either by
module option "type" or by ioctl TUNER_SET_TYPE.
The code is in InitFront(). DVB-0.8.2 distinguishes only between two
tuner types: DVB-S and DVB-C.

>  addr=0 (default) 
>           Not sure how this is automatically set. 

It's the I2C address. 0 means "don't change the default values", because
0 can't be a real I2C address. The default values are given in the source
elsewhere. Use it as module option only if you experience phantom 
detections of tuner chips by the I2C kernel layer.

> in i2c.h:
> I don't really understand when and how this is used.
> [...]

Well, look at the docs which are part of the i2c-2.5.x, i2c-2.6.x
packages.
"probe" defines a list of single I2C addresses where the kernel layer
tries to detect the current chip on the I2C bus(ses).
"probe_range" defines one range of I2C addresses where....
The other variables are more unimportant.

> msp3400.c is never refered to in the Makefile. 
> What cards exactly do use this audio chip ?

Analogue PCB module for DVB-C.

> ost/src
> --------
> [...]
> --------
> None of them seem to need parameters.

Right.

> mknod -m 0666 /dev/ost/ca2     c 249  1
> device ca2 has MINOR=1 same as device ca1 while all other devices2 have
> MINOR=2.
> Is this a feature or a typo ?

Typo.

> dvb_ost.c seem to be rewritten into dvb.c. Is it needed anymore ?

No. But I think the evolution was inverse: It was an attempt to _exclude_
those functions from dvb.c.

> dvb_comcode.h contains comments in german. Can someone help me translate
> ?
> 
> // Vereinbarung der Command/Message Codes und der Statusbits
> // Verwendung im ARM  UND  im C++ Projekt

Declaration of command/message codes and status bits
Usage in ARM *and* C++ project
 
> #define SECTION_IPMPE		0x0C	// bis zu 4k gro_

size up to 4k

> #define SECTION_HIGH_SPEED	0x1C	// vergr÷_erter Puffer fnr High Speed
> Filter

extended buffer for HSF

> #define DATA_PIPING_FLAG	0x20	// fnr Data Piping Filter

for DPF

> /*	Definition der Speicherbereiche und Register des 
> 	DPRAM (von PC aus gesehen) und des DRAM (am AV7110)
> */

Definition of memory areas and registers of DPRAM (from PC's point of
view) and DRAM (attached to AV7110)

> Makefile contains rules to build the firmware but the files are missing. 
> Shouldn't these rules be removed from the distribution ?

May be.

> ost/src/Makefile 
> test: test.o $(OBJS)
> 	$(CC) $(CFLAGS) -I../include -o test  $< $(OBJS)
> 
> This rule does not refer to any existing file.

Right.


Bye,
     Rolf



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.