> I've been considering for a while that, in addition to ->probe and ->remove, > we > have the following: > > "struct device" --> > ->attach - binds to the device and allocates data structures > ->probe - detects and sets up the hardware > ->start - begins transactions (like DMA) > ->stop - stops transactions > ->remove - prepares the hardware for no driver control > ->detach - frees stuff and unbinds the device > > ->start and ->stop would be optional, and only used where they apply.
>From my experience, this doesn't work. You actually want to have power transitions and start/stop semantics to be "atomic" as far as drvier state change is concerned. You can't for example stop all drivers, then in a second pass, change the power state, since after you have stopped drivers, you parent (bus) driver may not let you talk to your device anymore for obvious reasons (and thus may prevent you from doing the power state change). We really want all this to be part of the normal power management infrastructure. In this specific state, it's just basically a system state, that has already been discussed at lenght and that we nicknamed 'freeze' since it's exactly what suspend-to-disk needs before snapshoting the system image. > ->probe and ->remove would be useful for resource rebalancing > > Power management functions could (and usually should) manually call some of > these. Also this would be useful for error recovery and restarting devices. > > Still, cpufreq seems like a difficult problem. What's to prevent, > hypothetically, an SMP system from stoping a device while the upper class > layer tries to use it. Proper locking in the driver should prevent that. if you have a problem with "SMP", then you have a problem with preempt, and others ... then your model is flawed. > If the class level locks control of the device, then > DMA can't be stopped. Also, attempting to stop device activity may fail > if the driver decides it's not possible. No locking should be at the class level. All locking should be local to the device, unless the notion of device state is managed outside of the driver. I don't like this notion of "stop" separated from power states anyway, I think it just doesn't work in practice. Ben. > Thanks, > Adam > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
