> #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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
