[lkml]   [2013]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Regression on cpufreq in v3.12-rc1
On Fri, Sep 20, 2013 at 5:40 PM, Linus Walleij <> wrote:
> On Fri, Sep 20, 2013 at 5:32 PM, Srivatsa S. Bhat
> <> wrote:
>> On 09/20/2013 08:51 PM, Linus Walleij wrote:
>>> sa11x0_pcmcia_init() which starts this chain of events is called as
>>> an fs_initcall(), see drivers/pcmcia/sa1100_generic.c
>> But fs_initcall() comes after arch_initcall() right? (looking at
>> include/linux/init.h). Since the corresponding cpufreq-driver (drivers/
>> cpufreq/sa1100-cpufreq.c) uses arch_initcall() to register itself, it
>> is all the more surprising how this could happen...
> Hm it does happen if the cpufreq driver does not probe *at all*
> right? I will look closer at this, maybe it just doesn't register
> properly for some SA1100 variants...

Aha yeah this is it. The h3600 has an SA1110 and uses

This driver needs to know the RAM mounted on the board,
if it is this or that type, to perform properly.

This is passed from the command line or a default is selected
from the machine type:

if (!name[0]) {
if (machine_is_assabet())
name = "TC59SM716-CL3";
if (machine_is_pt_system3())
name = "K4S641632D";
if (machine_is_h3100())
name = "KM416S4030CT";
if (machine_is_jornada720())
name = "K4S281632B-1H";
if (machine_is_nanoengine())
name = "MT48LC8M16A2TG-75";

In this case we have neither. So the cpufreq driver fails to
register. But the kernel used to survive in any case, as you
could call cpufreq_get() without a cpufreq driver registered.

I think your suggested patch fixes the issue.

As a proper fix I'd like to add a default RAM type for the h3600
but that is for later...

Linus Walleij

 \ /
  Last update: 2013-09-20 18:41    [W:0.052 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site