#
# Loongson Processors' Support
#

# Only gcc >= 4.4 have Loongson specific support
cflags-$(CONFIG_CPU_LOONGSON2EF)	+= -Wa,--trap
cflags-$(CONFIG_CPU_LOONGSON2E) += \
	$(call cc-option,-march=loongson2e,-march=r4600)
cflags-$(CONFIG_CPU_LOONGSON2F) += \
	$(call cc-option,-march=loongson2f,-march=r4600)
# Enable the workarounds for Loongson2f
ifdef CONFIG_CPU_LOONGSON2F_WORKAROUNDS
  ifeq ($(call as-option,-Wa$(comma)-mfix-loongson2f-nop,),)
    $(error only binutils >= 2.20.2 have needed option -mfix-loongson2f-nop)
  else
    cflags-$(CONFIG_CPU_NOP_WORKAROUNDS) += -Wa$(comma)-mfix-loongson2f-nop
  endif
  ifeq ($(call as-option,-Wa$(comma)-mfix-loongson2f-jump,),)
    $(error only binutils >= 2.20.2 have needed option -mfix-loongson2f-jump)
  else
    cflags-$(CONFIG_CPU_JUMP_WORKAROUNDS) += -Wa$(comma)-mfix-loongson2f-jump
  endif
endif

cflags-$(CONFIG_CPU_LOONGSON64)	+= -Wa,--trap

#
# Some versions of binutils, not currently mainline as of 2019/02/04, support
# an -mfix-loongson3-llsc flag which emits a sync prior to each ll instruction
# to work around a CPU bug (see loongson_llsc_mb() in asm/barrier.h for a
# description).
#
# We disable this in order to prevent the assembler meddling with the
# instruction that labels refer to, ie. if we label an ll instruction:
#
# 1: ll v0, 0(a0)
#
# ...then with the assembler fix applied the label may actually point at a sync
# instruction inserted by the assembler, and if we were using the label in an
# exception table the table would no longer contain the address of the ll
# instruction.
#
# Avoid this by explicitly disabling that assembler behaviour. If upstream
# binutils does not merge support for the flag then we can revisit & remove
# this later - for now it ensures vendor toolchains don't cause problems.
#
cflags-$(CONFIG_CPU_LOONGSON64)	+= $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,)

#
# binutils from v2.25 on and gcc starting from v4.9.0 treat -march=loongson3a
# as MIPS64 R2; older versions as just R1.  This leaves the possibility open
# that GCC might generate R2 code for -march=loongson3a which then is rejected
# by GAS.  The cc-option can't probe for this behaviour so -march=loongson3a
# can't easily be used safely within the kbuild framework.
#
ifeq ($(call cc-ifversion, -ge, 0409, y), y)
  ifeq ($(call ld-ifversion, -ge, 225000000, y), y)
    cflags-$(CONFIG_CPU_LOONGSON64)  += \
      $(call cc-option,-march=loongson3a -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
  else
    cflags-$(CONFIG_CPU_LOONGSON64)  += \
      $(call cc-option,-march=mips64r2,-mips64r2 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
  endif
else
    cflags-$(CONFIG_CPU_LOONGSON64)  += \
      $(call cc-option,-march=mips64r2,-mips64r2 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
endif

# Some -march= flags enable MMI instructions, and GCC complains about that
# support being enabled alongside -msoft-float. Thus explicitly disable MMI.
cflags-y += $(call cc-option,-mno-loongson-mmi)

#
# Loongson Machines' Support
#

platform-$(CONFIG_MACH_LOONGSON64) += loongson64/
cflags-$(CONFIG_MACH_LOONGSON64) += -I$(srctree)/arch/mips/include/asm/mach-loongson64 -mno-branch-likely
load-$(CONFIG_LEMOTE_FULOONG2E) += 0xffffffff80100000
load-$(CONFIG_LEMOTE_MACH2F) += 0xffffffff80200000
load-$(CONFIG_LOONGSON_MACH3X) += 0xffffffff80200000