Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1659280 > unrolled thread

RISC-V Linux Port v2

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RISC-V Linux Port v2 Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
    [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
      Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Geert Uytterhoeven <geert@linux-m68k.org> - 2017-06-07 09:30 +0200
        Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Arnd Bergmann <arnd@arndb.de> - 2017-06-07 10:10 +0200
        Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Christoph Hellwig <hch@infradead.org> - 2017-06-08 10:20 +0200
          Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Arnd Bergmann <arnd@arndb.de> - 2017-06-08 10:40 +0200
    [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
      Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Geert Uytterhoeven <geert@linux-m68k.org> - 2017-06-07 09:20 +0200
        Re: [PATCH 08/17] dts: include documentation for the RISC-V  interrupt controllers Mark Rutland <mark.rutland@arm.com> - 2017-06-07 12:20 +0200
          Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Wesley Terpstra <wesley@sifive.com> - 2017-06-07 21:00 +0200
            Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Rob Herring <robh+dt@kernel.org> - 2017-06-07 22:00 +0200
              Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Wesley Terpstra <wesley@sifive.com> - 2017-06-07 22:40 +0200
            Re: [PATCH 08/17] dts: include documentation for the RISC-V  interrupt controllers Mark Rutland <mark.rutland@arm.com> - 2017-06-08 13:00 +0200
              Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Wesley Terpstra <wesley@sifive.com> - 2017-06-09 23:50 +0200
              Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Wesley Terpstra <wesley@sifive.com> - 2017-06-10 00:00 +0200
                Re: [PATCH 08/17] dts: include documentation for the RISC-V  interrupt controllers Mark Rutland <mark.rutland@arm.com> - 2017-06-19 16:40 +0200
      Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-06-08 00:30 +0200
    [PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
      Re: [PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver Geert Uytterhoeven <geert@linux-m68k.org> - 2017-06-07 09:20 +0200
    [PATCH 01/17] drivers: support PCIe in RISCV Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
      Re: [PATCH 01/17] drivers: support PCIe in RISCV Geert Uytterhoeven <geert@linux-m68k.org> - 2017-06-07 09:20 +0200
      Re: [PATCH 01/17] drivers: support PCIe in RISCV Christoph Hellwig <hch@infradead.org> - 2017-06-07 16:30 +0200
        Re: [PATCH 01/17] drivers: support PCIe in RISCV Olof Johansson <olof@lixom.net> - 2017-06-07 19:50 +0200
    [PATCH 15/17] RISC-V: Add mm subdirectory Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
    [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-07 01:10 +0200
      Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource Geert Uytterhoeven <geert@linux-m68k.org> - 2017-06-07 09:20 +0200
        Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource Arnd Bergmann <arnd@arndb.de> - 2017-06-07 09:30 +0200
      Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource Marc Zyngier <marc.zyngier@arm.com> - 2017-06-07 11:50 +0200
    Re: RISC-V Linux Port v2 David Howells <dhowells@redhat.com> - 2017-06-07 09:30 +0200
      Re: RISC-V Linux Port v2 Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-08 00:00 +0200
    Re: [PATCH 13/17] RISC-V: Add include subdirectory Arnd Bergmann <arnd@arndb.de> - 2017-06-07 10:20 +0200
    Re: RISC-V Linux Port v2 Will Deacon <will.deacon@arm.com> - 2017-06-07 11:30 +0200
      Re: RISC-V Linux Port v2 Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-08 00:00 +0200
        Re: RISC-V Linux Port v2 Will Deacon <will.deacon@arm.com> - 2017-06-08 12:30 +0200
          Re: RISC-V Linux Port v2 Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-08 20:20 +0200
    Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:00 +0200
      Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:30 +0200
    Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:10 +0200
      Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:30 +0200
      Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:40 +0200
        Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 15:00 +0200
          Re: [PATCH 13/17] RISC-V: Add include subdirectory Will Deacon <will.deacon@arm.com> - 2017-06-07 15:20 +0200
          Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 18:40 +0200
    Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 14:50 +0200
    Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-07 15:20 +0200
      Re: [PATCH 13/17] RISC-V: Add include subdirectory Peter Zijlstra <peterz@infradead.org> - 2017-06-09 10:20 +0200

Page 1 of 3  [1] 2 3  Next page →

#1659280 — RISC-V Linux Port v2

Thanks to everyone who has participated in the review process so far.  We've
made a lot of changes since the v1 and while this isn't ready to go yet, I
finally managed to get through everything in my inbox so I thought it would be
a good time to submit a v2 so everyone is on the same page.

A highlight of the changes since the v1 patch set includes:

  * We've split out our drivers into the right places, which means now there's
    a lot more patches.  I'll be submitting these patches to various subsystem
    maintainers and including them in any future RISC-V patch sets until
    they've been merged.

  * The SBI console driver has been completely rewritten to use the HVC helpers
    and is now significantly smaller.

  * We've begun to use weaker barries as opposed to just the big "fence".
    There's still some work to do here, specifically:
    - We need fences in the realxed MMIO functions.
    - The non-relaxed MMIO functions are missing R/W bits on their fences.
    - Many AMOs need the aq and rl bits set.

  * We now have thread_info in task_struct.  As a result, sscratch now contains
    TP instead of SP.  This was necessary because thread_info is no longer on
    the stack.

  * A few shared routines have been added that we use instead of creating
    another arch copy.

Here's my TODO list

  * The memory model changes indicated above.

  * I need to go through checkpatch again to make sure none of the messages are
    valid problems.

  * Put an implementation of atomic compare/exchange in the VDSO when atomic
    instructions are enabled, otherwise insert stubs to the cmpxchg syscall.

  * Remove the extra multiplexing in the cmpxchg syscall.

Aside from those two releatively minor ABI issues, I think our ABI is in good
shape.  Unless there are any other issues that crop up I'd like to begin our
glibc submission early next week.

[PATCH 01/17] drivers: support PCIe in RISCV
[PATCH 02/17] pcie-xilinx: add missing 5th legacy interrupt
[PATCH 03/17] base: fix order of OF initialization
[PATCH 04/17] Documentation: atomic_ops.txt is
[PATCH 05/17] MAINTAINERS: Add RISC-V
[PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}
[PATCH 07/17] lib: Add shared copies of some GCC library routines
[PATCH 08/17] dts: include documentation for the RISC-V interrupt
[PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource
[PATCH 10/17] irqchip: New RISC-V PLIC Driver
[PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver
[PATCH 12/17] tty: New RISC-V SBI Console Driver
[PATCH 13/17] RISC-V: Add include subdirectory
[PATCH 14/17] RISC-V: lib files
[PATCH 15/17] RISC-V: Add mm subdirectory
[PATCH 16/17] RISC-V: Add kernel subdirectory
[PATCH 17/17] RISC-V: Makefile and Kconfig

[toc] | [next] | [standalone]

#1659281 — [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

While upstreaming the RISC-V port, it was pointed out that multiple
architectures (arc, arm64, cris, microblaze, sh, tile) have copied the
mostly empty versions of at least one of these functions.  This defines
weakly bound versions of the common functions so other architetures can
use them.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
---
 drivers/pci/Makefile |  2 +-
 drivers/pci/bios.c   | 42 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/bios.c

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index a29d9ec05d13..fa7040915194 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -4,7 +4,7 @@
 
 obj-y		+= access.o bus.o probe.o host-bridge.o remove.o pci.o \
 			pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
-			irq.o vpd.o setup-bus.o vc.o mmap.o
+			irq.o vpd.o setup-bus.o vc.o mmap.o bios.o
 obj-$(CONFIG_PROC_FS) += proc.o
 obj-$(CONFIG_SYSFS) += slot.o
 
diff --git a/drivers/pci/bios.c b/drivers/pci/bios.c
new file mode 100644
index 000000000000..ffe34c024aa8
--- /dev/null
+++ b/drivers/pci/bios.c
@@ -0,0 +1,42 @@
+/*
+ * Code borrowed from arch/arm64/kernel/pci.c
+ *   which borrowed from powerpc/kernel/pci-common.c
+ *   which borrowed from arch/alpha/kernel/pci.c
+ *
+ * Extruded from code written by
+ *      Dave Rusling (david.rusling@reo.mts.dec.com)
+ *      David Mosberger (davidm@cs.arizona.edu)
+ * Copyright (C) 1999 Andrea Arcangeli <andrea@suse.de>
+ * Copyright (C) 2000 Ivan Kokshaysky <ink@jurassic.park.msu.ru>
+ * Copyright (C) 2003 Anton Blanchard <anton@au.ibm.com>, IBM
+ * Copyright (C) 2014 ARM Ltd.
+ * Copyright (C) 2017 SiFive
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+/* This file contains weakly bound functions that implement pcibios functions
+ * that some architectures have copied verbatim.
+ */
+
+#include <linux/pci.h>
+
+/*
+ * Called after each bus is probed, but before its children are examined
+ */
+__attribute__ ((weak))
+void pcibios_fixup_bus(struct pci_bus *bus)
+{
+       /* nothing to do, expected to be removed in the future */
+}
+/*
+ * We don't have to worry about legacy ISA devices, so nothing to do here
+ */
+__attribute__ ((weak))
+resource_size_t pcibios_align_resource(void *data, const struct resource *res,
+				       resource_size_t size, resource_size_t align)
+{
+       return res->start;
+}
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]

#1659474 — Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

CC pci folks

On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> While upstreaming the RISC-V port, it was pointed out that multiple
> architectures (arc, arm64, cris, microblaze, sh, tile) have copied the
> mostly empty versions of at least one of these functions.  This defines
> weakly bound versions of the common functions so other architetures can
> use them.
>
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> ---
>  drivers/pci/Makefile |  2 +-
>  drivers/pci/bios.c   | 42 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 43 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/pci/bios.c
>
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index a29d9ec05d13..fa7040915194 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -4,7 +4,7 @@
>
>  obj-y          += access.o bus.o probe.o host-bridge.o remove.o pci.o \
>                         pci-driver.o search.o pci-sysfs.o rom.o setup-res.o \
> -                       irq.o vpd.o setup-bus.o vc.o mmap.o
> +                       irq.o vpd.o setup-bus.o vc.o mmap.o bios.o
>  obj-$(CONFIG_PROC_FS) += proc.o
>  obj-$(CONFIG_SYSFS) += slot.o
>
> diff --git a/drivers/pci/bios.c b/drivers/pci/bios.c
> new file mode 100644
> index 000000000000..ffe34c024aa8
> --- /dev/null
> +++ b/drivers/pci/bios.c
> @@ -0,0 +1,42 @@
> +/*
> + * Code borrowed from arch/arm64/kernel/pci.c
> + *   which borrowed from powerpc/kernel/pci-common.c
> + *   which borrowed from arch/alpha/kernel/pci.c
> + *
> + * Extruded from code written by
> + *      Dave Rusling (david.rusling@reo.mts.dec.com)
> + *      David Mosberger (davidm@cs.arizona.edu)
> + * Copyright (C) 1999 Andrea Arcangeli <andrea@suse.de>
> + * Copyright (C) 2000 Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> + * Copyright (C) 2003 Anton Blanchard <anton@au.ibm.com>, IBM
> + * Copyright (C) 2014 ARM Ltd.
> + * Copyright (C) 2017 SiFive
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + */
> +
> +/* This file contains weakly bound functions that implement pcibios functions
> + * that some architectures have copied verbatim.
> + */
> +
> +#include <linux/pci.h>
> +
> +/*
> + * Called after each bus is probed, but before its children are examined
> + */
> +__attribute__ ((weak))
> +void pcibios_fixup_bus(struct pci_bus *bus)
> +{
> +       /* nothing to do, expected to be removed in the future */
> +}
> +/*
> + * We don't have to worry about legacy ISA devices, so nothing to do here
> + */
> +__attribute__ ((weak))
> +resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> +                                      resource_size_t size, resource_size_t align)
> +{
> +       return res->start;
> +}
> --
> 2.13.0

[toc] | [prev] | [next] | [standalone]

#1659502 — Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Wed, Jun 7, 2017 at 9:19 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> CC pci folks
>
> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> While upstreaming the RISC-V port, it was pointed out that multiple
>> architectures (arc, arm64, cris, microblaze, sh, tile) have copied the
>> mostly empty versions of at least one of these functions.  This defines
>> weakly bound versions of the common functions so other architetures can
>> use them.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>

Thanks a lot for taking care of this!

>> diff --git a/drivers/pci/bios.c b/drivers/pci/bios.c
>> new file mode 100644
>> index 000000000000..ffe34c024aa8
>> --- /dev/null
>> +++ b/drivers/pci/bios.c
>> @@ -0,0 +1,42 @@
>> +
>> +/* This file contains weakly bound functions that implement pcibios functions
>> + * that some architectures have copied verbatim.
>> + */

Instead of adding a new file, I would suggest adding the two functions next
to their callers, in probe.c and setup-res.c, respectively.

        Arnd

[toc] | [prev] | [next] | [standalone]

#1660912 — Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote:
> CC pci folks

Ok, replying with pci folks in Cc then :)

Weak symbols have (rightly) gotten a bad reputation, so maybe
we should approach this without them.

It seems we have a large number of emptry pcibios_fixup_bus calls
alreayd, so I think we should simply have the architectures
that do define it define a Kconfig or header symbol and not call
it at all otherwise.

For the ones that exist as lot just seem to call pci_read_bridge_bases
and/or pcibios_fixup_device_resources in one form or another,
and I wonder why we even need the arch indirection for that.

Similarly for pcibios_align_resource: a lot of architetures seem
to have a noop, and the once that don't mostly seem copy and
paste code, so we should again have a symbol for architectures
to opt into it, and we probably should have a generic helper
for the VGA window mirroring code instead of duplicating it multiple
times.

[toc] | [prev] | [next] | [standalone]

#1660938 — Re: [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource}

On Thu, Jun 8, 2017 at 10:12 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jun 07, 2017 at 09:19:49AM +0200, Geert Uytterhoeven wrote:
>> CC pci folks
>
> Ok, replying with pci folks in Cc then :)
>
> Weak symbols have (rightly) gotten a bad reputation, so maybe
> we should approach this without them.

Agreed, I would almost never recommend using a __weak symbol,
but they are already widely used in the PCI subsystem, so I suggested
using them here for consistency.

We have a struct pci_host_bridge now, and we should eventually
move most of the 38 pci specific weak  per-architecture symbols
into per-host driver callbacks, but that I think that would be too much
to ask for when adding an architecture port.

> It seems we have a large number of emptry pcibios_fixup_bus calls
> alreayd, so I think we should simply have the architectures
> that do define it define a Kconfig or header symbol and not call
> it at all otherwise.

I would argue that most of them should not be per-architecture
in the first place, the current state is mostly an artifact of the
times when each architecture had just one PCI implementation.

The ones that have multiple implementations (arm, powerpc, ...)
tend to actually override the weak functions with their own
per-host multiplexers again.

> For the ones that exist as lot just seem to call pci_read_bridge_bases
> and/or pcibios_fixup_device_resources in one form or another,
> and I wonder why we even need the arch indirection for that.
>
> Similarly for pcibios_align_resource: a lot of architetures seem
> to have a noop, and the once that don't mostly seem copy and
> paste code, so we should again have a symbol for architectures
> to opt into it, and we probably should have a generic helper
> for the VGA window mirroring code instead of duplicating it multiple
> times.

I now remember that we already have a host_bridge->align_resource
callback pointer, so the generic function should definitely try
to use that.

We could just use the version from arch/mips/pci/pci-generic.c
and remove that in the process. I'm not sure about why mips calls
pci_read_bridge_bases() in pcibios_fixup_bus() though, or whether
this make sense to put in the generic version.

       Arnd

[toc] | [prev] | [next] | [standalone]

#1659282 — [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

From: "Wesley W. Terpstra" <wesley@sifive.com>

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
---
 .../interrupt-controller/riscv,cpu-intc.txt        | 46 ++++++++++++++++++++++
 .../bindings/interrupt-controller/riscv,plic0.txt  | 44 +++++++++++++++++++++
 2 files changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
new file mode 100644
index 000000000000..62f02e834ff9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
@@ -0,0 +1,46 @@
+RISC-V Hart-Level Interrupt Controller (HLIC)
+---------------------------------------------
+
+RISC-V cores include Control Status Registers (CSRs) which are local to each
+hart and can be read or written by software. Some of these CSRs are used to
+control local interrupts connected to the core.
+
+Typical examples of local interrupts on a RISC-V core include: software IPI
+interrupts, timer interrupts, and a link to the PLIC interrupt controller.
+
+Required properties:
+- compatible : "riscv,cpu-intc"
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Furthermore, this interrupt-controller MUST be embedded inside the cpu
+definition of the hart whose CSRs control these local interrupts.
+
+Example:
+
+	cpu1: cpu@1 {
+		clock-frequency = <1600000000>;
+		compatible = "riscv";
+		d-cache-block-size = <64>;
+		d-cache-sets = <64>;
+		d-cache-size = <16384>;
+		d-tlb-sets = <1>;
+		d-tlb-size = <32>;
+		device_type = "cpu";
+		i-cache-block-size = <64>;
+		i-cache-sets = <64>;
+		i-cache-size = <16384>;
+		i-tlb-sets = <1>;
+		i-tlb-size = <32>;
+		mmu-type = "riscv,sv39";
+		next-level-cache = <&L2>;
+		reg = <1>;
+		riscv,isa = "rv64imac";
+		status = "okay";
+		tlb-split;
+		cpu1-intc: interrupt-controller {
+			#interrupt-cells = <1>;
+			compatible = "riscv,cpu-intc";
+			interrupt-controller;
+		};
+	};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
new file mode 100644
index 000000000000..c05b5806f7d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
@@ -0,0 +1,44 @@
+RISC-V Platform-Level Interrupt Controller (PLIC)
+-------------------------------------------------
+
+RISC-V cores typically include a PLIC, which route interrupts from multiple
+devices to multiple hart contexts.  The PLIC is connected to the interrupt
+controller embedded in a RISC-V core via the interrupt-related CSRs.
+
+A hart context is a priviledge mode in a hardware execution thread.  For
+example, in an 4 core system with 2-way SMT, you have 8 harts and probably
+at least two priviledge modes per hart; machine mode and supervisor mode.
+
+Each interrupt can be enabled on per-context basis. Any context can claim
+a pending enabled interrupt and then release it once it has been handled.
+
+Each interrupt has a configurable priority. Higher priority interrupts are
+serviced firs. Each context can specify a priority threshold. Interrupts
+with priority below this threshold will not cause the PLIC to raise its
+interrupt line leading to the context.
+
+Required properties:
+- compatible : "riscv,plic0"
+- #address-cells : should be <0>
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+- reg : Should contain 1 register range (address and length)
+- riscv,ndev : Specifies the number of interrupts attached to the PLIC
+- interrupts-extended : Specifies which contexts are connected to the PLIC
+
+Example:
+
+	plic: interrupt-controller@c000000 {
+		#address-cells = <0>;
+		#interrupt-cells = <1>;
+		compatible = "riscv,plic0";
+		interrupt-controller;
+		interrupts-extended = <
+			&cpu0-intc 11
+			&cpu1-intc 11 &cpu1-intc 9
+			&cpu2-intc 11 &cpu2-intc 9
+			&cpu3-intc 11 &cpu3-intc 9
+			&cpu4-intc 11 &cpu4-intc 9>;
+		reg = <0xc000000 0x4000000>;
+		riscv,ndev = <10>;
+	};
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]

#1659454 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

CC irqchip and devicetree folks

On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> From: "Wesley W. Terpstra" <wesley@sifive.com>
>
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> ---
>  .../interrupt-controller/riscv,cpu-intc.txt        | 46 ++++++++++++++++++++++
>  .../bindings/interrupt-controller/riscv,plic0.txt  | 44 +++++++++++++++++++++
>  2 files changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> new file mode 100644
> index 000000000000..62f02e834ff9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> @@ -0,0 +1,46 @@
> +RISC-V Hart-Level Interrupt Controller (HLIC)
> +---------------------------------------------
> +
> +RISC-V cores include Control Status Registers (CSRs) which are local to each
> +hart and can be read or written by software. Some of these CSRs are used to
> +control local interrupts connected to the core.
> +
> +Typical examples of local interrupts on a RISC-V core include: software IPI
> +interrupts, timer interrupts, and a link to the PLIC interrupt controller.
> +
> +Required properties:
> +- compatible : "riscv,cpu-intc"
> +- #interrupt-cells : should be <1>
> +- interrupt-controller : Identifies the node as an interrupt controller
> +
> +Furthermore, this interrupt-controller MUST be embedded inside the cpu
> +definition of the hart whose CSRs control these local interrupts.
> +
> +Example:
> +
> +       cpu1: cpu@1 {
> +               clock-frequency = <1600000000>;
> +               compatible = "riscv";
> +               d-cache-block-size = <64>;
> +               d-cache-sets = <64>;
> +               d-cache-size = <16384>;
> +               d-tlb-sets = <1>;
> +               d-tlb-size = <32>;
> +               device_type = "cpu";
> +               i-cache-block-size = <64>;
> +               i-cache-sets = <64>;
> +               i-cache-size = <16384>;
> +               i-tlb-sets = <1>;
> +               i-tlb-size = <32>;
> +               mmu-type = "riscv,sv39";
> +               next-level-cache = <&L2>;
> +               reg = <1>;
> +               riscv,isa = "rv64imac";
> +               status = "okay";
> +               tlb-split;
> +               cpu1-intc: interrupt-controller {
> +                       #interrupt-cells = <1>;
> +                       compatible = "riscv,cpu-intc";
> +                       interrupt-controller;
> +               };
> +       };
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
> new file mode 100644
> index 000000000000..c05b5806f7d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
> @@ -0,0 +1,44 @@
> +RISC-V Platform-Level Interrupt Controller (PLIC)
> +-------------------------------------------------
> +
> +RISC-V cores typically include a PLIC, which route interrupts from multiple
> +devices to multiple hart contexts.  The PLIC is connected to the interrupt
> +controller embedded in a RISC-V core via the interrupt-related CSRs.
> +
> +A hart context is a priviledge mode in a hardware execution thread.  For
> +example, in an 4 core system with 2-way SMT, you have 8 harts and probably
> +at least two priviledge modes per hart; machine mode and supervisor mode.
> +
> +Each interrupt can be enabled on per-context basis. Any context can claim
> +a pending enabled interrupt and then release it once it has been handled.
> +
> +Each interrupt has a configurable priority. Higher priority interrupts are
> +serviced firs. Each context can specify a priority threshold. Interrupts
> +with priority below this threshold will not cause the PLIC to raise its
> +interrupt line leading to the context.
> +
> +Required properties:
> +- compatible : "riscv,plic0"
> +- #address-cells : should be <0>
> +- #interrupt-cells : should be <1>
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- reg : Should contain 1 register range (address and length)
> +- riscv,ndev : Specifies the number of interrupts attached to the PLIC
> +- interrupts-extended : Specifies which contexts are connected to the PLIC
> +
> +Example:
> +
> +       plic: interrupt-controller@c000000 {
> +               #address-cells = <0>;
> +               #interrupt-cells = <1>;
> +               compatible = "riscv,plic0";
> +               interrupt-controller;
> +               interrupts-extended = <
> +                       &cpu0-intc 11
> +                       &cpu1-intc 11 &cpu1-intc 9
> +                       &cpu2-intc 11 &cpu2-intc 9
> +                       &cpu3-intc 11 &cpu3-intc 9
> +                       &cpu4-intc 11 &cpu4-intc 9>;
> +               reg = <0xc000000 0x4000000>;
> +               riscv,ndev = <10>;
> +       };
> --
> 2.13.0

[toc] | [prev] | [next] | [standalone]

#1659649 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Wed, Jun 07, 2017 at 09:11:31AM +0200, Geert Uytterhoeven wrote:
> CC irqchip and devicetree folks

Thanks Geert.

Palmer, in future, you can ensure (most) relevant parties are Cc'd by
using scripts/get_maintainer.pl to find them, and adding Cc: lines to
the relevant patches.

You can either hand that a patch or a path, e.g.

[mark@leverpostej:~/src/linux]% ./scripts/get_maintainer.pl -f Documentation/devicetree/bindings/interrupt-controller/                  
Thomas Gleixner <tglx@linutronix.de> (maintainer:IRQCHIP DRIVERS)
Jason Cooper <jason@lakedaemon.net> (maintainer:IRQCHIP DRIVERS)
Marc Zyngier <marc.zyngier@arm.com> (maintainer:IRQCHIP DRIVERS)
Rob Herring <robh+dt@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
Mark Rutland <mark.rutland@arm.com> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
linux-kernel@vger.kernel.org (open list:IRQCHIP DRIVERS)
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)

Otherwise, I have a few comments inline below.

> On Wed, Jun 7, 2017 at 12:59 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > From: "Wesley W. Terpstra" <wesley@sifive.com>
> >
> > Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> > ---
> >  .../interrupt-controller/riscv,cpu-intc.txt        | 46 ++++++++++++++++++++++
> >  .../bindings/interrupt-controller/riscv,plic0.txt  | 44 +++++++++++++++++++++
> >  2 files changed, 90 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> > new file mode 100644
> > index 000000000000..62f02e834ff9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> > @@ -0,0 +1,46 @@
> > +RISC-V Hart-Level Interrupt Controller (HLIC)
> > +---------------------------------------------
> > +
> > +RISC-V cores include Control Status Registers (CSRs) which are local to each
> > +hart and can be read or written by software. Some of these CSRs are used to
> > +control local interrupts connected to the core.
> > +
> > +Typical examples of local interrupts on a RISC-V core include: software IPI
> > +interrupts, timer interrupts, and a link to the PLIC interrupt controller.

So IIUC those interrupts are routed directly to the HLIC, and are (only)
controlled thought the HLIC?

Is the HLIC architecturally mandated? i.e. is this guaranteed to be
present on any RISC-V implementation?

Does the presence of the HLIC imply the presence of a PLIC (or
vice/versa)? Typically, the per-cpu and platform-wide parts of the
top-level interrupt controller are fairly intimately coupled.

> > +
> > +Required properties:
> > +- compatible : "riscv,cpu-intc"

You'll need to allocate the "riscv" vendor prefix in 
Documentation/devicetree/bindings/vendor-prefixes.txt

... if that was done in some other patch, I didn't receive it.

> > +- #interrupt-cells : should be <1>

What about the flags?

Are all HLIC interrupts edge triggered (or level triggered)?

> > +- interrupt-controller : Identifies the node as an interrupt controller
> > +
> > +Furthermore, this interrupt-controller MUST be embedded inside the cpu
> > +definition of the hart whose CSRs control these local interrupts.
> > +
> > +Example:
> > +
> > +       cpu1: cpu@1 {
> > +               clock-frequency = <1600000000>;
> > +               compatible = "riscv";
> > +               d-cache-block-size = <64>;
> > +               d-cache-sets = <64>;
> > +               d-cache-size = <16384>;
> > +               d-tlb-sets = <1>;
> > +               d-tlb-size = <32>;
> > +               device_type = "cpu";
> > +               i-cache-block-size = <64>;
> > +               i-cache-sets = <64>;
> > +               i-cache-size = <16384>;
> > +               i-tlb-sets = <1>;
> > +               i-tlb-size = <32>;
> > +               mmu-type = "riscv,sv39";
> > +               next-level-cache = <&L2>;
> > +               reg = <1>;
> > +               riscv,isa = "rv64imac";
> > +               status = "okay";
> > +               tlb-split;

We can probably replace most of these with a "...", as they're largely
irrelevany to this binding.

> > +               cpu1-intc: interrupt-controller {
> > +                       #interrupt-cells = <1>;
> > +                       compatible = "riscv,cpu-intc";
> > +                       interrupt-controller;
> > +               };
> > +       };
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
> > new file mode 100644
> > index 000000000000..c05b5806f7d2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,plic0.txt
> > @@ -0,0 +1,44 @@
> > +RISC-V Platform-Level Interrupt Controller (PLIC)
> > +-------------------------------------------------
> > +
> > +RISC-V cores typically include a PLIC, which route interrupts from multiple
> > +devices to multiple hart contexts.  The PLIC is connected to the interrupt
> > +controller embedded in a RISC-V core via the interrupt-related CSRs.

Do you mean that the PLIC is connected to the HLIC, or that the HLIC is
also managed in part through CSRs?

> > +
> > +A hart context is a priviledge mode in a hardware execution thread.  For
> > +example, in an 4 core system with 2-way SMT, you have 8 harts and probably
> > +at least two priviledge modes per hart; machine mode and supervisor mode.
> > +
> > +Each interrupt can be enabled on per-context basis. Any context can claim
> > +a pending enabled interrupt and then release it once it has been handled.
> > +
> > +Each interrupt has a configurable priority. Higher priority interrupts are
> > +serviced firs. Each context can specify a priority threshold. Interrupts
> > +with priority below this threshold will not cause the PLIC to raise its
> > +interrupt line leading to the context.
> > +
> > +Required properties:
> > +- compatible : "riscv,plic0"
> > +- #address-cells : should be <0>
> > +- #interrupt-cells : should be <1>

As with the HLIC, what about the flags?

> > +- interrupt-controller : Identifies the node as an interrupt controller
> > +- reg : Should contain 1 register range (address and length)
> > +- riscv,ndev : Specifies the number of interrupts attached to the PLIC

Why do we need to know this?

I suspect this ia actually the number of interrupts implemented in the
PLIC, rather than the number of interrupts attached. i.e. the PLIC can
be implemented with a subset of the potential registers/bits. Is that
correct?

If so, something like "riscv,num-interrupts" would be better, along with
a clearer description.

> > +- interrupts-extended : Specifies which contexts are connected to the PLIC

That description doesn't sound right.

I take it that these are the HLIC interrupts that the PLIC can raise?

You will need to be explicit about the order of interrupts in this
property. i.e. which interrupt is routed to which context?

Is the interrupt at the HLIC well known? From the example I see that
here local interrupts 11 adn 9 are used. Is that mandated, or just the
case for this particular implementation?

Also, please consider how you will handle the case when the Linux
logical CPU ID is not the same as the physical ID, and how you will
handle physical IDs being sparse.

We went though a lot of pain trying to do something similar for the ARM
PMU interrupts (see the interrupt-affinity property in
Documentation/devicetree/bindings/arm/pmu.txt), and it's still painful
to deal with.

> > +
> > +Example:
> > +
> > +       plic: interrupt-controller@c000000 {
> > +               #address-cells = <0>;

This can go, given you don't have sub-nodes, nor a #size-cells property.

Thanks,
Mark.

> > +               #interrupt-cells = <1>;
> > +               compatible = "riscv,plic0";
> > +               interrupt-controller;
> > +               interrupts-extended = <
> > +                       &cpu0-intc 11
> > +                       &cpu1-intc 11 &cpu1-intc 9
> > +                       &cpu2-intc 11 &cpu2-intc 9
> > +                       &cpu3-intc 11 &cpu3-intc 9
> > +                       &cpu4-intc 11 &cpu4-intc 9>;
> > +               reg = <0xc000000 0x4000000>;
> > +               riscv,ndev = <10>;
> > +       };
> > --
> > 2.13.0

[toc] | [prev] | [next] | [standalone]

#1660108 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Wed, Jun 7, 2017 at 3:13 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > +RISC-V Hart-Level Interrupt Controller (HLIC)
>> > +---------------------------------------------
>> > +
>> > +RISC-V cores include Control Status Registers (CSRs) which are local to each
>> > +hart and can be read or written by software. Some of these CSRs are used to
>> > +control local interrupts connected to the core.
>> > +
>> > +Typical examples of local interrupts on a RISC-V core include: software IPI
>> > +interrupts, timer interrupts, and a link to the PLIC interrupt controller.
>
> So IIUC those interrupts are routed directly to the HLIC, and are (only)
> controlled thought the HLIC?

Yes. You can have a local interrupt that goes directly to a specific
core, not via the PLIC.

> Is the HLIC architecturally mandated? i.e. is this guaranteed to be
> present on any RISC-V implementation?

It's in the RISC-V privileged specification. Therefore, if a riscv
core can run linux it will have these CSRs.

> Does the presence of the HLIC imply the presence of a PLIC (or
> vice/versa)?

No. SiFive implementations always have a PLIC, though.

> Typically, the per-cpu and platform-wide parts of the
> top-level interrupt controller are fairly intimately coupled.

They are coupled if they both exist. The privileged specification does
explicitly call out interrupts 9 and 11 in the HLIC for attaching the
PLIC.

> You'll need to allocate the "riscv" vendor prefix in
> Documentation/devicetree/bindings/vendor-prefixes.txt

@palmer: Can you add this?

> What about the flags?

What flags?

> Are all HLIC interrupts edge triggered (or level triggered)?

HLIC = level. PLIC = both.

> We can probably replace most of these with a "...", as they're largely
> irrelevany to this binding.

Sure. I thought it would be nice to include a complete cpu example
somewhere, though.

>> > +RISC-V cores typically include a PLIC, which route interrupts from multiple
>> > +devices to multiple hart contexts.  The PLIC is connected to the interrupt
>> > +controller embedded in a RISC-V core via the interrupt-related CSRs.
>
> Do you mean that the PLIC is connected to the HLIC, or that the HLIC is
> also managed in part through CSRs?

Both. The HLIC is entirely manager through CSRs. The PLIC is managed
through a memory mapped interface. The PLIC is attached to the HLIC.

>> > +Required properties:
>> > +- compatible : "riscv,plic0"
>> > +- #address-cells : should be <0>
>> > +- #interrupt-cells : should be <1>
>
> As with the HLIC, what about the flags?

Still unsure what flags we're talking about.

>> > +- riscv,ndev : Specifies the number of interrupts attached to the PLIC
>
> Why do we need to know this?
>
> I suspect this ia actually the number of interrupts implemented in the
> PLIC, rather than the number of interrupts attached. i.e. the PLIC can
> be implemented with a subset of the potential registers/bits. Is that
> correct?

You're in principle correct, although these are probably always the same.

> If so, something like "riscv,num-interrupts" would be better, along with
> a clearer description.

Uhm. I suppose we can change this. However, it would requires changes
to quite a number of riscv repositories. I believe this is also
included in the riscv platform specification. A better description is
easy, do we really need to change the key?


>> > +- interrupts-extended : Specifies which contexts are connected to the PLIC
>
> That description doesn't sound right.
>
> I take it that these are the HLIC interrupts that the PLIC can raise?

Yes.

> You will need to be explicit about the order of interrupts in this
> property. i.e. which interrupt is routed to which context?

Yes. Order and position matter.

> Is the interrupt at the HLIC well known? From the example I see that
> here local interrupts 11 adn 9 are used. Is that mandated, or just the
> case for this particular implementation?

9 and 11 are in the privileged specification.

> Also, please consider how you will handle the case when the Linux
> logical CPU ID is not the same as the physical ID, and how you will
> handle physical IDs being sparse.

We already deal with this. If the interrupt is '-1', we skip it.
That's done in plic.c:
                if (parent.args[0] == -1) continue; // skip context holes

>> > +       plic: interrupt-controller@c000000 {
>> > +               #address-cells = <0>;
>
> This can go, given you don't have sub-nodes, nor a #size-cells property.

The device-tree-specification seems to indicate that this is mandatory
for an interrupt-controller. Or have I understood this wrongly? When
you use interrupts-extended, doesn't it use the address-cells of the
interrupt controller? We should add that size-cells = 0, though.

[toc] | [prev] | [next] | [standalone]

#1660152 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Wed, Jun 7, 2017 at 1:57 PM, Wesley Terpstra <wesley@sifive.com> wrote:
> On Wed, Jun 7, 2017 at 3:13 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> > +RISC-V Hart-Level Interrupt Controller (HLIC)
>>> > +---------------------------------------------

[...]

>>> > +       plic: interrupt-controller@c000000 {
>>> > +               #address-cells = <0>;
>>
>> This can go, given you don't have sub-nodes, nor a #size-cells property.
>
> The device-tree-specification seems to indicate that this is mandatory
> for an interrupt-controller. Or have I understood this wrongly? When
> you use interrupts-extended, doesn't it use the address-cells of the
> interrupt controller? We should add that size-cells = 0, though.

It's only needed if you have an interrupt-map property AIUI.
#size-cells should never be needed (unless you have child nodes of
this one).

Rob

[toc] | [prev] | [next] | [standalone]

#1660194 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

I've reread the relevant sections now, and you are correct. We should
remove the address-cells from the PLIC's dts.

On Wed, Jun 7, 2017 at 12:57 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jun 7, 2017 at 1:57 PM, Wesley Terpstra <wesley@sifive.com> wrote:
>> On Wed, Jun 7, 2017 at 3:13 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> > +RISC-V Hart-Level Interrupt Controller (HLIC)
>>>> > +---------------------------------------------
>
> [...]
>
>>>> > +       plic: interrupt-controller@c000000 {
>>>> > +               #address-cells = <0>;
>>>
>>> This can go, given you don't have sub-nodes, nor a #size-cells property.
>>
>> The device-tree-specification seems to indicate that this is mandatory
>> for an interrupt-controller. Or have I understood this wrongly? When
>> you use interrupts-extended, doesn't it use the address-cells of the
>> interrupt controller? We should add that size-cells = 0, though.
>
> It's only needed if you have an interrupt-map property AIUI.
> #size-cells should never be needed (unless you have child nodes of
> this one).
>
> Rob

[toc] | [prev] | [next] | [standalone]

#1661054 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Wed, Jun 07, 2017 at 11:57:17AM -0700, Wesley Terpstra wrote:
> On Wed, Jun 7, 2017 at 3:13 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > +RISC-V Hart-Level Interrupt Controller (HLIC)
> >> > +---------------------------------------------
> >> > +
> >> > +RISC-V cores include Control Status Registers (CSRs) which are local to each
> >> > +hart and can be read or written by software. Some of these CSRs are used to
> >> > +control local interrupts connected to the core.
> >> > +
> >> > +Typical examples of local interrupts on a RISC-V core include: software IPI
> >> > +interrupts, timer interrupts, and a link to the PLIC interrupt controller.
> >
> > So IIUC those interrupts are routed directly to the HLIC, and are (only)
> > controlled thought the HLIC?
> 
> Yes. You can have a local interrupt that goes directly to a specific
> core, not via the PLIC.
> 
> > Is the HLIC architecturally mandated? i.e. is this guaranteed to be
> > present on any RISC-V implementation?
> 
> It's in the RISC-V privileged specification. Therefore, if a riscv
> core can run linux it will have these CSRs.
> 
> > Does the presence of the HLIC imply the presence of a PLIC (or
> > vice/versa)?
> 
> No. SiFive implementations always have a PLIC, though.
> 
> > Typically, the per-cpu and platform-wide parts of the
> > top-level interrupt controller are fairly intimately coupled.
> 
> They are coupled if they both exist. The privileged specification does
> explicitly call out interrupts 9 and 11 in the HLIC for attaching the
> PLIC.
> 
> > You'll need to allocate the "riscv" vendor prefix in
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> @palmer: Can you add this?
> 
> > What about the flags?
> 
> What flags?

Edge vs level, active high vs active low. Typically some of these are
programmable, and are described as flags in the interrupt-specifier.

See the examples in:

Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

> > Are all HLIC interrupts edge triggered (or level triggered)?
> 
> HLIC = level. PLIC = both.

Ok. Given that, flags aren't necessary for the HLIC, and the
interrupt-specifier is fine as-is.

> >> > +RISC-V cores typically include a PLIC, which route interrupts from multiple
> >> > +devices to multiple hart contexts.  The PLIC is connected to the interrupt
> >> > +controller embedded in a RISC-V core via the interrupt-related CSRs.
> >
> > Do you mean that the PLIC is connected to the HLIC, or that the HLIC is
> > also managed in part through CSRs?
> 
> Both. The HLIC is entirely manager through CSRs. The PLIC is managed
> through a memory mapped interface. The PLIC is attached to the HLIC.

So do any CSRs affect the state of the PLIC? If it's just MMIO, the
mention of CSRs above is just a little confusing.

It might be best to just say "The PLIC is connect to the HLIC embedded
in each RISC-V core".

> >> > +Required properties:
> >> > +- compatible : "riscv,plic0"
> >> > +- #address-cells : should be <0>
> >> > +- #interrupt-cells : should be <1>
> >
> > As with the HLIC, what about the flags?
> 
> Still unsure what flags we're talking about.

As covered above for the HLIC.

It sounds like we'd need these to distinguish edge/level interrupts,
unless that's fixed at integration time and you can determine it from
the PLIC itself?

> >> > +- riscv,ndev : Specifies the number of interrupts attached to the PLIC
> >
> > Why do we need to know this?
> >
> > I suspect this ia actually the number of interrupts implemented in the
> > PLIC, rather than the number of interrupts attached. i.e. the PLIC can
> > be implemented with a subset of the potential registers/bits. Is that
> > correct?
> 
> You're in principle correct, although these are probably always the same.

For now, perhaps. Let's not embed an assumption we cannot guarantee.

> > If so, something like "riscv,num-interrupts" would be better, along with
> > a clearer description.
> 
> Uhm. I suppose we can change this. However, it would requires changes
> to quite a number of riscv repositories. I believe this is also
> included in the riscv platform specification. A better description is
> easy, do we really need to change the key?

It's not too much of a problem, but if we end up having to change
anything else from the proposed bindings, those trees are going to
require updates anyway.

If we can, I would like to change this to keep things as clear as
possible from the outset.

[...]

> > You will need to be explicit about the order of interrupts in this
> > property. i.e. which interrupt is routed to which context?
> 
> Yes. Order and position matter.

Ok.

Please update the binding to explicitly define the ordering requirement.

[...]

> > Also, please consider how you will handle the case when the Linux
> > logical CPU ID is not the same as the physical ID, and how you will
> > handle physical IDs being sparse.
> 
> We already deal with this. If the interrupt is '-1', we skip it.
> That's done in plic.c:
>                 if (parent.args[0] == -1) continue; // skip context holes

If this is what we expect people to do, it needs to be documented in the
binding.

Does this mean that you expect Linux logical CPU IDs to be equal to
physical CPU IDs in all cases?

That's going to be painful for very sparse ID ranges, and won't work for
cases like kexec/kdump where you cannot guarantee which physical CPU
will end up being CPU0 in the new kernel.

I would strongly advise that you explicitly describe the relationship
using phandles to CPU nodes.

I would also advise that you try to decouple the physical CPU IDs and
Linux logical IDs. While assuming they're the same might simplify things
today, it will create longer term maintenance problems and get in the
way of a number of features.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1662765 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Thu, Jun 8, 2017 at 3:52 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> What flags?
>
> Edge vs level, active high vs active low. Typically some of these are
> programmable, and are described as flags in the interrupt-specifier.
>
> See the examples in:
>
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

Ok. Those are not applicable to the PLIC.

>
>> > Are all HLIC interrupts edge triggered (or level triggered)?
>>
>> HLIC = level. PLIC = both.
>
> Ok. Given that, flags aren't necessary for the HLIC, and the
> interrupt-specifier is fine as-is.
>
>> >> > +RISC-V cores typically include a PLIC, which route interrupts from multiple
>> >> > +devices to multiple hart contexts.  The PLIC is connected to the interrupt
>> >> > +controller embedded in a RISC-V core via the interrupt-related CSRs.
>> >
>> > Do you mean that the PLIC is connected to the HLIC, or that the HLIC is
>> > also managed in part through CSRs?
>>
>> Both. The HLIC is entirely manager through CSRs. The PLIC is managed
>> through a memory mapped interface. The PLIC is attached to the HLIC.
>
> So do any CSRs affect the state of the PLIC? If it's just MMIO, the
> mention of CSRs above is just a little confusing.
>
> It might be best to just say "The PLIC is connect to the HLIC embedded
> in each RISC-V core".
>
>> >> > +Required properties:
>> >> > +- compatible : "riscv,plic0"
>> >> > +- #address-cells : should be <0>
>> >> > +- #interrupt-cells : should be <1>
>> >
>> > As with the HLIC, what about the flags?
>>
>> Still unsure what flags we're talking about.
>
> As covered above for the HLIC.
>
> It sounds like we'd need these to distinguish edge/level interrupts,
> unless that's fixed at integration time and you can determine it from
> the PLIC itself?
>
>> >> > +- riscv,ndev : Specifies the number of interrupts attached to the PLIC
>> >
>> > Why do we need to know this?
>> >
>> > I suspect this ia actually the number of interrupts implemented in the
>> > PLIC, rather than the number of interrupts attached. i.e. the PLIC can
>> > be implemented with a subset of the potential registers/bits. Is that
>> > correct?
>>
>> You're in principle correct, although these are probably always the same.
>
> For now, perhaps. Let's not embed an assumption we cannot guarantee.
>
>> > If so, something like "riscv,num-interrupts" would be better, along with
>> > a clearer description.
>>
>> Uhm. I suppose we can change this. However, it would requires changes
>> to quite a number of riscv repositories. I believe this is also
>> included in the riscv platform specification. A better description is
>> easy, do we really need to change the key?
>
> It's not too much of a problem, but if we end up having to change
> anything else from the proposed bindings, those trees are going to
> require updates anyway.
>
> If we can, I would like to change this to keep things as clear as
> possible from the outset.
>
> [...]
>
>> > You will need to be explicit about the order of interrupts in this
>> > property. i.e. which interrupt is routed to which context?
>>
>> Yes. Order and position matter.
>
> Ok.
>
> Please update the binding to explicitly define the ordering requirement.
>
> [...]
>
>> > Also, please consider how you will handle the case when the Linux
>> > logical CPU ID is not the same as the physical ID, and how you will
>> > handle physical IDs being sparse.
>>
>> We already deal with this. If the interrupt is '-1', we skip it.
>> That's done in plic.c:
>>                 if (parent.args[0] == -1) continue; // skip context holes
>
> If this is what we expect people to do, it needs to be documented in the
> binding.
>
> Does this mean that you expect Linux logical CPU IDs to be equal to
> physical CPU IDs in all cases?
>
> That's going to be painful for very sparse ID ranges, and won't work for
> cases like kexec/kdump where you cannot guarantee which physical CPU
> will end up being CPU0 in the new kernel.
>
> I would strongly advise that you explicitly describe the relationship
> using phandles to CPU nodes.
>
> I would also advise that you try to decouple the physical CPU IDs and
> Linux logical IDs. While assuming they're the same might simplify things
> today, it will create longer term maintenance problems and get in the
> way of a number of features.
>
> Thanks,
> Mark.

[toc] | [prev] | [next] | [standalone]

#1662767 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

Ugh. Clicked reply without being done writing the reply!

On Thu, Jun 8, 2017 at 3:52 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Edge vs level, active high vs active low. Typically some of these are
> programmable, and are described as flags in the interrupt-specifier.
>
> See the examples in:
>
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

Ok. Those are not really relevant to the PLIC. It has a flat interrupt
namespace and the way you handle all four kinds of interrupts in the
driver is uniform. I don't think we want to architecturally expose
this to the operating system.

> So do any CSRs affect the state of the PLIC? If it's just MMIO, the
> mention of CSRs above is just a little confusing.

HLIC = CSR only. PLIC = MMIO only.

> It might be best to just say "The PLIC is connect to the HLIC embedded
> in each RISC-V core".

Fair enough.

> It sounds like we'd need these to distinguish edge/level interrupts,
> unless that's fixed at integration time and you can determine it from
> the PLIC itself?

They are fixed at integration time and the PLIC driver does not need to care.

> It's not too much of a problem, but if we end up having to change
> anything else from the proposed bindings, those trees are going to
> require updates anyway.

I'll talk to the other stakeholders.

> Please update the binding to explicitly define the ordering requirement.

The ordering requirement is that the first interrupts-extended entry
corresponds to the first context, second to second, etc. If a context
is unused for some reason, that's when you need a -1. The contexts are
linear and contiguous in the MMIO address map.

> Does this mean that you expect Linux logical CPU IDs to be equal to
> physical CPU IDs in all cases?

No. There is no 'physical CPU ID' anyway, except the mhartid CSR which
is unavailable to linux. The SBI conveys your CPU ID by passing it as
the first argument to the linux kernel.

The interrupts-extended in the PLIC uses a phandle to reference the
matching CPU in DTS. The num in cpu@<num> only need correspond to the
first register argument to the kernel.

If for some reason there end up too many -1 holes in the PLIC (b/c you
virtualized a 128-core machine down to say 2), you can always
virtualize the PLIC device and provide a matching simplified DTB.

[toc] | [prev] | [next] | [standalone]

#1669121 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Fri, Jun 09, 2017 at 02:58:14PM -0700, Wesley Terpstra wrote:
> Ugh. Clicked reply without being done writing the reply!
> 
> On Thu, Jun 8, 2017 at 3:52 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Edge vs level, active high vs active low. Typically some of these are
> > programmable, and are described as flags in the interrupt-specifier.
> >
> > See the examples in:
> >
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> 
> Ok. Those are not really relevant to the PLIC. It has a flat interrupt
> namespace and the way you handle all four kinds of interrupts in the
> driver is uniform. I don't think we want to architecturally expose
> this to the operating system.

Sure thing. I was just making sure I clarified my initial statement.

> > So do any CSRs affect the state of the PLIC? If it's just MMIO, the
> > mention of CSRs above is just a little confusing.
> 
> HLIC = CSR only. PLIC = MMIO only.
> 
> > It might be best to just say "The PLIC is connect to the HLIC embedded
> > in each RISC-V core".
> 
> Fair enough.
> 
> > It sounds like we'd need these to distinguish edge/level interrupts,
> > unless that's fixed at integration time and you can determine it from
> > the PLIC itself?
> 
> They are fixed at integration time and the PLIC driver does not need to care.

Ok.

> > Please update the binding to explicitly define the ordering requirement.
> 
> The ordering requirement is that the first interrupts-extended entry
> corresponds to the first context, second to second, etc. If a context
> is unused for some reason, that's when you need a -1. The contexts are
> linear and contiguous in the MMIO address map.

Ah. It wasn't at all clear to me that the order was in relation to the
MMIO space.

How is it possible to tell if an context is unused?

Are those mandated to be linear and contiguous in the address space?

How is the relationship between an MMIO context and hart determined?

I'm not sure that it makes sense to use -1 in this manner, since the
first cell of each interrupts-extended tuple entry is a phandle. IIRC
zero is currently de-facto invalid, and if we really need a NULL
phandle, we should get that clarified in the DT spec.

It might be better to describe each MMIO context separately, and then
associate IRQs with those in-order.

> 
> > Does this mean that you expect Linux logical CPU IDs to be equal to
> > physical CPU IDs in all cases?
> 
> No. There is no 'physical CPU ID' anyway, except the mhartid CSR which
> is unavailable to linux. The SBI conveys your CPU ID by passing it as
> the first argument to the linux kernel.
> 
> The interrupts-extended in the PLIC uses a phandle to reference the
> matching CPU in DTS. The num in cpu@<num> only need correspond to the
> first register argument to the kernel.

So you use the reference to the HLIC to implictly provide the CPU
affinity? Or do you assume that these align with the SBI-provided CPU
IDs?

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1660292 — Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers

On Tue, Jun 6, 2017 at 3:59 PM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> From: "Wesley W. Terpstra" <wesley@sifive.com>
>
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>

Small nitpick: its rather odd you send patches From one address but
not provide the SOB tag for them as well, best if you can include the
SOB tag of both. This applies to other patches as well.

 Luis

[toc] | [prev] | [next] | [standalone]

#1659283 — [PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver

This patch adds a driver that manages the local interrupts on each
RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual.
The local interrupt controller manages software interrupts, timer
interrupts, and hardware interrupts (which are routed via the
platform level interrupt controller).  Per-hart local interrupt
controllers are found on all RISC-V systems.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
---
 drivers/irqchip/Kconfig          |  14 +++
 drivers/irqchip/Makefile         |   1 +
 drivers/irqchip/irq-riscv-intc.c | 239 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 254 insertions(+)
 create mode 100644 drivers/irqchip/irq-riscv-intc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 2906d63934ef..dfde170e5886 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -313,3 +313,17 @@ config RISCV_PLIC
 	   interrupt sources (MSI, GPIO, etc) are subordinate to the PLIC.
 
 	   If you don't know what to do here, say Y.
+
+config RISCV_INTC
+	def_bool y if RISCV
+	#bool "RISC-V Interrupt Controller"
+	depends on RISCV
+	default y
+	help
+	   This enables support for the local interrupt controller found in
+	   standard RISC-V systems.  The local interrupt controller handles
+	   timer interrupts, software interrupts, and hardware interrupts.
+	   Without a local interrupt controller the system will be unable to
+	   handle any interrupts, including those passed via the PLIC.
+
+	   If you don't know what to do here, say Y.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index bed94cc89146..bc9a6b45903b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_ARCH_ASPEED)		+= irq-aspeed-vic.o
 obj-$(CONFIG_STM32_EXTI) 		+= irq-stm32-exti.o
 obj-$(CONFIG_QCOM_IRQ_COMBINER)		+= qcom-irq-combiner.o
 obj-$(CONFIG_RISCV_PLIC)		+= irq-riscv-plic.o
+obj-$(CONFIG_RISCV_INTC)		+= irq-riscv-intc.o
diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
new file mode 100644
index 000000000000..8150a035aada
--- /dev/null
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017 SiFive
+ *
+ *   This program is free software; you can redistribute it and/or
+ *   modify it under the terms of the GNU General Public License
+ *   as published by the Free Software Foundation, version 2.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ */
+
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/interrupt.h>
+#include <linux/ftrace.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+
+#include <asm/ptrace.h>
+#include <asm/sbi.h>
+#include <asm/smp.h>
+
+struct riscv_irq_data {
+	struct irq_chip		chip;
+	struct irq_domain	*domain;
+	int			hart;
+	char			name[20];
+};
+DEFINE_PER_CPU(struct riscv_irq_data, riscv_irq_data);
+DEFINE_PER_CPU(atomic_long_t, riscv_early_sie);
+
+static void riscv_software_interrupt(void)
+{
+#ifdef CONFIG_SMP
+	irqreturn_t ret;
+
+	ret = handle_ipi();
+	if (ret != IRQ_NONE)
+		return;
+#endif
+
+	BUG();
+}
+
+asmlinkage void __irq_entry do_IRQ(unsigned int cause, struct pt_regs *regs)
+{
+	struct pt_regs *old_regs = set_irq_regs(regs);
+	struct irq_domain *domain;
+
+	irq_enter();
+
+	/* There are three classes of interrupt: timer, software, and
+	 * external devices.  We dispatch between them here.  External
+	 * device interrupts use the generic IRQ mechanisms.
+	 */
+	switch (cause) {
+	case INTERRUPT_CAUSE_TIMER:
+		riscv_timer_interrupt();
+		break;
+	case INTERRUPT_CAUSE_SOFTWARE:
+		riscv_software_interrupt();
+		break;
+	default:
+		domain = per_cpu(riscv_irq_data, smp_processor_id()).domain;
+		generic_handle_irq(irq_find_mapping(domain, cause));
+		break;
+	}
+
+	irq_exit();
+	set_irq_regs(old_regs);
+}
+
+static int riscv_irqdomain_map(struct irq_domain *d, unsigned int irq,
+			       irq_hw_number_t hwirq)
+{
+	struct riscv_irq_data *data = d->host_data;
+
+	irq_set_chip_and_handler(irq, &data->chip, handle_simple_irq);
+	irq_set_chip_data(irq, data);
+	irq_set_noprobe(irq);
+
+	return 0;
+}
+
+static const struct irq_domain_ops riscv_irqdomain_ops = {
+	.map	= riscv_irqdomain_map,
+	.xlate	= irq_domain_xlate_onecell,
+};
+
+static void riscv_irq_mask(struct irq_data *d)
+{
+	struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
+
+	BUG_ON(smp_processor_id() != data->hart);
+	csr_clear(sie, 1 << (long)d->hwirq);
+}
+
+static void riscv_irq_unmask(struct irq_data *d)
+{
+	struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
+
+	BUG_ON(smp_processor_id() != data->hart);
+	csr_set(sie, 1 << (long)d->hwirq);
+}
+
+static void riscv_irq_enable_helper(void *d)
+{
+	riscv_irq_unmask(d);
+}
+
+static void riscv_irq_enable(struct irq_data *d)
+{
+	struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
+
+	/* There are two phases to setting up an interrupt: first we set a bit
+	 * in this bookkeeping structure, which is used by trap_init to
+	 * initialize SIE for each hart as it comes up.
+	 */
+	atomic_long_or((1 << (long)d->hwirq),
+		       &per_cpu(riscv_early_sie, data->hart));
+
+	/* The CPU is usually online, so here we just attempt to enable the
+	 * interrupt by writing SIE directly.  We need to write SIE on the
+	 * correct hart, which might be another hart.
+	 */
+	if (data->hart == smp_processor_id())
+		riscv_irq_unmask(d);
+	else if (cpu_online(data->hart))
+		smp_call_function_single(data->hart,
+					 riscv_irq_enable_helper,
+					 d,
+					 true);
+}
+
+static void riscv_irq_disable_helper(void *d)
+{
+	riscv_irq_mask(d);
+}
+
+static void riscv_irq_disable(struct irq_data *d)
+{
+	struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
+
+	/* This is the mirror of riscv_irq_enable. */
+	atomic_long_and(~(1 << (long)d->hwirq),
+			&per_cpu(riscv_early_sie, data->hart));
+	if (data->hart == smp_processor_id())
+		riscv_irq_mask(d);
+	else if (cpu_online(data->hart))
+		smp_call_function_single(data->hart,
+					 riscv_irq_disable_helper,
+					 d,
+					 true);
+}
+
+static void riscv_irq_mask_noop(struct irq_data *d) { }
+
+static void riscv_irq_unmask_noop(struct irq_data *d) { }
+
+static void riscv_irq_enable_noop(struct irq_data *d)
+{
+	struct device_node *data = irq_data_get_irq_chip_data(d);
+	u32 hart;
+
+	if (!of_property_read_u32(data, "reg", &hart))
+		printk(
+		  KERN_WARNING "enabled interrupt %d for missing hart %d (this interrupt has no handler)\n",
+		  (int)d->hwirq, hart);
+}
+
+static struct irq_chip riscv_noop_chip = {
+	.name = "riscv,cpu-intc,noop",
+	.irq_mask = riscv_irq_mask_noop,
+	.irq_unmask = riscv_irq_unmask_noop,
+	.irq_enable = riscv_irq_enable_noop,
+};
+
+static int riscv_irqdomain_map_noop(struct irq_domain *d, unsigned int irq,
+				    irq_hw_number_t hwirq)
+{
+	struct device_node *data = d->host_data;
+
+	irq_set_chip_and_handler(irq, &riscv_noop_chip, handle_simple_irq);
+	irq_set_chip_data(irq, data);
+	return 0;
+}
+
+static const struct irq_domain_ops riscv_irqdomain_ops_noop = {
+	.map    = riscv_irqdomain_map_noop,
+	.xlate  = irq_domain_xlate_onecell,
+};
+
+static int riscv_intc_init(struct device_node *node, struct device_node *parent)
+{
+	int hart;
+	struct riscv_irq_data *data;
+
+	if (parent)
+		return 0;
+
+	hart = riscv_of_processor_hart(node->parent);
+	if (hart < 0) {
+		/* If a hart is disabled, create a no-op irq domain.  Devices
+		 * may still have interrupts connected to those harts.  This is
+		 * not wrong... unless they actually load a driver that needs
+		 * it!
+		 */
+		irq_domain_add_linear(
+			node,
+			8*sizeof(uintptr_t),
+			&riscv_irqdomain_ops_noop,
+			node->parent);
+		return 0;
+	}
+
+	data = &per_cpu(riscv_irq_data, hart);
+	snprintf(data->name, sizeof(data->name), "riscv,cpu_intc,%d", hart);
+	data->hart = hart;
+	data->chip.name = data->name;
+	data->chip.irq_mask = riscv_irq_mask;
+	data->chip.irq_unmask = riscv_irq_unmask;
+	data->chip.irq_enable = riscv_irq_enable;
+	data->chip.irq_disable = riscv_irq_disable;
+	data->domain = irq_domain_add_linear(
+		node,
+		8*sizeof(uintptr_t),
+		&riscv_irqdomain_ops,
+		data);
+	WARN_ON(!data->domain);
+	printk(KERN_INFO "%s: %d local interrupts mapped\n",
+	       data->name, 8*(int)sizeof(uintptr_t));
+	return 0;
+}
+
+IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init);
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]

