On Wednesday 23 January 2008, Anil Yadav wrote:
> Hi,
> 
> I am working on a gadget which is based on kernel-2.4.28.

That's pretty old ... I hope there's some compelling reason
that such new development can't use a current (2.6.2x) kernel!


> I gone through the documents available on web for gadget driver
> implementation. I am having a problem in deciding whether to implement
> user space driver or in kernel.

The 2.4 kernel doesn't have gadgetfs.  So you'd be
using very old chardev based code, which isn't even
part of the standard kernel ... that would urge use
of custom code for the kernel part of your driver.


> Actually My driver have 2 
> configurations. Device will work in the configuration selected by the
> host when host sends SET_CONFIGURATION (host will come to know the no.
> of configurations by GET_CONFIGURATION). 

Normally the host will come to know how many configurations the
peripheral has because it's told that in the device descriptor,
through a GET_DESCRIPTOR call.  ;)


> There are 2 interfaces in the 
> configuration 0 and 3 interfaces in configuration 1.

Presumably you mean "configuration INDEX 0" and "INDEX 1";
configuration "NUMBER 0" means "unconfigured", and it has
no interfaces at all.


> I have to 
> implement the interface driver in configuration1. This driver will
> take care of  bulk transfer and isochronous transfer.

Both in the same interface?  That's unusual (but potentially OK).
Normally there'd be one interface dedicated to isochronous
transfers ... altsetting 0 having no endpoints, altsetting 1 having
ISO endpoints with one bandwidth demand, other altsettings using
different amounts of ISO bandwidth.


> As far as bulk 
> transfer is concerned there are not much issues as it transfers vendor
> commands only, but for Isochronous transfer I need to transfer
> data(audio) to Host. I gone through the text at
> http://tali.admingilde.org/linux-docbook/gadget/index.html which says
> Async I/O is available in kernel 2.6. My kernel is 2.4 as I mentioned
> where async I/O is not supported. In such circumstances Whether doing
> ISOC transfer from user space will be a nice thing to do?
> How the latency will affect the performance of the driver?

That entirely depends on how that driver works.  You can do what
some of the audio drivers do and work with an mmapped ring buffer,
and that'd be about as good as you'd get ... synch between kernel
code and userspace being a likely problem area, but not one that's
unique to the driver.  The 2.6 code does expect to use AIO there.



> Furthermore I gone through the code of inode.c (gadgetfs) which will
> be used to implement the driver in user space. The document "[patch
> 2.6.0-test4] usb "gadgetfs" (1/2)" at http://lwn.net/Articles/47571/

I'm sure there's an old version of that code that ran on 2.4 kernels;
check linux-usb list archives.  If you're going to use code that old,
rather than from a current kernel, you might as well use something
that requires less backporting.  ;)


> link says the driver supports single configuration and the code in
> dev_config()
> if (dev->dev->bLength != USB_DT_DEVICE_SIZE
>                       || dev->dev->bDescriptorType != USB_DT_DEVICE
>                       || dev->dev->bNumConfigurations != 1)
>               goto fail;
>       dev->dev->bNumConfigurations = 1;
>       dev->dev->bcdUSB = __constant_cpu_to_le16 (0x0200);
> also says so.
> I am not sure by using gadgetfs I cannot provide options of having 2
> configurations to Host ?

You'd have to change the userspace interface.  Nobody yet has been
interested enough to support multiple configurations, so it's still
got the original restrictions.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to