On Tue, 12 Jul 2005, Mac Michaels wrote: >> The way of the pll-programming is wrong in the lgdt3303. >> The tuner-programming should be out-sourced to either use >> dvb-pll or a pll_set-callback (or both). > > I would not be comfortable fixing this as the code looks > just a bit odd to me. Also, what does the .caps = > FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 | > FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO > mean for ATSC? I think for QAM. The demods I saw for ATSC/QAM have no register for setting the FEC rate, so I assume they specify the FEC rate automatically. Nonetheless the demods have the capibility, so it is correct to set the cap-bits here. OTOH, you cannot define the FEC rate when setting an ATSC frontend to use QAM. So, I guess this is superfluous. > Since this board is very new this driver has not had much > field testing. The driver was tested with a QAM-modulator with QAM256 and QAM64 and of course with 8VSB by the manufacturer, as far as I know. > I estimate that there are 3 registers that are manipulated > by the driver and are still the same. One of these has a > minor difference in that it selects between serial and > parallel hardware MPEG interface This is a board level > option that controls the interface with the PCI chip. > Fusion3 Gold uses serial and I think the card with the 3303 > uses parallel. (I'm not 100% sure about this as the > controlling bit may be different for the 3303.). > Selecting one or the other is a feature that new designs might need for > either chip. At some point this option should be controlled by a card > level selection. Yes, Output mode should be specified my the struct *_config passed to the _attach-function along with other card-specific options. > Most of the rest of the registers are either different or > have different uses. The differences could be handled by > if...else... code in about 6 places. Hmm, and maybe more, when new revisions of the demod will be out... >> Would the driver be bloated up to complete unreadability >> if the 3303-parts would be included in the 3302-driver? > > No. It would be more readable if the differences are > gathered together in an initialization structure. A > reasonable amount of work is required to achieve this. > > I am comfortable coding this, but I do not have the hardware > to test the 3303. I would be able to do an even better job > if I had access to the 3303 specification so I can > understand the differences. The card with dt3303 is not out yet. I'll try to get more information about it. best regards, Patrick. -- Mail: patrick.boettcher@xxxxxxx WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