#1659459 — Re: [PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver

CC irqchip folks

On Wed, Jun 7, 2017 at 1:00 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> This patch adds a driver that manages the local interrupts on each
> RISC-V hart, as specifiec by the RISC-V supervisor level ISA manual.
> The local interrupt controller manages software interrupts, timer
> interrupts, and hardware interrupts (which are routed via the
> platform level interrupt controller).  Per-hart local interrupt
> controllers are found on all RISC-V systems.
>
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> ---
>  drivers/irqchip/Kconfig          |  14 +++
>  drivers/irqchip/Makefile         |   1 +
>  drivers/irqchip/irq-riscv-intc.c | 239 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 254 insertions(+)
>  create mode 100644 drivers/irqchip/irq-riscv-intc.c
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 2906d63934ef..dfde170e5886 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -313,3 +313,17 @@ config RISCV_PLIC
>            interrupt sources (MSI, GPIO, etc) are subordinate to the PLIC.
>
>            If you don't know what to do here, say Y.
> +
> +config RISCV_INTC
> +       def_bool y if RISCV
> +       #bool "RISC-V Interrupt Controller"
> +       depends on RISCV
> +       default y
> +       help
> +          This enables support for the local interrupt controller found in
> +          standard RISC-V systems.  The local interrupt controller handles
> +          timer interrupts, software interrupts, and hardware interrupts.
> +          Without a local interrupt controller the system will be unable to
> +          handle any interrupts, including those passed via the PLIC.
> +
> +          If you don't know what to do here, say Y.
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index bed94cc89146..bc9a6b45903b 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -77,3 +77,4 @@ obj-$(CONFIG_ARCH_ASPEED)             += irq-aspeed-vic.o
>  obj-$(CONFIG_STM32_EXTI)               += irq-stm32-exti.o
>  obj-$(CONFIG_QCOM_IRQ_COMBINER)                += qcom-irq-combiner.o
>  obj-$(CONFIG_RISCV_PLIC)               += irq-riscv-plic.o
> +obj-$(CONFIG_RISCV_INTC)               += irq-riscv-intc.o
> diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> new file mode 100644
> index 000000000000..8150a035aada
> --- /dev/null
> +++ b/drivers/irqchip/irq-riscv-intc.c
> @@ -0,0 +1,239 @@
> +/*
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + *
> + *   This program is free software; you can redistribute it and/or
> + *   modify it under the terms of the GNU General Public License
> + *   as published by the Free Software Foundation, version 2.
> + *
> + *   This program is distributed in the hope that it will be useful,
> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *   GNU General Public License for more details.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/interrupt.h>
> +#include <linux/ftrace.h>
> +#include <linux/of.h>
> +#include <linux/seq_file.h>
> +
> +#include <asm/ptrace.h>
> +#include <asm/sbi.h>
> +#include <asm/smp.h>
> +
> +struct riscv_irq_data {
> +       struct irq_chip         chip;
> +       struct irq_domain       *domain;
> +       int                     hart;
> +       char                    name[20];
> +};
> +DEFINE_PER_CPU(struct riscv_irq_data, riscv_irq_data);
> +DEFINE_PER_CPU(atomic_long_t, riscv_early_sie);
> +
> +static void riscv_software_interrupt(void)
> +{
> +#ifdef CONFIG_SMP
> +       irqreturn_t ret;
> +
> +       ret = handle_ipi();
> +       if (ret != IRQ_NONE)
> +               return;
> +#endif
> +
> +       BUG();
> +}
> +
> +asmlinkage void __irq_entry do_IRQ(unsigned int cause, struct pt_regs *regs)
> +{
> +       struct pt_regs *old_regs = set_irq_regs(regs);
> +       struct irq_domain *domain;
> +
> +       irq_enter();
> +
> +       /* There are three classes of interrupt: timer, software, and
> +        * external devices.  We dispatch between them here.  External
> +        * device interrupts use the generic IRQ mechanisms.
> +        */
> +       switch (cause) {
> +       case INTERRUPT_CAUSE_TIMER:
> +               riscv_timer_interrupt();
> +               break;
> +       case INTERRUPT_CAUSE_SOFTWARE:
> +               riscv_software_interrupt();
> +               break;
> +       default:
> +               domain = per_cpu(riscv_irq_data, smp_processor_id()).domain;
> +               generic_handle_irq(irq_find_mapping(domain, cause));
> +               break;
> +       }
> +
> +       irq_exit();
> +       set_irq_regs(old_regs);
> +}
> +
> +static int riscv_irqdomain_map(struct irq_domain *d, unsigned int irq,
> +                              irq_hw_number_t hwirq)
> +{
> +       struct riscv_irq_data *data = d->host_data;
> +
> +       irq_set_chip_and_handler(irq, &data->chip, handle_simple_irq);
> +       irq_set_chip_data(irq, data);
> +       irq_set_noprobe(irq);
> +
> +       return 0;
> +}
> +
> +static const struct irq_domain_ops riscv_irqdomain_ops = {
> +       .map    = riscv_irqdomain_map,
> +       .xlate  = irq_domain_xlate_onecell,
> +};
> +
> +static void riscv_irq_mask(struct irq_data *d)
> +{
> +       struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
> +
> +       BUG_ON(smp_processor_id() != data->hart);
> +       csr_clear(sie, 1 << (long)d->hwirq);
> +}
> +
> +static void riscv_irq_unmask(struct irq_data *d)
> +{
> +       struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
> +
> +       BUG_ON(smp_processor_id() != data->hart);
> +       csr_set(sie, 1 << (long)d->hwirq);
> +}
> +
> +static void riscv_irq_enable_helper(void *d)
> +{
> +       riscv_irq_unmask(d);
> +}
> +
> +static void riscv_irq_enable(struct irq_data *d)
> +{
> +       struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
> +
> +       /* There are two phases to setting up an interrupt: first we set a bit
> +        * in this bookkeeping structure, which is used by trap_init to
> +        * initialize SIE for each hart as it comes up.
> +        */
> +       atomic_long_or((1 << (long)d->hwirq),
> +                      &per_cpu(riscv_early_sie, data->hart));
> +
> +       /* The CPU is usually online, so here we just attempt to enable the
> +        * interrupt by writing SIE directly.  We need to write SIE on the
> +        * correct hart, which might be another hart.
> +        */
> +       if (data->hart == smp_processor_id())
> +               riscv_irq_unmask(d);
> +       else if (cpu_online(data->hart))
> +               smp_call_function_single(data->hart,
> +                                        riscv_irq_enable_helper,
> +                                        d,
> +                                        true);
> +}
> +
> +static void riscv_irq_disable_helper(void *d)
> +{
> +       riscv_irq_mask(d);
> +}
> +
> +static void riscv_irq_disable(struct irq_data *d)
> +{
> +       struct riscv_irq_data *data = irq_data_get_irq_chip_data(d);
> +
> +       /* This is the mirror of riscv_irq_enable. */
> +       atomic_long_and(~(1 << (long)d->hwirq),
> +                       &per_cpu(riscv_early_sie, data->hart));
> +       if (data->hart == smp_processor_id())
> +               riscv_irq_mask(d);
> +       else if (cpu_online(data->hart))
> +               smp_call_function_single(data->hart,
> +                                        riscv_irq_disable_helper,
> +                                        d,
> +                                        true);
> +}
> +
> +static void riscv_irq_mask_noop(struct irq_data *d) { }
> +
> +static void riscv_irq_unmask_noop(struct irq_data *d) { }
> +
> +static void riscv_irq_enable_noop(struct irq_data *d)
> +{
> +       struct device_node *data = irq_data_get_irq_chip_data(d);
> +       u32 hart;
> +
> +       if (!of_property_read_u32(data, "reg", &hart))
> +               printk(
> +                 KERN_WARNING "enabled interrupt %d for missing hart %d (this interrupt has no handler)\n",
> +                 (int)d->hwirq, hart);
> +}
> +
> +static struct irq_chip riscv_noop_chip = {
> +       .name = "riscv,cpu-intc,noop",
> +       .irq_mask = riscv_irq_mask_noop,
> +       .irq_unmask = riscv_irq_unmask_noop,
> +       .irq_enable = riscv_irq_enable_noop,
> +};
> +
> +static int riscv_irqdomain_map_noop(struct irq_domain *d, unsigned int irq,
> +                                   irq_hw_number_t hwirq)
> +{
> +       struct device_node *data = d->host_data;
> +
> +       irq_set_chip_and_handler(irq, &riscv_noop_chip, handle_simple_irq);
> +       irq_set_chip_data(irq, data);
> +       return 0;
> +}
> +
> +static const struct irq_domain_ops riscv_irqdomain_ops_noop = {
> +       .map    = riscv_irqdomain_map_noop,
> +       .xlate  = irq_domain_xlate_onecell,
> +};
> +
> +static int riscv_intc_init(struct device_node *node, struct device_node *parent)
> +{
> +       int hart;
> +       struct riscv_irq_data *data;
> +
> +       if (parent)
> +               return 0;
> +
> +       hart = riscv_of_processor_hart(node->parent);
> +       if (hart < 0) {
> +               /* If a hart is disabled, create a no-op irq domain.  Devices
> +                * may still have interrupts connected to those harts.  This is
> +                * not wrong... unless they actually load a driver that needs
> +                * it!
> +                */
> +               irq_domain_add_linear(
> +                       node,
> +                       8*sizeof(uintptr_t),
> +                       &riscv_irqdomain_ops_noop,
> +                       node->parent);
> +               return 0;
> +       }
> +
> +       data = &per_cpu(riscv_irq_data, hart);
> +       snprintf(data->name, sizeof(data->name), "riscv,cpu_intc,%d", hart);
> +       data->hart = hart;
> +       data->chip.name = data->name;
> +       data->chip.irq_mask = riscv_irq_mask;
> +       data->chip.irq_unmask = riscv_irq_unmask;
> +       data->chip.irq_enable = riscv_irq_enable;
> +       data->chip.irq_disable = riscv_irq_disable;
> +       data->domain = irq_domain_add_linear(
> +               node,
> +               8*sizeof(uintptr_t),
> +               &riscv_irqdomain_ops,
> +               data);
> +       WARN_ON(!data->domain);
> +       printk(KERN_INFO "%s: %d local interrupts mapped\n",
> +              data->name, 8*(int)sizeof(uintptr_t));
> +       return 0;
> +}
> +
> +IRQCHIP_DECLARE(riscv, "riscv,cpu-intc", riscv_intc_init);
> --
> 2.13.0

