[linux-dvb] DViCO FusionHDTV DVB-T Hybrid and ZL10353-based FusionHDTV DVB-T Plus support

Michael Krufky mkrufky at linuxtv.org
Tue Feb 28 19:48:13 CET 2006


Chris,

Please pull from:

http://linuxtv.org/hg/~mkrufky/zl10353

for the following changeset that I'd like applied to your tree:

-Kconfig: fix in-kernel build for cx88-dvb: zl10353 frontend

For those interested, Chris pushed the following changeset to his 
tree... The commit message says it all:

http://linuxtv.org/hg/~pascoe/v4l-dvb?cmd=changeset;node=c9fc14efaadc

Acked-by: Michael Krufky <mkrufky at linuxtv.org>

It looks fine to me overall, but I have a few comments:

#1) in-kernel build was broken, but fixed in my tree (see topmost link)

#2)  As I've mentioned before, I would have preferred to see a unified 
module with support for both MT352 and ZL10353, as I understand that 
many vendors that have previously shipped devices containing the mt352 
demod may ship newer models of the same unit, replacing the mt352 with a 
zl10353, without updating the card id / eeprom.  If we had a unified 
module that could autodetect which demod was present, then it would be 
an automatic upgrade for each driver that uses mt352, and a much cleaner 
solution for the card-level programming.  However, the unified module 
would probably be a huge mess of switch..case statements.  I don't have 
any specs for these demods, so I don't know if what I'm asking for is 
really possible or not.  Regardless, this is just something that I would 
like -- I have no problems with the zl10353.ko module as-is, and this 
should NOT be considered a show-stopper, as the module clearly works 
correctly.  Im not even sure if this is possible, as it seems that the 
interfaces of the individual frontend modules differ from each other.  
Maybe what I'm asking for isn't worth it... any opinions?

#3)
+/* FE6600 used on DViCO Hybrid */
+struct dvb_pll_desc dvb_pll_unknown_fe6600 = {

Why unknown???  Can we s/"dvb_pll_unknown_fe6600"/"dvb_pll_fe6600" ?  
...or is there something that I'm missing, here?

#4) Can you explain why the abundance of "#if 1 .. foo .. #endif" in the 
zl10353*.[ch] files?  Do you plan to keep that code there, or can we 
remove the #if 1 tests?

#5) We should probably also apply the following:  (not as crucial as the 
Kconfig fix, apply this at your discretion)

diff -r dec7cf4d918d linux/drivers/media/video/cx88/cx88-cards.c
--- a/linux/drivers/media/video/cx88/cx88-cards.c       Tue Feb 28 
17:02:15 2006
+++ b/linux/drivers/media/video/cx88/cx88-cards.c       Tue Feb 28 
13:55:27 2006
@@ -1448,7 +1448,7 @@
 {
        struct i2c_msg msg = { .addr = 0x45, .flags = 0 };
        int i, err;
-       u8 init_bufs[13][5] = {
+       static u8 init_bufs[13][5] = {
                { 0x10, 0x00, 0x20, 0x01, 0x03 },
                { 0x10, 0x10, 0x01, 0x00, 0x21 },
                { 0x10, 0x10, 0x10, 0x00, 0xCA },

(you might want to test this before applying, although I dont forsee any 
problems...  I tried to make it "static const" , but gcc didnt like that.)

Signed-off-by: Michael Krufky <mkrufky at linuxtv.org>

Chris, if you think that this code is ready for inclusion into the 
master repository, please let Mauro know, by sending him an 
hg-pull-request.....  or you can just let me know and I'll mention it to 
him when I speak with him next.

comments, anyone?

Regards,

Michael Krufky





More information about the linux-dvb mailing list