* longrun.
@ 2004-07-03 16:38 Dave Jones
2004-07-03 19:33 ` longrun Dominik Brodowski
0 siblings, 1 reply; 2+ messages in thread
From: Dave Jones @ 2004-07-03 16:38 UTC (permalink / raw)
To: cpufreq
I was just looking into this..
Error: ./arch/i386/kernel/cpu/cpufreq/longrun.o .data refers to 00000018 R_386_32 .init.text
When I noticed that longrun_get_policy() is only called from longrun_cpu_init().
Is there a reason this driver doesn't have a .getpolicy method pointer pointing
to this routine ?
Incidentally, I'm a bit puzzled by the error.
The only __init functions are ..
longrun_get_policy
longrun_determine_freqs
longrun_cpu_init
longrun_init
The first two are only called by the 3rd. and the 3rd/4th are
only ever called at init time.
What do I miss here?
Dave
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: longrun.
2004-07-03 16:38 longrun Dave Jones
@ 2004-07-03 19:33 ` Dominik Brodowski
0 siblings, 0 replies; 2+ messages in thread
From: Dominik Brodowski @ 2004-07-03 19:33 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq
On Sat, Jul 03, 2004 at 05:38:07PM +0100, Dave Jones wrote:
> I was just looking into this..
> Error: ./arch/i386/kernel/cpu/cpufreq/longrun.o .data refers to 00000018 R_386_32 .init.text
>
> When I noticed that longrun_get_policy() is only called from longrun_cpu_init().
> Is there a reason this driver doesn't have a .getpolicy method pointer pointing
> to this routine ?
Because "policy" is/should be driver specific. Longrun CPUs can be set to a
frequency range _and_ a "policy" (powersave or performance); even though we
currently assume all such "range" CPUs support these two modes we should
stop doing so soon. So, the core doesn't implement a "getpolicy" method --
only a "get" (==get current frequency) function. For Longrun CPUs, this is
purely informational as neither the TSC nor any other part of the kernel
needs to know the current frequency, and the frequency may and most likely
will change "behind the kernel's back". And it is implemented in
static unsigned int longrun_get(unsigned int cpu)
>
> Incidentally, I'm a bit puzzled by the error.
> The only __init functions are ..
>
> longrun_get_policy
> longrun_determine_freqs
> longrun_cpu_init
> longrun_init
>
> The first two are only called by the 3rd. and the 3rd/4th are
> only ever called at init time.
>
> What do I miss here?
Sorry, don't know what's broken here. However, I might suspect these
functions being __init() [*] -- could you change that to __devinit and/or
remove it completely, and re-test, please?
Thanks,
Dominik
[*] ... I know, it was me ...
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-07-03 19:33 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-03 16:38 longrun Dave Jones
2004-07-03 19:33 ` longrun Dominik Brodowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.