[toc] | [prev] | [next] | [standalone]

#1659285 — [PATCH 01/17] drivers: support PCIe in RISCV

From: "Wesley W. Terpstra" <wesley@sifive.com>

There are RISC-V systems that have been mapped to Xilinx FPGAs that have
their PCIe controllers on chip.  These build system changes allow RISC-V
systems to enable the Xilinx PCIe controller, and to setup PCIe IRQs.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
---
 drivers/pci/Makefile     | 1 +
 drivers/pci/host/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 462c1f5f5546..a29d9ec05d13 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_MIPS) += setup-irq.o
 obj-$(CONFIG_TILE) += setup-irq.o
 obj-$(CONFIG_SPARC_LEON) += setup-irq.o
 obj-$(CONFIG_M68K) += setup-irq.o
+obj-$(CONFIG_RISCV) += setup-irq.o
 
 #
 # ACPI Related PCI FW Functions
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 7f47cd5e10a5..5148f3d3cab7 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -71,7 +71,7 @@ config PCI_HOST_GENERIC
 
 config PCIE_XILINX
 	bool "Xilinx AXI PCIe host bridge support"
-	depends on ARCH_ZYNQ || MICROBLAZE
+	depends on ARCH_ZYNQ || MICROBLAZE || RISCV
 	help
 	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
 	  Host Bridge driver.
-- 
2.13.0

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web