Hi Felipe,
thank you for advice.
I've looked at your patch and it makes quite sense to me. But
surprisingly, it doesn't help. So I've done a small investigation and
I've added printk into "gs_flush_chars" and discovered, that it is never
called.
I suppose, that calling "tcflush(fd, TCOFLUSH)" should lead to calling
this function, but it does not. I'm not experienced in kernel
architecture, so I'm limited in further investigation. But if you'll
have some other clues, I'd gladly try them.
I'm also not sure about the when this timeout occurs. You mention that
it is in gs_start_tx, but I've found it only in gs_close:
if (gs_buf_data_avail(&port->port_write_buf) > 0 && gser) {
spin_unlock_irq(&port->port_lock);
wait_event_interruptible_timeout(port->drain_wait,
gs_writes_finished(port),
GS_CLOSE_TIMEOUT * HZ);
spin_lock_irq(&port->port_lock);
gser = port->port_usb;
}
Where GS_CLOSE_TIMEOUT is set to 15.
Personally, I've set GS_CLOSE_TIMEOUT to 0 and it suits perfectly for
me. By the way, don't you think, taht 15 seconds is soo long timeout for
flushing 8k buffer over usb? Even ordinary serial port set to 9600bd
should transfer this amount of data twice. Would not 1s or even less do
the job as well?
Nevertheless, I guess, that we should discover, where the problem lies
and proper flushing should be added.
thanks and best regards
Petr
--
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
