Hi, Pierre Hartmut Hackmann schrieb: > Hi, Pierre > > Pierre Willenbrock schrieb: >> Hi Hartmut, >> >> Hartmut Hackmann schrieb: >>> Hi, Pierre >>> >>> Pierre Willenbrock schrieb: >>>> Hartmut Hackmann schrieb: >>>>> Hi, >>>>> >>>>> Aapo Tahkola schrieb: >>>>>> On Sat, 3 Mar 2007 03:10:41 +0200 >>>>>> Aapo Tahkola <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>>> On Fri, 02 Mar 2007 23:06:15 +0100 >>>>>>> Pierre Willenbrock <[EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>>> Michael Krufky schrieb: >>>>>>>>> Pierre Willenbrock wrote: >>>>>>>>>> Hi list, >>>>>>>>>> >>>>>>>>>> I am owner of a "MSI DIGIVOX mini-II". I got it to work using the >>>>>>>>>> attached patch and firmware. The patch and firmware are the >>>>>>>>>> result of analyzing some usb logs from windows. >>>>>>>>>> >>>>>>>>>> The patch breaks all users of tda10046, as i don't understand how >>>>>>>>>> that chip is supposed to work. The same goes for my driver >>>>>>>>>> implementation of the Philips 8275a. >>>>>>>>>> >>>>>>>>>> So this mess needs to be fixed before it can go into the >>>>>>>>>> repository. >>>>>>>>>> >>>>>>>>>> The patch is against a fresh hg checkout from >>>>>>>>>> http://linuxtv.org/hg/v4l-dvb at 2007-02-22 21:00 UTC. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Pierre >>>>>>>>> Pierre- >>>>>>>>> >>>>>>>>> I am very happy to hear that you got this device working... >>>>>>>>> Interestingly enough, we have already created a new tda827x dvb fe >>>>>>>>> module, which might be better for your device... This new tda827x >>>>>>>>> module has not yet been merged into the master v4l-dvb repository, >>>>>>>>> but it will be soon. Could you try to use the code located in: >>>>>>>>> >>>>>>>>> http://linuxtv.org/hg/~hhackmann/v4l-dvb >>>>>>>>> >>>>>>>>> The tda827x module will be able to detect the difference between >>>>>>>>> the tda8275 and the tda8275a ... You do not have to fill the >>>>>>>>> callback functions in the config struct -- that is really meant as >>>>>>>>> a hack for some required GPIO handling in the saa7134-dvb driver >>>>>>>>> for input switching. >>>>>>>>> >>>>>>>>> If you can generate a new patch against the repository above, it >>>>>>>>> would make it _much_ easier to integrate your patch into the >>>>>>>>> sources. After you get that done, we can work out the tda1004x >>>>>>>>> differences. >>>>>>>>> >>>>>>>>> You might also want to speak to aett and friedrich, regulars of >>>>>>>>> the #linuxtv irc chat room on irc.freenode.net ... aet is the >>>>>>>>> author of the m920x driver, and friedrich has the same device >>>>>>>>> that you have. They have been working on it, but haven't yet >>>>>>>>> gotten successful results. >>>>>>>>> >>>>>>>>> Good work! Hopefully we can clean this up after you generate a >>>>>>>>> new patch using the tda827x module from hhackmann's repository. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Mike Krufky >>>>>>>>> >>>>>>>> Hi Mike and Hartmut, >>>>>>>> >>>>>>>> this time, the patch does not change tda827x.c at all. I fiddled >>>>>>>> with the PHY2 value in tda1004x.c and found it to be related to the >>>>>>>> IF(there seems to be some factor between the IF and PHY2 introduced >>>>>>>> somewhere else). This leaves some differences in tda1004x.c. I don't >>>>>>>> know what to do with these, so i would be glad to get any hints. >>>>>>> Updated patch. I'm fine with these m920x changes. >>>>>>> >>>>>> Signed-of-by: Aapo Tahkola <[EMAIL PROTECTED]> >>>>>> >>>>> PHY2 indeed defines the IF frequency relative to the sampling frequency. >>>>> If you need a different value here, the reason most probably is the >>>>> following: >>>>> In some countries, i.e. Britain, France and Australia, the tranmitters >>>>> are +/- 166kHz off the channel center frequency. This isn't documented. >>>>> You can compensate this by simply tuning to the actually used channel >>>>> center frequency. >>>>> >>>> The windows driver used an IF of 4.75MHz for UHF, so i resorted to >>>> hardcoding it to 4.75MHz in tda827x.c, while using PHY2, WREF and the >>>> other settings from an usb log. After changing PHY2 the hack in >>>> tda827x.c is no longer needed. This leaves me with these settings for >>>> UHF(cannot test VHF -- i don't get any channels in that range): >>>> >>>> CONFPLL2=7 //52MHz sampling clock? >>> yes >>> >>>> FREQ_PHY2=0xc4f >>>> TIME_WREF1..5=0x5b, 0x02, 0xd0, 0x2d, 0x03 >>>> >>> This gives a IF center frequency of 5.0MHz and a bandwidth of 8MHz. >>> >>>>> A note: Some channel decoders can compensate this offset automatically. >>>>> The tda10046 needs assistance from the driver for this. This is not >>>>> built in yet. >>>>> >>>>> Hartmut >>>> Regards, >>>> Pierre >>>> >>> The only difference is that you use a sampling clock of 52MHz while the >>> original driver uses 48MHz. This btw is the same as the Philips default >>> driver for windows uses. >>> We could have a long discussion now about ideal sampling frequencies but >>> believe me: as long as your board does not have a weird interference >>> problem, 48MHz is the better choice for the sampling clock and adding a >>> additional one would only make life more difficult. >> I thought i checked that it does not easily work with 48MHz, but >> obviously i did not. The reception part works now perfectly without any >> modifications. >> > Ok, fine. > >> This leaves me with a last difference: >> >> CONF_TRISTATE1 must be -0-- -0-1 (binary, msb first, - is don't care) in >> tda10046_init. >> > The only difference i see here is bit 6 which enables the serial TS output. > All known applications yet use the parallel output but this can be different > in your case. > > RFC: should we make this a configuration option? > I would tend to add an entry "ts_mode" to tda1004x_config > which defaults to parallel (0) to remain backward compatible. At least > the standard modes should turn the other output off to avoid noise. > I can prepare a experimental patch for this to cross-check. > >> In case this helps, i am using AGC_IFO_AUTO_NEG and GPTRI, but >> CONF_POLARITY = 0x20 instead of 0x60 works, too, as well as >> CONFADC2=0x34 instead of 0x38. >> > You should use TDA10046_AGC_TDA827X, its a recommendation from Philips. > It reduces the AGC threshold to avoid distortion. > >> Regards, >> Pierre >> >> PS: A quick guess: 48MHz is said to interfere with the USB frequency? >> How does the tda10046 generate its clocks, anyway? >> > Hm, I have no idea about the spectral distribution on the USB interface. > The tda10046 generates its sampling (and processing) clock with a PLL > from a reference - either a crystal or from external source. Most probably > it uses the tuner reference (16MHz) in your case. > This clock MUST be very stable. This is one explaination why 48 MHz is a > good choice: it is a integer multiple of the reference. > > Hartmut > Here is the experimental patch i promised: The struct tda1004x_config has a new entry: .ts_mode Possible values are TDA10046_TS_PARALLEL or TDA10046_TS_SERIAL There always is only one interface active, default is parallel. Can you please give it a try?
Hartmut
diff -uNr v4l-dvb/linux/drivers/media/dvb/frontends/tda1004x.c v4l-dvb.new/linux/drivers/media/dvb/frontends/tda1004x.c --- v4l-dvb/linux/drivers/media/dvb/frontends/tda1004x.c 2007-03-17 02:07:11.000000000 +0100 +++ v4l-dvb.new/linux/drivers/media/dvb/frontends/tda1004x.c 2007-03-17 01:45:35.000000000 +0100 @@ -657,8 +657,16 @@ tda1004x_write_mask(state, TDA10046H_CONF_POLARITY, 0xf0, 0x60); // set AGC polarities break; } + if (state->config->ts_mode == 0) { + tda1004x_write_mask(state, TDA10046H_CONF_TRISTATE1, 0xc0, 0x40); + tda1004x_write_mask(state, 0x3a, 0x80, state->config->invert_oclk << 7); + } else { + tda1004x_write_mask(state, TDA10046H_CONF_TRISTATE1, 0xc0, 0x80); + tda1004x_write_mask(state, TDA10046H_CONF_POLARITY, 0x10, + state->config->invert_oclk << 4); + } tda1004x_write_byteI(state, TDA1004X_CONFADC2, 0x38); - tda1004x_write_byteI(state, TDA10046H_CONF_TRISTATE1, 0x79); // Turn IF AGC output on + tda1004x_write_mask (state, TDA10046H_CONF_TRISTATE1, 0x3e, 0x38); // Turn IF AGC output on tda1004x_write_byteI(state, TDA10046H_AGC_TUN_MIN, 0); // } tda1004x_write_byteI(state, TDA10046H_AGC_TUN_MAX, 0xff); // } AGC min/max values tda1004x_write_byteI(state, TDA10046H_AGC_IF_MIN, 0); // } @@ -668,7 +676,6 @@ tda1004x_write_byteI(state, TDA1004X_CONF_TS1, 7); // MPEG2 interface config tda1004x_write_byteI(state, TDA1004X_CONF_TS2, 0xc0); // MPEG2 interface config // tda1004x_write_mask(state, 0x50, 0x80, 0x80); // handle out of guard echoes - tda1004x_write_mask(state, 0x3a, 0x80, state->config->invert_oclk << 7); return 0; } diff -uNr v4l-dvb/linux/drivers/media/dvb/frontends/tda1004x.h v4l-dvb.new/linux/drivers/media/dvb/frontends/tda1004x.h --- v4l-dvb/linux/drivers/media/dvb/frontends/tda1004x.h 2007-03-17 02:07:11.000000000 +0100 +++ v4l-dvb.new/linux/drivers/media/dvb/frontends/tda1004x.h 2007-03-17 02:00:52.000000000 +0100 @@ -61,6 +61,11 @@ TDA10046_FREQ_052, /* low IF, 5.1667 MHZ for tda9889 */ }; +enum tda10046_tsout { + TDA10046_TS_PARALLEL = 0x00, /* parallel transport stream, default */ + TDA10046_TS_SERIAL = 0x01, /* serial transport stream */ +}; + struct tda1004x_config { /* the demodulator's i2c address */ @@ -72,6 +77,9 @@ /* Does the OCLK signal need inverted? */ u8 invert_oclk; + /* parallel or serial transport stream */ + enum tda10046_tsout ts_mode; + /* Xtal frequency, 4 or 16MHz*/ enum tda10046_xtal xtal_freq;
_______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb