Mark.Haywood at Sun.COM wrote: > Li, Aubrey wrote: >> On Saturday, December 01, 2007 4:01 AM, Mark.Haywood at Sun.COM wrote: >> >>> Mark Haywood wrote: >>>> Eric Saxe wrote: >>>>> Eric Saxe wrote: >>>>>> Li, Aubrey wrote: >>>>>>> C-state driver will let the processor go into deeper c-state. >>>>>>> >>>>>> I was thinking would use the existing mwait code path to bring >>>>>> the processor into the deeper c-states? >>>>>> ...or are you suggesting that the c-state driver would contain >>>>>> code that is invoked out of that path? >>>>>> >>>>> Sorry. In case you can't parse the above, let me try again. ;) >>>>> >>>>> I was thinking we would use the existing mwait code path to bring >>>>> the processor into the deeper c-states. >>>>> Are you suggesting that the c-state driver would contain the code >>>>> that could be invoked out of that path?... >>>>> or something else? >>>> I was wondering what we were going to do here too. Do the deeper >>>> c-states tend to be vendor specific mechanisms? If so, then I think >>>> we might want this support in a separate driver that can be >>>> accessed via something like layered ioctls? This is what I was >>>> thinking of doing with the reworked p-state support. >>> BTW, I don't know how expensive this kind of mechanism might be. >> >> I think the deeper c-states shouldn't be vendor specific. >> As long as: >> 1) the processor supports different power saving mode when it's in >> idle 2) the platform supports ACPI spec. > > Do we know if 2) is true. What I mean is that ACPI defines how to do > P-state transitions, but SpeedStep and PowerNow! (particularly the > Opteron type) are pretty different to implement. Is it unlikely that > there will be Vendor specific requirements for C-state support from > different vendors? > Is PowerNow already supported in Solaris? Please point the driver to me. If they are strictly complied with ACPI, then we'll get the io port after evaluate _PSS. And use that port the do speed transition. The question is, does PowerNow! use ACPICA?
C-state support is similar with P-state. If vendors are strictly complied with ACPI, Then we'll get the io port after evaluate _CST, and change the c-state by reading thoese ports. However, there may be one piece of vendor specific code if those ACPI objects return FFH, but this is another story. Does this make sense? Thanks, -Aubrey
