[linux-dvb] Pinnacle 300i (working!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

how did you manage to get the card working. I tried to fix the problem  
inside the sourcecode myself, but the card still does not work.

Which changes have to be made and how do I have to load the modules?

MfG
Tim

Am Fri, 3 Feb 2006 22:25:43 +0000 schrieb Mike Ferenduros  
<mike.ferenduros@xxxxxxxxx>:

> Hi,
>
> The problem seems to be that the mt2050 thinks it's an analog tuner -
> in mt2050_set_tv_freq(), the check for
> "V4L2_TUNER_DIGITAL_TV==t->mode" fails, so the wrong if2 is passed to
> mt2050_set_if_freq(). If I force if2 to the correct value then I get a
> good dvb scan and everything seems hunky-dory. But I have no idea why
> t->mode is wrong.
>
> Cheers,
> Mike Ferenduros
>
> On 2/3/06, Hartmut Hackmann <hartmut.hackmann@xxxxxxxxxxx> wrote:
>> Hi,
>>
>> hermann pitton wrote:
>> > Am Freitag, den 03.02.2006, 15:55 +0000 schrieb Mike Ferenduros:
>> >
>> >>Hi,
>> >>
>> >>Ah, the tuner module detects the mt2050 ok if I load tda9887 first,  
>> thanks
>> >>for the hint.
>> >>
>> >>Digital tuning is still broken though...there are no i2c problems I  
>> can see,
>> >>and the mt2050 says it's tuning to the right frequency, but nothing  
>> happens
>> >>beyond that.
>> >
>> >
>> > Interesting, we had lots of changes in the tuner area, but maybe the
>> > problem is somewhere else. After you try digital does the analog still
>> > work then?
>> >
>> >
>> >>Could anyone provide a log of a 300i doing a successful scan?
>> >
>> >
>> > Maybe Rainer can. The next suspect would be the TS interface then and
>> > one can enable debug for video-buf-dvb and ts_debug=1 for saa7134, see
>> > "modinfo saa7134" for further parameters. The changes here are _very_
>> > limited and Hartmut discussed them with Gerd, but I don't know if the
>> > saa7134 chip has been tested explicitly, since we are all mostly on
>> > saa7135 and 7131e, if it matters at all.
>> >
>> > Since Rainer says 20050627 works, there are only
>> >
>> >>http://www.linuxtv.org/cgi-bin/viewcvs.cgi/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-ts.c?root=v4l&r1=1.14&r2=1.15
>> >
>> > which Gerd explicitly changed the other way round previously for 300i
>> > and
>> >
>> >>http://www.linuxtv.org/cgi-bin/viewcvs.cgi/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-ts.c?root=v4l&r1=1.16&r2=1.17
>> >
>> > But you might have a look yourself with viewcvs.
>> > For the few changes in video-buf-dvb I assume no problems
>> > and these here are also only shots in the dark, since you seem to have
>> > no visible error messages. Strange.
>> >
>> I really don't think the problem lies in the TS interface. Even if it
>> were broken, this would not become visible before the channel decoder
>> reports lock. As far as i understood, it doesn't.
>> This is a just an idea:
>> The tuning procedure is "somewhat funny". The MT352 expects to control
>> the tuner via its own I2C master. This is not the case on this board.
>> The tuning procedure *might* be timing critical due to this.
>> In the suspected time frame, i added an msleep call in saa7134-i2c.c,  
>> line
>> 311 to ensure a sufficient gap between 2 messages. From the physical  
>> point
>> of view, a udelay(10) is sufficient but to my understanding, delay calls
>> should be avoided.
>> You might try to replace the msleep(1) by a udelay(10). Maybe this  
>> helps.
>>
>> Hartmut
>>
>
> _______________________________________________
> 
> linux-dvb@xxxxxxxxxxx
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>




[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux