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 <[EMAIL PROTECTED]>

--- 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 <[EMAIL PROTECTED]>

--- 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_PLL if !DVB_FE_CUSTOMISE
        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_LGDT330X if !DVB_FE_CUSTOMISE
        select DVB_ZL10353 if !DVB_FE_CUSTOMISE
+       select DVB_DST if !DVB_BE_CUSTOMISE
+       select DVB_DST_CA if !DVB_BE_CUSTOMISE
        select FW_LOADER
        help
          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
+
+config DVB_BE_CUSTOMISE
+       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.
+
+endmenu
--- 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!
IT IS: BIG MOUTH, NUT SHUT!
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 <[EMAIL PROTECTED]>

--- 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 @@
 
        case BTTV_BOARD_DVICO_FUSIONHDTV_5_LITE:
                lgdt330x_reset(card);
-               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");
-               }
                break;
 
        case BTTV_BOARD_NEBULA_DIGITV:
@@ -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);
                break;
 
        case BTTV_BOARD_PINNACLESAT:

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?

Cheers
Uwe
-- 
"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!

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Reply via email to