DViCO FusionHDTV DVB-T Hybrid and ZL10353-based FusionHDTV DVB-T Plus support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx>

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@xxxxxxxxxxx>

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



_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux