On Fri, 2003-08-22 at 18:53, David Brownell wrote:
> Benjamin Herrenschmidt wrote:
> >
> > Patrick is currently merging a bunch of important PM updates that
> > should help for non-PPC platforms.
>
> I'm pulling Linus' tree right now; seems to have a bunch of them,
> but I wouldn't know if it's back to working yet.
>
> I do notice that one part of the patch was to remove per-driver
> suspend/resume calls in favor of per-bus_type calls. That means
> we may have to reconsider the (lack of) need for usb-specific
> suspend/resume calls that drivers would implement (to unlink
> or otherwise cleanup before suspend, etc).
Yes. In the past, we had "struct device" calls that ended up beeing
filled by the bus driver and just called the bus-type specific
equivalents (so the PCI layer with old & improper semantics still
get called :)
Note that save_state in PCI is really suspend() (with IRQs enabled)
and suspend() in PCI is really power_down() (with IRQs disabled). This
is the real confusing part, but that's because Patrick didn't change
all PCI drivers (yet ?) :)
The OHCI should probably hook on save_state (that is real suspend)
rather than powerdown ...
> > The root hub timer patch doesn't seem to have gotten in since I
> > saw calls to it (see my detailed comment below in my previous mail)
>
> OK, someone needs to resolve that. I think it was a Paul Mackerras
> patch, from earlier this month. I just forwarded the last copy
> of the patch that I had sitting around.
Thanks.
> That kind of magic I don't like. It might be better to take
> a "we know it'll work" approach on 2.6 at this point, rather
> than find out what the exact problems were. ("usb-ohci" would
> leak TDs on some paths. That problem appears to be fixed now.)
Well, I want something robust in 2.6.
> Simpler to just check hcd->state and fail if it's not running.
Yup.
> > urb enqueue should fail imho (it could be implemented if we shadow
> > the queue registers but I prefer sending an error to a driver doing
> > the wrong thing), but doesn't it fail currently _after_ dealing
> > with the ED ? urb dequeue could be implemented with shadow registers
> > or be able to fail, but the later seem more complicated, don't you
> > think ?
>
> I don't follow you. If we go the "all urbs must be dequeued
> before we suspend" route, there's not going to be a problem.
> Then all the enqueue/dequeue paths will just check hcd->state
> and fail if it's not running.
Well... I though dequeue() couldn't fail, it seems I'm wrong after
double checking the code. So yes, that's a safe assumption and makes
things much simpler.
> Actually one of the goals of the HCD glue layer is to move most
> of the shared functionality into shared code, so that each HCD
> doesn't need to re-implement/re-debug such stuff ... and so that
> we don't have as many differences between HCDs. That's also a
> goal of the driver model: more similarity between drivers.
>
> In this case, there are certainly OHCI-specific things to do,
> like ASIC hooks that only make sense on PMAC, but most of the
> other things you've mentioned are also needed for EHCI and UHCI.
> So we'll be better off if most of the updates are generic.
Sure. Testing for hcd state and failing enqueue/dequeue should
surely be done in the generic layer.
I'll do more tests this week-end and see if I can come up with
a patch doing what we said that works (at least with no device
plugged, currently, I get problems even without anything plugged,
but I haven't had much time to dig further than the root hub
problem).
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
