[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-dvb
Subject:    [linux-dvb] Re: DViCO FusionHDTV DVB-T Hybrid and ZL10353-based
From:       Christopher Pascoe <c.pascoe () itee ! uq ! edu ! au>
Date:       2006-02-28 23:28:37
Message-ID: Pine.GSO.4.60.0603010906430.15072 () mango ! itee ! uq ! edu ! au
[Download RAW message or body]

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

Thanks, I have pulled that.

> #2)  As I've mentioned before, I would have preferred to see a unified module
> with support for both MT352 and ZL10353, 
[...]
> 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?

Whilst I agree it would be nice to have them in one, the problem as I see 
it is that the sequence to init the ZL10353 varies significantly from that 
to init the MT352.  Just blasting the MT352 init sequence at a ZL10353 
isn't going to work - we still have to identify the appropriate sequence 
for each board with the new chip, and patch appropriately.  The extra 
test and demod_init routine can be added to the board driver at that time.

Admittedly, the two ZL10353 based boards that I have tested on (both from 
DViCO) have compatible initialization strings, but this is how MT352 was 
when it started out.  Only by seeing the init sequences from further cards 
will we be able to tell how much more needs to be split out.

Also, having it as a separate module also has the side effect that anyone 
developing embedded products who knows they'll never use the other device 
type can throw away the code that they don't need.

> #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?

Every other card type has a vendor there.  I don't know the vendor for the 
FE6600, so I put unknown.  Perhaps someone else knows who makes the 
frontend.

> #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?

>From README.HG #16, this is test code that shouldn't go to mainline.  If 
people running the dev trees have problems, they can enable this to get 
register states, and I can get some idea about what is going on.

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

Done.

> 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.

I'm going to have the DVB-T Plus tested by a few more people and will let 
Mauro know when things appear satisfactory (hopefully on Monday next 
week).

Chris

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

[prev in list] [next in list] [prev in thread] [next in thread]