Hi ! The new ohci-hcd driver in 2.6 doesn't work for Power Management on Apple laptops at least. I've studied the code, but since I'm not very familiar with the whole new hcd architecture, I'm sure I'm still missing a lot.
The big problem with the current code is that it will still access the chip after suspend. (Or during the suspend operation, it would be better to properly stop all activities before writing to the control register to suspend the chip). This access cause a wide variety of side effects for me, ranging from lockup during the sleep process to memory corruption of the machine (possibly incorrect bus mastering, despite the removal of PCI_COMMAND_MASTER) or other possibly problems internal to Apple ASICs. In a more general thinking, I fell it's unsafe for other archs as well to have code tapping a chip that is in D3 mode... So I started looking at what should be done to "fix" that, but there I'm probably missing things. So far, I've seen: - The root hub timer. I hacked the get status function to return 0 when ohci->sleeping is set, though that would need proper synchronisation on SMP etc...That helped not locking up 100% of the time during the suspend process, but I'm still having the problem waking the machine up (memory corruption). I also reject root hub control urbs - It seems that we don't accept to link urbs (ohci_urb_enqueue returns with an error), however, ohci_urb_dequeue may do things that end up touching the queue head registers. Those registers should probably be shadowed some way. - I haven't yet figured out other code path leading to touching chip registers outside of the above, I'm not too sure about the ED stuffs. Any suggestion ? Right now, my fix to the root hub isn't enough it seems but I haven't yet spotted what else is touching the chip. The proper sequence of operations would probably be something like (similar to what we have today) for S3 (and S2 if we ever use that) - Set ohci->sleeping - Disable all IRQs but SF. From this point, no "link" operation is accepted (URBs or EDs) and root hub stops polling. Unlinks are still allowed - Wait a few frames so pending unlinks and done queue can be flushed - Mark the chip as suspended. This could be setting ohci->sleeping to 2 or using another flag. This one really means DO NOT TOUCH THE HW again (we could have wrappers on read/writel catching bugs here eventually but that would be ugly). At this point, unlinks will be done on shadow of the list head registers only. Make sure we sychronize with a pending unlink on another CPU - Really suspend the chip (write to control etc...) - Do the remaining bits ... (PCI PM mode, PowerMac specific shutdown code etc....) Do that seem correct to you ? In the case of S4 (suspend-to-disk), I beleive we have no much choice but doing a full unplug/replug of all devices though I'm not sure how to trigger that. 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
