Re: [PATCH V3 1/2] MIPS: Loongson-3: Enable COP2 usage in kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 2020/8/7 下午9:25, Jiaxun Yang 写道:


在 2020/8/7 21:13, Thomas Bogendoerfer 写道:
On Wed, Aug 05, 2020 at 09:51:44PM +0800, Jiaxun Yang wrote:
yes there is. Since this COP2 is a total black box to me, it would be
really helpfull to get some docs for it or at least some information what
it exactly does and how you want to use it in kernel code.
FYI:
Loongson doesn't have any CU2 register. It just reused LWC2 & LDC2 opcode to define some load & store instructions (e.g. 128bit load to two GPRs).

I have a collection of these instructions here[1].

 From GS464E (3A2000+), execuating these instruction won't produce COP2
unusable
exception. But older Loongson cores (GS464) will still produce COP2
exception, thus
we should have CU2 enabled in kernel. That would allow us use to these
instructions
to optimize kernel.
thank you that makes things a little bit clearer.

How will this be used in kernel code ? Special assembler routines or
by enabling gcc options ?

Via special assembly routines, as -msoft-float will disable generation of
these instructions in GCC.

I knew Huacai have out-of-tree memcpy optimization and Xuerui have
RAID5 optimiztion with these instructions.


And finally what I stil don't like is the splittering of more
#ifdef LOONGSON into common code. I'd prefer a more generic way
to enable COPx for in kernel usage. Maybe a more generic config option
or a dynamic solution like the one for user land.
Agreed. some Kconfig options or cpuinfo_mips.options can be helpful.
let's see whether this really is needed.

To me it looks like the COP2 exception support for loongson makes
thing worse than it helps. How about the patch below ? There is still
a gap between starting the kernel and COP2 enabled for which I'm not
sure, if we are hitting COP2 instructions.


I had a off-list discussion with Huacai and found it's not the case.

Some Loongson CU2 instructions (e.g. GSLQC1) uses FPU registers, and now we're uncoditionally
let the thread own FPU in cop2-ex handler when CU2 exception triggered.
However, if we enable CU2 all the time, than the FPU context of these instructions might be lost. (Yes, these instructions won't generate CU1 unusable exception when CU2 is enabled but not CU1,
it is likely to be a design fault.)

Thus we still need to enable CU2 with exception for user space, and we can always enable CU2 in
kernel since kernel won't be compiled with hard-float. :-)

Thanks.

- Jiaxun



[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux