All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Nigel Stephens" <nigel@mips.com>, "Thiemo Seufer" <ths@networkno.de>
Cc: "yshi" <yang.shi@windriver.com>, <linux-mips@linux-mips.org>
Subject: Re: [PATCH] malta4kec hang in calibrate_delay fix
Date: Tue, 4 Sep 2007 14:19:28 +0200	[thread overview]
Message-ID: <00a601c7eeed$d8095aa0$10eca8c0@grendel> (raw)
In-Reply-To: 46DD49B9.2090306@mips.com

> >> In that case, your core is a 4Kc and not a 4KEc.    
> >
> > Not quite true, early revisions of the 4KEc were only release 1. This
> > seems to be a bug in arch/mips/cpu-probe.c:
> >
> > static inline void cpu_probe_mips(struct cpuinfo_mips *c)
> > {
> >         decode_configs(c);
> >         switch (c->processor_id & 0xff00) {
> >         case PRID_IMP_4KC:
> >                 c->cputype = CPU_4KC;
> >                 break;
> >         case PRID_IMP_4KEC:
> >                 c->cputype = CPU_4KEC;
> >                 break;
> >         case PRID_IMP_4KECR2:
> >                 c->cputype = CPU_4KEC;
> >                 break;
> > ...
> >
> > The type for PRID_IMP_4KEC should be CPU_4KC.
> >
> >   
> 
> Maybe the probing code should read the ISA revision level from the AR 
> bits (12:10) of the Config0 register to figure out which revision of the 
> ISA is implemented.

It does.  c->cputype isn't what needs to be modulated here, it's c->isa_level,
which gets decoded as part of decode_configs(), as near as I can tell correctly
in the most recent source tree I've got. And it's isa_level that's being tested
by the cpu_has_mips32r2 et. al. macros.

            Regards,

            Kevin K.

WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Nigel Stephens <nigel@mips.com>, Thiemo Seufer <ths@networkno.de>
Cc: yshi <yang.shi@windriver.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] malta4kec hang in calibrate_delay fix
Date: Tue, 4 Sep 2007 14:19:28 +0200	[thread overview]
Message-ID: <00a601c7eeed$d8095aa0$10eca8c0@grendel> (raw)
Message-ID: <20070904121928.ZUF57rpCGVbXPO4U87vxgl3uM4Pxz1Ydj7CMrJDrU_U@z> (raw)
In-Reply-To: 46DD49B9.2090306@mips.com

> >> In that case, your core is a 4Kc and not a 4KEc.    
> >
> > Not quite true, early revisions of the 4KEc were only release 1. This
> > seems to be a bug in arch/mips/cpu-probe.c:
> >
> > static inline void cpu_probe_mips(struct cpuinfo_mips *c)
> > {
> >         decode_configs(c);
> >         switch (c->processor_id & 0xff00) {
> >         case PRID_IMP_4KC:
> >                 c->cputype = CPU_4KC;
> >                 break;
> >         case PRID_IMP_4KEC:
> >                 c->cputype = CPU_4KEC;
> >                 break;
> >         case PRID_IMP_4KECR2:
> >                 c->cputype = CPU_4KEC;
> >                 break;
> > ...
> >
> > The type for PRID_IMP_4KEC should be CPU_4KC.
> >
> >   
> 
> Maybe the probing code should read the ISA revision level from the AR 
> bits (12:10) of the Config0 register to figure out which revision of the 
> ISA is implemented.

It does.  c->cputype isn't what needs to be modulated here, it's c->isa_level,
which gets decoded as part of decode_configs(), as near as I can tell correctly
in the most recent source tree I've got. And it's isa_level that's being tested
by the cpu_has_mips32r2 et. al. macros.

            Regards,

            Kevin K.

  reply	other threads:[~2007-09-04 12:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04  8:52 [PATCH] malta4kec hang in calibrate_delay fix yshi
2007-09-04 10:03 ` Kevin D. Kissell
2007-09-04 10:03   ` Kevin D. Kissell
2007-09-04 10:32   ` yshi
2007-09-04 11:21     ` Kevin D. Kissell
2007-09-04 11:21       ` Kevin D. Kissell
2007-09-04 11:33       ` Thomas Bogendoerfer
2007-09-04 11:47         ` Kevin D. Kissell
2007-09-04 11:47           ` Kevin D. Kissell
2007-09-04 11:55       ` Thiemo Seufer
2007-09-04 12:04         ` Nigel Stephens
2007-09-04 12:19           ` Kevin D. Kissell [this message]
2007-09-04 12:19             ` Kevin D. Kissell
2007-09-04 12:42             ` Thiemo Seufer
2007-09-04 12:44 ` Ralf Baechle
2007-09-05  5:51   ` yshi
2007-09-05 10:49     ` Chris Dearman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00a601c7eeed$d8095aa0$10eca8c0@grendel' \
    --to=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    --cc=nigel@mips.com \
    --cc=ths@networkno.de \
    --cc=yang.shi@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.