Am Freitag, den 03.02.2006, 22:25 +0000 schrieb Mike Ferenduros: > 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 Hi Mike, very good job! The t->mode was the first suspect, but I thought V4L2_TUNER_DIGITAL_TV, defined in the API, is still mapped to be valid and it seems to read so. Obviously not. Cheers, Hermann > 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 > >
