[linux-dvb] 3 patches for Kernel 2.6.19-rc5

Uwe Bugla uwe.bugla at gmx.de
Thu Nov 16 16:31:52 CET 2006

Hi Mauro,
“No. For most users, it is a risky option to allow DVB_CUSTOMISE. A
warning should be added here, marking that this option may make DVB to
stop working.”

True. I added a comment as it is in fact necessary for now. Thanks for the hint!
But if you take a closer look on the lines above you will see that I am on the right path so that it won't be risky anymore in the future! The core point is not the “risk” of doing wrong selections, but the real core point is the whole reactionary concept of the common backend for all bt8xx cards. This backend  needs to be overworked completely. But before this can be done MR. ABRAHAM needs to be taught the difference between a frontend and a backend driver! FACT IS that his DST contributions are situated in the directory where the backend resides. FACT IS ALSO that the header lines of his modules say the following:
“Frontend/Card driver for TwinHan DST Frontend.” While in the dvb-bt8xx.c backend module we all can read: “DST is not a frontend driver!!!”
SO WHAT THE HELL IS DST?? So in my patch number TWO I called DST a backend, as it is situated in the same directory as dvb-bt8xx.c, which IS a backend without any doubts!

“Same as above.”

Wrong. Nobody needs two security warnings for the same issue.
So here is revised patch number ONE:
This patch synchronizes the documentation with the current state of kernel compilation:
Signed-Off-By: Uwe Bugla <uwe.bugla at gmx.de>

--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt
@@ -9,9 +9,15 @@
 Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
 Compiling kernel please enable:
-a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux"
+a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Enable Video for Linux API 1 (DEPRECATED)"
-b.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
- => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
+b.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "Video Capture Adapters" => "BT848 Video For Linux"
+c.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
+ => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
+Use the following option with care as incompetent deselections of frontends may result in a non functional DVB system!
+If you know the frontend driver that your card needs please enable:
+d.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
+ => "DVB for Linux" "DVB Core Support" "Customize DVB Frontends" => "Customize the frontend modules to build"
+ You can save RAM by deselecting every frontend module that your DVB card does not need.
 2) Loading Modules

“This comment doesn't help. For 99,9% of the current DVB boards, DVB_PLL
is needed. So, help should be something like "this is required for most
boards. You should disable it only if you know what you are doing".”

Partially true, partially wrong.
The missing security warning is the true point about this.
But the statement “For 99,9% of the current DVB boards......” I would call RUBBISH! You could never have argued in this bashing manner if you only once would have taken a closer look at the code. I'll prove you in how far this is rubbish:
There are only two groups of cards who definitely need this module:
They are both belonging to the lgdt330x group.
a. DviCO Fusion HDTV cards
b. pcHDTV cards
There may be another 3 or 4 card types needing this, but NEVER IN THIS LIFE close to 100 %!!!!! RUBBISH!
I deselected all obsolete modules that my Pinnacle PCTVSAT card definitely never needed – dst.c, dst_ca.c, dvb-pll.c
So here is patch number 2:
This patch makes the following modules deselectable: dst.c, dst_ca.c, dvb-pll.c. Those modules are PROVEN BY FACTS (NOT ASSUMPTIONS!) COMPLETELY OBSOLETE if the only card in your system is a Pinnacle PCTV Sat card.
Signed-Off-By: Uwe Bugla <uwe.bugla at gmx.de>

--- a/drivers/media/dvb/bt8xx/Makefile
+++ b/drivers/media/dvb/bt8xx/Makefile
@@ -1,3 +1,5 @@
-obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
+obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o
+obj-$(CONFIG_DVB_DST) += dst.o
+obj-$(CONFIG_DVB_DST_CA) += dst_ca.o
 EXTRA_CFLAGS = -Idrivers/media/dvb/dvb-core/ -Idrivers/media/video/bt8xx -Idrivers/media/dvb/frontends
--- a/drivers/media/dvb/bt8xx/Kconfig
+++ b/drivers/media/dvb/bt8xx/Kconfig
@@ -1,14 +1,16 @@
 config DVB_BT8XX
 	tristate "BT8xx based PCI cards"
 	depends on DVB_CORE && PCI && I2C && VIDEO_BT848
-	select DVB_PLL
 	select DVB_MT352 if !DVB_FE_CUSTOMISE
 	select DVB_SP887X if !DVB_FE_CUSTOMISE
 	select DVB_NXT6000 if !DVB_FE_CUSTOMISE
 	select DVB_CX24110 if !DVB_FE_CUSTOMISE
 	select DVB_OR51211 if !DVB_FE_CUSTOMISE
 	select DVB_ZL10353 if !DVB_FE_CUSTOMISE
 	select FW_LOADER
 	  Support for PCI cards based on the Bt8xx PCI bridge. Examples are
@@ -21,3 +23,33 @@
 	  an external software decoder to watch TV on your computer.
 	  Say Y if you own such a device and want to use it.
+menu "Customise DVB Backends"
+	depends on DVB_BT8XX
+	bool "Customise the backend modules to build"
+	default N
+	help
+	  This allows the user to deselect backend drivers unnecessary
+	  for their hardware from the build. Use this option with care
+	  as deselecting backends which are in fact necessary will result
+	  in DVB devices which cannot be tuned due to lack of driver support.
+	  If unsure say N.
+config DVB_DST
+	tristate "DST TwinHan module"
+	depends on DVB_BT8XX
+	default m if DVB_BE_CUSTOMISE
+	help
+	  A DVB-S tuner module. Say Y when your card is a TwinHan or clone.
+config DVB_DST_CA
+	tristate "DST TwinHan CA module"
+	depends on DVB_BT8XX
+	default m if DVB_BE_CUSTOMISE
+	help
+	  A DVB-S tuner module. Say Y when your card has a conditional access slot.
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -264,8 +264,14 @@
 	depends on DVB_CORE
 config DVB_PLL
-	tristate
+	tristate "PLL support for DVB tuners"
 	depends on DVB_CORE && I2C
+	default m if !DVB_FE_CUSTOMISE
+	help
+	  This module is required for the DViCO FusionHDTV cards and the pcHDTV cards.
+	  You should only deselect it if you know what you are doing.
+	  If unsure say Y.
 config DVB_TDA826X
 	tristate "Philips TDA826X silicon tuner"

The compiler errors are the following:
WARNING: "dst_ca_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
WARNING: "dst_attach" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
WARNING: "dvb_pll_configure" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
WARNING: "dvb_pll_lg_tdvs_h06xf" [drivers/media/dvb/bt8xx/dvb-bt8xx.ko] undefined!
This happens when you try to load dvb-bt8xx.ko.

WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_attach
WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dst_ca_attach
WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_lg_tdvs_h06xf
WARNING: /lib/modules/2.6.19-rc5/kernel/drivers/media/dvb/bt8xx/dvb-bt8xx.ko needs unknown symbol dvb_pll_configure

Warning number 1 and 2 refers to the dst stuff, warning number 3 and 4 refer to the dvb-pll.c module which is a dependency of the lgdt330x.c module – PROOF:
1.	“return lg_h06xf_pll_set”: This is a cross reference to header file lg_h06xf.h.
2.	This header file contains: “include dvb-pll.h”
3.	dvb-pll.c is a pll library, old material left from the Gerd Knorr maintainership.
4.	NOONE has ever taken the pain to see through whether the 20 chips mentioned in this file are still up to date. And their reference to specific cards is anything but visible and clear! And the reason for that is NOT, as always stated, lack of time, but simply INCOMPETENCE!

So if you are at least arguing with ME please avoid using percentages that you will never be able to prove! Do you know the difference between a funded PROOF and an ASSUMPTION? I swear I know!
It's always the same old story, isn't it? Some people are too small to admit that they do not know exactly what they are saying. Instead of asking questions and be REAL open they bash down other people. This is the communication scheme that I already know from ABRAHAM! From exactly THAT GUY who made the group of cards I am talking about unusable for 4 complete kernels:
2.6.13, 2.6.14, 2.6.15, 2.6.16. And it was HIM bashing down people who did only want to help to get things solved! I DO NOT call this an OLD structure, I do not call this a conservative structure, and it isn't even a reactionary structure, BUT IT IS JUST A /DEV/NULL STRUCTURE! BASTA!
So if this is your street for expecting respect then this is a one way street, Mr. Chehab! And, last but not least, let me tell you that I share a whole lot of positive experiences with maintainers all around the world. Sometimes it is even fun to work problems out. But as soon as any problem touches a TV issue it feels like a nightmare! Where is Gerd Knorr and where are the Metzler Brothers? I just cannot believe that conditions were always like they are now!
And why is Abraham still present? In a modern enterprise he would have taken the emergency exit at highest speed for what he has done and is responsible for! And who grew him? It was Stezenbach growing him, noone else!

“NO! You are just removing DST support from the driver! Saves some memory
for your board, but breaks support for a large number of boards.”

