Richard Pitt wrote: > The OTG extension to the 2.0 standard is where you want to go I'd > suggest.
If you're saying that we should plan on an API that can handle OTG, then yes! In 2.5 we have a small part already: <linux/usb_ch9.h> lets host and device side driver APIs use the same standard usb data structures. But that's for later. Walk first, then fly; an OTG-ready API must also handle pure "gadget" applications, and that's the part I sent around. > The typical embedded SA1100 systems don't have host capable USB and > nothing you do in software will fix this. They also don't have enough > end points to do RNDIS (for example). Or hardware capabilities to implement usb audio, example #2. Which is why the PXA250 (replacing it) gets interesting. OTG-capable products are a bit esoteric for now ... :) - Dave > richard > > On Sat, 2003-01-04 at 12:44, David Brownell wrote: > >>Dmitri quoted: >> > >> > http://www.embedded.com/story/OEG20021217S0036 >> >>Plus I'm still planning to follow up on this bit >>I posted a while back, with some running code: >> >> http://lwn.net/Articles/16117/ >> >>The goal being to have an API masking hardware details. >>Like whether it's an sa1100 underneath, or is instead >>something more flexible ... with endpoints to burn and >>maybe even capable of high speed operation. That way >>widely used drivers (like network or serial interfaces, >>as described in that "embedded.com" article) can run >>on other gadget hardware with minimal porting efforts. >> >>Certainly, having it work on SA-1100 hardware will >>help nudge things along, considering how many SA-1100 >>based PDAs are running Linux already! >> >>- Dave >> > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
