[linux-dvb] Preliminary examination of lgdt3303 driver.
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
> 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
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,
> Mail: patrick.boettcher at desy.de
> WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
> linux-dvb mailing list
> linux-dvb at linuxtv.org
More information about the linux-dvb