Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 2月, 2019 1 次提交
  3. 05 2月, 2019 3 次提交
    • P
      MIPS: Loongson32: Fix config brokenness; select SYS_SUPPORTS_32BIT_KERNEL · d6c2fba5
      由 Paul Burton 提交于 
      Commit a96d68ba ("MIPS: Loongson32: clarify we don't support MIPS16
and merge configs") attempted to reduce duplication in Kconfig by
consolidating some selects common to Loongson 1B & 1C CPUs under
CPU_LOONGSON1. Unfortunately it clearly wasn't tested because by
removing SYS_SUPPORTS_32BIT_KERNEL it prevented 32BIT from being enabled
leading to all sorts of strange build errors from a kernel configured to
build as neither 32 nor 64 bit.

Both loongson1b_defconfig & loongson1c_defconfig failed to build due to
this problem.

Revert the cleanup portions of commit a96d68ba ("MIPS: Loongson32:
clarify we don't support MIPS16 and merge configs"), keeping only its
removal of the selection of SYS_SUPPORTS_MIPS16.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Fixes: a96d68ba ("MIPS: Loongson32: clarify we don't support MIPS16 and merge configs")
      d6c2fba5
    • P
      MIPS: Don't select ARCH_HAS_SYNC_DMA_FOR_CPU when DMA is coherent · 9ae1f262
      由 Paul Burton 提交于 
      Commit f263f2a2 ("MIPS: Compile post DMA flush only when needed")
pushed the selection of ARCH_HAS_SYNC_DMA_FOR_CPU down to various
SYS_HAS_CPU_* Kconfig entries corresponding to CPUs for which
cpu_needs_post_dma_flush() might return true, but unfortunately missed
the fact that some of these CPUs can be used in configurations with
DMA_NONCOHERENT=n. When this is the case the kernel build does not
include our definition of arch_sync_dma_for_cpu() from
arch/mips/mm/dma-noncoherent.c and the build fails with a link error.

One example of this problem is ip27_defconfig:

  kernel/dma/direct.o: In function `dma_direct_sync_single_for_cpu':
  direct.c:(.text+0x6c): undefined reference to `arch_sync_dma_for_cpu'
  kernel/dma/direct.o: In function `dma_direct_sync_sg_for_cpu':
  direct.c:(.text+0x1f0): undefined reference to `arch_sync_dma_for_cpu'
  kernel/dma/direct.o: In function `dma_direct_alloc':
  direct.c:(.text+0xc20): undefined reference to `arch_dma_alloc'
  kernel/dma/direct.o: In function `dma_direct_free':
  direct.c:(.text+0xc3c): undefined reference to `arch_dma_free'
  make[1]: *** [Makefile:1021: vmlinux] Error 1
  make: *** [Makefile:152: sub-make] Error 2

Fix this by selecting ARCH_HAS_SYNC_DMA_FOR_CPU only when
DMA_NONCOHERENT is also selected. The SYS_HAS_CPU_BMIPS5000 case is left
as-is because systems with that CPU always select DMA_NONCOHERENT
anyway.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Fixes: f263f2a2 ("MIPS: Compile post DMA flush only when needed")
      9ae1f262
    • P
      MIPS: Enable hugepage support for MIPS64r6 · afd375dc
      由 Paul Burton 提交于 
      Our hugepage support already exists for MIPS64 CPUs, and is already
enabled for older architecture revisions. There's nothing MIPSr6
specific involved, and our hugepage support already works fine for
MIPS64r6 CPUs such as the I6500, so allow it to be selected in Kconfig.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
      afd375dc
  5. 23 1月, 2019 3 次提交
  7. 19 1月, 2019 1 次提交
    • H
      MIPS: Compile post DMA flush only when needed · f263f2a2
      由 Hauke Mehrtens 提交于 
      dma_sync_phys() is only called for some CPUs when a mapping is removed.
Add ARCH_HAS_SYNC_DMA_FOR_CPU only for the CPUs listed in
cpu_needs_post_dma_flush() which need this extra call and do not compile
this code in for other CPUs. We need this for R10000, R12000, BMIPS5000
CPUs and CPUs supporting MAAR which was introduced in MIPS32r5.

This will hopefully improve the performance of the not affected devices.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Cc: ralf@linux-mips.org
Cc: jhogan@kernel.org
Cc: linux-mips@vger.kernel.org
Cc: nbd@nbd.name
      f263f2a2
  9. 14 12月, 2018 1 次提交
  11. 23 11月, 2018 6 次提交
  13. 22 11月, 2018 1 次提交
    • P
      MIPS: Enable dead code elimination · c0436b50
      由 Paul Burton 提交于 
      Select CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION for MIPS, allowing the
user to enable dead code elimination. In order for this to work, ensure
that we keep the data bus exception table & the machine list by
annotating them with KEEP.

This shrinks both 32r2el_defconfig & 64r6el_defconfig builds by ~6%, as
shown by numbers from scripts/bloat-o-meter:

          | 32r2el_defconfig | 64r6el_defconfig
  --------|------------------|------------------
   No DCE | 8919864          | 8286307
      DCE | 8338988 (-6.51%) | 7741808 (-6.57%)
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/21187/
Cc: linux-mips@linux-mips.org
      c0436b50
  15. 21 11月, 2018 1 次提交
  17. 16 11月, 2018 2 次提交
    • M
      MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur · e4849aff
      由 Maciej W. Rozycki 提交于 
      The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1].  Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.

Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range.  The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.

I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.

Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available.  Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.

All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.

This shows up as follows:

Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
 memory: 000000000fe7fe00 @ 0000000000000000 (usable)
 memory: 000000001ffffe00 @ 0000000080000000 (usable)
 memory: 000000000ffffe00 @ 00000000c0000000 (usable)
 memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)

