From: Rob Herring <robh@kernel.org> To: Rich Felker <dalias@libc.org> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, SH-Linux <linux-sh@vger.kernel.org>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>, Pawel Moll <pawel.moll@arm.com> Subject: Re: [PATCH v2 02/12] of: add J-Core cpu bindings Date: Mon, 23 May 2016 23:29:48 +0000 [thread overview] Message-ID: <CAL_JsqK0O2RY5PO9vHuOPjimRb34n8RwXMa7c8xmbY7Oh7D2Xg@mail.gmail.com> (raw) In-Reply-To: <20160523210328.GE21636@brightrain.aerifal.cx> On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: > On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >> > Signed-off-by: Rich Felker <dalias@libc.org> >> > --- >> > Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >> > 1 file changed, 91 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >> > >> > diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >> > new file mode 100644 >> > index 0000000..00ef112 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >> > @@ -0,0 +1,91 @@ >> > +=========>> > +J-Core cpu bindings >> > +=========>> > + >> > +The J-Core processors are open source CPU cores that can be built as FPGA >> > +soft cores or ASICs. The device tree is also responsible for describing the >> > +cache controls and, for SMP configurations, all details of the SMP method, >> > +as documented below. >> > + >> > + >> > +--------------------- >> > +Top-level "cpus" node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- #address-cells: Must be 1. >> > + >> > +- #size-cells: Must be 0. >> > + >> > +Optional properties: >> > + >> > +- enable-method: Required only for SMP systems. If present, must be >> > + "jcore,spin-table". >> > + >> > + >> > +-------------------- >> > +Individual cpu nodes >> > +-------------------- >> > + >> > +Required properties: >> > + >> > +- device_type: Must be "cpu". >> > + >> > +- compatible: Must be "jcore,j2". >> >> Okay to have this, but you should have compatible strings for specific >> core implementations. AIUI, J2 is just the ISA. > > There was some past discussion you probably missed on the linux-sh > list, starting here: > > http://www.spinics.net/lists/linux-sh/msg50028.html > > Basically it's really hard to identify what "the specific core > implementation" even means with a soft core. If you have some ideas > I'd be happy to hear them, but I think there should always be a > "jcore,j2" fallback compatible tag in any case. Presumably you do some sort of versioning on the VHDL source that you can correlate to. If you have sufficient s/w accessible version registers that are always going to be updated on IP changes then, you don't really need more specific compatible strings. > FYI the way we're trying to use DT is to avoid hard-coding any > properties about the SoC (like mmio register addresses, cache > properties, etc.) in the cpu compatible tag, and instead breaking > things down into as many device nodes as possible, to allow variations > to be represented without having to encode them in the kernel/driver > sources. Yes, that is the purpose of DT. >> > +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based >> > + hardware cpu id on SMP systems. >> > + >> > +Optional properties: >> > + >> > +- clock-frequency: Clock frequency of the cpu in Hz. >> > + >> > +- cpu-release-addr: Necessary only for secondary processors on SMP systems >> > + using the "jcore,spin-table" enable method. If present, must consist of >> > + two cells containing physical addresses. The first cell contains an >> > + address which, when written, unblocks the secondary cpu. The second cell >> > + contains an address from which the cpu will read its initial program >> > + counter when unblocked. >> > + >> > + >> > +--------------------- >> > +Cache controller node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,cache". >> >> That's pretty generic... > > Most of the DT compatible tags were derived from the component > directory/source-file names in the J-Core source. In the case of > cache, it's actually called "icache" in the source for historical > reasons despite also including dcache, so I just used "cache" in the > DT. > >> > + >> > +- reg: A memory range for the cache controller registers. >> >> And standard cache properties? Are size, sets, ways, line size, etc. >> discoverable? > > I want to do the cache properties in a way that's generic for all of > arch/sh rather than specific to J2, but that's going to be part of the > DT conversion project. That's why I just have properties hard-coded > for now in the kernel source. They're not really used anyway except > for presenting them in /proc/cpuinfo. The DT spec (devicetree.org, formerly ePAPR) already defines arch independent cache properties. >> > +-------- >> > +IPI node >> > +-------- >> > + >> > +Device trees for SMP systems must have an IPI node representing the mechanism >> > +used for inter-processor interrupt generation. >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,ipi-controller". >> >> Again, seems pretty generic. > > I'm open to different ideas for naming schemes, but in the big scheme > of things it doesn't really matter. When there's a new incompatible > one, it can have a new compatible tag. It should make sense according to how you version the VHDL sources. The Xilinx folks have X.Y version numbers for example. We generally don't accept those, but for soft IP that is an exception. Better yet, since you can change "the hardware", make it more discoverable with registers for version numbering and feature bits. The failure here is having a process where that can be forgotten... >> > +---------- >> > +CPUID node >> > +---------- >> > + >> > +Device trees for SMP systems must have a CPUID node representing the mechanism >> > +used to identify the current processor on which execution is taking place. >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,cpuid-mmio". >> > + >> > +- reg: A memory range containing a single 32-bit mmio register which produces >> > + the current cpu id when read. >> >> This id matches the reg value in cpu node, right? If not, it should. > > Yes. Should I document that here? Yes. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Rich Felker <dalias@libc.org> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, SH-Linux <linux-sh@vger.kernel.org>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>, Pawel Moll <pawel.moll@arm.com> Subject: Re: [PATCH v2 02/12] of: add J-Core cpu bindings Date: Mon, 23 May 2016 18:29:48 -0500 [thread overview] Message-ID: <CAL_JsqK0O2RY5PO9vHuOPjimRb34n8RwXMa7c8xmbY7Oh7D2Xg@mail.gmail.com> (raw) In-Reply-To: <20160523210328.GE21636@brightrain.aerifal.cx> On Mon, May 23, 2016 at 4:03 PM, Rich Felker <dalias@libc.org> wrote: > On Mon, May 23, 2016 at 03:48:46PM -0500, Rob Herring wrote: >> On Fri, May 20, 2016 at 02:53:03AM +0000, Rich Felker wrote: >> > Signed-off-by: Rich Felker <dalias@libc.org> >> > --- >> > Documentation/devicetree/bindings/jcore/cpus.txt | 91 ++++++++++++++++++++++++ >> > 1 file changed, 91 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/jcore/cpus.txt >> > >> > diff --git a/Documentation/devicetree/bindings/jcore/cpus.txt b/Documentation/devicetree/bindings/jcore/cpus.txt >> > new file mode 100644 >> > index 0000000..00ef112 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/jcore/cpus.txt >> > @@ -0,0 +1,91 @@ >> > +=================== >> > +J-Core cpu bindings >> > +=================== >> > + >> > +The J-Core processors are open source CPU cores that can be built as FPGA >> > +soft cores or ASICs. The device tree is also responsible for describing the >> > +cache controls and, for SMP configurations, all details of the SMP method, >> > +as documented below. >> > + >> > + >> > +--------------------- >> > +Top-level "cpus" node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- #address-cells: Must be 1. >> > + >> > +- #size-cells: Must be 0. >> > + >> > +Optional properties: >> > + >> > +- enable-method: Required only for SMP systems. If present, must be >> > + "jcore,spin-table". >> > + >> > + >> > +-------------------- >> > +Individual cpu nodes >> > +-------------------- >> > + >> > +Required properties: >> > + >> > +- device_type: Must be "cpu". >> > + >> > +- compatible: Must be "jcore,j2". >> >> Okay to have this, but you should have compatible strings for specific >> core implementations. AIUI, J2 is just the ISA. > > There was some past discussion you probably missed on the linux-sh > list, starting here: > > http://www.spinics.net/lists/linux-sh/msg50028.html > > Basically it's really hard to identify what "the specific core > implementation" even means with a soft core. If you have some ideas > I'd be happy to hear them, but I think there should always be a > "jcore,j2" fallback compatible tag in any case. Presumably you do some sort of versioning on the VHDL source that you can correlate to. If you have sufficient s/w accessible version registers that are always going to be updated on IP changes then, you don't really need more specific compatible strings. > FYI the way we're trying to use DT is to avoid hard-coding any > properties about the SoC (like mmio register addresses, cache > properties, etc.) in the cpu compatible tag, and instead breaking > things down into as many device nodes as possible, to allow variations > to be represented without having to encode them in the kernel/driver > sources. Yes, that is the purpose of DT. >> > +- reg: Must be 0 on uniprocessor systems, or the sequential, zero-based >> > + hardware cpu id on SMP systems. >> > + >> > +Optional properties: >> > + >> > +- clock-frequency: Clock frequency of the cpu in Hz. >> > + >> > +- cpu-release-addr: Necessary only for secondary processors on SMP systems >> > + using the "jcore,spin-table" enable method. If present, must consist of >> > + two cells containing physical addresses. The first cell contains an >> > + address which, when written, unblocks the secondary cpu. The second cell >> > + contains an address from which the cpu will read its initial program >> > + counter when unblocked. >> > + >> > + >> > +--------------------- >> > +Cache controller node >> > +--------------------- >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,cache". >> >> That's pretty generic... > > Most of the DT compatible tags were derived from the component > directory/source-file names in the J-Core source. In the case of > cache, it's actually called "icache" in the source for historical > reasons despite also including dcache, so I just used "cache" in the > DT. > >> > + >> > +- reg: A memory range for the cache controller registers. >> >> And standard cache properties? Are size, sets, ways, line size, etc. >> discoverable? > > I want to do the cache properties in a way that's generic for all of > arch/sh rather than specific to J2, but that's going to be part of the > DT conversion project. That's why I just have properties hard-coded > for now in the kernel source. They're not really used anyway except > for presenting them in /proc/cpuinfo. The DT spec (devicetree.org, formerly ePAPR) already defines arch independent cache properties. >> > +-------- >> > +IPI node >> > +-------- >> > + >> > +Device trees for SMP systems must have an IPI node representing the mechanism >> > +used for inter-processor interrupt generation. >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,ipi-controller". >> >> Again, seems pretty generic. > > I'm open to different ideas for naming schemes, but in the big scheme > of things it doesn't really matter. When there's a new incompatible > one, it can have a new compatible tag. It should make sense according to how you version the VHDL sources. The Xilinx folks have X.Y version numbers for example. We generally don't accept those, but for soft IP that is an exception. Better yet, since you can change "the hardware", make it more discoverable with registers for version numbering and feature bits. The failure here is having a process where that can be forgotten... >> > +---------- >> > +CPUID node >> > +---------- >> > + >> > +Device trees for SMP systems must have a CPUID node representing the mechanism >> > +used to identify the current processor on which execution is taking place. >> > + >> > +Required properties: >> > + >> > +- compatible: Must be "jcore,cpuid-mmio". >> > + >> > +- reg: A memory range containing a single 32-bit mmio register which produces >> > + the current cpu id when read. >> >> This id matches the reg value in cpu node, right? If not, it should. > > Yes. Should I document that here? Yes. Rob
next prev parent reply other threads:[~2016-05-23 23:29 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-20 2:53 [PATCH v2 00/12] J-core J2 cpu and SoC peripherals support Rich Felker 2016-05-20 2:53 ` [PATCH v2 02/12] of: add J-Core cpu bindings Rich Felker 2016-05-20 2:53 ` Rich Felker [not found] ` <f3c89e4834665790ff13478c571cc9aaa9de5559.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-23 20:48 ` Rob Herring 2016-05-23 20:48 ` Rob Herring 2016-05-23 20:48 ` Rob Herring 2016-05-23 21:03 ` Rich Felker 2016-05-23 21:03 ` Rich Felker 2016-05-23 23:29 ` Rob Herring [this message] 2016-05-23 23:29 ` Rob Herring 2016-05-24 2:39 ` Rich Felker 2016-05-24 2:39 ` Rich Felker 2016-05-24 21:30 ` Rob Landley 2016-05-24 21:30 ` Rob Landley 2016-05-25 1:13 ` Rob Herring 2016-05-25 1:13 ` Rob Herring 2016-05-25 2:33 ` Rich Felker 2016-05-25 2:33 ` Rich Felker 2016-05-25 13:13 ` Rob Herring 2016-05-25 13:13 ` Rob Herring 2016-05-20 2:53 ` [PATCH v2 03/12] of: add J-Core interrupt controller bindings Rich Felker 2016-05-20 8:04 ` Geert Uytterhoeven 2016-05-20 8:04 ` Geert Uytterhoeven [not found] ` <CAMuHMdVs9=8BGwmCBuYch2abJBnCLKoEx7i3EMghW3UUjXc7dA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-20 22:34 ` Rich Felker 2016-05-20 22:34 ` Rich Felker 2016-05-20 22:34 ` Rich Felker 2016-05-21 18:07 ` Geert Uytterhoeven 2016-05-21 18:07 ` Geert Uytterhoeven 2016-05-21 19:17 ` Rich Felker 2016-05-21 19:17 ` Rich Felker 2016-05-23 20:53 ` Rob Herring 2016-05-23 20:53 ` Rob Herring 2016-05-23 21:13 ` Rich Felker 2016-05-23 21:13 ` Rich Felker 2016-05-23 21:13 ` Rich Felker [not found] ` <20160523211342.GG21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-24 8:09 ` Marc Zyngier 2016-05-24 8:09 ` Marc Zyngier 2016-05-24 8:09 ` Marc Zyngier [not found] ` <57440C45.5040105-5wv7dgnIgG8@public.gmane.org> 2016-05-25 2:25 ` Rich Felker 2016-05-25 2:25 ` Rich Felker 2016-05-25 2:25 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 08/12] irqchip: add J-Core AIC driver Rich Felker 2016-05-20 8:08 ` Geert Uytterhoeven 2016-05-20 8:08 ` Geert Uytterhoeven 2016-05-20 8:15 ` Marc Zyngier 2016-05-20 8:15 ` Marc Zyngier 2016-05-25 4:29 ` Rich Felker 2016-05-25 4:29 ` Rich Felker [not found] ` <cover.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-20 2:53 ` [PATCH v2 01/12] of: add vendor prefix for J-Core Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-23 20:49 ` Rob Herring 2016-05-23 20:49 ` Rob Herring 2016-05-20 2:53 ` [PATCH v2 12/12] sh: add device tree source for J2 FPGA on Mimas v2 board Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` Rich Felker [not found] ` <9960d6526523727d1bee3d11c6704e09e600c6fe.1463708766.git.dalias-8zAoT0mYgF4@public.gmane.org> 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 8:17 ` Geert Uytterhoeven 2016-05-20 22:42 ` Rich Felker 2016-05-20 22:42 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 06/12] sh: add support for J-Core J2 processor Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 11/12] sh: add defconfig for J-Core J2 Rich Felker 2016-05-20 2:53 ` [PATCH v2 04/12] of: add J-Core timer bindings Rich Felker 2016-05-20 8:03 ` Geert Uytterhoeven 2016-05-20 8:03 ` Geert Uytterhoeven 2016-05-20 2:53 ` [PATCH v2 09/12] clocksource: add J-Core PIT/RTC driver Rich Felker 2016-05-20 14:01 ` Daniel Lezcano 2016-05-20 14:01 ` Daniel Lezcano 2016-05-21 3:15 ` Rich Felker 2016-05-21 3:15 ` Rich Felker 2016-05-21 15:55 ` Rob Landley 2016-05-21 15:55 ` Rob Landley 2016-05-23 20:32 ` Daniel Lezcano 2016-05-23 20:32 ` Daniel Lezcano 2016-05-24 2:25 ` Rich Felker 2016-05-24 2:25 ` Rich Felker 2016-05-20 2:53 ` [PATCH v2 10/12] spi: add driver for J-Core SPI controller Rich Felker 2016-05-20 2:53 ` Rich Felker 2016-05-20 8:15 ` Geert Uytterhoeven 2016-05-20 8:15 ` Geert Uytterhoeven 2016-05-20 22:50 ` Rich Felker 2016-05-20 22:50 ` Rich Felker 2016-05-20 10:23 ` Mark Brown 2016-05-20 10:23 ` Mark Brown 2016-05-20 23:24 ` Rich Felker 2016-05-20 23:24 ` Rich Felker 2016-05-23 15:30 ` Mark Brown 2016-05-23 15:30 ` Mark Brown 2016-05-23 20:29 ` Rich Felker 2016-05-23 20:29 ` Rich Felker [not found] ` <20160523202938.GD21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-23 22:11 ` Mark Brown 2016-05-23 22:11 ` Mark Brown 2016-05-23 22:11 ` Mark Brown 2016-05-20 2:53 ` [PATCH v2 07/12] sh: add AT_HWCAP flag for J-Core cas.l instruction Rich Felker 2016-05-20 2:53 ` [PATCH v2 05/12] of: add J-Core SPI master bindings Rich Felker 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-20 8:05 ` Geert Uytterhoeven 2016-05-23 21:00 ` Rob Herring 2016-05-23 21:00 ` Rob Herring 2016-05-23 21:06 ` Rich Felker 2016-05-23 21:06 ` Rich Felker [not found] ` <20160523210618.GF21636-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org> 2016-05-23 23:16 ` Rob Herring 2016-05-23 23:16 ` Rob Herring 2016-05-23 23:16 ` Rob Herring
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=CAL_JsqK0O2RY5PO9vHuOPjimRb34n8RwXMa7c8xmbY7Oh7D2Xg@mail.gmail.com \ --to=robh@kernel.org \ --cc=dalias@libc.org \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=pawel.moll@arm.com \ /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.