Stuart Lynne wrote:
> I tried sending this to linux-usb-devel but it is not accepting my mail
> :-(
It gets that way sometimes. Anyway I've cc'd the list with my
responsive comments and haven't deleted any of yours. (Deleted
some of mine for brevity though, it's all in the list archives.)
Many thanks for your comments ... I know you've looked at these
issues a fair amount, though from a different perspective.
>>I thought I'd send around a version of something I've had on the
>>cooker for a bit In practical terms, not only is it thin, but
>>this is it for the API! No library level code (think "usbcore")
>>is needed, just some drivers. It's full (overfull) of functional
>>doc; it's gotta go somewhere! The structure is simple:
>>
>> - Hardware drivers do things like talk to the UDC on many ARM
>> based CPUs (Linux PDAs etc), PCI drivers like NetChip2280, the
>> Philips chips some folk use, and so on, and expose a simple API.
>>
>> - Gadget drivers do I/O using the endpoints exposed by that hardware
>> API, return usb descriptors, and enable/disable endpoints as needed
>> to implement the interfaces they expose (audio device, hid control,
>> networking, crypto, video, and so on). They own essentially all the
>> ep0 implementation code in the device.
>>
>>The API is URB-like, but it turns out that most of <linux/usb.h>
>>is host-centric. So for now only <linux/usb_ch9.h> is shared, but
>>it'd be good to share more. That way when we add USB role changes,
>>as required by OTG (slaves can become masters), the same I/O APIs
>>would work on bot sides. (Except of course for control requests.)
>>
>>...
>
>
> I think you need a middle layer. It needs to implement at a minimum:
>
> - registration of the function and bus interface drivers
I don't really see a need to have more than one of each at a time,
which makes this turn into very little code (a Good Thing).
* Certainly it can never be the case that a given bus interface
will talk to more than one function driver ... that's a basic
definitional thing. Only one can provide the device descriptor,
or the config descriptors that expose the device's function.
* While it's technically possible to have more than one device-side
bus interface driver (example: two net2280 chips on a PCI bus,
or two isp1181 chips with custom ISA-ish bus glue) that's contrary
to the design goals of USB. Such atypical bus hardware setups
could easily handle those issues themselves ... IMO this is an
issue of designing for the 99.9% of configurations.
On the other hand, you'll notice that the _interface_ doesn't force
any decisions about that particular issue at all.
> - implementation of the standard endpoint zero request handling
I want to see this live in function drivers, but it's worth discussing.
Why shouldn't all of that be handled by the function/gadget driver?
It's already got to do so for class, vendor, and "other" request types.
(Some of which are quite standard, just not part of the chapter 9 spec.)
Handing every such call to the function driver is a huge simplification,
and lets the more esoteric (and optional!) standard requests be handled
by drivers that really need them, and easily be ignored otherwise.
> - urb queuing
This is essentially a list_add_tail() call ... apart from whatever
hardware-specific logic is needed, like kicking a FIFO or filling
out and queueing a DMA descriptor and recovering from errors when
those can't be done. I've been unable to persuade myself to put
that list_add_tail() in common code; this is usually much simpler
than it is on the host side.
> If you don't have a middle layer you'll end up re-implementing all of
> that in each and every function driver. This is a needless replication
> of code and leads to inconsistant behaviour across function drivers.
Hmm, the urb queueing and registration issues would be hardware driver
issues, not function driver issues, as I had described things. And
testing (+bugfixing) will lead to consistency.
The ep0 implementation issues are more debatable, but there shouldn't
usually be much code there.
I'm not really opposed to a mid-layer here, but IMO any such should
be small ... but I've not seen anything yet that persuades me that
more of a mid-layer is needed than you saw in those inlines. Maybe
by the time the third hardware driver appears, I'll want one.
> I also doubt that you'll be able to make class/function drivers use a
> common API. At least not easily. It could be done but I really don't
> think it will actually get you anything.
I can't buy that one at all. The basic functionality is reading or
writing a buffer to an endpoint ... there's no justification for
that to vary because of the hardware. Did you see anything in those
read/write APIs that was hardware-specific?
The only complication is the ep0 code, and there are really only a
limited number of variances to be concerned with there: endpoint,
maxpacket, and so on. Easy to handle them all with #defines.
Yes, some of that will get a bit more clear when I post sample code
for such a gadget/function driver.
>>Looks like some people could have much fun with PXA-250 based PDAs,
>>they have fifteen endpoints! It ought to be easy to make the rocker
>>switches show up in a HID control, affecting the audio and video
>>streams, yes? :)
>
>
> Unfortunately the PXA USB can only support a single function. While it
> is possible to design a function that has multiple protocols you will
> need a class driver that knows what they all are and can do something
> interesting with them. It is NOT possible to implement a virtual hub and
> compound device with multiple separate function (drivers) that talk to
> multiple separate class drivers.
Erm, I *was* talking about a single function. With that many endpoints,
it's easy to come up with multiple configurations, each of which can
handle multiple interfaces. Compound devices need a _real_ hub chip.
In that example, three interfaces: HID, audio out, video out. One endpoint
each, with plenty left over ... and of course, the iso interfaces each need
altsettings (legal default configs may not include iso endpoints).
In fact, I can easily imagine people writing mostly reusable code to
handle those kinds of interfaces. At least for common media stream
formats, talking to the existing Linux media APIs (I'd sure hope!), and
for some of the more typical HID functionality.
As I said, "it ought to be easy..." and much of that is making more code
become hardware-neutral, so it can be reused.
>>>+ * usb_set_halt - set or clear the endpoint halt feature.
>...
>
> We never seen any reason to push this information up past the bus interface layer.
> Except perhaps indirectly as a cancelled URB.
Even for protocols like usb-storage, which halt endpoints to indicate
errors in the application protocol? How else would the function
driver halt the endpoint? Or (given ep0 logic as part of the function
driver) clear the halt?
>>>+ * usb_set_enable_sof - enables or disables start-of-frame callbacks
>...
>>
>>Enables or disables, yes -- like enabling or disabling the bits controlling
>>a SOF interrupt. I'm not sure what naming convention you'd use here, this is
>>one I've seen. I'm not sure how often drivers will really use this particular
>>feature, but some hardware does support it.
>
>
> Yes, the keyword being some devices. So having any code in the function
> driver that uses it limits where that function can be used.
No more than using, say, ISO endpoints ... not all hardware has them.
Yet I don't think you'd want to de-support ISO!
The thing about that functionality that bothers me is that expecting
interrupts at that rate just seems like a good thing to discourage,
even on hardware which can do it.
> We have used SOF interrupts to good purpose in the bus interface driver
> on one or two devices to help get around other hardware problems. But
> I'm not sure that telling the function driver about them on the few
> devices that support them gets you much.
I'd not miss this one if it were gone. Likely I'll just delete it from
the next version, it could always be restored later.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
