[patch] blast_scache nop for sc cpus without scache

[patch] blast_scache nop for sc cpus without scache

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]


Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /scratch/local/linux-mips-cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.108
diff -u -p -r1.108 c-r4k.c
--- arch/mips/mm/c-r4k.c	25 Apr 2005 16:36:23 -0000	1.108
+++ arch/mips/mm/c-r4k.c	25 Jun 2005 13:15:55 -0000
@@ -225,6 +225,8 @@ static inline void r4k_blast_icache_setu
 
 static void (* r4k_blast_scache_page)(unsigned long addr);
 
+static void blast_scache_page_nop(unsigned long page) {}
+
 static inline void r4k_blast_scache_page_setup(void)
 {
 	unsigned long sc_lsize = cpu_scache_line_size();
@@ -237,10 +239,14 @@ static inline void r4k_blast_scache_page
 		r4k_blast_scache_page = blast_scache64_page;
 	else if (sc_lsize == 128)
 		r4k_blast_scache_page = blast_scache128_page;
+	else
+		r4k_blast_scache_page = blast_scache_page_nop;
 }
 
 static void (* r4k_blast_scache_page_indexed)(unsigned long addr);
 
+static void blast_scache_page_indexed_nop(unsigned long page) {}
+
 static inline void r4k_blast_scache_page_indexed_setup(void)
 {
 	unsigned long sc_lsize = cpu_scache_line_size();
@@ -253,10 +259,14 @@ static inline void r4k_blast_scache_page
 		r4k_blast_scache_page_indexed = blast_scache64_page_indexed;
 	else if (sc_lsize == 128)
 		r4k_blast_scache_page_indexed = blast_scache128_page_indexed;
+	else 
+		r4k_blast_scache_page_indexed = blast_scache_page_indexed_nop;
 }
 
 static void (* r4k_blast_scache)(void);
 
