From: Justin Carlson <carlson@sibyte.com>
To: linux-mips@oss.sgi.com
Subject: Re: broken RM7000 in CVS ...
Date: Fri, 12 Jan 2001 11:06:56 -0800 [thread overview]
Message-ID: <0101121116201G.07691@plugh.sibyte.com> (raw)
In-Reply-To: <3A5F53CB.F8EC3947@mvista.com>
On Fri, 12 Jan 2001, you wrote:
> I think that is a good idea. I suggest we have two more pointers in the
> mips_cpu strcuture : one to mips_mmu_ops structure, and the other to
> setup_exception_vectors() function.
>
> BTW, I have a question about MIPS32 (or 4KC). Do all MIPS32 CPUs have the
> same PRID? Or all "incarnations" of 4KC have the same PRID?
No. Mips32 defines PRID into 4 partitions: a company id, processor id,
revision id, and company options field.
>I suppose MIPS32
> CPUs have a more complete config register where you can probe for all the
> options. For others we can use a table-like structure to fill in the options.
This is sort of true. Mips32 does do a pretty good job of defining how to
probe for L1 caches and the like, but other things, such as L2 caches, are not
going to be so easily probed. I think the mmu_ops routines should continue
to be specialized on a per-processor basis, just because they are both quite
performance sensitive and relatively easy to write/maintain.
>
> Along this line, it probably makes sense to have another pointer to
> mips_cpu_config() function, where for MIPS32 it is the standard MIPS32 config
> probing function and for most others it is NULL.
>
> Now the mips_cpu_table looks like :
>
> struct mips_cpu mips_cpu_table[]={
> { PRID_IMP_4KC, mips32_cpu_config},
> { PRID_IMP_RM7K, null, 0xaaa, {...}}
> .....
> };
If I'm understanding your idea correctly, this table would require you to
always compile in all the mmu routines for all processors, just to fill in the
table entries. Doesn't seem like a particularly good idea to me, even if we
could use generic mips32 routines for most parts.
> The cpu_probe() routine will now look like:
> {
> read prid register
> find mips_cpu_table[i] with matching PRID.
> mips_cpu = &mips_cpu_table[i];
> if (mips_cpu->mips_cpu_config) mips_cpu->mips_cpu_config();
> }
>
> To me this is beautiful. Am I dreaming? :-)
See objections above.
I did submit a patch to Ralf a couple weeks ago to fix cpu_probe so it
checks PRID according to the mips32 spec, but never heard back, and haven't
seen it show up in CVS. WIll try again sometime soon, methinks.
-Justin
next prev parent reply other threads:[~2001-01-12 19:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-12 3:54 broken RM7000 in CVS Jun Sun
2001-01-12 7:23 ` Kevin D. Kissell
2001-01-12 7:23 ` Kevin D. Kissell
2001-01-12 18:58 ` Jun Sun
2001-01-12 19:06 ` Justin Carlson [this message]
2001-01-12 20:27 ` Jun Sun
2001-01-12 20:29 ` Justin Carlson
2001-01-12 21:39 ` Jun Sun
2001-01-12 23:48 ` Alan Cox
2001-01-12 23:48 ` Alan Cox
2001-01-15 8:37 ` Ralf Baechle
2001-01-15 8:37 ` Ralf Baechle
2001-01-12 19:42 ` Kevin D. Kissell
2001-01-12 19:42 ` Kevin D. Kissell
2001-01-15 8:42 ` Ralf Baechle
2001-01-15 8:42 ` Ralf Baechle
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=0101121116201G.07691@plugh.sibyte.com \
--to=carlson@sibyte.com \
--cc=linux-mips@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox