From: Wesley Terpstra <wesley@sifive.com> To: Mark Rutland <mark.rutland@arm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org>, Palmer Dabbelt <palmer@dabbelt.com>, Linux-Arch <linux-arch@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>, Albert Ou <albert@sifive.com>, patches@groups.riscv.org, Thomas Gleixner <tglx@linutronix.de>, Jason Cooper <jason@lakedaemon.net>, Marc Zyngier <Marc.Zyngier@arm.com>, Rob Herring <robh+dt@kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Date: Fri, 9 Jun 2017 14:46:28 -0700 [thread overview] Message-ID: <CAMgXwTgk0yY2WzqKGnriy+KR0+YqZJYLEBz_HStYq03d5C3QKQ@mail.gmail.com> (raw) In-Reply-To: <20170608105230.GC5765@leverpostej> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Wesley Terpstra <wesley-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org> To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> Cc: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>, Palmer Dabbelt <palmer-96lFi9zoCfxBDgjK7y7TUQ@public.gmane.org>, Linux-Arch <linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>, Albert Ou <albert-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>, patches-q3qR2WxjNRFS9aJRtSZj7A@public.gmane.org, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>, Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Date: Fri, 9 Jun 2017 14:46:28 -0700 [thread overview] Message-ID: <CAMgXwTgk0yY2WzqKGnriy+KR0+YqZJYLEBz_HStYq03d5C3QKQ@mail.gmail.com> (raw) In-Reply-To: <20170608105230.GC5765@leverpostej> On Thu, Jun 8, 2017 at 3:52 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-06-09 21:46 UTC|newest] Thread overview: 281+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-23 0:41 RISC-V Linux Port v1 Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Palmer Dabbelt 2017-05-23 11:30 ` Arnd Bergmann 2017-05-27 0:57 ` Palmer Dabbelt 2017-05-29 10:50 ` Arnd Bergmann 2017-06-06 4:56 ` Palmer Dabbelt 2017-06-06 17:39 ` Karsten Merker 2017-06-06 17:57 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 2/7] RISC-V: arch/riscv Makefile and Kconfigs Palmer Dabbelt 2017-05-23 1:27 ` Olof Johansson 2017-05-23 1:31 ` Randy Dunlap 2017-05-23 4:49 ` Palmer Dabbelt 2017-05-23 4:49 ` Palmer Dabbelt 2017-05-23 5:16 ` [patches] " Olof Johansson 2017-05-23 21:07 ` Benjamin Herrenschmidt 2017-05-23 5:23 ` Olof Johansson 2017-05-23 15:29 ` Palmer Dabbelt 2017-05-23 10:51 ` Geert Uytterhoeven 2017-05-25 1:59 ` Palmer Dabbelt 2017-05-23 11:46 ` Arnd Bergmann 2017-05-27 0:57 ` Palmer Dabbelt 2017-05-29 11:17 ` Arnd Bergmann 2017-06-06 4:56 ` Palmer Dabbelt 2017-06-06 9:20 ` Arnd Bergmann 2017-06-06 20:38 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 3/7] RISC-V: Device Tree Documentation Palmer Dabbelt 2017-05-23 12:03 ` Arnd Bergmann 2017-05-27 0:57 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 4/7] RISC-V: arch/riscv/include Palmer Dabbelt 2017-05-23 12:55 ` Arnd Bergmann 2017-05-23 21:23 ` Benjamin Herrenschmidt 2017-06-03 2:00 ` Palmer Dabbelt 2017-06-01 0:56 ` Palmer Dabbelt 2017-06-01 9:00 ` Arnd Bergmann 2017-06-06 4:56 ` Palmer Dabbelt 2017-06-06 8:54 ` Arnd Bergmann 2017-06-06 19:07 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 5/7] RISC-V: arch/riscv/lib Palmer Dabbelt 2017-05-23 10:47 ` Geert Uytterhoeven 2017-05-23 22:07 ` Palmer Dabbelt 2017-05-23 11:19 ` Arnd Bergmann 2017-05-25 1:59 ` Palmer Dabbelt 2017-05-26 9:06 ` Arnd Bergmann 2017-06-06 4:56 ` Palmer Dabbelt 2017-06-06 9:31 ` Arnd Bergmann 2017-06-06 20:53 ` Palmer Dabbelt 2017-06-07 7:35 ` Arnd Bergmann 2017-06-23 23:24 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 6/7] RISC-V: arch/riscv/kernel Palmer Dabbelt 2017-05-23 2:11 ` Olof Johansson 2017-05-25 1:59 ` Palmer Dabbelt 2017-05-25 19:51 ` Arnd Bergmann 2017-06-06 4:56 ` Palmer Dabbelt 2017-06-06 9:03 ` Arnd Bergmann 2017-06-06 20:38 ` Palmer Dabbelt 2017-05-23 13:35 ` Arnd Bergmann 2017-06-02 23:56 ` Palmer Dabbelt 2017-06-06 9:01 ` Arnd Bergmann 2017-06-06 20:37 ` Palmer Dabbelt 2017-05-25 17:05 ` Pavel Machek 2017-06-03 3:32 ` Palmer Dabbelt 2017-05-23 0:41 ` [PATCH 7/7] RISC-V: arch/riscv/mm Palmer Dabbelt 2017-05-23 1:28 ` Randy Dunlap 2017-05-23 2:17 ` Olof Johansson 2017-05-23 3:36 ` Palmer Dabbelt 2017-05-23 1:16 ` RISC-V Linux Port v1 Olof Johansson 2017-05-23 1:25 ` Randy Dunlap 2017-05-23 3:36 ` Palmer Dabbelt 2017-05-23 3:36 ` Palmer Dabbelt 2017-05-23 6:45 ` Tobias Klauser 2017-05-23 15:44 ` Palmer Dabbelt 2017-05-23 2:16 ` Randy Dunlap 2017-05-23 4:49 ` Palmer Dabbelt 2017-06-06 22:59 ` RISC-V Linux Port v2 Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 01/17] drivers: support PCIe in RISCV Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:17 ` Geert Uytterhoeven 2017-06-07 14:25 ` Christoph Hellwig [not found] ` <CAMgXwTjXZ5dsxmJ2FyWhCRWo-3nyvKUDfhfV0nNC+oakF=AEsA@mail.gmail.com> 2017-06-07 17:40 ` Olof Johansson 2017-06-23 21:47 ` [patches] " Palmer Dabbelt 2017-06-23 21:47 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 02/17] pcie-xilinx: add missing 5th legacy interrupt Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:18 ` Geert Uytterhoeven 2017-06-07 9:24 ` Marc Zyngier 2017-06-07 19:03 ` Wesley Terpstra 2017-06-06 22:59 ` [PATCH 03/17] base: fix order of OF initialization Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:07 ` Geert Uytterhoeven 2017-06-07 9:35 ` Mark Rutland 2017-06-07 9:35 ` Mark Rutland 2017-06-07 18:39 ` Wesley Terpstra 2017-06-07 21:10 ` Benjamin Herrenschmidt 2017-06-08 3:49 ` Frank Rowand 2017-06-08 9:05 ` Mark Rutland 2017-06-08 9:05 ` Mark Rutland 2017-06-08 9:05 ` Mark Rutland 2017-06-09 0:37 ` Frank Rowand 2017-06-06 22:59 ` [PATCH 04/17] Documentation: atomic_ops.txt is core-api/atomic_ops.rst Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:19 ` Geert Uytterhoeven 2017-06-07 9:20 ` Will Deacon 2017-06-06 22:59 ` [PATCH 05/17] MAINTAINERS: Add RISC-V Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 06/17] pci: Add generic pcibios_{fixup_bus,align_resource} Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:19 ` Geert Uytterhoeven 2017-06-07 8:01 ` Arnd Bergmann 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-08 8:12 ` Christoph Hellwig 2017-06-08 8:35 ` Arnd Bergmann 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 07/17] lib: Add shared copies of some GCC library routines Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 08/17] dts: include documentation for the RISC-V interrupt controllers Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:11 ` Geert Uytterhoeven 2017-06-07 10:13 ` Mark Rutland 2017-06-07 18:57 ` Wesley Terpstra 2017-06-07 19:57 ` Rob Herring 2017-06-07 20:31 ` Wesley Terpstra 2017-06-08 10:52 ` Mark Rutland 2017-06-09 21:46 ` Wesley Terpstra [this message] 2017-06-09 21:46 ` Wesley Terpstra 2017-06-09 21:58 ` Wesley Terpstra 2017-06-19 14:30 ` Mark Rutland 2017-06-07 22:27 ` Luis R. Rodriguez 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-06 22:59 ` [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource Palmer Dabbelt 2017-06-06 22:59 ` Palmer Dabbelt 2017-06-07 7:12 ` Geert Uytterhoeven 2017-06-07 7:25 ` Arnd Bergmann 2017-06-23 23:24 ` Palmer Dabbelt 2017-06-23 23:24 ` Palmer Dabbelt 2017-06-07 9:43 ` Marc Zyngier 2017-06-24 2:02 ` Palmer Dabbelt 2017-06-24 2:02 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 10/17] irqchip: New RISC-V PLIC Driver Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-07 7:13 ` Geert Uytterhoeven 2017-06-07 7:55 ` Arnd Bergmann 2017-06-24 0:45 ` Palmer Dabbelt 2017-06-24 0:45 ` Palmer Dabbelt 2017-06-07 10:52 ` Marc Zyngier 2017-06-09 13:47 ` Will Deacon 2017-06-27 1:09 ` Palmer Dabbelt 2017-06-27 1:09 ` Palmer Dabbelt 2017-06-25 20:49 ` Palmer Dabbelt 2017-06-25 20:49 ` Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 11/17] irqchip: RISC-V Local Interrupt Controller Driver Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-07 7:14 ` Geert Uytterhoeven 2017-06-06 23:00 ` [PATCH 12/17] tty: New RISC-V SBI Console Driver Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-07 7:15 ` Geert Uytterhoeven 2017-06-07 7:58 ` Arnd Bergmann 2017-06-24 0:45 ` Palmer Dabbelt 2017-06-24 0:45 ` Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 13/17] RISC-V: Add include subdirectory Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-07 8:12 ` Arnd Bergmann 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-24 2:01 ` Palmer Dabbelt 2017-06-24 15:42 ` Benjamin Herrenschmidt 2017-06-24 21:32 ` [patches] " Palmer Dabbelt 2017-06-24 21:32 ` Palmer Dabbelt 2017-06-25 3:01 ` Benjamin Herrenschmidt 2017-06-07 11:54 ` Peter Zijlstra 2017-06-07 12:25 ` Peter Zijlstra 2017-06-07 12:06 ` Peter Zijlstra 2017-06-07 12:18 ` Peter Zijlstra 2017-06-07 12:36 ` Peter Zijlstra 2017-06-07 12:58 ` Peter Zijlstra 2017-06-07 13:16 ` Will Deacon 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-27 0:07 ` Daniel Lustig 2017-06-27 8:48 ` Will Deacon 2017-06-07 16:35 ` Peter Zijlstra 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-07 12:42 ` Peter Zijlstra 2017-06-07 13:17 ` Peter Zijlstra 2017-06-09 8:16 ` Peter Zijlstra 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-26 20:07 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 14/17] RISC-V: lib files Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 15/17] RISC-V: Add mm subdirectory Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 16/17] RISC-V: Add kernel subdirectory Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` [PATCH 17/17] RISC-V: Makefile and Kconfig Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-06 23:00 ` Palmer Dabbelt 2017-06-07 9:23 ` RISC-V Linux Port v2 Will Deacon 2017-06-07 21:54 ` Palmer Dabbelt 2017-06-07 21:54 ` Palmer Dabbelt 2017-06-08 10:26 ` Will Deacon 2017-06-08 18:16 ` Palmer Dabbelt 2017-06-08 18:16 ` Palmer Dabbelt 2017-06-28 18:55 ` RISC-V Linux Port v3 Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 1/9] RISC-V: Init and Halt Code Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-29 9:44 ` Geert Uytterhoeven 2017-06-29 9:44 ` Geert Uytterhoeven 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 2/9] RISC-V: Atomic and Locking Code Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 3/9] RISC-V: Generic library routines and assembly Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 4/9] RISC-V: ELF and module implementation Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 5/9] RISC-V: Task implementation Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 23:32 ` James Hogan 2017-06-28 23:32 ` James Hogan 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-29 8:22 ` Tobias Klauser 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-29 8:39 ` Tobias Klauser 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-29 22:52 ` Palmer Dabbelt 2017-06-30 7:57 ` Tobias Klauser 2017-06-28 18:55 ` [PATCH 7/9] RISC-V: Paging and MMU Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 23:09 ` James Hogan 2017-06-28 23:09 ` James Hogan 2017-06-29 22:11 ` Palmer Dabbelt 2017-06-29 22:11 ` Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 8/9] RISC-V: User-facing API Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 21:49 ` Thomas Gleixner 2017-06-28 21:52 ` Thomas Gleixner 2017-06-29 17:22 ` Palmer Dabbelt 2017-06-29 17:22 ` Palmer Dabbelt 2017-06-28 22:42 ` James Hogan 2017-06-28 22:42 ` James Hogan 2017-06-29 21:42 ` Palmer Dabbelt 2017-06-29 21:42 ` Palmer Dabbelt 2017-07-03 23:06 ` James Hogan 2017-07-03 23:06 ` James Hogan 2017-07-05 16:49 ` Palmer Dabbelt 2017-07-05 16:49 ` Palmer Dabbelt 2017-06-28 18:55 ` [PATCH 9/9] RISC-V: Build Infastructure Palmer Dabbelt 2017-06-28 18:55 ` Palmer Dabbelt 2017-06-28 21:05 ` Karsten Merker 2017-06-28 21:13 ` Palmer Dabbelt 2017-06-28 21:13 ` Palmer Dabbelt 2017-06-28 21:25 ` James Hogan 2017-06-28 21:25 ` James Hogan 2017-06-29 16:29 ` Palmer Dabbelt 2017-06-29 16:29 ` Palmer Dabbelt 2017-06-28 22:54 ` James Hogan 2017-06-28 22:54 ` James Hogan 2017-06-29 22:11 ` Palmer Dabbelt 2017-06-29 22:11 ` Palmer Dabbelt 2017-06-06 22:59 ` RISC-V Linux Port v2 Palmer Dabbelt 2017-06-07 7:29 ` David Howells 2017-06-07 21:54 ` Palmer Dabbelt 2017-06-07 21:54 ` Palmer Dabbelt 2017-06-07 21:54 ` Palmer Dabbelt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMgXwTgk0yY2WzqKGnriy+KR0+YqZJYLEBz_HStYq03d5C3QKQ@mail.gmail.com \ --to=wesley@sifive.com \ --cc=Marc.Zyngier@arm.com \ --cc=albert@sifive.com \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=geert@linux-m68k.org \ --cc=jason@lakedaemon.net \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=olof@lixom.net \ --cc=palmer@dabbelt.com \ --cc=patches@groups.riscv.org \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.