On Tuesday 29 May 2007, Tony Lindgren wrote: > > > (Peripheral maintains _both_ b_hnp_enable set by > > > a_host and user preference on b_device on using > > > b_hnp_enable) > > > > That "user preference" is problematic. What do you > > end up with if that requirement for a user choice is > > removed ... ? > > How else do you tell when to use HNP then? It's the > b-device that needs to have that configured in, and > having HNP always enabled on b-device make sense either.
I don't see why it wouldn't. In fact, I what's always puzzled me is the notion of HNP under program control. (And it's puzzled most everyone else I've asked about it too. At this year's embedded systems conference the show floor had a lot more people who actually knew OTG ... a first. But nobody had a better use case for HNP than fixing the "hook cable up wrong" scenario.) Think of it this way: USB has had a *LOT* of effort put into its design to avoid the need for user error. Cables are keyed so there's no way to insert them the wrong way. Autoconfiguration. (A notion that Microsoft abhors, but that's their bug ... they want people to ship driver disks.) Power is delivered over the bus, so it's routine not to need a power brick (or batteries). And more. One of the basic design constraints of OTG is "no silent errors"; one part of that is exposing diagnostics, but another is minimizing even the potential for errors which need for them. Question: where would *needing* any user choice for HNP enter that picture? Answer: It doesn't. The *primary* purpose of HNP is to cope with a potential "error": user connected the "wrong" end of an OTG cable into a device, for the particular task they intended to perform. Example: a handheld device knows how to print (as host), but the printer only knows how to grab pictures from a camera ... but the user hooked them up wrong (printer is host), HNP fixes that error up pronto, handheld device can print as expected once it assumest that host role. > I think it's designed to as a ways for b-device to > request being a host, so it's not supposed to be automatic. > If you want automatic host mode, then just use a-cable, > right? And *WHEN* you hook up the other way around (maybe one end of your OTG cable was already hooked up), it should still work painlessly ... without the end user needing to care. Without needing to eyeball the connector to try and figure out which end is which. (I suspect a lot of OTG cables consist of MiniA adapters and standard A-to-MiniB cables, which will make it easier.) Remember that with OTG, end users aren't necessarily going to be aware of host vs peripheral. They'll just hook up an OTG cable the usual way -- whatever works! Then they'll expect their documents to start printing, or whatever. > Anyways, I'll play with an OPT and send patches in few > weeks, no need to do anything meanwhile unless somebody > else is also working on HNP stuff. > > > > > > ... deletia ... > > > > Glad to know the mechanisms are working. But right > > now I'm puzzled why musb_hdrc is misbehaving in > > host mode ... it's mangling descriptors as it reads > > them in. > > Which hardware? DaVinci or H4 with TUSB6010? At least > on N800 the host mode can go through testusb -a. H4/TUSB. I've not fired up DaVinci in a while. - Dave > > Tony > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
