Re: [Syllable-developer] [patch] PowerNow CPU frequency scaling

[Tim t. L. <ti...@sc...>]

On Sun, 10 Jun 2007, Kristian Van Der Vliet wrote:

> Has there been any further development? I see some of the patches have
> been put into CVS but no drivers. Did Arno & yourself manage to come to
> an agreement on how the ACPI & hardware drivers should interact?
>
> P.S: Sorry for the large included text but I wanted to jog peoples
> memories without forcing you all to hunt for old emails!

I didn't have time to work on this for a while, but I did read a lot of 
the ACPI spec and actually started coding again a few days ago.

The next iteration of my PowerNow driver is meant to include also parsing 
of the relevant ACPI objects (especially _PSS) to read supported 
frequencies. I intend to merge the info from both sources, as opposed to 
the Linux and FreeBSD drivers which choose one and fall back on the other. 
Hopefully that will get me the best of both worlds, instead of the 
worst :)

Also it appears Arno's ACPI Processor driver doesn't clash with my 
PowerNow driver. The ACPI objects contain info useful to my driver, but on 
their own cannot provide the info needed for an ACPI-only driver (this 
because PowerNow works only with special CPU registers, ACPI cannot 
describe those). So that's not a very pressing problem right now, although 
we might eventually need such a mechanism, in CPU scaling (SpeedStep has 
quite a few variants it seems) or other subsystems.

I don't remember a reaction of Arno on my suggestion to split his driver 
into a seperate ACPI C-states driver and a ACPI Processor frequency 
driver.

>>> Processors already get registered by another part of the system, but
>>> I can't think where. Arno may be able to help. I'd suggest we stick
>>> to "generic" interfaces for as much functionaliy as possible, not just
>>> for frequency scalling, and do it all via. generic CPU device nodes
>>> and extend those with device specific IOCTLs where required.
>>
>> But then the scaling driver would not be able to claim the device, or am I
>> missing something here? That would make it difficult to create fallback
>> drivers I think.

My above reply is rather moot at the moment, but I do have some other 
comments and questions now. Right now I can see 3 more or less sane ways 
to do this:

1. Have indeed 1 device node per (logical?) CPU, managed by a "driver"
    inside the core kernel. Drivers like those for frequency scaling then
    register functions with the CPU driver to handle specific ioctls. We
    would need to manage the ioctl numbers very good to prevent clashes,
    but I think it is managable. (Alternatively you could implement a
    specific ioctl as a "name service", like the NFS portmapper. But I
    think that is overengineering). I'm more concerned about the difficulty
    for userspace to determine which functionality is supported, and how we
    can get the extension drivers to load. Also, would we need a CPU
    busmanager to get hold of the CPU driver, or is there a better way?

2. Create a device for every CPU sub-function we'd like to support, at the
    same place in the code that now creates the CPU devices. So for each
    CPU, a CPU<n>-frequency, CPU<n>-throttling, CPU<n>-Cstates,
    CPU<n>-microcode, etc. An advantage is that we can just keep using our
    current system for triggering driver load, device claiming, node
    creation etc. Disadvantages are of course that we're speculatively
    creating devices (we don't know in advance if the CPU actually supports
    frequency scaling), potentially a lot of them, and that you need to
    change the core kernel for every additional class of functionality.
    Again, would all the created devices need to be under a CPU busmanager?

3. Put a frequency scaling subsystem into the core kernel, like Linux (and
    I think FreeBSD too) have done. Advantage is you can share common code,
    especially if you're also going to support loadable policies in the
    kernel. It would also mean a lot of code that not everybody needs
    though. It's not something I'd be looking forward to do either, to be
    honest.

Right now I'm leaning slightly towards #2, but I realise that's also 
because it would involve the least work. I'm hoping someone can come up 
with a #4 that gives a clean interface both in the kernel and to 
userspace; that would make it worthwhile, even if it were a lot of work to 
implement it...

Tim.