in the bootstrap log and removes failures like these:

defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1

when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.

This updates commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
DMA32.").

References:

[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
    Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
    "Memory Map", pp. 34-38

[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
    Corporation, 18 May 2004, Section 3: "Physical Description",
    "Supported DRAM", p. 23
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
      e4849aff
    • M
      MIPS: SiByte: Enable ZONE_DMA32 for LittleSur · 756d6d83
      由 Maciej W. Rozycki 提交于 
      The LittleSur board is marked for high memory support and therefore
clearly must provide a way to have enough memory installed for some to
be present outside the low 4GiB physical address range.  With the memory
map of the BCM1250 SOC it has been built around it means over 1GiB of
actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical
address range[1].

Complement commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
DMA32.") then and also enable ZONE_DMA32 for LittleSur.

References:

[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
    Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
    "Memory Map", pp. 34-38
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21107/
Fixes: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
      756d6d83
  19. 13 11月, 2018 3 次提交
  21. 10 11月, 2018 4 次提交
  23. 09 11月, 2018 1 次提交
  25. 06 11月, 2018 1 次提交
  27. 31 10月, 2018 2 次提交
  29. 27 9月, 2018 1 次提交
    • Y
      MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions · 932afdee
      由 Yasha Cherikovsky 提交于 
      MIPSR6 CPUs do not support unaligned load/store instructions
(LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit).

Currently the MIPS tree has some special cases to avoid these
instructions, and the code is testing for !CONFIG_CPU_MIPSR6.

This patch declares a new Kconfig variable:
CONFIG_CPU_HAS_LOAD_STORE_LR.
This variable indicates that the CPU supports these instructions.

Then, the patch does the following:
- Carefully selects this option on all CPUs except MIPSR6.
- Switches all the special cases to test for the new variable,
  and inverts the logic:
    '#ifndef CONFIG_CPU_MIPSR6' turns into
    '#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR'
    and vice-versa.

Also, when this variable is NOT selected (e.g. MIPSR6),
CONFIG_GENERIC_CSUM will default to 'y', to compile generic
C checksum code (instead of special assembly code that uses the
unsupported instructions).

This commit should not affect any existing CPU, and is required
for future Lexra CPU support, that misses these instructions too.
Signed-off-by: NYasha Cherikovsky <yasha.che3@gmail.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20808/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
      932afdee
  31. 23 9月, 2018 1 次提交
  33. 20 9月, 2018 4 次提交
  35. 15 9月, 2018 1 次提交
    • M
      mips: switch to NO_BOOTMEM · bcec54bf
      由 Mike Rapoport 提交于 
      MIPS already has memblock support and all the memory is already registered
with it.

This patch replaces bootmem memory reservations with memblock ones and
removes the bootmem initialization.

Since memblock allocates memory in top-down mode, we ensure that memblock
limit is max_low_pfn to prevent allocations from the high memory.

To have the exceptions base in the lower 512M of the physical memory, its
allocation in arch/mips/kernel/traps.c::traps_init() is using bottom-up
mode.
Signed-off-by: NMike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20560/
Cc: Serge Semin <fancer.lancer@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
      bcec54bf
  37. 08 9月, 2018 1 次提交
  39. 31 8月, 2018 1 次提交
    • P
      MIPS: Use GENERIC_IOMAP · b962aeb0
      由 Paul Burton 提交于 
      MIPS has a copy of lib/iomap.c with minor alterations, none of which are
necessary given appropriate definitions of PIO_OFFSET, PIO_MASK &
PIO_RESERVED. Provide such definitions, select GENERIC_IOMAP & remove
arch/mips/lib/iomap.c to cut back on the needless duplication.

The one change this does make is to our mmio_{in,out}s[bwl] functions,
which began to deviate from their generic counterparts with commit
0845bb72 ("MIPS: iomap: Use __mem_{read,write}{b,w,l} for MMIO"). I
suspect that this commit was incorrect, and that the SEAD-3 platform
should have instead selected CONFIG_SWAP_IO_SPACE. Since the SEAD-3
platform code is now gone & the board is instead supported by the
generic platform (CONFIG_MIPS_GENERIC) which selects
CONFIG_SWAP_IO_SPACE anyway, this shouldn't be a problem any more.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20342/
Cc: linux-mips@linux-mips.org
      b962aeb0
  41. 22 8月, 2018 1 次提交
    • P
      MIPS: Workaround GCC __builtin_unreachable reordering bug · 906d441f
      由 Paul Burton 提交于 
      Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

    https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):

    Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
    VPE topology {2,2} total 4
    Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
    Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
    <AdEL exception here>

This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.

That was actually done already for other reasons by commit 173a3efd
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.

Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:

    arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
    arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode

Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.

We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.
Signed-off-by: NPaul Burton <paul.burton@mips.com>
Fixes: 173a3efd ("bug.h: work around GCC PR82365 in BUG()")
Patchwork: https://patchwork.linux-mips.org/patch/20270/
Cc: James Hogan <jhogan@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@linux-mips.org
      906d441f