Dear List, I am finishing up the last stages of a new driver for the TerraTec Piranha DVB-T adapter (Sanio SMS-100x chipset), and I have some general questions some of the more experienced driver writers could perhaps provide some advice on. First of all, because of some odd USB interfacing (see my previous mail about endpoints) I do not use the dvb-usb framework, but used the ttusb-budget driver as my main example. The device scans, tunes, filters PIDs etc correctly. With Kaffeine, one can do all the usual watching-TV stuff. Some details such as reporting signal quality are missing (so far). * All TS data comes in from a bulk endpoint, and always in quantities of exactly 21 TS packets (plus 8 byte header, so always exactly 3956 bytes, never more, never less). Occasionally a command-response is received on the same endpoint, about 12-60 bytes. How many urbs should I have doing the reading ? Does having multiple urbs help also for bulk transfers ? I allocate the memory with pci_alloc_consistent, one large block of "how-many-urbs * 3965" bytes and distribute this over the urbs. * When receiving a TS packet (so in the urb completion irq handler) I feed the TS data to dvb_dmx_swfilter(..). Is it OK to do that in the irq handler? (i.e. from a performance point of view the rule is to do as little as possbible in the completion function). * Can usb urb read completion callbacks come back concurrently, i.e. do I need to lock the call to dvb_dmx_swfilter(...) ? * When loading the module, and plugging in the device, the module becomes in-use and can not be unloaded until the device is unplugged. Is it possible to change this, so that the module will "close" the device and allow itself to be unloaded, event when the device is still plugged in ? * When unplugging the device during playback, the tv app stops (obviously), but the module gets stuck, i.e. can not be unloaded anymore and may or may not be in some kind of sane state where replugging the device will work. Can this be handled gracefully ? * Some applications request the frontend status very often (many times per second), to really ask the status from the device needs a round-trip request. Is it common to cache the results and only ask the device for an update occasionally, or is it normal to just ask every time ? (it just logs a lot of debug messages so it looks like a lot, don't know if it is really an issue) * The only locking I am doing currently is in sending a request and reading a response from the device (the whole routine, including the completion wait at the read step). This is similar to the "semusb" lock of the ttusb-budget driver. Where else should I be careful with locking ? * Any common gotchas I should keep in mind? :-) Thanks! Dennis _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
