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. In
particular, to make udc.c support, say, mq11xx_udc I would need to add
the respective if (!strcmp (driver, "mq11xx_udc")) {...}
> 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.
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
task similar to "list all natural numbers on a few rows". Perhaps it's
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.
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.
The arbiter will look through the capabilities of the UDC driver and
do its best to select a set of endpoints for the gadget driver. Some
requirements may be mandatory, some maybe just wishes. For example, a
driver may request a DMA-backed endpoint, if it is available and makes
sense for the gadget (if it does large data transfers), but if there's
no free DMA-backed endpoint it'll do just find without it. Or even whole
endpoints can be optional - for example, the g_ether gadget can work
with just two bulk endpoints, although it would prefer to have one more
endpoint for interrupt transfers.
People with memory-limited embedded systems can use a simpler arbiter,
which will use little code: it will be hardcoded for specific
gadgets+UDC combinations. The default gadget arbiter should be smart
enough to handle all UDC controllers. In fact, this arbiter is not
required anymore as soon as all gadget drivers are loaded; it just set
up the connection between these twose, and it can be safely unloaded
after that (so it's also a type of init-time additional cost, no
run-time).
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.
If some UDC has a limit on iso transfer length, this length should be
specified by the controller. Now if gadget doesn't say it can cope with
limited-length iso transfers, the arbiter will ignore this endpoint.
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
- Max packet length (as power-of two? 4 bits would be enough) (any UDC
with non-power-of-two maximum packet lengths?)
- Can use DMA in IN mode
- Can use DMA in OUT mode
- Maximum transfer length (perhaps in some units... power-of-two?
32-bit words?). Say 12 bits.
- Maybe something else I don't know about (yet).
That's 23 bits for now... 9 bits left for your imagination :) Not
enough? Add another 32-bit word and use it too...
Now a gadget driver could just pass the endpoint requirements to the
gadget arbiter in a array of 32-bit words, say something like this:
u32 first_endpoint [] = { IN | BULK | INDMA, IN | BULK }
u32 second_endpoint [] = { OUT | BULK | OUTDMA, OUT | BULK }
u32 third_endpoint [] = { IN | INT, 0 }
struct usb_gadget_endpoints_selector {
int alt_count;
u32 *epcaps;
} endpoint_selector [] = {
{ ARRAY_SIZE(first_endpoint), first_endpoint },
{ ARRAY_SIZE(second_endpoint), second_endpoint },
{ ARRAY_SIZE(third_endpoint), third_endpoint },
};
usb_gadget_select_endpoints (endpoint_selector,
ARRAY_SIZE (endpoint_selector));
The endpoint requirements are listed in a decreasing priority order,
e.g. for first endpoint it first looks for a unused IN BULK endpoint
that is backed by DMA, and if there's no free endpoint with such
characteristics, it looks then for a free simple IN BULK endpoint. The
capabilities request for third endpoint says: I want an IN INT endpoint,
but if there's no one free, I won't use this endpoint in general
(EP_STATUS_NUM in ether.c).
Matching such rules should be simple, thus the arbiter won't be that big
for those who care about memory size. In fact, this could be implemented
as a separate __init code (linked into every gadget driver that needs
it) that will be called at init time by the gadget driver; if gadget
driver is very specialized and works with one and only one UDC, it could
implement endpoint searching in any other way - it could even implement
its own, more sophisticated rules than the default arbiter.
Ok, this starts to be too long, I'll pause here for a while.
--
Greetings,
Andrew
-------------------------------------------------------
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