+static void blast_scache_nop(void ) {}
+
 static inline void r4k_blast_scache_setup(void)
 {
 	unsigned long sc_lsize = cpu_scache_line_size();
@@ -269,6 +279,8 @@ static inline void r4k_blast_scache_setu
 		r4k_blast_scache = blast_scache64;
 	else if (sc_lsize == 128)
 		r4k_blast_scache = blast_scache128;
+	else 
+		r4k_blast_scache = blast_scache_nop;
 }
 
 /*

-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] blast_scache nop for sc cpus without scache

[Ralf Baechle]

On Sat, Jun 25, 2005 at 03:19:38PM +0200, Florian Lohoff wrote:

> Subject: [patch] blast_scache nop for sc cpus without scache

Interesting.  Which system needs this patch?

  Ralf

Re: [patch] blast_scache nop for sc cpus without scache

[Thomas Bogendoerfer]

On Sat, Jun 25, 2005 at 06:03:16PM +0200, Ralf Baechle wrote:
> On Sat, Jun 25, 2005 at 03:19:38PM +0200, Florian Lohoff wrote:
> 
> > Subject: [patch] blast_scache nop for sc cpus without scache
> 
> Interesting.  Which system needs this patch?

RM400; looks like the secondary cache on the cpu module isn't normally
attached, but like the board caches on den Indy. CONF_SC isn't set
in cp0 config, but the cpu is an R4400SC -> crash in r4k_scache_blast*.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [patch] blast_scache nop for sc cpus without scache

[Maciej W. Rozycki]

On Sat, 25 Jun 2005, Thomas Bogendoerfer wrote:

> > > Subject: [patch] blast_scache nop for sc cpus without scache
> > 
> > Interesting.  Which system needs this patch?
> 
> RM400; looks like the secondary cache on the cpu module isn't normally
> attached, but like the board caches on den Indy. CONF_SC isn't set
> in cp0 config, but the cpu is an R4400SC -> crash in r4k_scache_blast*.

 Are you sure CONF_SC isn't set?  That would be weird, it's one of the 
boot-mode settings so it would be hard to get it wrong.  What's printed 
upon bootstrap about caches?

 Anyway these days we apparently ignore the result of the S-cache probe 
and the sc_present variable.  The only values that determine whether an 
S-cache is present or not are: cpu_has_dc_aliases, cpu_has_ic_fills_f_dc 
and cpu_has_subset_pcaches which you need to get right for your 
configuration -- I guess cpu_has_dc_aliases == 0, cpu_has_ic_fills_f_dc == 
1 and cpu_has_subset_pcaches == 0 should be right to fulfil your needs 
(but it may break elsewhere).  Have I heard: "serious brain damage" from 
you?  Well, I couldn't agree more...

  Maciej

Re: [patch] blast_scache nop for sc cpus without scache

[Ralf Baechle]

On Mon, Jun 27, 2005 at 01:45:39PM +0100, Maciej W. Rozycki wrote:

>  Anyway these days we apparently ignore the result of the S-cache probe 
> and the sc_present variable.  The only values that determine whether an 
> S-cache is present or not are: cpu_has_dc_aliases, cpu_has_ic_fills_f_dc 
> and cpu_has_subset_pcaches which you need to get right for your 
> configuration -- I guess cpu_has_dc_aliases == 0, cpu_has_ic_fills_f_dc == 
> 1 and cpu_has_subset_pcaches == 0 should be right to fulfil your needs 
> (but it may break elsewhere).  Have I heard: "serious brain damage" from 
> you?  Well, I couldn't agree more...

What matters isn't the presence of a second level cache but the actual
properties.  The old code was relying almost exclusively on the precense
of an S-cache, so had to be very liberal in it's assumption about that
cache's properties.  Performancewise that sucked, badly.

  Ralf

Re: [patch] blast_scache nop for sc cpus without scache

[Maciej W. Rozycki]

On Mon, 27 Jun 2005, Ralf Baechle wrote:

> What matters isn't the presence of a second level cache but the actual
> properties.  The old code was relying almost exclusively on the precense
> of an S-cache, so had to be very liberal in it's assumption about that
> cache's properties.  Performancewise that sucked, badly.

 Well, I do think the defaults for these "features to be overridden" 
should be liberal about accepting what's available.  That is they should 
never take anything for granted.  Performance doesn't matter.  Code has to 
be correct.  It's up to a platform maintainer to tune it if desired and 
possible.

 And if we go back in time for c-r4k.c far enough, then we'll see these 
setup_scache_funcs() and setup_noscache_funcs() functions we used to have 
for proper handling of set-ups both with and without secondary caches.  
There could have been bugs, certainly, but at least the framework was in 
place.

  Maciej

Re: [patch] blast_scache nop for sc cpus without scache

[Thomas Bogendoerfer]

On Mon, Jun 27, 2005 at 01:45:39PM +0100, Maciej W. Rozycki wrote:
>  Are you sure CONF_SC isn't set?

I've checked that after we saw a crash in __flush_cache_all().

> That would be weird, it's one of the boot-mode settings so it would be
> hard to get it wrong.  What's printed upon bootstrap about caches?

I don't have the console working yet, we just put enough prom_printf()s
to work out, what was going wron.

> (but it may break elsewhere).  Have I heard: "serious brain damage" from 
> you?  Well, I couldn't agree more...

well, I haven't digged deep enough, to have a good opion on the whole
issue.

I'm also not sure, whether adding the blast_scache_nop() stuff is
the way to go. I'd probably throw out the switch case over CPU types
and use a single test before calling r4k_blast_scache(). Hmm, the
probably cheapest version would be:

	if (r4k_blast_scache)
		r4k_blast_scache();

Problem solved.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [patch] blast_scache nop for sc cpus without scache

[Maciej W. Rozycki]

On Mon, 27 Jun 2005, Thomas Bogendoerfer wrote:

> >  Are you sure CONF_SC isn't set?
> 
> I've checked that after we saw a crash in __flush_cache_all().

 I see -- that's OK.

> > That would be weird, it's one of the boot-mode settings so it would be
> > hard to get it wrong.  What's printed upon bootstrap about caches?
> 
> I don't have the console working yet, we just put enough prom_printf()s
> to work out, what was going wron.

 How about using these prom_printf()s to implement a real early printk()?  
You'd save yourself and perhaps others a lot of hassle.

> I'm also not sure, whether adding the blast_scache_nop() stuff is
> the way to go. I'd probably throw out the switch case over CPU types
> and use a single test before calling r4k_blast_scache(). Hmm, the
> probably cheapest version would be:
> 
> 	if (r4k_blast_scache)
> 		r4k_blast_scache();
> 
> Problem solved.

 Probably, but there are actually other conditions already used, which may 
happen to fit, or otherwise you are rather after creating "cpu_has_scache" 
which would expand to a bit test for cpu_data[0].options or 0 or 1 as 
appropriate, depending on platform settings.

  Maciej

Re: [patch] blast_scache nop for sc cpus without scache

[peter fuerst]

Hi !


On Mon, 27 Jun 2005, Maciej W. Rozycki wrote:
>  How about using these prom_printf()s to implement a real early printk()?  
> You'd save yourself and perhaps others a lot of hassle.

Here's what helped me *a lot* when debugging. It's rather ugly, polluting
printk.c with platform/driver-(cross-)dependent hacks, but output is available
immediately on kernel startup, and on some machines you just can't do without
that ;)
(perhaps someone sometimes will create a clean implementation...)

--- kernel/printk.c	Tue Apr 19 21:43:47 2005
+++ kernel/printk.c	Mon Jun 13 22:13:09 2005
@@ -33,6 +33,7 @@
 #include <linux/syscalls.h>
 
 #include <asm/uaccess.h>
+#define early_log_by_prom_write 1
 
 #define __LOG_BUF_LEN	(1 << CONFIG_LOG_BUF_SHIFT)
 
@@ -403,12 +403,27 @@
 	}
 }
 
+static void inline __call_prom_write(unsigned long start, unsigned long end)
+{
+	static int prom_write(const char *s, int n);
+	prom_write(&LOG_BUF(start), end - start);
+}
+
 /*
  * Write out chars from start to end - 1 inclusive
  */
 static void _call_console_drivers(unsigned long start,
 				unsigned long end, int msg_log_level)
 {
+	if (/*msg_log_level < console_loglevel &&*/ start != end) {
+		if ((start & LOG_BUF_MASK) > (end & LOG_BUF_MASK)) {
+			/* wrapped write */
+			__call_prom_write(start & LOG_BUF_MASK, log_buf_len);
+			__call_prom_write(0, end & LOG_BUF_MASK);
+		} else {
+			__call_prom_write(start, end);
+		}
+	}
 	if (msg_log_level < console_loglevel &&
 			console_drivers && start != end) {
 		if ((start & LOG_BUF_MASK) > (end & LOG_BUF_MASK)) {
@@ -892,6 +907,7 @@
 		 * for us.
 		 */
 		spin_lock_irqsave(&logbuf_lock, flags);
+/*if(!early_log_by_prom_write)*/
 		con_start = log_start;
 		spin_unlock_irqrestore(&logbuf_lock, flags);
 	}
@@ -994,3 +1010,27 @@
 				printk_ratelimit_burst);
 }
 EXPORT_SYMBOL(printk_ratelimit);
