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 <aet@xxxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>>> On Fri, 02 Mar 2007 23:06:15 +0100
>>>>>>> Pierre Willenbrock <pierre@xxxxxxxxxxxxxxxxxxxx> 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 <aet@xxxxxxxxxxxxxx>
>>>>>>
>>>>> 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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
