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.
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!
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.
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 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.
> My other problem is that the over current sensor on
> our board will only assert an over current whilst
> power is on, so it is only possible to asser the
> wPortStatus PORT_OVER_CURRENT flag wilst power is
> supplied to the port. Since the current port checks
> do not check this field, it would seem acceptable
> at the moment not to try and work around this
> problem.
Makes sense to me!
- Dave
>
> --
> 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
