EIT seems to "trigger" the event, but it will happen even with EIT disabled, but much less frequent. EIT forces the adapter to be constantly active.
/Henrik On 3/11/07, Juha Ruotsalainen <[EMAIL PROTECTED]> wrote:
I'm using VDR. Could someone with more understanding tell me, can EIT be disabled in VDR? Or, alternatively, give an educated guess why enabling EIT causes USB disconnects? On 3/11/07, Eduard Huguet <[EMAIL PROTECTED]> wrote: > > > > From: Antti P Miettinen <[EMAIL PROTECTED]> > > To: [email protected] > > Date: Sat, 10 Mar 2007 21:44:37 +0200 > > Subject: [linux-dvb] Re: Nova-T 500 Channel scanning + EIT + Kernel > > oops... > > "Henrik Beckman" <[EMAIL PROTECTED]> writes: > > > Are there any differences in the windows stream ? > > > > Well, I've only managed to look at the beginning so far, but there > > seem to be at least some minor differences. > > > > The trace starts (after some descriptor reads) with firmware > > loading. The firmware seems to be in more or less Intel hex record [1] > > format and checked against that assumption I think what I extracted > > from the trace should be more or less OK. At least the record wise > > checksums match. > > > > There are some messages for which I cannot find any counterparts in > > the linux driver code. Before the firmware download starts the windows > > driver sends a five byte bulk packet to EP1: > > > > 02 a1 00 00 08 > > > > and receives eight byte bulk packet: > > > > d0 40 20 50 99 00 01 05 > > > > Then the firmware is sent just like in linux. Before the jumpram > > message, there is one 12 byte read: > > > > 00 00 00 00 70 00 00 00 06 11 60 d4 > > > > Looks like this contains the start address, maybe some kind of > > checksum. > > > > Then some decsriptor reading, setting configs, and then something that > > looks like the GPIO setting in the linux driver, but there's a small > > difference from what is done in bristol_frontend_attach(). If I'm > > interpreting the log correctly the windows driver is doing the > > equivalent of: > > > > dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1); > > dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 0); > > dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 0); > > msleep(10); > > dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 1); > > > > And then I got tired :-) > > > > I'll try deciphering the log more later. > > > > [1] http://en.wikipedia.org/wiki/Intel_HEX > > > > -- > > http://www.iki.fi/~ananaza/ <http://www.iki.fi/%7Eananaza/> > > > > > > Just as a matter of update, I've reenabled EIT scanning in MythTV just for > testing. It took less than 5 min to get a kernel oops due to the USB > disconnect ("dmesg | grep disconn" was explicit enough...). > > I don't know if this can help you in any way, but in my case the equation is > pretty clear: > > - EIT = USB disconnect > - No EIT = No USB disconnect > > :D > > Cheers, and thank you again for your hard work. > Eduard > -- jussi _______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________ linux-dvb mailing list [email protected] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
