Do you want the device polled at some regular interval?
Then you could pretend it's an interrupt endpoint and
just set some suitable polling interval.  There is no guarantee
you get that exact interval, but if the interval is 2^N with
0<=N<=7 you get exactly that interval with all current host
controllers.

	-- Lennart

Matthias Drochner wrote:
> yamt@mwd.biglobe.ne.jp said:
> 
>>it usually means context switch in illegal context. i guess
>>usbd_do_request can't be used from interrupt context. 
> 
> 
> Yes - thanks, it seems that usbd_do_request attempts to sleep
> under some circumstances which happen randomly.
> 
> lennart@augustsson.net said:
> 
>>usbd_do_request() has to be used very carefully from a non-process
>>context.  Perhaps you should consider a kernel thread? 
> 
> 
> As I understand it, the kernel thread would be on an lower
> priority than the softclock handler, increasing the jitter
> even more.
> The original Linux driver used asynchronous USB calls --
> initiated from a timer handler, with the result delivered to
> a callback. I could perhaps model this with more low-level
> usbdi functions like usbd_setup_default_xfer(). Would that
> work? Can I reuse an xfer initialized that way, or do I have
> to call the usbd_setup_default_xfer() always before submitting?
> Is that interface for public consumption at all?
> 
> best regards
> Matthias
> 
>