On Thu, 2003-03-27 at 07:37, DOYU,Hiroshi wrote:
> I attached the SH775xR patch for 2.4.20 kernel and ipl+g. It works well
> on SolutionEngine 775[0-1]R.
>
> If you have any comments, please let me know.
>
This is a bit of a surprise, I wasn't aware anyone even monitored the
other branches.
First off, thanks for taking care of the clear_page.S changes, I had
been putting those off for awhile due to lack of hardware to test on.
Presuming everything else still works, I'll merge this back into the 2.5
code.
Secondly, in this hunk:
> diff -Naur -X dontdiff linux-2_4_20.ORG/include/asm-sh/bugs.h
linux-2_4_20/include/asm-sh/bugs.h
> --- linux-2_4_20.ORG/include/asm-sh/bugs.h 2003-03-24
10:42:45.000000000 +0900
> +++ linux-2_4_20/include/asm-sh/bugs.h 2003-03-25 19:52:13.000000000
+0900
> @@ -13,11 +13,16 @@
> */
>
> #include <asm/processor.h>
> +#include <asm/pci-sh7751.h>
>
> static void __init check_bugs(void)
> {
> extern unsigned long loops_per_jiffy;
> char *p= &system_utsname.machine[2]; /* "sh" */
> + unsigned int id_51, id_51r;
> +
> + id_51 = (SH7751_DEVICE_ID << 16) | SH7751_VENDOR_ID;
> + id_51r = (SH7751R_DEVICE_ID << 16) | SH7751_VENDOR_ID;
>
> cpu_data->loops_per_jiffy = loops_per_jiffy;
>
What's the point of this change? We already take care of 7751/7751R
probing in detect_cpu_and_cache_system().
The only downfall of the new probing code so far is that it leaves the
ST40 in a broken state. I made a note about this awhile ago, but nothing
has been done to fix that up yet. Stuart?
In addition to this, the new cache handling code has the side effect of
bloating sh_cpuinfo on things like the sh2 and the sh3, which don't have
a split I/D distinction. Though, I suppose this can be ifdef'ed around,
or shoved in a union, or something equally ugly in the interest of
saving space. For sh4 and sh5 however, things are fine.
Regards,
--
Paul Mundt <le...@li...>
|
