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