Re: [RFC/PATCH 1/2] usb: gadget: u_char: introduce chardev abstraction layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Mar 09, 2010 at 11:43:53AM -0800, Greg KH wrote:
> > you do if you want to use the composite framework to build all sorts
> > of possible combinations with mtp (which is currently using u_char.c).
> 
> Like what kind of combinations?  Does gadgetfs not support the composite
> framework?  If not, how about just solving that?

if you look at the composite framework, it expects us to bind a function
driver which won't be available with gadgetfs, at least until you load
the userland implementation. By then the usb cable might already have
been connected and we already passed to the host all our descriptors.

how do you suggest to solve that ? we can't simply change our
descriptors on the fly. We need at least a reset sent from the host. In
the case of the reset, we will need a special driver to give us the
reset based on a timer basis (?!?) since we can't notify the host (at
least with standard requests) that our mtp/video/hid device is now
available because gadgetfs application has loaded.

again, how do you suggest to solve that ?

gadgetfs is really cool but when we want to build composite drivers it's
just not really useful. And solving all those issues will be rather
complicated due to what I said above.

if you have good solutions for those, please let me know but as of now,
u_char.c seems better than tty for our usecase. With it, we could get
over 20MB/sec with musb on the TX path and about 14~18MB/sec on the RX
path. When using obex (u_serial.c) the troughput went down to a little
over 5MB/sec if I remember correctly.

> > u_char.c would also help on writting a USB HID gadget driver for
> > linux or even a Video Class driver.
> 
> We have USB HID code already using gadgetfs, right?  A video one would
> also not be that difficult from userspace.

and I'm not against that. But I also want to have the ability to build
up composite gadget drivers with those classes. To me, it's a lot
simpler to have video and hid functions drivers and build a composite
gadget exporting the devnodes to kernel than write the whole thing in
userland with gadgetfs.

besides, whatever userland stack is necessary to handle mtp/video/hid isn't
that portable anymore (unless you ifdef the code out) when you use
gadgetfs.

-- 
balbi

--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux