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.
next prev parent 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.