+
+#include <asm/sgialib.h>
+static int prom_write(const char *s, int n)
+{
+#ifdef CONFIG_SGI_IP28
+	extern int ip22zilog_is_active(void);
+	extern int impactgfx_is_active(void);
+	if (n > 0 && early_log_by_prom_write)
+		if(!ip22zilog_is_active() && !impactgfx_is_active())
+		{	unsigned long oldstate;
+			int i;
+			romvec = ROMVECTOR;
+			oldstate = ip2628_enable_ucmem();
+			for (i = 0; i < n; ++i, ++s)
+			{	if ('\n' == *s)
+					prom_putchar('\r');
+				prom_putchar(*s);
+			}
+			ip2628_return_ucmem(oldstate);
+			return 1;
+		}
+#endif
+	return 0;
+}

kind regards

pf

Re: [patch] blast_scache nop for sc cpus without scache

[Maciej W. Rozycki]

On Tue, 28 Jun 2005, peter fuerst wrote:

> Here's what helped me *a lot* when debugging. It's rather ugly, polluting
> printk.c with platform/driver-(cross-)dependent hacks, but output is available
> immediately on kernel startup, and on some machines you just can't do without
> that ;)
> (perhaps someone sometimes will create a clean implementation...)

 Hint, hint!  Please have a look at arch/mips/dec/prom/console.c to see 
how trivial it can be!  (Of course DECstations have a particularly fancy 
piece of firmware -- you may have to do more work with less capable one.)

  Maciej

Re: [patch] blast_scache nop for sc cpus without scache

[Stanislaw Skowronek]

>  Hint, hint!  Please have a look at arch/mips/dec/prom/console.c to see 
> how trivial it can be!  (Of course DECstations have a particularly fancy 
> piece of firmware -- you may have to do more work with less capable one.)

Nice to know that you can register a console so early on :)

Both the ImpactSR and Odyssey drivers contain early console code (hint,
hint, pf) so they could be used for this.

Stanislaw