Do all these URBs get created when the user writes to your driver's device file? If they do, then a simple approach needs only a mutex (so that only one write can happen at a time) and the value of "jiffies" as of the last URB. If the current transfer is too soon after the last one, do an interruptible sleep for the appropriate time before submitting the URB and releasing the mutex. This is much easier than keeping track of a queue of pending commands.
I'm using that approach right now in a way. Just to get things to work temporarily I placed an msleep() at the beginning of the write commands. This is essentially the same as your suggestion, but your's is more optimised for one-shot transfers. The problem with this (and the above) approach is that the user functions must block while the driver waits for the timeout to expire. This is particularly bad, for instance, if the user flicks a knob and the value changes 20 units. The user is stuck waiting for 2 seconds while the device "counts up". The user interface lags up even though most of the intermediate messages could have been omitted. Another problem is the way the radio seeks. To increase the frequency I must send two messages, in sequence, with a delay in between them. Then, I must wait for the next report sent from the device. If the reception quality is poor then I increase the frequency and repeat. But, changing the frequency requires a sleep, so I cannot call it from in_interrupt (the receive callback or timer). And it would be a plus if the user can call seek asynchronously as well since it can take up to 20 seconds to check the whole FM band and I don't want to require knowledge of threads. -Paul
> > If you want to be really clever, you can keep track of the status messages > > and reset the device if they no longer arrive as expected. > > Unfortunately the only way to reset this device is by cycling power > (the device has an external power source). Too bad. > I think what I'll end up doing is using a circular buffer. The file > operations will cause commands to be inserted into the cirular > buffer. There will a kthread that will send the next message from the > buffer and then sleep for the needed interval. I could use a timer > instead of a kthread, but at least the kthread's function will not be > in_interrupt. If you do it this way don't use a kthread, do use a timer. The fact that it runs atomically doesn't matter. > Does this sound fair or am I doing alot of work for something the > kernel may already provide me? I know the kernel has a ton of data > structures for queuing and locking but I don't think any of them apply > to my problem. I don't know of anything in particular that would be applicable. Alan Stern
------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
