>>> - Have you given any thought on how the kernel is going to
>>> access the ACPI C-state data?
>>>
>> Here is what I am thinking now. Only an acpi_idle() function will be
>> offered to the kernel.
>> If deeper c-state is supported, idle_cpu will be acpi_idle().
>>
>> So here is acpi_idle() prototype.
>>
>> acpi_idle()
>> {
>> switch(next_idle_type)
>> case C1:
>> idle_cpu = cpu_idle or cpu_idle_mwait
>> case C2:
>> idle_cpu = acpi_idle_C2
>> case C3:
>> idle_cpu = acpi_idle_C3
>>
>> idle_policy();
>> }
>> Any suggestions?
>>
>
> Sure that looks good. My question was more directed at how the kernel is
> going to access C-state data/functions in the driver. The P-state
> support works because Sun's DDI includes a dev_ops devo_power entry.
Perhaps acpi_idle could call a policy function which decides which idle
state to enter?
acpi_idle would then do whichever idle halt it should do.
Something like:
acpi_idle()
{
do_idle_preprocessing /* dtrace probes etc */
spin:
switch (idle_policy())
case SPIN_IDLE;
smp_pause()
goto spin
break
case HALT_C1:
halt_idle_c1()
break
case MWAIT_C1:
mwait_idle_c1()
break
case ACPI_C2:
acpi_idle_c2()
break
case ACPI_C3:
acpi_idle_c3()
break
}
do_idle_postprocessing(); /* dtrace probes etc */
}
This scheme would allow us to plug in whatever policy function we want
for testing. The policy could be based on time until the next cyclic
interrupt
and hints from the power aware scheduler.
This scheme would also allow us to do adaptive idle on systems which have
a lower latence mwait which uses more power than halt. The processor
could use mwait if it knew it was going to wake up soon and halt if it was
going to be idle a long time.
Bill
