[linux-dvb] Preliminary examination of lgdt3303 driver.

Patrick Boettcher patrick.boettcher at desy.de
Tue Jul 12 23:05:24 CEST 2005

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

   Mail: patrick.boettcher at desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/

More information about the linux-dvb mailing list