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@xxxxxxx > WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ > > _______________________________________________ > > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
