Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 5月, 2022 1 次提交
  3. 08 2月, 2022 1 次提交
  5. 26 1月, 2022 1 次提交
  7. 21 12月, 2021 1 次提交
  9. 01 12月, 2021 1 次提交
  11. 21 10月, 2021 2 次提交
  13. 18 10月, 2021 1 次提交
  15. 29 9月, 2021 1 次提交
  17. 31 5月, 2021 1 次提交
  19. 10 5月, 2021 1 次提交
  21. 08 4月, 2021 1 次提交
  23. 24 3月, 2021 2 次提交
  25. 15 3月, 2021 1 次提交
  27. 26 1月, 2021 1 次提交
  29. 22 1月, 2021 1 次提交
    • S
      irqchip/sun6i-r: Use a stacked irqchip driver · 4e346146
      由 Samuel Holland 提交于 
      The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
original sun4i interrupt controller than the sun7i/sun9i NMI controller.
It is used for two distinct purposes:
 - To control the trigger, latch, and mask for the NMI input pin
 - To provide the interrupt input for the ARISC coprocessor

As this interrupt controller is not documented, information about it
comes from vendor-provided firmware blobs and from experimentation.

Differences from the sun4i interrupt controller appear to be:
 - It only has one or two registers of each kind (max 32 or 64 IRQs)
 - Multiplexing logic is added to support additional inputs
 - There is no FIQ-related logic
 - There is no interrupt priority logic

In order to fulfill its two purposes, this hardware block combines four
types of IRQs. First, the NMI pin is routed to the "IRQ 0" input on this
chip, with a trigger type controlled by the NMI_CTRL_REG. The "IRQ 0
pending" output from this chip, if enabled, is then routed to a SPI IRQ
input on the GIC. In other words, bit 0 of IRQ_ENABLE_REG *does* affect
the NMI IRQ seen at the GIC.

The NMI is followed by a contiguous block of 15 "direct" (my name for
them) IRQ inputs that are connected in parallel to both R_INTC and the
GIC. Or in other words, these bits of IRQ_ENABLE_REG *do not* affect the
IRQs seen at the GIC.

Following the direct IRQs are the ARISC's copy of banked IRQs for shared
peripherals. These are not relevant to Linux. The remaining IRQs are
connected to a multiplexer and provide access to the first (up to) 128
SPIs from the ARISC. This range of SPIs overlaps with the direct IRQs.

Because of the 1:1 correspondence between R_INTC and GIC inputs, this is
a perfect scenario for using a stacked irqchip driver. We want to hook
into setting the NMI trigger type, but not actually handle any IRQ here.

To allow access to all multiplexed IRQs, this driver requires a new
binding where the interrupt number matches the GIC interrupt number.
(This moves the NMI from number 0 to 32 or 96, depending on the SoC.)
For simplicity, copy the three-cell GIC binding; this disambiguates
interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
binding (SPI 0) by the number of cells.

Since R_INTC is in the always-on power domain, and its output is visible
to the power management coprocessor, a stacked irqchip driver provides a
simple way to add wakeup support to any of its IRQs. That is the next
patch; for now, just the NMI is moved over.

This commit mostly reverts commit 173bda53 ("irqchip/sunxi-nmi:
Support sun6i-a31-r-intc compatible").
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210118055040.21910-4-samuel@sholland.org
      4e346146
  31. 20 1月, 2021 1 次提交
    • A
      ARM: remove zte zx platform · 89d4f98a
      由 Arnd Bergmann 提交于 
      The ZTE ZX set-top-box SoC platform was added in 2015 by Jun Nie, with
Baoyou Xie and Shawn Guo subsequently becoming maintainers after the
addition of the 64-bit variant.

However, the only machines that were ever supported upstream are the
reference designs, not actual set-top-box devices that would benefit
from this support. All ZTE set-top-boxes from the past few years seem
to be based on third-party SoCs. While there is very little information
about zx296702 and zx296718 on the web, I found some references to other
chips from the same family, such as zx296716 and zx296719, which were
never submitted for upstream support. Finally, there is no support for
the GPU on either of them, with the lima and panfrost device drivers
having been added after work on the zx platform had stopped.

Shawn confirmed that he has not seen any interest in this platform for
the past four years, and that it can be removed.

Thanks to Jun and Shawn for maintaining this platform over the past
five years.

Cc: Jun Nie <jun.nie@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      89d4f98a
  33. 05 1月, 2021 1 次提交
  35. 10 12月, 2020 1 次提交
  37. 26 11月, 2020 1 次提交
  39. 10 11月, 2020 1 次提交
  41. 31 10月, 2020 1 次提交
    • A
      timekeeping: default GENERIC_CLOCKEVENTS to enabled · 0774a6ed
      由 Arnd Bergmann 提交于 
      Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to
require each one to select that symbol manually.

Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as
a simplification. It should be possible to select both
GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now
and decide at runtime between the two.

For the clockevents arch-support.txt file, this means that additional
architectures are marked as TODO when they have at least one machine
that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when
at least one machine has been converted. This means that both m68k and
arm (for riscpc) revert to TODO.

At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS
rather than leaving it off when not needed. I built an m68k
defconfig kernel (using gcc-10.1.0) and found that this would add
around 5.5KB in kernel image size:

   text	   data	    bss	    dec	    hex	filename
3861936	1092236	 196656	5150828	 4e986c	obj-m68k/vmlinux-no-clockevent
3866201	1093832	 196184	5156217	 4ead79	obj-m68k/vmlinux-clockevent

On Arm (MACH_RPC), that difference appears to be twice as large,
around 11KB on top of an 6MB vmlinux.
Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      0774a6ed
  43. 26 10月, 2020 1 次提交
  45. 23 9月, 2020 1 次提交
  47. 20 8月, 2020 1 次提交
  49. 23 7月, 2020 1 次提交
  51. 17 7月, 2020 2 次提交
  53. 03 6月, 2020 1 次提交
    • A
      clk: sprd: fix compile-testing · b5f73d47
      由 Arnd Bergmann 提交于 
      I got a build failure with CONFIG_ARCH_SPRD=m when the
main portion of the clock driver failed to get linked into
the kernel:

ERROR: modpost: "sprd_pll_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_comp_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_clk_probe" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_clk_regmap_init" [drivers/clk/sprd/sc9863a-clk.ko] undefined!
ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!
ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!
ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined!

This is a combination of two trivial bugs:

- A platform should not be 'tristate', it should be a 'bool' symbol
  like the other platforms, if only for consistency, and to avoid
  surprises like this one.

- The clk Makefile does not traverse into the sprd subdirectory
  if the platform is disabled but the drivers are enabled for
  compile-testing.

Fixing either of the two would be sufficient to address the link failure,
but for correctness, both need to be changed.

Fixes: 2b1b799d ("arm64: change ARCH_SPRD Kconfig to tristate")
Fixes: d41f59fd ("clk: sprd: Add common infrastructure")
Acked-by: NChunyan Zhang <chunyan.zhang@unisoc.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      b5f73d47
  55. 06 5月, 2020 3 次提交
  57. 11 3月, 2020 1 次提交
  59. 09 3月, 2020 1 次提交
  61. 06 3月, 2020 1 次提交
  63. 26 10月, 2019 2 次提交
  65. 11 10月, 2019 1 次提交
  67. 05 9月, 2019 1 次提交