> > The question is what is the right way to force the controller to catch
> > up, and ideally let the kernel do some other things in the mean time?
>
> What do standard serial port drivers do?
Stuff data into the chip and if need be maintain an internal buffer. One
of the problems with the serial stuff is that the buffering algorithms
you need to packetize serial streams without poor behaviour or overruns
are non trivial and the USB serial layer doesn't provide anything
remotely resembling sanity.
Secondly most USB serial drivers lie about their write room which causes
overruns.
What should happen is something like this
foo_write_room()
{
if(no_urbs_left) return 0;
if(one_urb_left) return bytes_in_urb_left;
else return size_of_one_urb;
}
foo_write()
{
stuff bytes into urb
if (urbs_left > 1 &&
some_function_of_bytes_queued_and_speed())
send_urb_now();
}
In other words never lie in the write_room method. Try to send data as
early as possible, but don't queue data inefficiently when the port has
plenty left to send.
The rules for write_room are simple
If you say you have space for X bytes you can't say you have room
for less bytes unless those bytes have actually been written - no
window shrinking so to speak.
If your write_room method works properly, and you fix the buffering logic
then the rest will work. Probably we need usb/serial/buffer.c which has a
generic implementation in then that can be used to replace the completely
bogus hacks in most of the drivers.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
