Re: Status of arch/arm in linux-next

Re: Status of arch/arm in linux-next

[Arnd Bergmann]

On Tuesday 19 April 2011, Linus Walleij wrote:
> I will surely put that into drivers/regulator, Mark already requested that
> as part of his review.
> 
> The problem is that it is dependent on the PRCMU driver which
> provides the communication mechanism to actually control these
> regulators.
> 
> The PRCMU is the Power Reset and Control Management Unit,
> it is a register pages where you send commands to a firmware
> running on its own CPU on the other side, partly using mailboxes.
> The firmware handles things like voltage and power domains
> (modeled as regulators), frequency changes (using CPUfreq),
> idle states (CPUidle and sleep, idling), as well as resetting
> particular memory blocks AND an I2C channel to the AB8500
> chip (driven from drivers/ab8500-core.c indeed) and some
> GPIO configuration.

Ok, thanks for the explanation.

> Thinking of it, is it OK to put chip CPUfreq drivers into
> drivers/cpufreq/* instead of into the arch/arm/* platform
> code as everyone does right now? We could probably
> fix that and bring down the diffstat considerably.

That's something to discuss with Dave Jones and other people
interested in cpufre. Right now, all cpufreq drivers, including
those for other architectures are in arch/.

I think it would be good to have the out of the individual
platforms, in particular in order to get better reviews of
new cpufreq drivers by people that are interested in them.

	Arnd

Re: Status of arch/arm in linux-next

[Mark Brown]

On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:

> I think it would be good to have the out of the individual
> platforms, in particular in order to get better reviews of
> new cpufreq drivers by people that are interested in them.

FWIW when I pushed the S3C64x0 cpufreq driver into mainline I posted the
driver to the cpufreq list and maintainers but never got any response
from them.

Re: Status of arch/arm in linux-next

[Dave Jones]

On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:
 > > Thinking of it, is it OK to put chip CPUfreq drivers into
 > > drivers/cpufreq/* instead of into the arch/arm/* platform
 > > code as everyone does right now? We could probably
 > > fix that and bring down the diffstat considerably.
 > 
 > That's something to discuss with Dave Jones and other people
 > interested in cpufre. Right now, all cpufreq drivers, including
 > those for other architectures are in arch/.
 > 
 > I think it would be good to have the out of the individual
 > platforms, in particular in order to get better reviews of
 > new cpufreq drivers by people that are interested in them.

The platform drivers are by their nature architecture specific,
so arch/ seems apropos.  drivers/platform/arm/ maybe ?

Though, having arm do something different to every other arch seems
a bit awkward too. Everyone else has their cpufreq platform driver
somewhere under arch/whatever/../cpufreq/..  so changing that
violates the principle of least surprise.

I'm also not convinced that moving them would increase review of changes.

What problem is this solving again ?

	Dave

Re: Status of arch/arm in linux-next

[Arnd Bergmann]

On Tuesday 19 April 2011 18:27:42 Dave Jones wrote:
> On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:
>  > > Thinking of it, is it OK to put chip CPUfreq drivers into
>  > > drivers/cpufreq/* instead of into the arch/arm/* platform
>  > > code as everyone does right now? We could probably
>  > > fix that and bring down the diffstat considerably.
>  > 
>  > That's something to discuss with Dave Jones and other people
>  > interested in cpufre. Right now, all cpufreq drivers, including
>  > those for other architectures are in arch/.
>  > 
>  > I think it would be good to have the out of the individual
>  > platforms, in particular in order to get better reviews of
>  > new cpufreq drivers by people that are interested in them.
> 
> The platform drivers are by their nature architecture specific,
> so arch/ seems apropos.  drivers/platform/arm/ maybe ?
> 
> Though, having arm do something different to every other arch seems
> a bit awkward too. Everyone else has their cpufreq platform driver
> somewhere under arch/whatever/../cpufreq/..  so changing that
> violates the principle of least surprise.
> 
> I'm also not convinced that moving them would increase review of changes.
> 
> What problem is this solving again ?

Right now, every subarchitecture in arm implements a number of 
drivers (irq, clocksource, gpio, pci, iommu, cpufreq, ...).
These drivers are frequently copies of other existing ones with
slight modifications or (worse) actually are written independently
for the same IP blocks. In some cases, they are copies of drivers
for stuff that is present in other architectures.

We are discussing on a number of fronts to turn the source code
layout from subarchitecture-centric to subsystem-centric, e.g.
put all gpio drivers into one directory instead of each one
into the directory for its (sub)architecture, in order to improve
the abstractions and code reuse we have between the different
implementations.

	Arnd

Re: Status of arch/arm in linux-next

[Linus Walleij]

2011/4/19 Dave Jones <davej@redhat.com>:

> The platform drivers are by their nature architecture specific,
> so arch/ seems apropos.  drivers/platform/arm/ maybe ?

I opted for putting stuff in there, it was not popular, it will probably
just cause overpopulation there instead, like drivers/misc is doing
right now :-(

> Though, having arm do something different to every other arch seems
> a bit awkward too. Everyone else has their cpufreq platform driver
> somewhere under arch/whatever/../cpufreq/..  so changing that
> violates the principle of least surprise.
>
> I'm also not convinced that moving them would increase review of changes.
>
> What problem is this solving again ?

Recent complaints from Linus (the other one) about overpopulation
bad code reuse and patch collision churn in the arch/arm/* tree.

If all cpufreq drivers (including the x86 ones!) were under
drivers/cpufreq/* it would mean better review and more
opportunity for consolidation I guess? We could begin the move
with a few ARM architectures. Do you agree?

Yours,
Linus Walleij

Re: Status of arch/arm in linux-next

[Dave Jones]

On Tue, Apr 19, 2011 at 05:05:46PM +0100, Mark Brown wrote:
 > On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:
 > 
 > > I think it would be good to have the out of the individual
 > > platforms, in particular in order to get better reviews of
 > > new cpufreq drivers by people that are interested in them.
 > 
 > FWIW when I pushed the S3C64x0 cpufreq driver into mainline I posted the
 > driver to the cpufreq list and maintainers but never got any response
 > from them.

Like I said in another mail, the platform-specific nature of cpufreq drivers
means that the only people who can really review them are people familiar
with the architecture. (modulo the cpufreq api bits, but it's usually
either no-brainer stuff, or bugs that aren't immediately obvious from review,
like some of the locking mistakes we've historically seen)

This is why I don't believe that moving this code from arch/ to drivers/
will change anything.

if there's commonality between some of the ARM arch drivers, why can't
there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?

Right now "move it out of the arm tree into the cpufreq tree" just seems
like a cop-out to hide the problem.

	Dave

Re: Status of arch/arm in linux-next

[Nicolas Pitre]

On Thu, 21 Apr 2011, Dave Jones wrote:

> On Tue, Apr 19, 2011 at 05:05:46PM +0100, Mark Brown wrote:
>  > On Tue, Apr 19, 2011 at 06:01:19PM +0200, Arnd Bergmann wrote:
>  > 
>  > > I think it would be good to have the out of the individual
>  > > platforms, in particular in order to get better reviews of
>  > > new cpufreq drivers by people that are interested in them.
>  > 
>  > FWIW when I pushed the S3C64x0 cpufreq driver into mainline I posted the
>  > driver to the cpufreq list and maintainers but never got any response
>  > from them.
> 
> Like I said in another mail, the platform-specific nature of cpufreq drivers
> means that the only people who can really review them are people familiar
> with the architecture. (modulo the cpufreq api bits, but it's usually
> either no-brainer stuff, or bugs that aren't immediately obvious from review,
> like some of the locking mistakes we've historically seen)

So what? Lots of drivers in drivers/ are used and even usable only on 
one architecture already.  Moving the cpufreq drivers from arch/* into 
drivers/cpufreq/ won't change the fact that only the people familiar 
with the target hardware will be able to properly review the details.  
This is no different for most kind of drivers.

> This is why I don't believe that moving this code from arch/ to drivers/
> will change anything.

That at least would have the property of gathering drivers together 
according to their _purpose_, irrespective of their implementation 
details.  That's the case for all the other class of drivers already. 
Why would cpufreq drivers be different?

> if there's commonality between some of the ARM arch drivers, why can't
> there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?

Because usually there isn't.  "ARM" is just a CPU architecture, not a 
system architecture.  Everything around the core is different from one 
vendor to the next.  And when commonality exists it is much easier to 
deal with if it is close together.

According to your argument, we would have to create arch/arm/net, 
arch/arm/alsa, arch/arm/video, etc, which no one would agree with.  Yet 
almost all those ARM related drivers are highly platform-specific.

The criteria for sorting out driver location is normally the driver's 
purpose, not the platform where it is used. Why would cpufreq have to be 
different?

> Right now "move it out of the arm tree into the cpufreq tree" just seems
> like a cop-out to hide the problem.

No, there is nothing to hide.  If there is a code duplication problem, 
it will be even more visible if that code is moved to a common place, 
and therefore any needed consolidation would happen more naturally.  I 
doubt anyone would try to copy a driver just to perform slight 
modifications on it if it is to land in the same directory as the 
original.


Nicolas

Re: Status of arch/arm in linux-next

[Tony Lindgren]

* Nicolas Pitre <nicolas.pitre@linaro.org> [110421 13:59]:
> On Thu, 21 Apr 2011, Dave Jones wrote:
> 
> > On Tue, Apr 19, 2011 at 05:05:46PM +0100, Mark Brown wrote:
> 
> > This is why I don't believe that moving this code from arch/ to drivers/
> > will change anything.
> 
> That at least would have the property of gathering drivers together 
> according to their _purpose_, irrespective of their implementation 
> details.  That's the case for all the other class of drivers already. 
> Why would cpufreq drivers be different?

And drivers do have well defined standards, so that automatically prevents
people sneaking in spaghetti calls to platform specific code ;)

Tony

Re: Status of arch/arm in linux-next

[Arnd Bergmann]

On Thursday 21 April 2011, Nicolas Pitre wrote:
> > if there's commonality between some of the ARM arch drivers, why can't
> > there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?
> 
> Because usually there isn't.  "ARM" is just a CPU architecture, not a 
> system architecture.  Everything around the core is different from one 
> vendor to the next.  And when commonality exists it is much easier to 
> deal with if it is close together.

Exactly. To make matters worse, we are starting to see a number of vendors
that use multiple CPU architectures with the same I/O devices (e.g. Renesas,
Freescale, Xilinx, TI, ...). Not sure if any of these use the same cpufreq
register on more than one architecture, but it's quite likely to happen
at some point.

	Arnd

Re: Status of arch/arm in linux-next

[Rafael J. Wysocki]

On Tuesday, April 26, 2011, Arnd Bergmann wrote:
> On Thursday 21 April 2011, Nicolas Pitre wrote:
> > > if there's commonality between some of the ARM arch drivers, why can't
> > > there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?
> > 
> > Because usually there isn't.  "ARM" is just a CPU architecture, not a 
> > system architecture.  Everything around the core is different from one 
> > vendor to the next.  And when commonality exists it is much easier to 
> > deal with if it is close together.
> 
> Exactly. To make matters worse, we are starting to see a number of vendors
> that use multiple CPU architectures with the same I/O devices (e.g. Renesas,
> Freescale, Xilinx, TI, ...). Not sure if any of these use the same cpufreq
> register on more than one architecture, but it's quite likely to happen
> at some point.

Indeed.  So in my opinion it makes sense to move code into the drivers
directory, at least the code that's going to be used by multiple platforms
(that need not be a complete driver).

We're doing the same thing with the runtime PM code at the moment.

Thanks,
Rafael

Re: Status of arch/arm in linux-next

[Dave Jones]

On Tue, Apr 26, 2011 at 07:04:45PM +0200, Rafael J. Wysocki wrote:
 > On Tuesday, April 26, 2011, Arnd Bergmann wrote:
 > > On Thursday 21 April 2011, Nicolas Pitre wrote:
 > > > > if there's commonality between some of the ARM arch drivers, why can't
 > > > > there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?
 > > > 
 > > > Because usually there isn't.  "ARM" is just a CPU architecture, not a 
 > > > system architecture.  Everything around the core is different from one 
 > > > vendor to the next.  And when commonality exists it is much easier to 
 > > > deal with if it is close together.
 > > 
 > > Exactly. To make matters worse, we are starting to see a number of vendors
 > > that use multiple CPU architectures with the same I/O devices (e.g. Renesas,
 > > Freescale, Xilinx, TI, ...). Not sure if any of these use the same cpufreq
 > > register on more than one architecture, but it's quite likely to happen
 > > at some point.
 > 
 > Indeed.  So in my opinion it makes sense to move code into the drivers
 > directory, at least the code that's going to be used by multiple platforms
 > (that need not be a complete driver).

Ok, so my opinion on this has changed a little over the weekend.
I don't totally hate it now, but I'm still not a huge fan.
That said, I won't stand in the way if this is what everyone agrees is
the way forward.

in cpufreq.next I moved the x86 drivers over.  Someone look it over ?
If that looks like what you all had in mind, start sending me the patches
for other arches, and I'll get them queued up for .40

	Dave

Re: Status of arch/arm in linux-next

[Dave Jones]

On Tue, Apr 26, 2011 at 02:15:08PM -0400, Dave Jones wrote:

 >  > Indeed.  So in my opinion it makes sense to move code into the drivers
 >  > directory, at least the code that's going to be used by multiple platforms
 >  > (that need not be a complete driver).
 > 
 > Ok, so my opinion on this has changed a little over the weekend.
 > I don't totally hate it now, but I'm still not a huge fan.
 > That said, I won't stand in the way if this is what everyone agrees is
 > the way forward.
 > 
 > in cpufreq.next I moved the x86 drivers over.  Someone look it over ?
 > If that looks like what you all had in mind, start sending me the patches
 > for other arches, and I'll get them queued up for .40

FYI, this is now on the 'move-drivers' branch in cpufreq.git
Unless there's a good reason not to, I'm going to start pushing this to Linus
next merge window.

	Dave

Re: Status of arch/arm in linux-next

[Nicolas Pitre]

On Fri, 29 Apr 2011, Dave Jones wrote:

> On Tue, Apr 26, 2011 at 02:15:08PM -0400, Dave Jones wrote:
> 
>  >  > Indeed.  So in my opinion it makes sense to move code into the drivers
>  >  > directory, at least the code that's going to be used by multiple platforms
>  >  > (that need not be a complete driver).
>  > 
>  > Ok, so my opinion on this has changed a little over the weekend.
>  > I don't totally hate it now, but I'm still not a huge fan.
>  > That said, I won't stand in the way if this is what everyone agrees is
>  > the way forward.
>  > 
>  > in cpufreq.next I moved the x86 drivers over.  Someone look it over ?
>  > If that looks like what you all had in mind, start sending me the patches
>  > for other arches, and I'll get them queued up for .40
> 
> FYI, this is now on the 'move-drivers' branch in cpufreq.git
> Unless there's a good reason not to, I'm going to start pushing this to Linus
> next merge window.

Thanks.  Additional drivers should follow suit.


Nicolas

Re: Status of arch/arm in linux-next

[Jamie Lokier]

Arnd Bergmann wrote:
> On Thursday 21 April 2011, Nicolas Pitre wrote:
> > > if there's commonality between some of the ARM arch drivers, why can't
> > > there be a arch/arm/cpufreq/ dir for the shared code, and do everything there ?
> > 
> > Because usually there isn't.  "ARM" is just a CPU architecture, not a 
> > system architecture.  Everything around the core is different from one 
> > vendor to the next.  And when commonality exists it is much easier to 
> > deal with if it is close together.
> 
> Exactly. To make matters worse, we are starting to see a number of vendors
> that use multiple CPU architectures with the same I/O devices (e.g. Renesas,
> Freescale, Xilinx, TI, ...). Not sure if any of these use the same cpufreq
> register on more than one architecture, but it's quite likely to happen
> at some point.

Can't comment on in-tree SoCs, but out of tree (they use Linux but
don't submit anything upstream as far as I can tell), Sigma Designs
use ARM & MIPS CPU architectures, with the clock/timing registers, irq
registers and more or less everything else being the same among them.

-- Jamie

[BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Jonathan Nieder]

(-cc: linux-arm-kernel, +cc: linux-kernel, Mattia)
Hi,

Dave Jones wrote:

> in cpufreq.next I moved the x86 drivers over.  Someone look it over ?

Some people[1] have been seeing regressions after this change (when
moving from 2.6.39 to 3.0, presumably from commit bb0a56ecc4ba,
"[CPUFREQ] Move x86 drivers to drivers/cpufreq/").  The first symptom
was messages at boot:

| Loading cpufreq kernel modules...FATAL: Error inserting powernow_k7 (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/powernow-k7.ko): No such device
| FATAL: Error inserting speedstep_ich (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/speedstep-ich.ko): No such device
| FATAL: Error inserting acpi_cpufreq (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/acpi-cpufreq.ko): Device or resource busy
[etc]

The second symptom was the wrong cpufreq driver being loaded
(p4-clockmod instead of acpi-cpufreq).  The cause seems to be some
code in init scripts that originated in powernowd 0.97-2ubuntu1 (2007)
or some time before that:

|         #get list of available modules (governors and helpers)
|         LOC="/lib/modules/$(uname -r)/kernel/drivers/cpufreq"
|         if [ -d $LOC ]; then
|           MODAVAIL=$( ( find $LOC -type f -name "*.o" -printf "basename %f .o\n"; \
|               find $LOC -type f -name "*.ko" -printf "basename %f .ko\n" ) | /bin/sh)
|         else
|           MODAVAIL=""
|         fi
| 
|         #echo "Loading cpufreq modules:"
|         for mod in $MODAVAIL; do
|         #        echo "     $mod"
|                 echo $LIST| grep -q -w "$mod" || modprobe $mod >/dev/null || /bin/true
|         done

This takes all kernel modules in drivers/cpufreq, blindly assumes
they must be governors or helpers, and loads them.  Nowadays it is
in the loadcpufreq script in cpufrequtils; so in cpufrequtils 007-2
(03 Aug 2011), the pattern changed to drivers/cpufreq/cpufreq_*.ko
which just matches the governors and helpers and everybody's happy.

Except:

 (1) This is still incredibly fragile.  What *should* cpufrequtils
     be doing to get the drivers it needs?

 (2) Using the 3.0 or later kernel with old userspace gives bad
     results (e.g., 30% increase in power consumption for one
     reporter).  That's a regression.  Bad kernel, no biscuit.

Ideas?

[1] http://bugs.debian.org/635348

Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Jonathan Nieder]

Jonathan Nieder wrote:

>  (1) This is still incredibly fragile.  What *should* cpufrequtils
>      be doing to get the modules it needs?
>
>  (2) Using the 3.0 or later kernel with old userspace gives bad
>      results (e.g., 30% increase in power consumption for one
>      reporter).  That's a regression.

The "30% increase" part was an unrelated bug (i915.i915_enable_rc6=1
brings power consumption back to normal), for those who were
wondering. :)

Old userspace automatically loading the wrong cpufreq drivers still
does not seem great to me, though I don't have any great ideas about
how to prevent that (a separate drivers/cpufreq-drivers/ directory
does not sound too appealing).  I guess I'd be most interested in how
to fix (1) first.

Thanks,
Jonathan

Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Dave Jones]

On Sat, Aug 13, 2011 at 02:02:46PM -0500, Jonathan Nieder wrote:
 > Jonathan Nieder wrote:
 > 
 > >  (1) This is still incredibly fragile.  What *should* cpufrequtils
 > >      be doing to get the modules it needs?
 > >
 > >  (2) Using the 3.0 or later kernel with old userspace gives bad
 > >      results (e.g., 30% increase in power consumption for one
 > >      reporter).  That's a regression.
 > 
 > The "30% increase" part was an unrelated bug (i915.i915_enable_rc6=1
 > brings power consumption back to normal), for those who were
 > wondering. :)
 > 
 > Old userspace automatically loading the wrong cpufreq drivers still
 > does not seem great to me, though I don't have any great ideas about
 > how to prevent that (a separate drivers/cpufreq-drivers/ directory
 > does not sound too appealing).  I guess I'd be most interested in how
 > to fix (1) first.

If we have to move stuff again, we could do drivers/cpufreq/x86/ etc..
Even if we do that though, you really want to fix that userspace, because
you're right that "load everything and see what sticks" is fragile,
and pure luck that it ever did the right thing.

What we used to do in Fedora grew more and more complex over time.
Here's the last incarnation: http://fpaste.org/uvDb/
As you can see in the start() function, it's pretty hairy, and even
that doesn't cover every possible case, which is why it allows a user
override in the $DRIVER variable. Messy.

Basic thinking is
- If AMD64, load powernow-k8
- if that fails to load : try acpi-cpufreq
- For everything else : acpi-cpufreq
- If acpi-cpufreq fails : p4-clockmod

What we're moving towards for Fedora 16 is to change all the drivers
to be linked in rather than modular, and rely on link order to do the right thing.
It sounds like a step backwards in some ways, towards the 'see what sticks'
approach, but the difference here is the link-order specifying the correct
order for initialisation. You get none of that with modules.

In an ideal world, we'd auto-load the right module on a hotplug event
from a cpu, but we're not there yet. I believe Kay is working on that.

Over time, 'the right driver' seems to be converging on acpi-cpufreq.
There's some patches pending to even move some of the powernow-k8 use-cases
to use acpi-cpufreq instead. But modern intel should be using that,
(where modern = almost everything since p4, except those that lack P-states)


And then there's the 'which governor' mess.
I'd really like that to eventually converge so that 'ondemand' is always the
right answer.  For this to happen, there needs to be no difference between
an idle machine running powersave, and ondemand or (harder) a busy machine
running performance.
(conservative with some work could be just a runtime mode for ondemand).

	Dave

Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Mattia Dongili]

On Sat, Aug 13, 2011 at 05:11:42PM -0400, Dave Jones wrote:
> On Sat, Aug 13, 2011 at 02:02:46PM -0500, Jonathan Nieder wrote:
>  > Jonathan Nieder wrote:
>  > 
>  > >  (1) This is still incredibly fragile.  What *should* cpufrequtils
>  > >      be doing to get the modules it needs?
>  > >
>  > >  (2) Using the 3.0 or later kernel with old userspace gives bad
>  > >      results (e.g., 30% increase in power consumption for one
>  > >      reporter).  That's a regression.
>  > 
>  > The "30% increase" part was an unrelated bug (i915.i915_enable_rc6=1
>  > brings power consumption back to normal), for those who were
>  > wondering. :)
>  > 
>  > Old userspace automatically loading the wrong cpufreq drivers still
>  > does not seem great to me, though I don't have any great ideas about
>  > how to prevent that (a separate drivers/cpufreq-drivers/ directory
>  > does not sound too appealing).  I guess I'd be most interested in how
>  > to fix (1) first.
> 
> If we have to move stuff again, we could do drivers/cpufreq/x86/ etc..
> Even if we do that though, you really want to fix that userspace, because
> you're right that "load everything and see what sticks" is fragile,
> and pure luck that it ever did the right thing.

not sure why this bug landed here finally, it was clearly an
overlook in the Debian startup script and it's only specific to Debian.

The "load everything" part was not for cpu drivers but for governors
and helpers that used to sit into drivers/cpufreq alone.
The cpu driver loading part is fairly complex (or yes, messy as you say)
and not too dissimilar than the one from fedora.

-- 
mattia
:wq!

Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Jonathan Nieder]

(-cc: ARM/etc people; +cc: Kay)

Dave Jones wrote:

> If we have to move stuff again, we could do drivers/cpufreq/x86/ etc..

Unfortunately the old script used "find", not "ls", so that wouldn't
work. :/

> What we used to do in Fedora grew more and more complex over time.
> Here's the last incarnation: http://fpaste.org/uvDb/

The main difference from Debian seems to be that this script loads the
module corresponding to the chosen governor, while Debian's init
script loads all governor modules early (using a heuristic I would
like to avoid that involves running "find" to list them) and chooses
the governor to use later.

> In an ideal world, we'd auto-load the right module on a hotplug event
> from a cpu, but we're not there yet. I believe Kay is working on that.

Yes, that is what I was hoping for.  Are there patches to test?

The comment at
http://thread.gmane.org/gmane.linux.kernel/796450/focus=796874 also
looks promising.

Thanks much for the help,
Jonathan

Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

[Kay Sievers]

On Sun, Aug 14, 2011 at 19:01, Jonathan Nieder <jrnieder@gmail.com> wrote:
> (-cc: ARM/etc people; +cc: Kay)
>
> Dave Jones wrote:
>
>> If we have to move stuff again, we could do drivers/cpufreq/x86/ etc..
>
> Unfortunately the old script used "find", not "ls", so that wouldn't
> work. :/
>
>> What we used to do in Fedora grew more and more complex over time.
>> Here's the last incarnation: http://fpaste.org/uvDb/
>
> The main difference from Debian seems to be that this script loads the
> module corresponding to the chosen governor, while Debian's init
> script loads all governor modules early (using a heuristic I would
> like to avoid that involves running "find" to list them) and chooses
> the governor to use later.

Right, loading cpufreq drivers from userspace is fragile, and can not
properly work today. Only the kernel itself know which driver to try
to bind in which order. Modular cpufreq kernel modules make no real
sense here with the infrastructure we have available today.

>> In an ideal world, we'd auto-load the right module on a hotplug event
>> from a cpu, but we're not there yet. I believe Kay is working on that.
>
> Yes, that is what I was hoping for.  Are there patches to test?

Yeah, it's on the TODO list, I just get too many 'really broken'
things get sorted on top all time. :) But it will happen in the next
months.

> The comment at
> http://thread.gmane.org/gmane.linux.kernel/796450/focus=796874 also
> looks promising.

That could work, but we better go right for the CPU specific aliases
and do not try to load all of them, even when for completely different
systems. That would just encode another workaround into kernel
modules, which we better solve properly.

Kay