Raj, Ashok wrote:
>>> 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...)
>
So, I wasn't requesting anything *specifically* tied to ddi_setprop, etc,
A good example of what I'm talking about is how the SCSI capabilities
are managed (scsi_ifgetcap()) -- you pass a numeric "name", and get back
the value. You can do this in a read-write fashion too. For example,
look at how SDcard uses "properties": in
usr/src/uts/common/sys/sdcard/sda.h there are the sda_prop_t, and the
associated setprop and getprop routines in the sda_ops structure.
-- Garrett
> Cheers,
> ashok
>
