Manu Abraham wrote: > Patrick Boettcher wrote: >> Hi Jeremy, >> >> On Mon, 28 Nov 2005, Jeremy Nysen wrote: >>> The control data requests for dvb-usb devices (I'm testing with a >>> VP7045 device) is quite slow. Each request can take a few hundred >>> milliseconds to complete and return data. This gets longer when >>> multiple data bytes are requested from the frontend. eg. generating >>> 3 requests for 3 register bytes of AGC information for the MT352 in >>> the device can take a whole second. If I perform 6 requests it takes >>> twice as long. >> Reading the MT352 is an extension, which is (afair) not done in the >> Windowsdriver made by Twinhan. Additionally I have a large msleep in >> every read-function, because reads are failing "all the time". You >> can try to reduce the read-delay in vp7045.c to an optimal value. Twinhan's recommended firmware interface call for 'signal quality' is to use the same register access function you have used. Whether or not the Windows driver does this, who knows, but there doesn't appear to be any other signal quality function from the list they supplied. There is also a bug in vp7045-fe.c where it uses the wrong bits to calculate the snr. Ideally it should read all three snr bytes from the MT352 and process them along a non-linear curve to turn them into a linear 'quality' value. I'll work something out for this and send a patch for that function back to the list. > Reads will fail, as does happen in the PCI version too. Rather than > playing around with increasing/decreasing timeouts, this _is_ > nonsense. The dst too suffered from this same illness off playing with > transaction timings earlier and had unusually long delays. Asking end > users to play around with the timings would generally cause confusion, > and generally for each and every problem people would be fiddling with > the timings,, which is _not_ the actual solution. > > A better way would be _probably_ to handle the transaction errors > accordingly. ie, if there is an error_condition, handle the error > condition and retry the transaction. For the PCI cards, to identify > these transaction errors i had put verbose messages for these > operations such that people can report back on these, rather than > hiding them. These debug messages can be used to fix the actual problems. This sounds like a more methodical approach to solving the problem. Patrick, where is the right place to perform this error checking? Cheers, Jeremy
