On Tue, 24 Feb 2004 11:56:18 -0800 David Brownell <[EMAIL PROTECTED]> wrote:
- See the autoconfig() routine in that user mode driver; it handles "bulk-only" configs just fine.
Yep, it just uses if()'s instead of #ifdef's, this is the only
difference. This doesn't overcome the first limitation you mentioned:
the need to modify every gadget driver as new UDC drivers are added.
Erm, it would overcome it if (as proposed) there were an autoconfig() routine that most "bulk-only" function drivers could share.
So the basic idea would be to have a kernel mode autoconfig() running from the gadget driver bind() method. That should live in the init section, so that costs are shifted only from compile-time to load-time, not into run-time.
So basically instead of spreading this UDC driver knowledge across multiple gadget drivers, you propose to make a central repository of this knowledge and let the gadget drivers use it, right? I can think of the following drawbacks:
a) The "function driver", as you call it, will have a lot more knowledge than required in any particular case. Yes, this can be #ifdef'ed carefully to ommit code for UDC drivers not compiled at all, but it anyway looks a kind of overkill. Like carrying around a encyclopaedia just to use from time to time the world map on a double-spread in the beginning of the book.
See above. One copy of that particular logic ... NOT (!!) part of the function driver (except by init linkage). Reusable library code. You understood that later (called it an evil "central repository", existence of which is bad); why not here?
b) There are so many possible configurations of one, two, three gadget drivers, and you'll have to specify a separate case for every useable configuration for every available UDC controller. It's a
Huh?? Not at all. There'd be a complication in terms of needing to "reserve" endpoints in composite configurations (each endpoint can only be used by one interface), yes ... a convention like "ep->driver_data non-null means it's already been allocated" seems sufficient.
You may not understand the word "configuration" yet. That means something very specific in USB, and I made a point to not use that word in any other sense.
task similar to "list all natural numbers on a few rows". Perhaps it's
You may be referring to the desire to combine function drivers into a single "composite" gadget driver (which can support several different configurations).
Counting such combinations is indeed combinatoric, but choosing any particular combination is a policy choice. So it isn't auto-configurable. It's got to be declared explicitly, part of what distinguishes one vendor/product ID pair from another one.
not a big issue today as we have just a few UDC drivers, but as new UDC chips are produced almost every day, after a few years this "central repository" will be a ultimate mess.
Given how different the UDCs are, there MUST be a place to fit heuristics in any autoconfiguration scheme.
By virtue of the endpoint naming policy, and by restricting that logic to "bulk-only" configurations, it's actually possible to automate most bulk autoconfig() logic. Something roughly like this:
- Ignore endpoints that were already allocated.
- Apply heuristics first. (goku: ep2 preferred for bulk IN,
because of DMA, ep3 for interrupt transfers since it's
only single-buffered. net2280: use ep-e and ep-f for
interrupts if maxpacket is 64 bytes or less. And so on.) - Ignore all direction-restricted endpoints where the
direction is wrong. (If you want IN, ignore "ep3out",
but "ep2" and "ep4-iso" are OK.) - Ignore all type-restricted endpoints where the endpoint
type isn't bulk. (So "ep1-bulk" is OK, so is "ep3",
but "ep4-iso" is no good.)- Any of the remaining endpoints should be OK.
With that approach, it'll be possible to avoid lots of special casing.
What I agree with you is that we need some intermediate arbiter between the UDC driver and the gadget drivers. There may be several alternative arbiters - but only one loaded at any given time. The gadget driver will tell the arbiter a set of requirements for the configuration it wants - the number of wanted endpoints, the endpoint type requirements and such.
That sounds a lot fancier than necessary. Have you looked at the USB class specifications, or most of the current bulk drivers? The requirements are: bulk-in, bulk-out. Optionally, a status transfer using an interrupt-in (or bulk-in) endpoint. End of requirements.
I recognize almost every UDC controller has its quirks. Well, these quirks just have to be described in controller's capabilities field and the arbiter should be modified to cope with this particular limitation.
The endpoint naming convention suffices to report almost all of those issues. (Except for the rather arbitrary ones where it's better to have simple heuristics.)
I believe all these capabilities can be described by a extra 32-bit word per endpoint, and perhaps an additional 32-bit word for the whole UDC (self-power flag comes to mind). Some endpoint capabilities:
- Can be configured as IN - Can be configured as OUT - Can be configured as INT - Can be configured as BULK - Can be configured as ISO
All of that information is already conveyed by the endpoint naming convention.
- Max packet length (as power-of two? 4 bits would be enough) (any UDC with non-power-of-two maximum packet lengths?)
Already exposed in the "struct usb_ep". Plus, this isn't sufficient ... there are double-buffering issues that drivers may need to know about.
...
Plus speed-specific issues, and interdependencies between endpoint configurations, and quirks that require driver level workarounds (like superh_udc endpoint halt processing), and probably even some things that pack into nice small non-algorithmic bit patterns... :)
That's 23 bits for now... 9 bits left for your imagination :) Not enough? Add another 32-bit word and use it too...
Well, since the most important information is already available, and the rest is such an open-ended set, I can't yet be convinced to start defining, allocating, and managing additional descriptive bits. The reason "bulk-only" is interesting is _precisely_ because it needs the least intelligence to autoconfigure. And the API is already exposing the most relevant information.
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
