Re: [GIT repo] loongson: Merge and Clean up fuloong(2e), fuloong(2f) and yeeloong(2f) support

[Wu Zhangjin <wuzhangjin@gmail.com>]

On Fri, 2009-05-15 at 10:25 +0200, Arnaud Patard wrote:
> Wu Zhangjin <wuzhangjin@gmail.com> writes:
> 
> Hi,
> 
> > Dear all,
> >
> > I have cleaned up the source code of loongson-based machines support and
> > updated it to linux-2.6.29.3, the result is put to the following git
> > repository:
> >
> >    git://dev.lemote.com/rt4ls.git linux-2.6.29-stable-loongson-to-ralf
> >
> > this job is based on the to-mips branch of Yanhua's
> > git://dev.lemote.com/linux_loongson.git and the lm2e-fixes branch of
> > Philippe's git://git.linux-cisco.org/linux-mips.git. thanks goes to
> > them.
> 
> I'd like to look at your patches but getting a git url prevents me to do
> this because replying/commenting is not possible. Can you please send
> patches to the list instead ?
> 

Yes, I will tune some commits and then send the patches out.
thanks very much for your reply :-)

> >
> > I have tested it with gcc 4.3 on fuloong(2e), fuloong(2f), yeeloong(2f),
> > both 32bit and 64bit kernel works well, if you want to try it with gcc
> > 4.4, please use the patch from attachment.
> 
> I have some questions/comments :
> 
> - Why this patch is not merged in your patchset ?

this patch is not ready yet for several reasons:

1. under gcc 4.4(I'm using the version 4.4.0 20090313, not update to the
latest one yet), there are tons of problems when compiling
linux-loongson in 32bit. basically, 64bit is okay, but also some
problems there(i just found the reboot command of fuloong2f not work
under gcc4.4, but works well under gcc 4.3).

2. -march=loongson2* only goes into gcc >= 4.4, so, there is a need to
consider gcc >= 4.4 and gcc <= 4.3 differently, beside this compile
option, some extra source code should be treated differently too. for
example, this fix for gcc 4.4 will not work under gcc 4.3.

diff --git a/arch/mips/include/asm/delay.h
b/arch/mips/include/asm/delay.h
index b0bccd2..db054ec 100644
--- a/arch/mips/include/asm/delay.h
+++ b/arch/mips/include/asm/delay.h
@@ -82,12 +82,10 @@ static inline void __udelay(unsigned long usecs,
unsigned long lpj)
                : "=h" (usecs), "=l" (lo)
                : "r" (usecs), "r" (lpj)
                : GCC_REG_ACCUM);
-       else if (sizeof(long) == 8 && !R4000_WAR)
-               __asm__("dmultu\t%2, %3"
-               : "=h" (usecs), "=l" (lo)
-               : "r" (usecs), "r" (lpj)
-               : GCC_REG_ACCUM);
-       else if (sizeof(long) == 8 && R4000_WAR)
+       else if (sizeof(long) == 8 && !R4000_WAR) {
+               typedef unsigned int uint128_t
__attribute__((mode(TI)));
+               usecs = ((uint128_t) usecs * lpj) >> 64;
+       } else if (sizeof(long) == 8 && R4000_WAR)
                __asm__("dmultu\t%3, %4\n\tmfhi\t%0"
                : "=r" (usecs), "=h" (hi), "=l" (lo)
                : "r" (usecs), "r" (lpj

> - even if it should not affect the kernel, compiling with
>   -march=loongson2f even for 2e (you're matching on loongson2 so 2e and
>   2f) looks weird.

sorry, this is really a very obvious error, in 2e, -march=loongson2e
should be used.

to fix this problem, perhaps we can add two new kernel options:

config CPU_LOONGSON2E
	bool

config CPU_LOONGSON2F
	bool

and then use this solution:

config FULOONG2E
	...
	select CPU_LOONGSON2E
	...

config YEELOONG2F
	...
	select CPU_LOONGSON2F
	...

cflags-$(CONFIG_CPU_LOONGSON2E)  += -march=loongson2e -Wa,--trap
cflags-$(CONFIG_CPU_LOONGSON2F)  += -march=loongson2f -Wa,--trap

is this solution okay?

> - you're using the -mfix-ls2f-kernel binutils flag but afaik upstream
>   binutils doesn't know it. I really don't know how such a thing should
>   be handled but it seems strange to use this flag before binutils has
>   been patched for it. (the previous comment about -march=loongson2f
>   applies here too)
> 

so, it is better not use -mfix-ls2f-kernel before this option goes to
the upstream binutils, i will remove it later.

but for the above reasons, i really do not want to focus on gcc 4.4
support currently, is it okay?

thanks!
Wu Zhangjin