“Large number” is WRONG! I PROVED IT ALREADY!
I can prove that it breaks support for the two groups of cards I already mentioned above. But instead of offering “perfect patches” (whatever that may be) I am searching for alternative solutions to save RAM!
In so far the following patch is a very humble one as it is partially destructive:

Number THREE – a humble helper patch for patch Number TWO.
In the proven case that the only card in your machine is a Pinnacle PCTV Sat (and ASSUMABLY THIS IS TRUE FOR MANY MANY OTHERS!!!!) this patch cleans obsolete module attachments so that module dvb-bt8xx.c can compile cleanly. I put it down as nondestructive as I could!
Signed-Off-By: Uwe Bugla <uwe.bugla at gmx.de>

--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -568,11 +568,6 @@
 	.demod_init = digitv_alps_tded4_demod_init,
-static int tdvs_tua6034_tuner_set_params(struct dvb_frontend* fe, struct dvb_frontend_parameters* params)
-	struct dvb_bt8xx_card *card = (struct dvb_bt8xx_card *) fe->dvb->priv;
-	return lg_h06xf_pll_set(fe, card->i2c_adapter, params);
 static struct lgdt330x_config tdvs_tua6034_config = {
 	.demod_address    = 0x0e,
@@ -614,11 +609,6 @@
-		card->fe = dvb_attach(lgdt330x_attach, &tdvs_tua6034_config, card->i2c_adapter);
-		if (card->fe != NULL) {
-			card->fe->ops.tuner_ops.set_params = tdvs_tua6034_tuner_set_params;
-			dprintk ("dvb_bt8xx: lgdt330x detected\n");
-		}
@@ -675,15 +665,9 @@
 		state->bt = card->bt;
 		state->dst_ca = NULL;
 		/*	DST is not a frontend, attaching the ASIC	*/
-		if (dvb_attach(dst_attach, state, &card->dvb_adapter) == NULL) {
-			printk("%s: Could not find a Twinhan DST.\n", __FUNCTION__);
-			break;
-		}
 		/*	Attach other DST peripherals if any		*/
 		/*	Conditional Access device			*/
 		card->fe = &state->frontend;
-		if (state->dst_hw_cap & DST_TYPE_HAS_CA)
-			dvb_attach(dst_ca_attach, state, &card->dvb_adapter);

It will easily show where the humble parts in the backend driver dvb-bt8xx.c are. If someone manages to find a solution in which those “wrong” or at least for some specific cases “obsolete” attachments do not happen anymore, then we all will win a system of deselection which is:
a. no more “risky” at all
b. highly efficient by saving lots of RAM!

P. S.: “He is always looking DVB support from his own personal prisma. Since he have (this should be “HAS”, Mauro, not “HAVE”) only a Pinnacle PCTV Sat DVB-S card, all other stuff for him is irrelevant.”
Doesn't that statement say everything about your real so-called “open-mindedness”?
If the path that I am going will be verified (that means: PROVEN BY FACTS!), the following will be a matter of fact (and a WIN) for everybody:

Thesis number 1:
A. The following cards neither need dst modules nor dvb-pll.c:
Pinnacle PCTV Sat:		 94
Nebula Electronics Digi TV:	104
Avermedia AverTV DVB-T 771:	123
Avermedia AverTV DVB-T 761:	124

Thesis number 2:
B. The following cards do not need dvb-pll.c at all:
Pinnacle PCTV Sat:		 94
Nebula Electronics Digi TV:	104
Twinhan DST and clones:		113
Avermedia AverTV DVB-T 771:	123
Avermedia AverTV DVB-T 761:	124

And I am very convinced that this list is incomplete! I ASSUME there are many many other cards who do not need the above mentioned modules at all!

Thesis number 3:
C. If the relationship “card type – frontend and backend name” can be cleared then the help sections in the deselection menus can be improved so that there won't be no more “risk” at all! As long as you are drowning this by sentences like “99,9 % of all cards need this dvb-pll.c module” you do not show any “open-mindedness” towards patchwork at all. The concept line should be: “Small, thin, effective” instead of “Fat, fatter, obsolete, dumb.”
So I am not talking about “benefits” or “risky features” at all, but I am simply talking about waste of RAM (for what a virus disguised as “operating system” is well-known). I do not want to be condemned to waste RAM with rubbish that I do not need at all! This is a kind of Windoze attitude that I cannot appreciate at all!
All I ask you is to work over the humble parts of dvb-bt8xx.c so that obsolete module attachments do not happen anymore. Would be a pleasure for everybody using this type of cards, wouldn't it? Or do I expect too much again?

"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

More information about the linux-dvb mailing list