| To: | Keith M Wesolowski <wesolows@foobazco.org> |
|---|---|
| Subject: | Re: RFC: Cleanup/detection patch |
| From: | Jun Sun <jsun@mvista.com> |
| Date: | Thu, 05 Apr 2001 14:53:14 -0700 |
| Cc: | linux-mips@oss.sgi.com |
| References: | <20010401235212.B9737@foobazco.org> <3ACA8A3B.8BBABB11@mvista.com> <20010403203055.A17365@foobazco.org> <3ACB5FD8.6B166BA6@mvista.com> <20010405004618.A30899@foobazco.org> <3ACCD599.1765FCB2@mvista.com> <20010405140338.A1508@foobazco.org> |
| Sender: | owner-linux-mips@oss.sgi.com |
Keith M Wesolowski wrote: > > On Thu, Apr 05, 2001 at 01:29:13PM -0700, Jun Sun wrote: > > > I don't like bc_ops idea. Usually the external cache capability is still > > integral part of the CPU. > > How can it be both an integral part of the CPU and board-specific? Hmm, I am thinking about something like Rm7k, where the tertiary cache is controlled by the CPU (through cache instruction and TagLo/TagHi regsiters, etc) but the size is only known to the board. I think some CPUs can have secondary, external cache but cannot figure the size and, especially, the layout (# of ways, ...) automatically. (Any confirmation?) Those are what I was referring to. The key point is that machine_detection() should happen BEFORE cpu_probe()/cache_probe() so that we have an elegant way to address the above situation. Jun |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC: Cleanup/detection patch, Keith M Wesolowski |
|---|---|
| Next by Date: | ucLinux for MIPS, Lisa . Hsu |
| Previous by Thread: | Re: RFC: Cleanup/detection patch, Keith M Wesolowski |
| Next by Thread: | Re: RFC: Cleanup/detection patch, Geert Uytterhoeven |
| Indexes: | [Date] [Thread] [Top] [All Lists] |