[linux-dvb] Preliminary examination of lgdt3303 driver.

Mac Michaels wmichaels1 at earthlink.net
Tue Jul 12 21:51:43 CEST 2005


On Tuesday 12 July 2005 12:17 pm, Patrick Boettcher wrote:
> Hi Mac,
>
> On Tue, 12 Jul 2005, Mac Michaels wrote:
> > I examined the lgdt3303  driver to see if it makes
> > sense to merge it with the lgdt3302 driver. I don't
> > have a spec sheet for the 3303 chip so I may have made
> > some errors in my examination. It may be pin
> > compatible, but it is not software compatible.
> >
> :(
> :
> > The lgdt3303 is connected to a different PCI interface
> > chip than the lgdt3302.
>
> Hmm, that is why there are frontend-drivers. To reuse the
> driver on different PCI boards or USB boxes or somewhere
> in embedded systems or whatever. Frontend-drivers should
> be independ of the card's/box's BUS and tuner and other
> hardware. That's why the bus-driver implements an
> I2C-adapter, which is the bus the demod-driver talks to
> its IC.
>
> > Overall the driver structure is nearly identical.
> > Different registers are used by the 3303 in a lot of
> > places. Some of the registers are read only in the 3302
> > and writable in the 3303. A number of new registers are
> > set in the 3303. The drivers could be combined, but I
> > am not sure how beneficial that would be.
> >
> > There is an unusual way of setting up the tuner.
>
> 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 do not recommend merging the two drivers at this
> > time.

Since this board is very new this driver has not had much 
field testing.

> So, how different is the register-programming. Can you
> describe it in more detail. From your point of view, is
> the lgdt3033 just an extension or really completely
> different.

Actually programming the chip with i2c is identical for both 
3302 and 3303. Routines to read or write the registers on 
the chip use the same i2c techniques.

The default values of the 330x chips are correct for most 
designs. Although the default values are different on the 
two chips, they have no impact on the driver. A few 
registers need to be adjusted to select specific options 
and values required by the design. A few other registers 
are required to select between 8VSB, QAM64, and QAM256.

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.

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.

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

> thanks for your investigations,
> Patrick.
>
> --
>    Mail: patrick.boettcher at desy.de
>    WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb




More information about the linux-dvb mailing list