ext Greg KH wrote:
On Tue, Mar 09, 2010 at 05:16:40PM +0200, Felipe Balbi wrote:
On Tue, Mar 09, 2010 at 06:54:30AM -0800, Greg KH wrote:
Why is this needed? Why not just use the serial driver instead? That
should provide you with exactly the same end result, right?
we experienced several problems with tty layer. The biggest of them is
a race between flush_to_ldisc() and ->receiv_buf() which makes the line
discipline (I guess only n_tty) loose bytes in some circumstances.
That sounds like a bug we need to fix then, right?
On top of that there's also the performance issues with tty. the
u_serial.c forces us to push each bMaxPacketSize packet to the
controller driver which prevents us from actually getting some good deal
out of the DMA engine. With u_char.c we are unloading based on what's in
the kfifo right now (maybe we should use PAGE_SIZE transfers since our
kfifo is allocated using vmalloc()), and we can easily optimize that on
a per-product basis.
Then why not just fix u_serial.c to push the same ammount of data?
Performance is a key concept here; specially when we need to flash
hundreds of thousands of devices in a production line. Every milisecond
counts.
Sure, I understand, but it seems like it is easier to fix the existing
code for these minor things, than to write a whole new driver, right?
If you do that, then the existing users will also benifit from those
changes.
hi Greg,
We also needed the following from MTP point of view
1) ability to handle ioctls in gadget driver
2) capability to send ZLP/SLP (zero/short length packets) at precisely the
correct point in the data stream.
3) capability to send events received on EP0 to user space.
Is it good/possible to have these done in existing TTY framework?
regards,
-roger
--
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
