On Tue, Oct 19, 2004 at 11:54:48AM -0700, David Brownell wrote: > Hi Ben, > > Thanks for the preview/heads-up. > > On Tuesday 19 October 2004 7:48 am, Ben Dooks wrote: > > I've attacehd the latest version of the usb driver for the > > S3C2410/2440 onchip usb controller, including an interface > > for the board to tell the usb driver when it detects > > an over-current event. I would welcome comments on this > > driver, as I would like to get it included soon. > > Linus just merged a small mountain of USB patches > from Greg, so you'll need a version updated to match > that one. It should let you remove some cloned OHCI > init/reset logic.
Ok, i'll look at the next release and see what is necessary > > If you're up for it, I'd rather see a generic hook for > turning port N power on/off ... just hang a method in > the "struct ohci_hcd", and when it's there ohci-hub.c > would call it. It's not just S3C2410 boards needing > custom power switching (and overcurrent) handlers! Should we do something per-port, or for the whole root hub? > Also, please make your custom root hub control > request handler switch() like the others, so it's > more immediately obvious what's going on. That's > just a style thing. If we get the new control handling in place, we shoudln't need to actually have any code in there > There a several shim functions that shouldn't be > needed, like the irq handler and the platform > bus probe/remove functions. In both cases, > there's no need for the thin wrapper around > the code doing Real Work. That's a bit of > cut/paste from the old sa1111 code I'd like > to see go away ... makes things more complex > than they need to be! I'll see what happens with this out > .. I'll also have some small Kconfig patches that > I'll post soon, that should make adding another > flavor of embedded OHCI much easier. This > way's fine for the moment though. > > > > I have a couple of questions regrading the handling of > > the over-current handling, which seems to ignore the > > PORT_OVER_CURRENT field in the wPortStatus field, > > and only check the C_PORT_OVERCURRENT_CHANGE? > > You must mean in "hub.c"/usbcore .. what's the question? > > Rising edge signals the event and powers the port down > (as I recall), so there's no falling edge event to worry about. > I guess that means the C_* (change) bit must be latched; > and come to think of it, the point of powering down is to > get rid of the OVERCURRENT state! > > > > The second is that once this change has been detected, > > it seems that the port is then re-powered pretty > > much immediately, causing the system to keep bouncing > > the power, possibly a delay could be added so that > > the affected port(s) are not thrashed? > > That sounds like maybe your SC32410 code should > handle the issue; other hardware doesn't have that > problem. See the USB 2.0 spec for how hubs should > act, and make your root hub act that way. They may > say that the hub itself has such a timer; I don't recall > such problems being reported with other hubs. I'll have a look and see what needs to be done. Would it be easier to make a patch w/o the extra power switching code, or to wait until we have sorted out the power/oc control? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
