>> >> >> Predominantly, the issue to external devices is only idle, so that >> they can take other actions to reduce power. Part of the assumption >> here is that idle can absorb the extra latency required by the >> callback and will reduce the impact to performance. Considering that >> C/T/P-states will likely occur very frequently, having additional >> notifications could circumvent the value of those state transitions. >>
Randy is right. Our initial target is just focused on memory power management. This structure was a lot smaller when we started :-) the other hints were added assuming there might be different things we could do if we know more information.. say when next timeout etc once we have tickless implementation etc. so we can choose different state of power save for memory or other subsystems. >> Evolution of PAD (Power Aware Dispatcher) may change some of these >> considerations, but for now this is the most we want to open the door. >> >> >Fair enough. But, IMO, all the more reason to avoid hard coding a >structure and instead use property name/value pairs if at all possible. >It sounds like there is potential for significant evolution here in the >future. > Thanks Garrett. So you mean how we pass things like ddi_set_prop_valu?? Etc? is there an example you can point to us where a similar callback is structured in a form of name/value pairs as you suggest. Seems like a good approach, just point us in the right direction. As you pointed out the version etc were just for consideration in case we add new/remove old we could keep compatibility.. (but I agree it's a weak approach, generally things would break and you need to support legacy...) Cheers, ashok
